صفحه 2 از 4 اولاول 1234 آخرآخر
نمایش نتایج 41 تا 80 از 139

نام تاپیک: گفتگوی فنی در مورد طراحی Database سیستم مالی

  1. #41
    کاربر تازه وارد
    تاریخ عضویت
    بهمن 1389
    محل زندگی
    ترکیه - دنیزلی
    پست
    63

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط حمیدرضاصادقیان مشاهده تاپیک
    خواص موجودیت اشخاص حقیقی :

    1- کد شخص
    2- نام شخص
    3- نام خانوادگی
    4- شماره تماس
    5- آدرس
    6- کد ملی
    7- کد پستی
    8- میزان اعتبار

    این موارد به نظر من دارای اهمیت می باشند.
    [/B][/I][/COLOR]
    آقای صادقیان عزیز
    من سیستمهای زیادی را دیده ام سراسر از فیلدهای اضافی و بدون استفاده است و در مواردی دیده ام که کاربران نیاز به فیلدی دارند که در سیستم تعریف نشده است و به اجبار مقدار آن را در یکی از فیلدهای اضافی ذخیره کرده اند. مثلاً شرکتی را در نظر بگیرید که از کد پستی استفاده نمیکند اما در عوض از آدرس ایمیل افراد استفاده میکند. در نتیجه کاربران مقدار آدرس ایمیل را در این فیلد ذخیره کرده اند.
    به نظر من بهترین فیلدهایی که میتوان برای اشخاص در نظر گرفت فیلدهای ارتباطی است. منظور من فیلدهایی است که به وسیله آن من بتوانم به آن فرد دسترسی پیدا کنم شامل:
    1- کد شخص
    2- نام شخص
    3- نام خانوادگی
    4- شماره تماس ثابت
    5- شماره همراه
    6- آدرس وب سایت
    7- آدرس ایمیل
    8- آدرس منزل
    9- توضیحات
    من این فیلدها را در تمام جداول اشخاص حقیقی و حقوقی و غیره تعریف میکنم.
    حال سوال این است که اگر شرکتی فرضاً نیاز داشت که کد ملی افراد و نام شرکتی که فرد در آن شاغل است را نیز در سیستم ذخیره کند. برای این موضوع چه کار کنیم آیا درست است سورس برنامه را باز کنیم و برای تک تک خواسته های مشتری اصلاحات انجام دهیم؟
    من اینکار را نکردم بلکه در عوض قدرت تعریف فیلد برحسب نیاز را به مشتریانم دادم به این صورت:
    ابتدا یک جدول تعریف کردم که کاربر میتواند در آن فیلدهای مورد نیازش را تعریف کند.
    سپس یک جدول کمکی(پیوست) برای جدول اشخاصم تعریف کردم که در آن سه فیلد داریم
    1: سریال فیلد مشتری(مثلاً سریال فیلد کد ملی)
    2: سریال شخص(یک از اشخاصی که در جدول اشخاص است)
    3: مقداری که برای این فیلد نوشته شده است( مثلاً: 1234567890)
    برای نمایش این اطلاعات نیز در کنار جدول اصلی ام یک جدول کوچک نیز قرارداده ام تا مشتری بتواند سایر اطلاعات فرد مورد نظر را در آن ببیند

    Tel.jpg
    البته من از تاریخ تولد در برنامه هام نیز استفاده میکنم چون از آن زیاد استفاده میکنم.
    برای مورد شماره همراه و شماره تلفن و آدرس ایمیل با توجه به آنکه افراد ممکن است بیش از یک شماره یا آدرس داشته باشند نیز آنها را در جداول کمکی دیگری که برای این منظور ایجاد کرده ام ذخیره میکنم تا با مستریانی که اعلام میکنند اشخاصشان چند شماره تماس دارند مشکلی نداشته باشم


  2. #42
    کاربر تازه وارد
    تاریخ عضویت
    بهمن 1389
    محل زندگی
    ترکیه - دنیزلی
    پست
    63

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط mohammadi4net مشاهده تاپیک
    مرکز هزینه رو میشه یک قسمت از حسابهای هزینه در نظر گرفت پس از موجودیت کد حساب حذف میشه.
    آقای محمدی عزیز سلام
    این موضوع که مرکز هزینه را میتوانیم یک قسمت از حسابهای هزینه در نظر گرفت برای موارد و شرکتهایی خوب است که تعداد مراکز هزینه کم و محدودی داشته باشند. در این صورت به فرموده شما میتوان به جای تعریف مرکز هزینه حساب هزینه مربوطه را تعریف کرد اما در مواردی که مراکز هزینه زیاد هستند چاره ای نداریم جز آنکه جایی را برای تعریف مرکز هزینه در نظر بگیریم.
    شما شرکتی را فرش کنید که 10 تا قسمت دارد و در هر قسمت 10 تا میز دارد و میخواهد به عنوان مثال هزینه چای و دستمال کاغذی و لوازم التحریر هر میز را جمع بندی کند. مطمئناً نمیتواند 100 حساب هزینه تعریف کند.
    در مورد حساب شناور منظور همین تفضیلی ها است. که در آن یک حساب معین میتواند به عنوان مثال از تفضیلی اشخاص (شناور در نظر بگیرید) بدهکار یا بستانکار بشود

  3. #43

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط Mahbod Rad مشاهده تاپیک
    آقای محمدی عزیز سلام
    این موضوع که مرکز هزینه را میتوانیم یک قسمت از حسابهای هزینه در نظر گرفت برای موارد و شرکتهایی خوب است که تعداد مراکز هزینه کم و محدودی داشته باشند. در این صورت به فرموده شما میتوان به جای تعریف مرکز هزینه حساب هزینه مربوطه را تعریف کرد اما در مواردی که مراکز هزینه زیاد هستند چاره ای نداریم جز آنکه جایی را برای تعریف مرکز هزینه در نظر بگیریم.
    شما شرکتی را فرش کنید که 10 تا قسمت دارد و در هر قسمت 10 تا میز دارد و میخواهد به عنوان مثال هزینه چای و دستمال کاغذی و لوازم التحریر هر میز را جمع بندی کند. مطمئناً نمیتواند 100 حساب هزینه تعریف کند.
    در مورد حساب شناور منظور همین تفضیلی ها است. که در آن یک حساب معین میتواند به عنوان مثال از تفضیلی اشخاص (شناور در نظر بگیرید) بدهکار یا بستانکار بشود
    ممنون که پاسخ دادید
    یعنی موقع سند زدن مرکز هزینه رو مشخص کنیم و هیچ ربطی به کدینگ نداره درست گفتم؟
    در مورد تفصیلی شناور من هنوز دو قرونیم کجه میشه با مثال توضیح بدین ....
    خوب من این مطالب رو پیدا کردم :
    کد تفصیلی شناور یا همون سطح چهارم و در بعضی از نرم افزار ها بعضاً پنجم و ششم ، شامل گروه هایی مانند نام اشخاص حقیقی و حقوقی ، طرف حساب ها ، قراردادها ، صورت وضعیت ها و غیره می باشد ،
    برای مثال شما حساب های کل و معین و تفصیلی های زیر را دارید ،
    گروه 1 دارایی های جاری
    حساب کل 12 حسابهای دریافتنی تجاری
    معین 1201 حساب های دریافتنی
    معین 1202 مطالبات مشکوک الوصول

    تفصیلی 20001 شرکت الف
    002005 آقای رضایی
    010020پیمانکاری صادقی

    شرکت الف از شما 100،000 ریال خرید نسیه انجام داده است
    حساب های دریافتنی
    1201 حساب های دریافتنی 100،000
    20001 شرکت الف
    فروش 100،000
    ---------------------------------------------------------------------------------------
    آقای رضایی هم از شما 20،000 ریال خرید انجام داده است
    حساب های دریافتنی
    1201 حساب های دریافتنی 100،000
    002005 آقای رضایی

    فروش 100،000
    ---------------------------------------------------------------------------------------
    مانده معین 1201 حساب های دریافتنی شما 120،000 ریال است و اگر حجم عملیات شما بالا باشد و با معین های متفاوتی سند بخورد ، برای اینکه بتوانید مانده حساب آقای رضایی را ببینید ، گزارش خود را بر اساس تفصیلی مورد نظر فی_لتر می نمایید و ابتدا تفصیلی 002005 را انتخاب کرده و سپس معین 1201 را ، در اینجا با یک گزارشگیری ساده مشاهده می کنید که مانده ی حساب دریافتنی از آقای رضایی 20،000 ریال می باشد .
    همچنین حساب معین فقط برای حساب کلی که در آن ایجاد شده می باشد ، اما حساب های تفصیلی شناور می باشند و می توانند با چندین معین درگیر شوند.

    در نرم افزار های قدیمی سطوح حساب به این ترتیب بود
    1 - گروه
    2 - کل
    3 - معین
    4 - تفصیل 1
    5 - تفصیل 2 و ...
    و شما برای این که مثلا برای آقای رضایی میخواستید حسابی باز کنید باید به نام ایشان در تمام حسابها ، حساب باز میکردید ، شاید ایشان هم تنخواه دار بودند ، هم صندوق دار ، هم بستانکار ، هم بدهکار و شما برای تمام اینها یک حساب جدا گانه باز میکردید و این 2 اشکال عمده داشت
    1 - گزارش گیری از تمام این حسابها سخت بود
    2 - هر بار افتتاح حساب برای این شخص در زیر مجموعه ها و حساب تفصیلی زمان بر و بیهوده بود
    در حال حاضر کدینگ شناور جایگزین گردیده یعنی شما مثلا کد 015 را به آقای رضائی مرتبط مینمائید و اگر این کد را در پایان هر یک از حسابها وارد نمائید اسم ایشان نمایان شده و به حساب ایشان ثبت میگردد .
    و اگر برای گزارش گیری فقط در قسمت مربوطه کد 015 را وارد نمائید ، سیستم هم مانده ها را میتواندتهاتر کند و بدهکاری و یا بستانکاری را اعلام نماید و هم تمام گردش حساب ایشان در سر فصلهای مختلف را میتواند گزارش دهد
    و در ادامه دوست دیگری اینجوری توضیح دادن :
    به نظر من كد تفصيلي شناور به سرفصلهايي اطلاق ميشه كه قابليت گردش در سمت چپ و راست ترازنامه را دارن . در حسابداري قديم يك عنوان حساب فقط مربوط به يك سمت بود مثلا آقاي اكبري فقط بدهكار بود يا جزء اشخاص بستانكار در غير اينصورت عدم ماهيت حساب ايجاد ميشد يعني اكبري كه در اشخاص بدهكار تعريف شده نميتونست براساس گردش حساب بستانكار بشه ولي در سيستمهاي امروزي يك حساب در كدينگ تعريف ميشه كه مانده حساب تعيين كننده جايگاه حسابه يعني اگه مانده بدهكاربود در سمت چپ اگه بستانكار بود در سمت راست قرار ميگيره.من با دوستمون اقاي ميرزا خاني تا يك جائي رو موافقم ولي اين تفصيلي شناور تو يك سرفصل حساب اتفاق ميوفته نه در چندين سرفصل حساب مثل اشخاص و تنخواه و .... .چيزي كه ميتونه ارتباط بين اين كدهاي ايجاد كنه كه در سرفصلهاي ديگه اي قرار دارند يك سري كدهاست كه براي گزارشات ازش استفاده ميشه مثل كد ربط حسابها كه در سطوح كل و معين و تفصيلي گزارشات كاملي در اختيارمون ميزاره

    سلام جناب پیرزاده ودوستان گرامی با تشکر ازهمه ولی اگه یه مثال جامع خوب دراین مورد بزنی خیلی ممنون میشم

    بعنوان مثال من يك كد حساب در كدينگ تعريف ميكنم اين كد چون هنوز مانده ندارد داراي ماهيت نيست اما وقتي من سندي براي اين كد ميزنم كه با اين سند مانده حساب كد بدهكار يا بستانكار ميشود پس براساس مانده كد در سمت چپ يا راست ترازنامه قرار ميگيره و اگه ثبت سند بعدي ماهيت اين كد را از بدهكار به بستانكار يا برعكس تغيير بده دوباره جايگاه كد در ترازنامه تغيير ميكنه . ما در حسابداري سمت چپ و راست ترازنامه رو با كدهاي گروه حسابها تفكيك ميكنيم مثلا دارائيهاي جاري كد گروه 1 دارند ولي كد كل و معين و تفصيلي يكسان ميباشد.بعنوان مثال اشخاص تجاري دريافتني در گروه 1 ( داراييهاي جاري ) قرار ميگيرد و اشخاص تجاري پرداختني در گروه 4 ( بدهي هاي جاري) پس وقتي مانده تغيير ميكند اين كد گروه حساب است كه تغيير ميكند نه كد كل و معن و تفصيلي . اين كدها ثابتند و كد گروه حساب متغير

    منبع
    آخرین ویرایش به وسیله mohammadi4net : یک شنبه 15 خرداد 1390 در 23:38 عصر دلیل: درج منبع

  4. #44
    کاربر تازه وارد
    تاریخ عضویت
    بهمن 1389
    محل زندگی
    ترکیه - دنیزلی
    پست
    63

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    محمدی عزیز سلام
    فکر میکنم بهترین کسی که میتواند در مورد حساب تفضیلی شناور توضیح دهد خود آقای صادقیان است که در ابتدای این تایپیک این نام را بکار برد. شاید در آخر همه متوجه شوند که در مورد یک پیز صحبت میکنند
    اما در مورد موجودیت اشخاص که آقای صادقیان فرمودند و منهم مواردی را بیان کردم به خواص آن فیلد فعال را نیز اضافه میکنم. چون بسیار پیش میآید که شرکتی با مشتریان قدیمی اش کار نمیکند و نمیخواهد در هر گزارش یا انتخاب افراد آنها را مشاهده کند.
    در ضمن ترجیح میدهم به جای فیلد اعتبار افراد مقدار اعتبار را در لحظه نیاز محاسبه کنم.
    در مورد مطالبی هم شما در بالا فرمودید در زمان تعریف موجودیت اسناد حسابداری پیشنهاد خودم را در مورد فیلدها بیان میکنم
    www.abshar-system.ir

  5. #45
    کاربر دائمی آواتار hossein_h62
    تاریخ عضویت
    فروردین 1388
    محل زندگی
    اصفهـــــان
    پست
    720

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    سلام
    من فکر میکنم بحث مرکز هزینه فعلا بی مورد هست چون مراکز هزینه یکی از گروههای تفصیل هستند، پس فعلا در بحث خواص موجودیت ها مثل سایر تفصیل ها هستند!
    در مورد حساب شناور منظور همین تفضیلی ها است. که در آن یک حساب معین میتواند به عنوان مثال از تفضیلی اشخاص (شناور در نظر بگیرید) بدهکار یا بستانکار بشود
    این تعریف مناسبی از حسابهای شناور نیست.تعریف شناور بودن یک حساب اینه که یک تفصیل میتونه با همه حسابهای معین با هر ماهیتی گردش پیدا کنه و به تعبیر دیگه حسابهای تفصیل یونیک خواهند بود.

  6. #46

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    سلام
    یه کاری رو شروع کردیم پس باید تا آخر بریم ، من با توجه به اینکه با کدینگ درختی کار کرده بودم هیچ درکی صحیحی از کدینگ شناور نداشتم و ناخودآگاه با ساختار درختی مقایسه می کردم ، امروز از حسابدار شرکت خواستم کدینگ شناور رو برام توضیح بده تا بلکه خدا دلش به رحم بیاد و دوقرونی ما رو راست کنه. در ضمن پست های قبلی رو پاک کردم تا دیگران رو گمراه نکنم.

    حساب ها در سطح های زیر ساخته میشه :
    گروه
    کل
    معین
    معین در معین(اینو تا حالا نشنیده بودم)

    بعد میایم گروه های تفضیلی رو تعریف می کنیم:
    اشخاص و موسسات
    مراکز هزینه
    بانکها
    و....

    بعد میایم زیر مجموعه گروه های تفصیلی حسابهای شناور تفصیلی رو تعریف می کنیم.

    موقع سند زدن ما حساب رو انتخاب می کنیم و اگه لازم شد حساب تفصیلی اون رو هم مشخص می کنیم.

    حالا سوال اینجاست که روابط بین حساب ها و گروه های تفصیلی چگونه مشخص می شود؟
    ببخشید زیاد سوال می پرسم به هر حال پرسیدن عیب نیست ، ندانستن عیب است.

  7. #47

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    خوب خداروشکر دوستان دارند مجدداً در این بحث شرکت میکنند.
    من اگر مقداری با تاخیر شرکت میکنم به دلیل مشغله زیاد هست ولی تمام تلاشمو میکنم تاپیک از تکاپو نیافته.
    بذارید من با یک مثال بحث تفصیلی شناور با تفصیلی پله ای رو کامل توضیح بدم.

    فرض کنید ما می خواهیم این سرفصل رو تعریف کنیم.

    توجه : من گروه حساب رو ذکر نمیکنم چون گروههای حساب ثابت هستند.

    1- موجودی نقد و بانک
    - بانکها
    - بانک صادرات
    - شعبه عباس آباد
    - جاری 12345
    - شعبه بلوار ناهید
    - جاری 101082
    - بانک ملی
    - شعبه گلفام
    - جاری 5210765
    - بانک تجارت
    - شعبه بلوار آفریقا
    - پس انداز 125436

    - صندوق
    - آقای محمدی
    - آقای کریمی
    - تنخواه گردان
    - آقای محمدی
    - آقای کریمی

    2- بستانکاران
    - بستانکاران حقوق
    - آقای محمدی
    - آقای کریمی


    خوب در اینجا من دو حساب کل دارم. که زیر مجموعه اون یک سری حساب معین تعریف شده و در زیر مجموعه اون تفصیلی ها تعریف شده است.
    در حساب نقد و بانک در زیر مجموعه تنخواه و صندوق میبینید یک سری اشخاص تعریف شده است که مشترک هستند. همین افراد نیز در حساب بستانکاران حقوق هستند.

    حالا اینجا تفاوت حساب تفصیلی پله ای و شناور کاملا مشهود هست.
    در حساب پله ای شمامجبورید به همین شکلی که بنده تعریف کردم حسابها رو تعریف کنید.
    خوب تا اینجا که مشکلی نیست. مشکل زمانی ایجاد خواهد شد که من بخوام یک گزارش تلفیقی از حساب آقای کریمی داشته باشم.
    اینجا به مشکل برخواهم خورد و مجبورم در برنامه مقداری کار خودمو سخت کنم.
    حالا این آقای کریمی ممکنه در حساب تنخواه گردان کد 1 رو داشته باشه و در حساب بستانکاران حقوق کد 10. اینجا دیگه نمیشه به این راحتی گزارشی تهیه کرد.
    حالا در حساب شناور شما تا سطح معین که همون حساب تنخواه- بانکها - بستانکاران حقوق هست رو به صورت پله ای تعریف می کنید.
    در قسمت تفصیلی شما ابتدا میاید اشخاص رو در زیرمجموعه اشخاص حقیقی تعریف میکنید و به هر حسابی میخواهید ارتباط می دهید. همه اینها با یک کد مشترک کار می کنند و یک شخص فقط یک جا تعریف می شود. اگر بخواهید نام اون شخص رو تغییر بدید فقط در یک جدول تغییر میدهید ولی در روش پلکانی مجبورید تمام جداول مرتبط رو تغییر بدید.
    همچنین وقتی بخواهید کلا گردش حساب آقای کریمی رو بگیرید کافیه در جداول سند فقط کد تفصیلی آقای کریمی که فرضا 1000 بهش اختصاص داده شده رو جستجو کنید.
    همین کار رو برای حساب بانکها و مابقی حسابها میشه پیاده سازی کرد.
    که حالا کاربر میتواند حسابهای خود را دسته بندی کند و هر حساب تفصیلی رو در گروه خودش قرار بده.مثلا مشتریان خودش رو تفکیک کنه.اشخاصی که باهاش در ارتباط هست رو تفکیک کنه و به حسابهای معین دلخواهش ارتباط بده.

    امیدوارم توضیحات واضح بوده باشه.
    در مورد موجودیت ها هم سعی میکنم به صورت کامل تا یکی دو روز آینده لیستو قرار بدم تا دوستان نظر بدن و ادامه بدیم.

  8. #48

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    سلام
    آقای صادقیان بابت توضیحاتتون ممنون کامل بود ولی ترا خدا از سوال پرسیدنهای ما ناراحت نشید من چون خودم حسابدارم و در شرکت با سیستم حسابداری ی که کار میکنم ساختار حسابها درختی و با توضیحات شما کاملا ساختار درختی و گزارش گیری آن را متوجه شدم ولی در مورد شناور میشه توضیحاتتون را با مثال همون طوری که درختی را توضیح دادید یه مثال هم براش بزنید خوب مگه توی ساختار درختی مثلان آقای کریمی 2 تا کد داره یعنی در قسمت شناور فقط یک کد برای هم تنخواه و هم بستانکاران داره ؟؟ پس چطوری تفکیک می شه
    اگه سوالم مبتدی از دوستان هم عذر خواهی می کنم

    و یه سوال دیگه اینکه شما آقای کریمی را هم در قسمت تنخواه تعریف کردید و هم در قسمت بستانکاران (یعنی این قسمت برای دریافت حقوق ماهانه آقای کریمی است؟) و یا آقای کریمی از شرکت خریداری کرده است ؟

  9. #49

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    اینجوری گزارش می کنیم:
    گزارش حساب آقای X با تفصیلی شماره 1234 : تمام گردش مالی اونو توی تمام دفاتر نشون میده
    گزارش حساب آقای X با تفصیلی شماره 1234 که فقط مربوط به حساب فروش می باشد. اینجوری گردش مالی رو به یک حساب معین محدود می کنیم.

  10. #50

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    ببینید آقای کریمی در حساب تفصیلی یک جا اسمش تعریف میشه و در تمام سیستم یک کد بهش اختصاص داده میشه. هرجا نیاز بود از آقای کریمی استفاده کنیم از همون کد مربوط به ایشون استفاده میکنیم.
    حالا موقع گزارش گیری اگر بخواهیم ببینیم در حساب تنخواه اقای کریمی چقدر گردش داشته با انتخاب کل نقد و بانک و معین تنخواه و تفصیلی آقای کریمی اینرو بدست میاریم.
    حالا اگر بخواهیم ببینیم کلا آقای کریمی در کل سیستم و در تمام حسابهایی که تعریف شده چقدر گردش داشته فقط حساب تفصیلی آقای کریمی رو انتخاب میکنیم.
    در ساختار درختی ما آقای کریمی رو در زیر هر حساب معینی که نیاز داشتیم تعریف میکنیم. ممکنه یکبار کاربر بهش کد 10 رو اختصاص بده و یکبار کد 20 و یکبار کد 1
    ولی در ساختار شناور شما آقای کریمی رو یکبار تعریف میکنید و فقط یک کد بهش اختصاص میدیدو در هرحساب معین که نیاز داشتید فقط به اون حساب ارتباط میدی.
    در بستانکاران مثلا آقای کریمی برای دریافت حقوق ثبت شده است.

  11. #51

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    آقای صادقیان یه سوال دیگه در مورد موجودیتها :

    شما چک را بعنوان موجودیت شناسایی کردید و گفتید که ((دسته چکها را هم به چکها بعنوان تفضیلی اضافه می کنید تا خطای شماره چک را از کاربر بگیرید )) درسته ؟

    حالا من یه سوال دارم یعنی در برنامه حسابداری که موجودی نقد - بانک - شعبه - دسته چک را تعریف می کنیم ما می تونیم مثلان در قسمت پیمانکاران که می خواهیم چک برای پیمانکاران بکشیم مثلان مقداری از طلبشون را بهشون پرداخت کنیم و اطلاعات شماره حساب هر شرکتی را هم داریم فقط کاربر لیست اسامی شرکتهایی که ماه مربوطه در پرداخت هستند و مبلغ مورد نظر را وارد کنه سیستم صدور چک بقیه کارهای مربوط را طبق لیست وارد شده انجام بده ؟؟؟

  12. #52

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    دسته چکها را هم به چکها بعنوان تفضیلی اضافه می کنید تا خطای شماره چک را از کاربر بگیرید
    دسته چکها دیگه ارتباطی به تفصیلی ندارند. در قسمت تعاریف حساب ، یک قسمت به نام چکها خواهیم داشت که مشخصات هر دسته چکی در آنجا ثبت خواهد شد.

    حالا من یه سوال دارم یعنی در برنامه حسابداری که موجودی نقد - بانک - شعبه - دسته چک را تعریف می کنیم ما می تونیم مثلان در قسمت پیمانکاران که می خواهیم چک برای پیمانکاران بکشیم مثلان مقداری از طلبشون را بهشون پرداخت کنیم و اطلاعات شماره حساب هر شرکتی را هم داریم فقط کاربر لیست اسامی شرکتهایی که ماه مربوطه در پرداخت هستند و مبلغ مورد نظر را وارد کنه سیستم صدور چک بقیه کارهای مربوط را طبق لیست وارد شده انجام بده ؟؟؟
    اینکار را هم میتوان انجام داد ولی این در مراحل آخر هست. ما فعلا با این موضوع کاری نداریم.

  13. #53
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    هر سیستم مالی یک قسمت اصلی به نام حسابداری دارد. قسمت حسابداری را با 3 جدول می شود پیاده سازی کرد.
    1- جدول حسابها
    2- جدول تراکنشهای مالی
    3- جدول جزیئات تراکنش مالی
    برای نمونه نرم افزار gnucash را ببینید.

  14. #54

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    خوب دوستان مجددا تاپیک رو بالا آوردم.ولی انشالله تمام تلاشم رو خواهم کرد دیگه ایندفعه به یک هدف مشخصی برسونیم.

    من تا اینجا بحث رو جمع میکنم و سعی میکنم بحث طراحی رو شروع کنیم.
    ببینید الان ما میخواهیم چارچوب زیر رو پیاده سازی کنیم( این موارد هم شامل 3-4 هفته بررسی من روی سیستمهای مختلف از لحاظ تعریف کدینگ حسابداری با 3 تا حسابدار مختلف می باشد)

    1- گروه حساب ( کد گروه - نام گروه - ماهیت گروه)
    گروه حسابها مثل دارایی های جاری - بدهی های جاری و... می باشد. ماهیت گروه مشخص میکنیم حساب ترازنامه ای یا سود و زیانی یا انتظامی هست.

    2- حساب کل( کد حساب کل( شامل ترکیب کد گروه و کد کل) - نام حساب کل- ماهیت حساب)
    کد حساب کل مثلا اگر کاربر مشخص کرده باشه که حساب کل باید 3 رقم باشه و کد گروه نیز 1 رقم ، در اصل کاربر 2 رقم برای کل وارد میکنه و یک رقم اون مربوط به کد گروه حساب می باشد که به صورت درختی به هم متصل هستند. ماهیت حساب نوع بدهکار - بستانکاری حساب رو مشخص میکند.

    3- حساب معین( کد حساب معین - نام حساب معین )
    کد حساب معین نیز شامل ترکیب کد حساب کل و کد حساب معین می باشد و روند کار مانند کد حساب کل می باشد.

    4- گروه تفصیلی ( کد گروه - نام گروه)
    این گروههای تفصیلی فعلا به جایی ارتباط ندارند و به صورت کاملا مستقل از معین و تفصیلی تعریف می شوند.

    5- حساب تفصیلی( کد تفصیلی- نام تفصیلی)
    کد تفصیلی نیز از فرمول همان کد معین و کل پیروی میکند وترکیب کد تفصیلی و کد گروه آن می باشد.

    6- ارتباط حساب معین مثلا در 10 سطح مختلف با حسابهای تفصیلی

    باید جداول طوری طراحی شوند که دارای شرایط زیر باشند.
    1- اولا تعداد سطوح شناور در معین نامحدود باشد.
    2- در ابتدا بتوانیم طول کدینگ هرحساب رو مشخص کنیم.

    منتظر نظرات دوستان هستم.
    جداول پیشنهادی خودتون رو در صورت امکان به شکل Diagram ارسال کنید که راحتتر بشه بررسی کرد.
    دلیل انتخاب نوع فیلدها رو هم در صورت امکان بفرمائید.

  15. #55
    کاربر تازه وارد آواتار alireza1514
    تاریخ عضویت
    بهمن 1384
    محل زندگی
    بندرکنگ
    پست
    70

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    با سلام خدمت دوستان عزيز ....
    بيشتر يك الگو ست
    ببينيد دوستان بيشتر يه ايده است. به سه شكل ميشه عمل كرد. تعريف حسابها تا سطع معين در جدول تراكنش، كه براي هر حساب بايد سه كد گروه و كل و معين و . بايد در سه فيلد جداگانه ثبت بشه.
    الگوهايي كه من ديدم براي سطح تفصيلي اين بود كه تمامي حسابهاي شناور و معرفي مي كردي و بهشون يك گروه اختصاص ميدادي. بعد در تعريف حساب معين ميگفتي كه اين معين در سطح اول تفصيلي با اين گروه ها در ارتباط باشه و در سطح دوم با اين گروهها و الي آخر و مهم در اينجا تعداد سطوحي است كه بر نامه نويس مشخص ميكرد.
    يه الگوي ديگه هم اين بود كه سيستم بر اساس كدينگ عمل ميكرد مثل همون روش كدينگ حسابها فقط براش يه تيك ميزاشتي كه اين حساب جز پذير باشه و در اينجا ديگه سطوح حساب نميتونست زياد باشه چون كار بر بايد يك رشته كد طولاني رو حفظ ميكرد.
    .................................................. .................................................. .................................................. .........................................
    الان هم دارم روي نرم افزار گرين كار ميكنم ببينم اصولش رو به چه سبكي گذاشته اگه موفق شدم حتما طراحي جداول معرفي حساب رو هم براتون ميزارم.
    به اميد اينكه تونسته باشم كمكي كرده باشم

  16. #56

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    [QUOTE=حمیدرضاصادقیان;1272372]دوست عزیز قبل از اینکه لینک بذارید لطفا به نوشته های من توجه کنید.
    ما هنوز نه با حسابداری کار داریم ، نه با فاکتور ، نه با چک و نه هیچ چیز دیگه.
    تا وقتی نتونیم کدینگ حسابها رو تعریف کنیم پیش بردن این مباحث کاری بیهوده هست.
    در ضمن برای پیش بردن این مورد شما یک راست رفتی سر ایجاد جدول که جداول Master,Detail میخواهیم. !
    اگر به این روش پیش بریم مطمئنا کاری بدون اصول رو انجام دادیم. ما هنوز نیازمندیهای مسئله رو روشن نکردیم چطور میخواهیم سند ثبت کنیم؟
    فعلا قرار شده که دوستان زحمت بکشند و موجودیتهای مربوط به کدینگ حسابها که در بالا کامل توضیح دادم رو در بیارند و اینجا معرفی کنند.

    من برای شروع کار چند موجودیت رو خودم پیشنهاد میدم. لطفا دوستانی که در بحث شرکت میکنند فقط در حیطه سوالات مطرح شده پیش برند تا پستها حذف نشوند و تاپیک از یک نظمی برخوردار باشه در غیر اینصورت ادامه دادنش کار جالبی نخواهد بود.

    موجودیتهای پیشنهادی برای سیستم کدینگ حسابداری :

    1- گروه حساب
    2- حسابهای کل
    2- حسابهای معین
    3- گروه تفصیلی
    4- حسابهای تفصیلی
    5- اشخاص حقیقی
    6- اشخاص حقوقی
    7- بانکها
    8- چک
    9- شرح ثابت حسابها
    10- ارتباط با سایر زیرسیستمها
    11- ارتباط معین با حسابهای تفصیلی


    دوستان اگر در مورد این موجودیتها سوالی دارید بفرمائید. یااگر به نظرتون نیازی هست تغییراتی در اونها اعمال بشه با ذکر دلیل بفرمائید.
    باتشکر
    منظورتون در مورد شرح ثابت حسابها و ارتباط با سایر سیستمها چیست؟

  17. #57

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    ببینید هرحسابی برای خودش یک سری شرح ثابت داره که موقع سند زدن خیلی کاربرد داره. مثلا کاربر میخواد برای حساب صندوقش یک سری شرح ثابت بذاره بابت دریافت و پرداخت و ...
    اونارو اینجا تعریف میکنه و با حساب مربوطه لینک میکنه که در اسناد بهش نمایش داده میشه تا کارش سریعتر پیش بره

    چرا در خود حساب یا در سند مشخص نمی کنید و جداگانه در نظر می گیرید ؟اگه جدا در نظر می گیرید شامل چه فیلدهایی ؟

  18. #58
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    عملیات حسابداری یک قسمت اصلی و مرکزی دارد که در 2 موجودیت خلاصه می شود
    1- حساب ها
    2- اسناد
    سایر قسمت هایی که اشاره شده در پست قبلی ربطی به قسمت اصلی ندارد.
    حسابها را در یک ساختار درختی می شود ذخیره کرد.به این صورت
    1- کدحساب
    2-کد والد حساب
    3- نام حساب
    4- شماره حساب
    5-نوع حساب(بدهکار، بستانکار)
    و اگر لازم شد چندتا فیلد دیگر می شود اضافه کرد.
    تعریف کدینگ حسابداری با مشتری هست و حسابداری در هر حرفه کدینگ های خاص خودش را دارد.شاید در یک بقالی با 5 تا حساب کل سیستم حسابداری هم بیاید ولی در بانکها طبق بانک مرکزی تا 3 سطح حساب باید تعریف شود که این هم استاندارد هست و در حدود 1200 سرفصل هست.
    وقتی شما جدول حسابها را به این شکل تعریف می کنید تا بینهایت سطح برای بی نهایت حساب می شود تعریف کرد و دست کاربر برنامه هست تا بنا بر احتیاج خودش حساب تعریف کند.
    حالا در پست بعد هم در مورد سند خواهم نوشت

  19. #59
    کاربر دائمی
    تاریخ عضویت
    فروردین 1388
    محل زندگی
    اصفهان
    سن
    28
    پست
    138

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط hossein_h62 مشاهده تاپیک

    حسابهای کل> حسابهای معین(2 سطح)> حسابهای تفصیل (3 سطح)
    * البته بدلیل اینکه تعریف حساب معین در 2 سطح باعث میشه سطح اول اونها خیلی کلی باشن، تعریف حسابهای معین در یک سطح بهتره.
    در بعضی از سیستم ها سطوح تفضیل تا 4 هم می رسه. معمولاً جدول تفضیل رو با خودش relation میدن.

  20. #60
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نمیدونم چرا این بحث ها تا یک حدود میرند و بعدش هم می خوابند گفتم بنویسم شاید دوباره ادامه پیدا کنه :
    من تاپیکها را مطالعه کردم و نتایج خودم را می نویسم :
    سطح کلی طبقات : این سطوح تقریبا در تمامی نرمافزارها ثابت می باشند در اصل همان گروه حسابها هستند و کلیه گزارشها در نهایت از این موارد گرفته می شوند و اینها ریشه درختواره حساب ما به حساب می ایند
    1. دارییها
    2. بدهی ها
    3. درامدها
    4. سرمایه و اندوخته
    5. انتظامی
    6. هزینه ها

    سطح بعد دفتر کل ما است :
    1. کد کل 2. نام کل 3. توضیحات
    سطح بعد دفتر معین :
    1. کد معین (کد کل + کد معین ) 2. نام معین 3. توضیحات
    سطح بعد دفتر تفصلی :
    1. کد تفصیل 2. نام تفصیل 3. توضیحات

    تعریف افراد حقیقی :
    1. کد مشتری 2. نام 3. نام خانوادگی 4 . ش ملی 5 . ش .ش 6. تلفن 7. موبایل 8 . ایمیل 9. وب سایت 10 ادرس 11. کد پستی
    تعریف افراد حقوقی :
    1. کد مشتری 2. نام شرکت 3. ک ملی 4. کد ثبت 5 . کد اقتصادی 6. تلفن 7. ادرس 8. کد پستی 9. وب سایت . 10 . فرد ارتباطی 11. توضیحات
    تعریف کالا :
    عنوان کالا 2. گروه کالا 3. نام کالا 4. کد کالا 5. شماره ثبت 6. قیمت خرید 7. قیمت فروش 8. تعداد اولیه 9. کد بار کد
    تعریف بانک :
    1. نام بانک 2. شعبه بانک 3. ادرس 4 . تلفن 5 . حسابهای موجود در بانک و نوع حساب (چک . کارت خوان ..) 6. توضیحات 7. کد بانک
    تعریف صندوق :
    1. کد صندوق 2. موجودی صندوق 3 . نام صندوق
    کارمندان :
    1. کد 2. نام و نام خانوادگی 3. تلفن 4. ادرس 5. دستمزد 6. میزان بیمه 7. درصد برداشت از فروش
    هزینه ها :
    1. کد هزینه 2. نام هزینه 3. توضیحات
    فاکتور خرید :
    1. کد فاکتور 2. کد مشتری 3. اقلام فاکتور ( کد کالا . نام کالا. تعداد خرید . قیمت خرید . قیمت فروش ) 4. جمع فاکتور 5. تاریخ فاکتور 6. توضیحات

    خوب تا ادامه ....
    چند سئوال :
    1. ما حسابها ی خود را تعریف کردیم و گروه ها .. دفتر کل .. معین .. تفصیل ... حالا سئوال اینجاست ارتباط ما بین این حسابها با فاکتور ما و اطلاعات پایه ما که شامل بانک . صندوق. بستانکاران . بدهکاران . کارمندان .. به چه صورت می باشد .

    به نظر من مهمترین چیز ارتباط بین جداول و نحوه فراخوانی مقادیر از هر جدول و در نهایت گرفتن گزارش یعنی در اصل باید اول ارتباط درختواره ما مشخص شود ... اینکه بعد از خرید یک کالا چه اتفاقاتی در درختواره حسابهای ما می افتد ؟؟؟

  21. #61
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    دوست عزیز شما دقیقا باید حد فاصل حسابداری را با بقیه قسمت ها مشخص کنید، حسابداری همش با 3 تا جدول درست می شود، یک جدول برای حسابها، دو جدول هم برای سندها.
    بعد از این دیگر ربطی به حسابداری ندارد، یک چیر دیگری می شود، که باید بر اساس نیاز خودتان توسعه بدهید.
    تعریف مشتری، بانک، صندوق، چک و .... این ها جز هسته اصلی حسابداری نیست، بر اساس نیاز می شود هر جوری که خواستید توسعه بدهید.
    حالا اگر فرصت شد یک برنامه کوچک درست می کنم در آینده نه چندان دور که فقط هسته اصلی حسابداری را پیاده کند.
    باز یک نکته را بگویم، تعریف حسابها و سر فصل که به من برنامه نویس ربطی ندارد، مشتری بر حسب نیاز خود، این ها را تعریف خواهد کرد.

  22. #62
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط linux مشاهده تاپیک
    دوست عزیز شما دقیقا باید حد فاصل حسابداری را با بقیه قسمت ها مشخص کنید، حسابداری همش با 3 تا جدول درست می شود، یک جدول برای حسابها، دو جدول هم برای سندها.
    بعد از این دیگر ربطی به حسابداری ندارد، یک چیر دیگری می شود، که باید بر اساس نیاز خودتان توسعه بدهید.
    تعریف مشتری، بانک، صندوق، چک و .... این ها جز هسته اصلی حسابداری نیست، بر اساس نیاز می شود هر جوری که خواستید توسعه بدهید.
    حالا اگر فرصت شد یک برنامه کوچک درست می کنم در آینده نه چندان دور که فقط هسته اصلی حسابداری را پیاده کند.
    باز یک نکته را بگویم، تعریف حسابها و سر فصل که به من برنامه نویس ربطی ندارد، مشتری بر حسب نیاز خود، این ها را تعریف خواهد کرد.
    ای کاش بیشتر توضیح میدادید ... و نمونه نرم افزارتون را زودتر میگذاشتید تا مشکلاتم هل بشه ...

  23. #63
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    جدولهای زیرا من پیشنهاد می کنم برای حسابداری
    (BBP.IR)Accounting.jpg

  24. #64
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    جدولهای زیرا من پیشنهاد می کنم برای حسابداری
    این جدول برای بدهکار بستانکار هستش ؟
    من برای ای دی ها از bigint استفاده کرده ام
    خوب معین و کل و تفصیل کدام جدول هستش؟
    یکم در مورد ارتباطاتش بگو ؟
    ممنونم

  25. #65

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط noroozifar مشاهده تاپیک
    این جدول برای بدهکار بستانکار هستش ؟
    من برای ای دی ها از bigint استفاده کرده ام
    خوب معین و کل و تفصیل کدام جدول هستش؟
    یکم در مورد ارتباطاتش بگو ؟
    ممنونم
    کل معین تفصیلی میشه سه سطح ، بعضی جا ها از تفصیلی استفاده نمی کنند و بعضی ها هم نیاز به سطح های پایین تری دارند پس بهترین کار این که سطوح حساب ها نامحدود باشه ، مثل جدول A_Accounts که با خودش رابطه یک به چند برقرار کرده و میشه تا n سطح حساب تعریف کرد.

    من کاربرد SerialNum و Type رو متوجه نشدم ، جناب آقای بخشایش لطفا این بحث رو ادامه بدید تا به نتیجه کاربردی برسه و هرجا هم نیاز هست تقسیم کار کنید.

  26. #66
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط mohammadi4net مشاهده تاپیک
    کل معین تفصیلی میشه سه سطح ، بعضی جا ها از تفصیلی استفاده نمی کنند و بعضی ها هم نیاز به سطح های پایین تری دارند پس بهترین کار این که سطوح حساب ها نامحدود باشه ، مثل جدول A_Accounts که با خودش رابطه یک به چند برقرار کرده و میشه تا n سطح حساب تعریف کرد.

    من کاربرد SerialNum و Type رو متوجه نشدم ، جناب آقای بخشایش لطفا این بحث رو ادامه بدید تا به نتیجه کاربردی برسه و هرجا هم نیاز هست تقسیم کار کنید.
    در مورد نوع آی دی ها خیلی مهم نیست که عدد باشد یا guid .
    serialno چیز خاصی نیست، معمولا وقتی سندی ثبت می شود روی برگ سند یک شماره سریال هست این را برای وارد کردن آن شماره در نظر گرفتم تا بعدا جستجو برای کاربر بر حسب شماره سند هم راحت باشد.
    type را برای نوع حساب گرفتم. ساده ترین حالتش این هست که بدهکار یا بستانکار بودن یک حساب را مشخص کند.
    ریشه هر چی باشد باید شاخه ها هم همان شود.

    از روی این می شود کنترل های را موقع ثبت سند انجام داد.

  27. #67
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط noroozifar مشاهده تاپیک
    این جدول برای بدهکار بستانکار هستش ؟
    من برای ای دی ها از bigint استفاده کرده ام
    خوب معین و کل و تفصیل کدام جدول هستش؟
    یکم در مورد ارتباطاتش بگو ؟
    ممنونم
    نمی دانم منظور شما از بدهکار و بستانکار کدام هست. جدول trasnaction برای ثبت سند هست و جدول account برای نگهداری حسابها.
    اینجا را نگاه کنید یک کدینگ حسابداری هست http://hesabketab.blogfa.com/post-13.aspx
    1-داراییها
    11- داراییهای جاری
    1110- موجودی نقد و بانک
    111001-صندوق ریالی
    11100110-صندوق شماره یک
    تا ینج سطح ریز کردیم
    به همین راحتی شما می توانید گزارش گیری هم کنید، بر اساس هر کدام از این سطوح.
    سطح 1 را اسمش را کل بگذارید، سطح بعدی معین و بعدی تفضیلی و ... همین طور تا آخر
    این سه جدول اساس یک سیستم حسابداری هست. بعد از این ربطی به حسابداری ندارد.

  28. #68
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    خوب در اصل من باید یک اعتراف بکنم من زیاد از حسابداری میشنوم یک مشاوره حسابداری دارم در اصل من از حسابداری زیاد سر در نمیارم شاید این مثال شما را برای نمونه انجام بشه که یک سند زده بشه داخلش بتونم بفهمم جریان کار چیه وقتی فاکتور زده میشه و سند به صورت مثلا از طریق بانک یا صندوق نقدی پرداخت میشه و سند تنظیم و ثبت میشه اطلاعات به چه طریق تو جدولهای حسابداری ما که شامل کل (دارایی) - معین - تفصیل هست ذخیره میشه

    برای مثال : ما یک فاکتور داریم کالاها در ان انتخاب شده حالا فاکتور برای مشتریه و هزینه ان مثلا 50000 تومان شده و طرف نقد دریافت کرده و باید سند بزنه و به صندوق اضافه کنه ... این یک نمونه مثال ؟؟

    بعد اقای بخشایش خواهشا این بحث را ادامه بدهید تا به نتیجه ممنونم از شما من تو این بحث خیلی مشکل دارم ؟
    بعد اگر لطف کنید فیلدها را هم توضیح مختصر دید هر کدام کارش چیه و جداول کدام فیلدهاشون با هم لینک شده اند ؟

    ممنون از همه افرادی که در این بحث شرکت میکنند

  29. #69
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    جدول account با خودش ارتباط یک به چند داره از طریق فیلد id, parentId این برای پیاده سازی یک ساختار درختی هست.
    جدول transaction با جدول transactiondetail ارتباط یک به چند دارد از طریق فیلد transactionId
    و جدول transactiondetail با جدول اکانت ارتباط یک به چند دارد از طریق فیلد AccountId
    در پست قبل گفتم که چطور اطلاعات در جدول اکانت ذخیره می شود.
    کسانی که حسابداری کار کردند دید سیستمی ندارند و شما را گمراه خواهند کرد.
    من با فاکتور کالای شما کاری ندارم مهم سند حسابداری هست
    در این حالتی که گفتید صندوق شما بدهکار می شود و یک حساب دیگر بستانکار
    این حسابها قبلا در جدول اکانت ثبت شده اند
    برای ثبت این سند یک رکورد در جدول transaction و دو رکورد در جدول trasnactiondetail ذخیره می گردد،
    مثلا در جدول تراکنش
    id= 1,saveDate=2011/12/31,comment=New Sale
    و در جدول جزنیات تراکنش اطلاعات زیر ذخیره می گردد
    1،1،شماره حساب صندوق،0، 50000
    2 ،1 ، شماره حساب شخص،5000 ، 0
    همه این رکورد ها باید در همزمان ذخیره شوند.(یک تراکنش)
    اطلاعات مربوط به دفتر کل و معین و تفضیلی در صورت نیاز توسط گزارش از توی جدول transaction و جدول trasnactiondetail تهیه می شوند،

  30. #70
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    درسته فرد حسابدار خیلی جاها منو گمراه میکنه و فکرکنم الان کاملا گیج شده ام نمی تونم سیستم را تحلیل کنم شاید مشلوره با این فرد باشه ..
    گفتید جدول transaction با جدول transactiondetail ارتباط یک به چند دارد از طریق فیلد transactionId اما فکر کنم با اون عکسی که در چند پست قبل از دیاگرام گذاشتی تناقض داره ؟
    خوب طیق فرضیات شما می خواهم ببینم درست متوجه شده ام ما در accounts این حساب را مقدار دهی کردیم و ایجاد کردیم ؟
    ?Id=1, parentId=11,code=?,name=darayhai jary,type
    id=11,parentId=1110,code?,name=mojodi naghd va bank,type=?f
    id=1110,parentid=01,code=?,name=sandogh ryali , type=?k
    id=2110,parentid=01,code=?,name=hesab ashkhas,type?k
    حالا عملیات زدن سند ابتدا یک رکورد در a-transection :
    id=10,savedate=1390/05/02,serialno=34567,commont
    حالا دو رکورد در a-transectiondetalis:
    id=1,transctionid=10,accountid=111001,debit=0,cred it=5000,comment=??f
    id=2,transectionid=10,accountid=211001,debit=5000, credit=0,comment??f
    خوب ایا سند من درست زده شد ؟
    بعد یکسری علامت ؟ گذاشتم نمیدونستم چه مقادیری میگیرند ؟

    هنوز سئوالات زیادی دارم ...
    باز هم ممنونم از شما

  31. #71
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    تعریف حسابها را اشتباه انجام دادید،
    برای داراییهای جاری
    id را سیستم ایجاد می کند، حالا یا عدد صحیح هست یا guid
    parentid برای داراییهای جاری اینجا null هست.
    code همان شماره کدینگ هست که خودتان می شناسید در این مثلا مثلا برای صندوق ریالی 1110 هست.
    type می توانید برای خوتان قرارداد کنید مثلا حسابهایی که ماهیت بدهکار دارند مثل ، دارایی ها (بانک ، صندوق و.... ) 1 بگیرید و آنهایی که ماهیت بستانکار دارند ، 2
    در transactiondetails برای کامنت خیلی مهم نیست که مقدار بگذارید، بعضی شرکت ها لازم دارند که در این قسمت مقدار بگذارند.
    خلاصه تقریبا درست تعریف کردید، حالا هر وقت خواستید می توانید با گزارش دفتر کل و معین و تفضیلی را از همین 3 جدول بدست آورید.

  32. #72
    کاربر دائمی آواتار noroozifar
    تاریخ عضویت
    بهمن 1385
    محل زندگی
    کرمان
    پست
    446

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    تعریف حسابها را اشتباه انجام دادید،
    اصلاح شده آن به چه طریقه ؟
    2. حالا حسابهای ما تعریف شده اند ولی این امکان داره که چندین حساب تعریف بشه ... شخص بیاد چندین حساب تعریف کنه حالا زمان سند باید ما ایا از شخص بخواهیم حساب مورد نظری که ایجاد کرده انتخاب کنه ... خوب پس اگر به این طریق باشه شخص باید همیشه سطح آخر را انتخاب کنه درسته ؟؟ یعنی ما حسابها را به صورت یک کتمبو باکس سطح اخر را بزاریم و بعد شخص انتخاب کنه ؟

    نمونه مثال شما کی اماده میشه شاید با یک مثال عملی کاملا همه چی بدستم بیاد ؟؟

  33. #73
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط noroozifar مشاهده تاپیک
    اصلاح شده آن به چه طریقه ؟
    2. حالا حسابهای ما تعریف شده اند ولی این امکان داره که چندین حساب تعریف بشه ... شخص بیاد چندین حساب تعریف کنه حالا زمان سند باید ما ایا از شخص بخواهیم حساب مورد نظری که ایجاد کرده انتخاب کنه ... خوب پس اگر به این طریق باشه شخص باید همیشه سطح آخر را انتخاب کنه درسته ؟؟ یعنی ما حسابها را به صورت یک کتمبو باکس سطح اخر را بزاریم و بعد شخص انتخاب کنه ؟

    نمونه مثال شما کی اماده میشه شاید با یک مثال عملی کاملا همه چی بدستم بیاد ؟؟
    دوست عزیز خودتان هم دست بکار شوید، حداقل یک پروژه ایجاد کنید، با هم و با کمک بقیه توسعه می دهیم

  34. #74
    کاربر تازه وارد آواتار havakili
    تاریخ عضویت
    مهر 1387
    محل زندگی
    کاشمر
    پست
    36

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    با سلام به همه
    با تشکر از همه دوستان
    به نظر من خیلی این تاپیک طولانی شده
    باید یه نفر که تجربه عملی در این زمینه داره بحث رو با توجه به تجربه اش کامل کنه
    بعد دوستان در مورد نقاط ضعف و قدرت اون اظهار نظر کنند
    اگه قرار باشه واسه تحلیل یه برنامه این همه وقت بزارید که .................

  35. #75

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    استاد عزيز آيا مثلا اگر بخواهيم با دات نت برنامه نويسي كنيم آيا بايستي اين دياگرام هارو تو ديتا بيس مثل اسكيوال سرور داشته باشيم و هيچ منافاتي با برنامه نويسي نداره ممنونم

  36. #76
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط havakili مشاهده تاپیک
    با سلام به همه
    با تشکر از همه دوستان
    به نظر من خیلی این تاپیک طولانی شده
    باید یه نفر که تجربه عملی در این زمینه داره بحث رو با توجه به تجربه اش کامل کنه
    بعد دوستان در مورد نقاط ضعف و قدرت اون اظهار نظر کنند
    اگه قرار باشه واسه تحلیل یه برنامه این همه وقت بزارید که .................
    شما دست بکار بشوید، یک چیزی تولید کنید، اینجا کسانیکه بخواهند نظر بدهند زیادند

  37. #77
    کاربر دائمی
    تاریخ عضویت
    مرداد 1389
    محل زندگی
    Tehran
    پست
    392

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    با سلام دوستان عزیر شما همگی برنامه نویس هستید و ابن تالار مربوط به بچه های حسابداری نیست که شما ریز حسابها رو تشریح می کنید و کار شما به عنوان یک برنامه نویس تحلیل و طراحی نرم افزار با کمک حسابداران و استفاده از نظرات انها جهت پیاده سازی نرم افزاری جهت تسهیل کار آنهاست نه تعریف کدینگ حسابداری . به عنوان مثال شما نیازی نیست که حسابها را بشناسید و بدانید که دارادیهای جاری و غیر جاری ، بدهیهای جاری و غیر جاری ،حقوق صاحبان سهام ، هزینه ها ، درآمدها و حسابهای انتظامی که 8 گروه معمولا مورد توافق حسابداران هستند اطلاع داشته باشید شما باید ابزار را در اختیار آنها قرار دهید اینکه آنها چه عنوانی تعرف می کنند به خودشان ربط دارد و باعث می شود شما از کار خسته شده و احساس کنید این کار کار شما نیست . مختصر توضیحاتی در زمینه سیستم حسابداری مالی می دهم که اگر دوستان علاقه داشتند در مورد سایر سیستمها و جزئیات همه آنها بدون نیاز به وارد شدن به جزئیات حسابداری ادامه می دهیم امید که همگی بتوانند در تمام این زمینه ها برنامه نویسان خبره و کارآمدی شوند.
    همانگونه که دوستان قبلا توضیح داده اند در حسابداری دو نوع حساب داریم ، حسابهای مالی و حسابهای تفصیلی
    حسابهای مالی با دید کامپیوتری اگر بخواهید نگاه کنید مثل فولدر بندی معمولی است که شما روزانه فایلهایتان را دسته بندی کرده و در فولدرهایی که از قبل پیش بینی کرده اید می گذارید مثل فولدر فیلم ، موسیقی و .. حال اینکه اینجا نحوه هزبنه و درآمدها و ... دسته بندی می شود
    در سیستم حسابداری این کدینگ (حسابهای مالی) بسیار مهم است و بهترین راه برای این کار همانگونه که دوستان گفتند لایه بندی است
    در حسابهای مالی ما معمولا سه سطح به ترتیب داریم : گروه - کل - معین
    ولی یک حساب با یک کد شناخته می شود و ورود اطلاعات فقط در سطح معین انجام می شود یعنی در سطح آخر به عنوان مثال اگر کد گروه ما 1 باشد و کد کل ما 12 باشد و کد معین ما 150 باشد کد این حساب (معین) معادل 112150 می باشد یعنی با چسباندن این کدها به یکدیگر.(اصلا به عناوین دقت نکنید) حال اینکه طول گروه و کل و معین هر کدام چقدر باید باشد باز این به برنامه نویس ربطی ندارد و نباید ثابت تعریف کنید باید امکانی به کاربر بدهید که نحوه کدگذاری را خود تعیین کند.و معمولا مثلا می گویند 124 است یا 236 یا هر چیز دیگر که هر رقم معادل طول کد در آن لایه است. 236 نشان می دهد طول معین ما 11 رقمی است در هر لایه در صورتی که کاربر کدی کمتر از تعداد آن مقدار تعیین شده تعریف کند شما موظفید در برنامه به تعداد طول کد آن لایه در آن لایه به قبل از آن عدد صفر اضافه کنید مثلا 010010003 یک کد حساب معتبر برای 236 می باشد.
    تعربف حساب به شکل لایه بندی یک Table با تعداد فیلدهای زیر می خواهد
    کد حساب - کد لایه بالاتر (پدر)- عنوان حساب - ماهیت حساب - نوع حساب - عطف - عطف ارزی به غیر از موارد 1 تا 3 خودتان را درگیر بقیه عناوین نکنید فقط مثل یک فیلد با آنها برخورد کنید(توضیحات بیشتر در زمینه این موارد در مراحل بعدی ارایه خواهد شد)
    کد حساب و کد لایه بالاتر و عنوان حساب همگی از نوع رشته ای می باشند (با توجه به وجود عدد صفر در ابتدای بعضی از حسابها) .معمولا تعداد 32 کارکتر برای این حسابها زیاد هم هست و برای عنوان حداکثر 200 کارکتر کفایت می کند.
    بیشتر برنامه های حسابداری سه سطح حسابهای مالی را در سه فرم طراحی می کنند به صورت :
    تعریف گروه حسابها : در اینجا کد و عنوان حساب و بقیه مشخصات بدون لایه بالاتر را تکمیل می کنند
    تعریف کل : بغیر از موارد قبلی لایه بالاتر یعنی گروه نیز باید مشخص گردد
    تعریف معین : کد ، عنوان و سایر موارد بعلاوه لایه بالاتر که حسابهای کل می باشد وارد می شود
    ولی پیشنهاد می شود شما همه را در یک فرم تعریف کرده و مثلا از ابزاری مانند Tree و یا بعضی از Grid ها که امکان تعریف درختوار را دارند استفاده کنید و یا خودتان اینگونه Grid ها را طراحی کنید تا اینجای کار اگر شما موفق به طراحی فرمی با کاربری ساده و زیبا شده باشید از نظر بنده که چندین سیستم حسابداری مالی برای شرکتهای مختلف پیاده سازی کرده ام 15 درصد یک سیستم حسابداری را تکمیل کرده اید متاسفانه به دلیل تعهد اینجانب به این شرکتها امکان نمایش شکل فرم این برنامه ها در اینجا وجود ندارد. از نظر من تا اینجای کار در این پست برای دوستانی که بخواهند کار را شروع کنند و به خاطر اینکه شلوغ کاری نشود در صورت استقبال این تاپیک را تا پیاده سازی بک سیستم کامل حسابداری با زبان کامپیوتری نه حسابداری ادامه می دهیم.
    از مدیران عزیز هم تقاضا دارم که امکان تعریف هر سیستم را در یک تاپیک جدا بدهند چون خودشان هم بهتر می دانند اگر در زمینه همه سیستم ها از جمله حسابداری ، انبار ، فروش ، خزانه داری ، حقوق و دستمزد ، اموال و خرید و تدارکات و ..... در یک تاپیک سوال پرسیده شود هیچگاه به سرانجام نخواهد رسید.

  38. #78

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    هدف این تاپیک اینه که یه تحلیل حرفه ای و بدربخور از دل اون بیرون بیاد که تا حالا این اتفاق نیقتاده ، اگر قرار بود سیستم ساده حسابداری نوشته بشه که خیلی ها این کار رو کم و زیاد انجام دادن ، بماند که مخاطبین اینجا سوال های متفاوتی نسبت به سواد و تجربه شون می پرسند و این باعث شده شما فکر کنید سطح سواد حسابداری تمام کااربران اینجا خیلی پایینه.

    به نظرم من اگه کسی بخواد یکی سیستم حسابداری رو تحلیل کنه باید حسابداری رو از خود حسابدارها بهتر یاد بگیره ، وقتی ما کدینگ رو پیاده می کنیم باید بدونیم این چیه در کجاها ازش استفاده میشه بعدا قراره چه خروجی هایی از این گرفته بشه و ....
    خنده دار نیست فردا به یک نفر سیستم مالی بفروشی بعد اگه یه سوال ازت پرسید بهش بگی خود تو برنامه بگرد ببینم چنین قابلیتی داره یا نه ؟!

    اگه پست های قبل رو خونده باشی حداقل نتیجه ای که گرفته شد اینه که یه سیستم کدینگ نامحدود پیاده کنیم. و کاربر خودش تصمیم بگیره تا چند سطح کدینگشو تعریف کنه.

    من خیلی خوشحال میشم بتونم ازتجربیات مفید شما استفاده کنم ولی باید یک نفر پیدا بشه گفتگو رو مدیریت کنه و در یک تاپیک دیگه جمع بندی انجام بشه که پستها هدفمند و طبق یک روال منظم پیش برند.
    البته اگه موافق باشید من می تونم این کار رو انجام بدم.

  39. #79
    کاربر دائمی
    تاریخ عضویت
    مرداد 1389
    محل زندگی
    Tehran
    پست
    392

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    دوست عزیز من قصد توهین به کسی رو ندارم ولی سیستمهای حسابداری که من خودم نوشتم در جاهایی استفاده می شه که گردش مالی آنها در سال بیش از 2 میلیارد دلار است و اینکه برنامه نویس باید حسابداریو بیشتر از یک حسابدار بلد باشه باعث می شه هیچ برنامه نویسی سمت این کار نره . مثلا من از شما بپرسم که در خزانه داری سمت بدهکار معین واگذاری چک دریافتی چه حسابی است است و یا در دستمزد تفصیلی اول کسور اقساطی چه کسی است و یا در انبار معین بستانکار رسید برگشت از مصرف چه حسابی است چه ربطی به برنامه نویسی دارد . درست است اگر برنامه نویس اینها را بداند بهتر می تواند این کار را انجام بدهد ولی معمولا تمام کسانی که حسابداری نوشته اند از یک حسابدار کمک گرفته اند و این تاپیک هم ظاهرا برای کسانی ایجاد شده که نتوانسته اند به این هدف دست یابند والا اگه به قول شما سواد حسابداری همه بالاست شاید من اشتباها در یک تاپیک مربوط به رشته حسابداری پست گذاشتم و اینجا همه مشکل برنامه نویسی دارند. اگر حسابداری بلدید و برنامه نویسی تخصص شماست پس در این تاپیکها دنبال مطلب نگردید قاعدتا شاید در برخی موارد به مشکل بخورید که آن هم نیاز به یادگیری از اول نیست . مثل این است که من یک زبان برنامه نویسی را بلد باشم و برای پیدا کردن جواب یک مشکل کتاب را از اول و نحوه تعریف متغیر مطالعه کنم. هدف این تاپیک برای از بین بردن ترس کسانی است که می گویند برای نوشتن برنامه های مالی باید ابتدا حسابداری را وارد باشید . بک حسابدار خوب اگر یک برنامه نویس خوب اگر باشد می تواند برنامه مالی خوبی ایجاد کند و برعکس .من خودم با مفاهیم مالی آشنا هستم و در این تاپیک اگر با زبان حسابداری بخواهم صحبیت کنم تاپیک چیزی میشه مثل الان که 80 تا پست داره ولی چیزی نمی شه ازش در آورد . و در آخر یک سوال که شما می گویید ما باید یک حسابدار خوب باشیم . اینکه من بدانم حسابهای انتظامی (در سیتم حسابداری) چیست به چه درد من می خورد؟ لطفا یک جواب منطقی بدهید یعنی اگر من ندانم چیست نمی توانم سیستم مالی ایجاد کنم.؟؟؟ بعدش اینکه سیستم غیر ساده حسابداری یعنی چه؟ مگر در تمام سیستم های حسابداری حسابهای مالی و تفصیلی ، صدور سند،اسناد تجمیعی ، مرور حسابها ، مغایرت بانکی و ... نداریم؟؟ اگر شما سیستم حسابداری بدون این مشخصات می شناسید آنها پروژه دانشجویی بوده اند. اگر شما سیستم دستمزد و خزانه داری و ... اینها را هم کلا می گویید سیستم مالی پس تعاریف ما با هم مشکل دارد اینها سیستمهای جدایی هستند که معمولا برحسب کاربرد به سیستم حسابداری سند ارسال می کنند و خود سیستم آنها کلا پیز دیگری است و ارتباط آنها با مالی 2 درصد سیستمشان را تشکیل می دهد .

  40. #80
    کاربر دائمی آواتار linux
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    تهران
    پست
    2,314

    نقل قول: گفتگوی فنی در مورد طراحی Database سیستم مالی

    نقل قول نوشته شده توسط mohammadi4net مشاهده تاپیک
    هدف این تاپیک اینه که یه تحلیل حرفه ای و بدربخور از دل اون بیرون بیاد که تا حالا این اتفاق نیقتاده ، اگر قرار بود سیستم ساده حسابداری نوشته بشه که خیلی ها این کار رو کم و زیاد انجام دادن ، بماند که مخاطبین اینجا سوال های متفاوتی نسبت به سواد و تجربه شون می پرسند و این باعث شده شما فکر کنید سطح سواد حسابداری تمام کااربران اینجا خیلی پایینه.

    به نظرم من اگه کسی بخواد یکی سیستم حسابداری رو تحلیل کنه باید حسابداری رو از خود حسابدارها بهتر یاد بگیره ، وقتی ما کدینگ رو پیاده می کنیم باید بدونیم این چیه در کجاها ازش استفاده میشه بعدا قراره چه خروجی هایی از این گرفته بشه و ....
    خنده دار نیست فردا به یک نفر سیستم مالی بفروشی بعد اگه یه سوال ازت پرسید بهش بگی خود تو برنامه بگرد ببینم چنین قابلیتی داره یا نه ؟!

    اگه پست های قبل رو خونده باشی حداقل نتیجه ای که گرفته شد اینه که یه سیستم کدینگ نامحدود پیاده کنیم. و کاربر خودش تصمیم بگیره تا چند سطح کدینگشو تعریف کنه.

    من خیلی خوشحال میشم بتونم ازتجربیات مفید شما استفاده کنم ولی باید یک نفر پیدا بشه گفتگو رو مدیریت کنه و در یک تاپیک دیگه جمع بندی انجام بشه که پستها هدفمند و طبق یک روال منظم پیش برند.
    البته اگه موافق باشید من می تونم این کار رو انجام بدم.
    دوست عزیز در مورد کدینگ قبلا هم گفتم این کار برنامه نویس نیست، هر صنفی کدینگ حسابهای خودش را دارد و اکثرا هم به یک استاندار رسیده اند در مورد بانکها عرض کنم یک کدینگ استاندارد از طرف بانک مرکزی ارائه می شود که بقیه هم مکلف به استفاده از این کدینگ هستند.
    اینجا یک نمونه از کدینگ حسابداری هست http://hesabketab.blogfa.com/post-13.aspx با حدود 350 تا سرفصل به هر حال ایجاد این کدینگ باید در دست کاربرنهایی باشد که با توجه به نیاز و استانداردها کدینگ خودش را تعرف کرده و استفاه نماید

صفحه 2 از 4 اولاول 1234 آخرآخر

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •