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

[حمیدرضاصادقیان]

سلام دوستان.
در این تاپیک قصد داریم با همفکری دوستان یک Database سیستم مالی رو طراحی کنیم.
فقط برای اینکه بحث کاملا منطقی و فنی پیش بره خواهشمند است دوستانی که در بحث شرکت می کنند اگر موردی رو بیان میکنند کاملا به صورت منطقی دلیلشو بیان کنند. فرض کنید نوع فیلدی رو Char و طولشو 10 در نظر میگیرید کاملا ذکر کنید که چرا این نوع فیلد رو انتخاب کردید.
این سیستم مالی شامل بخشهای حسابداری - خزانه داری- انبارداری - خرید و فروش - دفتر اموال - حقوق و دستمزد هست.

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

باتشکر از دوستانی که در بحث شرکت خواهند کرد.

[حمیدرضاصادقیان]

کلاً در سیستم های مالی مهمترین مباحث ابتدا تعاریف اولیه سیستم هستند.
که شامل تعریف حسابها ، تعریف کالاها، تعریف انبار، تعریف پرسنل ، و... هستند.
ما چون قصد داریم فعلا سیستم حسابداری رو تعریف کنیم بیشتر صحبتمون فعلا روی تعاریف حساب هست.

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

سوال 1:آیا لزومی داره حسابهای سطح تفصیلی به صورت شناور تعریف شوند؟ میتوان آنها را به صورت درختی طراحی کرد یا خیر؟ مزایا و معایب هرکدام از روشها چه هستند؟

در این بخش ما یک سری تعاریف عمومی مثل تعریف بانک ، شعبه، دسته چک، لیست اشخاص ، لیست شرکتها و... نیز داریم.

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


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


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

[chasbonakam]

با سلام خدمت مدیر گرامی ، جناب آقای صادقیان

یه سوال داشتم :

منظور شما از تعریف حساب های تفضیلی به صورت شناور چیست؟ (البته من با مفهوم شناور آشنایی ندارم)

البته شاید مطرح کردن این سوال تو این تاپیک کار درستی نباشه.

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

اگر اینجا امکان بحث در این رابطه وجود نداره لطفا یه لینک معرفی کنید تا بنده با این مفهوم بیشتر آشنا بشم.



بنده یه برنامه خیلی کوچولو و ساده حسابداری نوشتم ، در اون برنامه تمامی حساب ها رو تو یه جدول ذخیره کردم


نحوه کار به این صورت بود که:

کد حساب های کل را سه رقمی در نظر گرفتم

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

و همین طور برای حساب های تفضیلی کد نه رقمی در نظر گرفتم که شش رقم ابتدایی ، نشان دهنده حساب معین مربوطه بود

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

1-دارایی
2-سرمایه
3- بدهی
4-خرید
5- فروش
و...

[hossein_h62]

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

به دلیل رعایت جامعیت کدینگ حسابداری و همچنین ساختار منظم درختی جهت ایجاد جداول و روابط بین آنها بهتره ساختار درختی حسابها یا همون کدینگ حسابداری رو از بالاترین سطح اون شروع به طراحی کنیم،

یعنی در اولین گام تعیین طبقه حسابها :

1- حسابهای ترازنامه ای
2- حسابهای سود و زیانی
3- حسابهای آماری و انتظامی

پس از اون تعیین گروه حسابها :

1- دارائیها (مربوط به طبقه 1 )
2- بدهی ها (مربوط به طبقه 1 )
3- حقوق صاحبان سهام (مربوط به طبقه 1 )
4- حسابهای سود و زیانی (مربوط به طبقه 2 )
5- حسابهای انتظامی (مربوط به طبقه 3 )

حالا تعیین زیر گروههای حساب ها :
1-1 - دارائیهای جاری
1-2 - دارائیهای غیرجاری
2-1 - بدهی های جاری
2-2 - بدهی های غیر جاری
3-1 - حقوق صاحبان سهام
4-1 - فــــــروش و درآمدها
4-2 - قیمت تمام شده کالای فروش رفته
4-3 - هزینــــــــه ها
4-4 - حسابهای جذب و انحرافات
5-1 - حسابهای انتظامی
5-2 - طرف حسابهای انتظامی

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

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

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

[m.hamidreza]

حرکت شما بسیار نیکو و پسندیده هست و من به نوبه خودم از شما تشکر می کنم ولی این موضوع مربوط به تحلیل و طراحی نرم افزار میشه. البته من دقیقا نمیدونم این موضوع رو تا چه حد میخواین بسط بدین و تا چه حدی پیش برین و نقش SQL SERVER در اینجا چی هست. چه ورودی هایی دارین و چه خروجی هایی قرار هست داشته باشین ولی در کل اگر این موضوع رو در قالب یک متدولوژی توسعه نرم افزار مثل RUP ببینید و تا مرحله تولید Class Diagram پیش ببرید بعد با توجه به مستندات بدست اومده تا اینجا، از روی Class Diagram کار طراحی دیتابیس رو در SQL شروع کنید به نظر من خیلی بهتر و مفیدتر هست. در واقع بدون این پیش نیازها خیلی سخت هست تا Vision به مخاطب منتقل شه و تاپیک فقط برای افرادی مفید میشه که قبلا تجربه هرچند مختصری در تولید موضوع تاپیک داشتن.
موفق باشید.

[حمیدرضاصادقیان]

سلام.

منظور شما از تعریف حساب های تفضیلی به صورت شناور چیست؟

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

کد حساب های کل را سه رقمی در نظر گرفتم

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

و همین طور برای حساب های تفضیلی کد نه رقمی در نظر گرفتم که شش رقم ابتدایی ، نشان دهنده حساب معین مربوطه بود

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

1-دارایی
2-سرمایه
3- بدهی
4-خرید
5- فروش
و...

خوب با این روش چه طوری رابطه Master-Detail رو برقرار میکنید؟ نوع فیلدها رو چی در نظر میگیرید؟
چون اگر بخواهید Relation بین جدول کل و معین برقرار کنید بهتون خطا میده.چون کد کل به همون شکل در جدول معین نیست و باکد جدول معین تلفیق شده است و SQL Server اینو تشخیص نمیده.مگر اینکه یک فیلد جداگانه برای ارتباط با جدول بالایی اون داشته باشید.

حرکت شما بسیار نیکو و پسندیده هست و من به نوبه خودم از شما تشکر می کنم ولی این موضوع مربوط به تحلیل و طراحی نرم افزار میشه. البته من دقیقا نمیدونم این موضوع رو تا چه حد میخواین بسط بدین و تا چه حدی پیش برین و نقش SQL SERVER در اینجا چی هست. چه ورودی هایی دارین و چه خروجی هایی قرار هست داشته باشین ولی در کل اگر این موضوع رو در قالب یک متدولوژی توسعه نرم افزار مثل RUP ببینید و تا مرحله تولید Class Diagram پیش ببرید بعد با توجه به مستندات بدست اومده تا اینجا، از روی Class Diagram کار طراحی دیتابیس رو در SQL شروع کنید به نظر من خیلی بهتر و مفیدتر هست. در واقع بدون این پیش نیازها خیلی سخت هست تا Vision به مخاطب منتقل شه و تاپیک فقط برای افرادی مفید میشه که قبلا تجربه هرچند مختصری در تولید موضوع تاپیک داشتن.

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

یعنی در اولین گام تعیین طبقه حسابها :

1- حسابهای ترازنامه ای
2- حسابهای سود و زیانی
3- حسابهای آماری و انتظامی

پس از اون تعیین گروه حسابها :

1- دارائیها (مربوط به طبقه 1 )
2- بدهی ها (مربوط به طبقه 1 )
3- حقوق صاحبان سهام (مربوط به طبقه 1 )
4- حسابهای سود و زیانی (مربوط به طبقه 2 )
5- حسابهای انتظامی (مربوط به طبقه 3 )

گروههای حسابداری ثابت هستند ولی فکر میکنم بهتر باشه کاربر خودش بتونه این گروهها رو تغییر بده و بتونه کدینگ های اونها رو به دلخواه خودش تعیین کنه.
مورد دیگه اینکه طول فیلدها هم باید جوری در نظر گرفته بشه که اولا رابطه بین جداول حفظ بشه دوما کاربر بتونه تعیین کنه مثلا برای حساب کل 2 رقم یا 3 رقم نیاز داره یا به حساب معین 2 -3یا 4 رقم اختصاص بده. البته این مورد دیگه خیلی ریز میشه و به قسمت طراحی برمیگرده.
ما الان میخواهیم نیازمندیهای یک قسمت تعریف حساب در سیستم مالی رو شناسایی کنیم.
بعد ازاون به سمت طراحی دیاگرامها بریم.

سوال 1: برای تعریف بانک و دسته چک چه تدابیری اندیشیده اید؟
سوال 2: چند سطح حساب معمولا برای سیستمهای مالی نیاز هست؟

[hossein_h62]

ولی فکر میکنم بهتر باشه کاربر خودش بتونه این گروهها رو تغییر بده و بتونه کدینگ های اونها رو به دلخواه خودش تعیین کنه.

گروه حسابها که در پست قبلی ذکر شد گروههای استاندارد حسابداری هستند،کاربر چه تغییری میتونه توی این گروه بندی بده ؟!

سوال 1: برای تعریف بانک و دسته چک چه تدابیری اندیشیده اید؟

در همون سیستم طراحی شناور حسابهای تفصیل، یک طبقه تفصیل رو طبقه بانکها تشکیل میدن، هر بانک/حساب بانکی یک حساب تفصیل خواهد داشت.

سوال 2: چند سطح حساب معمولا برای سیستمهای مالی نیاز هست؟

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

[saeid69]

خیلی کارتون درسته
در مورد
کدینگ بهتر نیست که حساب ها دارای 3 فیلد جدای عددی سرفصل و معین و حساب در یک جدول باشند تا اینکه بیایم این 3 رو در یک فیلد کاراکتری بیاریم.
مزایای این روش :
1. کاربر با این روش میتونه هر رقم که خواست تعریف کنه و محدود به کدینگ نیست
2. Sql هم با این روش سازگار تره و میتونید Relation برقرار کنید
3. نوع فیلد ها از نوع عددند و فضای کمتری را اشغال مینمایند و سر عت را افزایش میدهد
4. منطقی تر هم هست (به نظر من)

در مورد بانک و دسته چک هم که میتونند هرکدام یک جدول جدا باشند و با این حساب ها ارتباط برقرار کنند.

[alireza1514]

در مورد طراحی جداول اطلاعات پایه اگه بحواهیم جداول را طراحی کنیم ....باید..یا بهتره بگم دوتا فیلد در نظر میگیریم یه فیلد به عنوان فیلد primer key ويك فيلد دیگر را به عنوان کد در نظر می گیریم...مثال: جدول کل این روش استاندارده
kol_id int identity primery key
kol_number int
GOID int

[حمیدرضاصادقیان]

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

همچنان منتظر نظر دوستان هستم.

[ab_ba]

با سلام
من یک روش ابداع کردم که تو اون تمام حسابها توی یک جدول تعریف میشن
به این ترتیب تو تعداد تفضیلی ها هیچ محدودیتی نداریم
طول کد حسابها هم متغیر است و دلخواه کاربر

[ostovarit]

با سلام
من یک روش ابداع کردم که تو اون تمام حسابها توی یک جدول تعریف میشن
به این ترتیب تو تعداد تفضیلی ها هیچ محدودیتی نداریم
طول کد حسابها هم متغیر است و دلخواه کاربر

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

[حمیدرضاصادقیان]

حالا آقاي صادقيان : بياين بزنيم توي سرخودمون توي اين تاپيكها و پستها داد بزنيم كه رابطه چيه و چنده !؟

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

[Rejnev]

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

[MOJTABAATEFEH]

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

[mahdy.asia]

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

[Rejnev]

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

با سلام و تشکر.
1- میشه بگید وقتی سندی به صورت اتومات و بعد از ثبت مثلا یک فاکتور خرید، ایجاد شد، در صورت ویرایش و یا حذف سند فاکتور خرید، باید چهکاری صورت بگیره.
2- در ثبت سند حسابداری، تراز سند معمولا ثبت میشه. مثلا به ازای یک سند خرید(بستانکار)، یک سند پرداخت هم به صورت بدهکار ثبت میشه. و همه این رکوردها تشکیل یک سند رو میدن(master/detail). حالا بفرمایید که در روش ثبت سند خودکار باید چطوری این تراز رو ایجاد کنیم؟

[k1csharpdeveloper]

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

[Mahbod Rad]

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

Acc_1.jpg

[Mahbod Rad]

سلام دوباره
از لحاظ ساختار جدول برای حسابها جدول زیر را تعریف کردم

CREATE TABLE [dbo].[AccAccount] (
[AccSi] [int] IDENTITY (20, 1) NOT NULL , سریال جدول
[AccKnd] [bit] NULL , نوع حساب :ه آیا آخرین سطح حساب است یا پدری است که فرزند دارد
[AccCu] [smallint] NULL , کد حساب
[AccName] [nvarchar] (50) COLLATE Arabic_CI_AS NULL , نام حساب
[AccActive] [bit] NULL , فعال بودن یا غیر فعال بودن حساب برای آنکه در زمان صدور اسناد حسابداری فقط حسابهای فعال را در اختیار کاربر قرار دهد
[AccFather] [int] NULL , سریال پدر حساب
[AccTafzili] [tinyint] NULL , نوع تفضیلی. با یک عدد اعلام میکنم که تفضیلی اشخاص است - یا مراکز هزینه - یا کالا یا گروههای کالا و غیره
[AccFullNames] [nvarchar] (200) COLLATE Arabic_CI_AS NULL - نام کامل حساب به همراه اجدادش برای نمایش راحتتر به کاربر
) ON [PRIMARY]

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

[Mahbod Rad]

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

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

[Mahbod Rad]

با سلام و تشکر.
1- میشه بگید وقتی سندی به صورت اتومات و بعد از ثبت مثلا یک فاکتور خرید، ایجاد شد، در صورت ویرایش و یا حذف سند فاکتور خرید، باید چهکاری صورت بگیره.
2- در ثبت سند حسابداری، تراز سند معمولا ثبت میشه. مثلا به ازای یک سند خرید(بستانکار)، یک سند پرداخت هم به صورت بدهکار ثبت میشه. و همه این رکوردها تشکیل یک سند رو میدن(master/detail). حالا بفرمایید که در روش ثبت سند خودکار باید چطوری این تراز رو ایجاد کنیم؟

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

[kamyar_a]

با سلام .

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

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

[Mahbod Rad]

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

[alireza1514]

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

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

[alireza1514]

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

[Mahbod Rad]

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

دوست عزیز من هیچ وقت کلید جداول را روی اطلاعاتی که میتواند توسط کاربران ویرایش شود قرار نمیدهم. شماره سند دیتایی است که توسط کاربران به راحتی میتواند بارها تغییر کند. بهتره کلید رابطه جداول را ID های جداول باشد و یا هر چیز دیگری که اطلاعات و مقدار آن توسط برنامه مدیریت شود

[nazanin61]

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

به نظر شما اول باید ساختار حسابها (کل و معین و تفضیلی) مشخص بشه یا سال مالی در سیستم حسابداری؟

اگه سوالاتم مبتدیانه است ببخشید

و اینکه فرق طراحی در سیستمی که در سرور استفاده می شه با سیستم هایی که کاربر استفاده می کنن در چی ؟ و کجا مشخص می شه ؟؟؟

[Rejnev]

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

[حمیدرضاصادقیان]

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

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

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

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

[mohammadi4net]

اولین چیزی که برای تحلیل یک سیستم نیاز داریم دانش مربوط به اون سیستمه که برای شروع پیشنهاد می کنم کتاب های اصول حسابداری یک و دو رو حتما مطالعه کنید.
لینک مفید !

یک سیستم حسابداری حداقل شامل قسمت های زیر می باشد :
1. کدینگ حسابداری
2. عملیات اسناد
3. عملیات فاکتور و کالا
4. عملیات چک

برای ساده کردن موضوع پیشنهاد می کنم مثالی جلو بریم ، و به دلیل ساده بودن ساختار سند اول اونو توضیح میدیم بعد می ریم سراغ گزینه های بعدی :
بهترین راه حلی که من بلدم استفاده از ساختار مستر دتیل است:
جدول مستر :
شماره سند (یکتا) ، تاریخ سند ، شرح سند ، قطعیت سند
جدول دتیل :
شماره سند(کلید خارجی)،کد حسابداری، بدهکار ، بستانکار، شرح آرتیکل

1 ، " 1390/03/05" ، "دریافت بدهی" ، خیر
2، 06/03/1390"، "پرداخت هزینه آب و برق"، خیر

... ، 1 ، 101(صندوق)، 1000، 0، " "
... ، 1 ، 201(بدهکاران ،محمدی)، 0، 1000، " "
... ، 2 ، 101(صندوق)، 0، 800، " "
... ، 2 ، 603(هزینه، آب)،300، 0، "طی قبض شماره 1252544"
... ، 2 ، 608(هزینه، برق)،500، 0، "طی قبض شماره 9864654"

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

[حمیدرضاصادقیان]

اولین چیزی که برای تحلیل یک سیستم نیاز داریم دانش مربوط به اون سیستمه که برای شروع پیشنهاد می کنم کتاب های اصول حسابداری یک و دو رو حتما مطالعه کنید.

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

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

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

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


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

[mohammadi4net]

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

اگه بخواهیم از کدینگ درختی استفاده کنیم می تونیم از چنین ساختاری استفاده کنیم :

همون طور که می بینید تمام حساب های کل و معین (تفصیلی رو هم میشه به همین روش اضافه کرد) توی یک جدول هستند.
و در نوع فیلد مشخص کردیم چه نوع حسابیه K کل M معین T تفصیلی برای سند از کد سرفصل استفاده می کنیم که ممکنه کل معین یا تفصیلی باشه.

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

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

[حمیدرضاصادقیان]

خوب من در بالا توضیح دادم .
قصد پیاده سازی سیستم کدنیگ شناور رو داریم. نمیخواهیم کدینگ حسابداری رو درست کنیم. میخواهیم یک ساختار تعاریف حساب کلی درست کنیم که هرکسی با هر سلیقه ای بتونه هر دیتایی رو توش وارد کنه.
پس عملاً فعلا نیازی نیست وارد مقوله سند بشیم. ما داریم فعلا از بالا به مساله نگاه میکنیم و دیدمون طراحی یک سیستم تعریف حساب جامع و کلی هست.
الان شما باز دارید به دید دیتابیسی به مسئله نگاه میکنید!
اصلا از فکر جدول و فیلد و ارتباط بیاید بیرون. خیلی کلی به مسئله بنگرید.لطفا یکبار دیگه پستهای 32و34 رو با دقت بخونید ببینید دقیقا چه چیزی مدنظر هست.
من اصلا کاری ندارم نوع فیلدها چیه، چند تا جدول نیاز داریم ، ارتباطشون چه جوریه و...
فعلا ما میخواهیم نیازمندیهای تعاریف حساب رو دربیاریم. من در پست 32 توضیح دادم چی میخواهیم. در پست شماره 34 نمونه ای از موجودیتها رو نوشتم. لطفا تمرکزتون رو روی این قسمت معطوف کنید.
باتشکر.

[nazanin61]

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

آقای صادقیان به نظر من شما مطالب خودتون را در قسمت مربوطه بذارید باشد که روزی کسانی ازش استفاده کنن

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

بقیه حسابها در این 4 تاگنجانده می شود

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

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

و
.
.

هم برای خودشان سیستم های جداگانه ای هستند که همه حسابها در کل به 4 بخش کل ، معین ، تفضیلی 1 و 2 تقسیم می شوند
امیدوارم تونسته باشم منظورم را درست رسونده باشم

[Mahbod Rad]

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

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

باتشکر.

آقای صادقیان وقت بخیر
من منظور شما را از گروه تفضیلی نمیفهمم. گروه تفضیلی دیگه چیه؟
در ضمن اشخاص را اعم از حقیقی و حقوقی در یک جدول قرار میدهم و برایم فرقی ندارند که این شخص که بدهکار است حقیقی است یا حقوقی. شما برای چه منظور و هدفی آنها را جدا کرده اید؟
منظورتان از شرح ثابت حسابها چیست؟
آیا اینکه چک ها را به عنوان یک موجودیت در نظر گرفته اید برای این بوده که به عنوان تفضیلی دیده شود یا صرفاً هدف این بوده که کنترلی روی چکهای اشخاص(که دریافت میکنیم) و چک شخصی(که صادر میکنیم) باشد؟
در ضمن بندهای 5و6و7 را جزو حسابهای تفضیلی در نظر میگیرم. ضمن آنکه عنوانهای دیگری را هم به این موضوع اضافه میکنم از جمله مراکز هزینه که مدیران خیلی علاقه دارند که بدانند کدام قسمتهای شرکتشان برایشان هزینه بیشتری دارند
لطفاً مواردی که در ذهنتان است را بیشتر باز کنید

www.Abshar-System.ir

[حمیدرضاصادقیان]

ممنون از اینکه وقت گذاشتید شرکت کردید.

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

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

منظورتان از شرح ثابت حسابها چیست؟

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

آیا اینکه چک ها را به عنوان یک موجودیت در نظر گرفته اید برای این بوده که به عنوان تفضیلی دیده شود یا صرفاً هدف این بوده که کنترلی روی چکهای اشخاص(که دریافت میکنیم) و چک شخصی(که صادر میکنیم) باشد؟

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

در ضمن بندهای 5و6و7 را جزو حسابهای تفضیلی در نظر میگیرم. ضمن آنکه عنوانهای دیگری را هم به این موضوع اضافه میکنم از جمله مراکز هزینه که مدیران خیلی علاقه دارند که بدانند کدام قسمتهای شرکتشان برایشان هزینه بیشتری دارند

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

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

[حمیدرضاصادقیان]

تا حد زیادی طراحی سیستم و ساخت جداول سلیقه ای است

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

کد حسابها 4 مورد کافی کل ، معین ، تفضیلی در سطح 1 و تفضیلی سطح 2

بقیه حسابها در این 4 تاگنجانده می شود

بعضی از مراکز ، مثل شرکتهای پیمانکاری نیاز دارن سطوح بیشتر باشه.

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

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

[Mahbod Rad]

آقای صادقیان عزیز
در مورد گروهای تفضیلی منظورتان را متوجه شدم.
به نظرم روش اصولی همین است که شما فرمودید و منهم در برنامه هایم از آن استفاده میکنم.
اما در مورد اشخاص شامل حقیقی و حقوقی و این مورد آخر مشتریان که شما برای آن نیز یک گروه باز کردید با شما مشکل دارم. اگر اینطور پیش برویم به زودی پرسنل هم یک گروه تفضیلی میشوند؟
من تمام اشخاص حقیقی و حقوقی را با حداقل فیلدهای عمومی برای شناسایی فرد را در یک جدول تعریف میکنم و از آن در تفضیلی اشخاص استفاده میکنم(حقیقی - حقوقی - پرسنل - مشتریان - ...) اگر نیاز به اطلاعات بیشتر برای یک دسته خاص از افراد داشته باشم یک جدول کمکی برای آن دسته ایجاد میکنم که در ارتباط با جدول اشخاص میباشد اما لزومی نمیبینم که در تفضیلی ها بیایم و این موارد را جدا کنم. البته از یک نظر شمادرست میگوئید مثلاً شرکتی میخواهد به کارمندش حقوق بدهد بهتر است یک تفضیلی از نوع پرسنل داشته باشد که در زمان سند زدن اشخاص دیگر دیده نشوند. اما تا آنجا که من میدانم این ریز شدن کار خود آن شرکت را سخت میکند و مجبور میشود حسابداری سختتری را انجام دهد. برای نمونه در همین مثال فرض کنید در آن شرکت افراد به صورت بازاریابی کار میکنند و از طریق ویزیتوری از شرکت کسب درآمد میکند و عملاً مستخدم شرکت نیستند.
در مورد اون قسمت از صحبتهاتون که فرمودید کاربر مراکز هزینه و حسابها و ... را تعریف میکنه و زیر مجموعه آنها افراد را معرفی میکنه نیز یکم باهاتون مشکل دارم چون در این موارد کاربر صرفاً افراد تعریف شده در جدول اشخاص را میتواند به این موارد تخصیص بدهد.
البته در مورد اهداف حسابداری میتوانیم در زمان سند زدن از دو تفضیلی اشخاص و مراکز هزینه استفاده کنیم.
www.Abshar-System.ir

[حمیدرضاصادقیان]

سلام.

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

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

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

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

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

خواص موجودیت اشخاص حقیقی :

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

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

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