# پایگاه‌های داده > SQL Server > T-SQL > تحلیل و طراحی بانک اطلاعات >  گفتگوی فنی در مورد طراحی 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-دارایی
> ...


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





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


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






> یعنی در اولین گام تعیین طبقه حسابها :
> 
> 1- حسابهای ترازنامه ای
> 2- حسابهای سود و زیانی
> 3- حسابهای آماری و انتظامی
> 
> پس از اون تعیین گروه حسابها :
> 
> 1- دارائیها (مربوط به طبقه 1 )
> ...


گروههای حسابداری ثابت هستند ولی فکر میکنم بهتر باشه کاربر خودش بتونه این گروهها رو تغییر بده و بتونه کدینگ های اونها رو به دلخواه خودش تعیین کنه.
مورد دیگه اینکه طول فیلدها هم باید جوری در نظر گرفته بشه که اولا رابطه بین جداول حفظ بشه دوما کاربر بتونه تعیین کنه مثلا برای حساب کل 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- اشخاص حقوقی
> ...


آقای صادقیان وقت بخیر
من منظور شما را از گروه تفضیلی نمیفهمم. گروه تفضیلی دیگه چیه؟
در ضمن اشخاص را اعم از حقیقی و حقوقی در یک جدول قرار میدهم و برایم فرقی ندارند که این شخص که بدهکار است حقیقی است یا حقوقی. شما برای چه منظور و هدفی آنها را جدا کرده اید؟
منظورتان از شرح ثابت حسابها چیست؟
آیا اینکه چک ها را به عنوان یک موجودیت در نظر گرفته اید برای این بوده که به عنوان تفضیلی دیده شود یا صرفاً هدف این بوده که کنترلی روی چکهای اشخاص(که دریافت میکنیم) و چک شخصی(که صادر میکنیم) باشد؟
در ضمن بندهای 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- میزان اعتبار

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

----------


## Mahbod Rad

> *خواص موجودیت اشخاص حقیقی :*
> 
> 1- کد شخص
> 2- نام شخص 
> 3- نام خانوادگی
> 4- شماره تماس
> 5- آدرس
> 6- کد ملی 
> 7- کد پستی
> ...


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

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

----------


## Mahbod Rad

> مرکز هزینه رو میشه یک قسمت از حسابهای هزینه در نظر گرفت پس از موجودیت کد حساب حذف میشه.


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

----------


## mohammadi4net

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


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



> کد تفصیلی شناور یا همون سطح چهارم و در بعضی از نرم افزار ها بعضاً پنجم و ششم ، شامل گروه هایی مانند نام اشخاص حقیقی و حقوقی ، طرف حساب ها ، قراردادها ، صورت وضعیت ها و غیره می باشد ، 
> برای مثال شما حساب های کل و معین و تفصیلی های زیر را دارید ،
> گروه                 1          دارایی های جاری
> حساب کل        12        حسابهای دریافتنی تجاری   
>   معین              1201    حساب های دریافتنی
>  معین               1202   مطالبات مشکوک الوصول
> 
> تفصیلی   20001   شرکت  الف
>                 002005  آقای رضایی
> ...


و در ادامه دوست دیگری اینجوری توضیح دادن :



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

----------


## Mahbod Rad

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

----------


## hossein_h62

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



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


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

----------


## mohammadi4net

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

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

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

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

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

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

----------


## حمیدرضاصادقیان

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

فرض کنید ما می خواهیم این سرفصل رو تعریف کنیم.
*
توجه : من گروه حساب رو ذکر نمیکنم چون گروههای حساب ثابت هستند.
*
1- موجودی نقد و بانک 
    - بانکها
           - بانک صادرات
              - شعبه عباس آباد
                 - جاری 12345
              - شعبه بلوار ناهید
                 - جاری 101082
           - بانک ملی
               - شعبه گلفام
                    - جاری 5210765
           - بانک تجارت
               - شعبه بلوار آفریقا
                    - پس انداز 125436

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

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


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

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

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

----------


## nazanin61

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

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

----------


## mohammadi4net

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

----------


## حمیدرضاصادقیان

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

----------


## nazanin61

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

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

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

----------


## حمیدرضاصادقیان

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


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




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


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

----------


## linux

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

----------


## حمیدرضاصادقیان

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

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

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

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

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

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

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

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

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

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

----------


## alireza1514

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

----------


## Elham.M

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

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

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

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


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

----------


## Elham.M

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

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

----------


## linux

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

----------


## pooyan3000

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


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

----------


## noroozifar

نمیدونم چرا این بحث ها تا یک حدود میرند و بعدش هم می خوابند گفتم بنویسم شاید دوباره ادامه پیدا کنه :
من تاپیکها را مطالعه کردم و نتایج خودم را می نویسم :
سطح کلی طبقات : این سطوح تقریبا در تمامی نرمافزارها ثابت می باشند در اصل همان گروه حسابها هستند و کلیه گزارشها در نهایت از این موارد گرفته می شوند و اینها ریشه درختواره حساب ما به حساب می ایند
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. ما حسابها ی خود را تعریف کردیم و گروه ها .. دفتر کل .. معین .. تفصیل ... حالا سئوال اینجاست ارتباط ما بین این حسابها با فاکتور ما و اطلاعات پایه ما که شامل بانک . صندوق. بستانکاران . بدهکاران . کارمندان .. به چه صورت می باشد .

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

----------


## linux

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

----------


## noroozifar

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


ای کاش بیشتر توضیح میدادید ... و نمونه نرم افزارتون را زودتر میگذاشتید تا مشکلاتم هل بشه ...

----------


## linux

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

----------


## noroozifar

> جدولهای زیرا من پیشنهاد می کنم برای حسابداری


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

----------


## mohammadi4net

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


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

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

----------


## linux

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


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

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

----------


## linux

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


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

----------


## noroozifar

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

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

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

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

----------


## linux

جدول 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 تهیه می شوند،

----------


## noroozifar

درسته فرد حسابدار خیلی جاها منو گمراه میکنه و فکرکنم الان کاملا گیج شده ام نمی تونم سیستم را تحلیل کنم شاید مشلوره با این فرد باشه ..
گفتید جدول 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
خوب ایا سند من درست زده شد ؟
بعد یکسری علامت ؟ گذاشتم نمیدونستم چه مقادیری میگیرند ؟

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

----------


## linux

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

----------


## noroozifar

> تعریف حسابها را اشتباه انجام دادید،


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

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

----------


## linux

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


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

----------


## havakili

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

----------


## nowar1352

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

----------


## linux

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


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

----------


## tiphooo

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

----------


## mohammadi4net

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

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

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

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

----------


## tiphooo

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

----------


## linux

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


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

----------


## mohammadi4net

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


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

----------


## mohammadi4net

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


بهتره این بحث ادامه ندیم چون از اصل مطلب دور میشیم ، شما هرجور صلاح می دونید ادامه بدید.

----------


## linux

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


با آن ساختار درختی که گفته شد دست کاربر باز تا هر جور که  می خواهد کدینک تعریف کند

----------


## noroozifar

آقا خیلی دلمان می خواهد این بحث به جای برسد که ماها که تجربه برنامه نویسی کمی داریم بتونیم یک سیستم حسابداری ایجاد کنیم آقای linux قول داده بودید که نمونه کد بزارید برنامه بنویسید و اینجا قرار بدید ؟؟؟

----------


## mahan.2002

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

----------


## linux

> آقا خیلی دلمان می خواهد این بحث به جای برسد که ماها که تجربه برنامه نویسی کمی داریم بتونیم یک سیستم حسابداری ایجاد کنیم آقای linux قول داده بودید که نمونه کد بزارید برنامه بنویسید و اینجا قرار بدید ؟؟؟


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

----------


## noroozifar

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


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

----------


## delphidark

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

اما در عوض کلی تناقض موجود هست !


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

----------


## swallow.pa

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

----------


## noroozifar

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

----------


## swallow.pa

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

----------


## tiphooo

معمولا تاریخ تاسیس یک شرکت به عنوان مبدا شروع سال مالی تعریف شده و طول آن معمولا  365 روز می باشد و همیشه منظور از سال مالی یک سال کامل از 1/1 الی 12/29 نیست مثلا می تواند از 91/07/01 الی 92/06/31 باشد و در سیستم حسابداری بازه شروع شماره اسناد در پایان دوره مجددا reset شده و از یک شروع می شود پس باید معلوم شود بالفرض سند شماره 10 از کدام سال مالی چون ممکن است چندین سال مالی داشته باشیم و در همه آنها سند شماره 10 وجود داشته باشد
در کلیه سیستم ها با انتخاب سال مالی معمولا با ورود به هر فرم باید اطلاعات مربوط به سال مالی (دوره مالی ) انتخاب شده نمایش داده شود
گاها بعضی از شرکتها برای اینکه سال مالی آنها از ابتدا تا انتهای یک سال شمسی باشد تاریخ تاسیس شرکت تا پایان همان سال را یک دوره در نظر گرفته و دوره های بعدی از ابتدا تا انتهای سال می باشد و طول دوره اول در این حالت از سایر دوره ها کوتاهتر است بنابراین الزامی برای یکسان بودن طول دوره مالی وجود ندارد

----------


## mohammadi4net

> .... همیشه منظور از سال مالی یک سال کامل از 1/1 الی 12/29 نیست مثلا می تواند از 91/07/01 الی 92/06/31 باشد....


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

----------


## linux

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


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

----------


## masoomenoroozi

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

----------


## noroozifar

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

سئوال دیگه اینه :
ما الان بلفرض یک شاخه حساب داریم به این صورت :
1. دارایی - دارایی جاری - بانک - بانک صادرات - حساب سپهر - شماره حساب1
2.- سرمایه
3- بدهکاریها
4..

می خواستم ببینم حساب یک شخص مثلا " اقای نوروزی "  حسابش جز کدام دسته از کدینگ حسابها میشه ؟

----------


## tiphooo

دوست عزیز نقطه شروع و خاتمه سال مالی را شما مشخص نمی کنید که مثلا با تاریخ یا ساعت سیستم کنترل کنید
سال مالی را کاربر تعریف می کند شروع سال مالی شاید بیشتر از 50 درصد شرکتها ابتدای سال شمسی نیست و گرنه مثلا می گفتند سال 1391 یا 1390 دیگر نمی گفتند سال مالی
و در مورد حسابرسی که دوستمون گفتن حسابرسی هر سال مالی در انتهای سال دیگر صورت می گیرد و اگر مثلا شروع سال مالی یک شرکت 10/01 باشد در سال بعد حسابهای انجا حسابرسی می شود و اگر هم 01/01 هم بود باز به همین شکل بود
آقای نوروزی فر در لیست حسابهای مالی نیست اشخاص در تفصیلی ها مشخص می شوند نه در حسابهای مالی

----------


## noroozifar

من میدونم شخصها در تفصلیها می باشند اما جزو کدام دسته ؟؟

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

----------


## tiphooo

لیست تفصیلی ها از حسابهای مالی جداست
مثلا  دارایی - دارایی جاری - بانک - بانک صادرات - حساب سپهر - شماره حساب1 
اگر بخواهید اینها را به صورت درختواره تعریف کنید دچار اشتباه شده اید
درست آن به این شکل است
 دارایی جاری - بانک - صندوق ریالی   ------------> این موارد در قسمت حسابهای مالی تعریف می شود
بانکها - بانک صادرات شماره حساب 1  -----------> این قسمت در تفصیلی ها تعریف می شود
جدول حساب و تفصیلی از هم جداست
سال مالی در سال اول می تواند حتی 10 روزه باشد و در سالهای بعد 365 یا 366 روزه است
بنابراین اینکه سال مالی همیشه 365 روز است اینگونه نیست
کلمه سال مالی را یا کلمه <<سال>> اشتباه نگیرید . سال با سال مالی فرق می کند
شما به جای سال مالی از کلمه دوره مالی استفاده کنید شاید مفهوم را بهتر برساند
حتما در مدرسه به یاد دارید که می گفتند سال تحصیلی 91-90 شروع دوره مالی آنها از 1390/07/01 الی 1391/06/31 می باشد

----------


## noroozifar

من سال مالی را به این صورت جدولش را ایجاد کردم
ID  سال مالی
Name نام سال مالی
Datestart شروع سال مالی
Datefinish پایان سال مالی

و ای دی این سال مالی را در تمامی سندها و فاکتورها و حتی در کالاها هم قرار داده ام که تقریبا به این صورت شده 
IDSaal ای دی سال مالی
ID سند 
شماره سند 
نوع سند

ایا به این صورت درست می باشد

----------


## hadi_peek

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

----------


## علی فتحی

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

----------


## ahsaya

با سلام .


من یک سئوالی برام پیش اومده .

باید برای هر سال مالی یک دیتابیس جداگونه تعریف بشه یا نه کل اطلاعات رو می شه توی یک دیتابیس ذخیره کرد ؟

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

----------


## mahdy.asia

> باید برای هر سال مالی یک دیتابیس جداگونه تعریف بشه یا نه کل اطلاعات رو می شه توی یک دیتابیس ذخیره کرد ؟


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

----------


## ahsaya

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


با فرض طراحي يك ديتابيس براي كل اطلاعات ، اگر سالهاي مالي متعددي ايجاد شود و در هر سال مالي ، اسناد حسابداري زيادي هم ثبت شود ، سرعت لود اطلاعات به شدت كاهش مي يابد .

همچنين گزارشگيري از اطلاعات نيز مستلزم صرف زمان زيادي مي باشد .

من فكر مي كنم كه بايستي هر سال مالي ديتابيس جداگانه اي داشته باشد .

----------


## ahsaya

اين تاپيك تعطيل شده يا هنوزدوستاني هستن كه بخوان بحث روادامه بدن ؟

من همه موضوعات مطرح شده رو مرور كردم . مطالب جالبي عنوان شده و حيفه كه نيمه كاره رها بشه .

اگه دوستان همكاري كنن و اساتيد كمك كنن اين بحث رو به يه سرانجامي برسونيم . هدف كسب تجربه و آموزش مگه نيست .

تحليل سيستمهاي مالي به دليل فراگير بودنشون خيلي به افزايش مهارتها كمك مي كنه .

دوستان اعلام آمادگي كنن .

----------


## sarahjoon

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


سلام ساختاري كه معرفي كرديد اصلا قابل مشاهده نيست :متعجب:  :گیج:

----------


## mohsen5459

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

----------


## ali_md110

سلام 
اول اینکه اگر امکان داره چدولتون رو به 2 چدول گروه و کالاها تبدیل کنید و رابطه بین چداول برقرار کنید 
ولی با هیمن چدول موجود هم میتونید از فیلد کد گروه به کد کالا ارتباط برقرار کنید

بعدش کوئری تون بسازید

"select kalaname from kala where groupid="filter mored nazar


kalaname  فیلد نام کالاتون هست و groupid فیلد کد گروه

----------


## علي فتحي

دوستان ميتونيد حسابداري تارارو دانلود كنيد. براي هر سال مالي يك بك آپ يا همون سال مالي جديد درست ميكنه در ضمن بانك اطلاعاتي اون قايل استفاده ميباشد.http://www.taragroup.org/Downloads.aspx

----------


## ali_md110

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

----------


## siavash525

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


با تشکر از شما : 
در یک برنامه حسابداری بهتر هستیکسری حسابها بعنوان حسابهایسیستمی تعریف شن مثل: حسابهای سرمایه ، اسناددریافتنی ، اسناد پرداختنی ، صندوق ، درآمد فروش ، قیمت تمام شده کالای فروش رفته : موحودی کالا و...
البته قبل از همه باید مشخص بشه که ما می خوایم فوندانسیون حسابداری مون رو بر اساس حسابداری دائمی تعریف کنیم یا حسابداری ادواری ؟ و یا کاربر می تونه در همون اول برنامه انتخاب کنه و .....
بقیه حسابها رو خود کاربر باید بتونه تعریف و کد گذاری کنه . لازم به توضیح هست که کدهایی که در نظر می گیریم بر اساس استاندارد موجود باشند که برای دارائی ها کد 1 - بدهی ها کد 2 ، سرمایه کد 3 ، درآمدها کد 4 ، خرید و قیمت تمام شده کد 5 و هزینه ها کد 6 تعریف شده

----------


## siavash525

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


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

----------


## siavash525

> حالا این سیستم مالی  چه جوری میشه پیاده سازیش کرد یعنی  به چه طریق کنترل کنیم که 365 روز فرار رسید اخه با ساعت سیستم نمیشه چون امکان داره کاربر ساعت و تاریخ سیستم را جلو یا عقب ببره به چه طریق میشه کنترل کرد ؟
> 
> سئوال دیگه اینه :
> ما الان بلفرض یک شاخه حساب داریم به این صورت :
> 1. دارایی - دارایی جاری - بانک - بانک صادرات - حساب سپهر - شماره حساب1
> 
> 
> 2.- سرمایه
> 3- بدهکاریها
> ...


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

----------


## ali_md110

> این روش برای یک سفارش خوب هست ولی اگر می خواید برنانه ای کلی بنویسید باید این امکان رو برای کاربر قرار بدید که خوذش حسابهای کل ، معین و تفضیلی رو بصورت شاخه ای یا درختی ایجاد بکنه و بتونه گزارش هم بگیره یعنی گزارش هم درختی و شاخه ای باشه


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

----------


## mojtaba0912433

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

----------


## علی فتحی

اینم یک نمونه ساده  یک نونه خوب از بانک هم دارم نمیتونم ارسال کنم نمیدونم چرا؟

----------


## علی فتحی

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

----------


## eng.szarei

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

----------


## SepehrJon

ممنون از مطالبتون

----------


## mahshahr_63m

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

----------


## HadiVB

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

----------


## stabesh

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

----------


## behzad_lover

خسته نباشید دوستان...
(چون مبحث پیش پا افتاده ای هست و پاسخش کوتاه دیگه تاپیک جدیدی نزدم...)

معادله اصلی حسابداری اینه:
دارایی ها = بدهی ها + سرمایه

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

1-دارایی ها جاری
2-دارایی های غیر جاری
3-بدهی های جاری
4-بدهی های بلند مدت
5-حقوق صاحبان سهام
6-درآمدها
7-بهای تمام شده کالای فروش رفته و خدمات ارائه شده
8-هزینه ها
9-سایر حساب ها (که میشه انتظامی و ...)

پیشاپیش ممنونم...

----------


## علی فتحی

جدولهای کل -معین و تفضیل رو تو اینجا طراحی کردم فقط مشکلی که وجود داره . حساب تفضیلی شناو هستش که نمیدونم باشون چ کارکنم.برای تفضیلهای ثابت مشکلی که وجود داره در هنگام استفاده از سند هستش .معینهایی که حساب تفضیل ندارن ثبت نمیشن .البته هدف جداول بانک بود واسه همین سورس رو ارسال نکردم . کسی خواست درخدمتم.
آیا حسابهای شناور هم باید به معین جوین بشن؟
اگر جوین نشن در ثبت سند مشکلی نست ولی در حساب ترازنامه مشکل ایجاد میشه
اگرجوین بشن بازم مشکل بالاپیش میاد برای معینهایی که تفضیل ندارن
http://s3.picofile.com/file/81927355...older.rar.html
vs2010

----------


## علی فتحی

مشکل حل شد تفضیل رو جوین نباید کرد

----------


## علی فتحی

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

----------


## علی فتحی

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

----------


## علی فتحی

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

----------


## pbm_soy

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

در هرصورت تصمیم و قضاوت با شماست

----------


## علی فتحی

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

----------


## bobesfanji

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

----------


## علی فتحی

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

----------


## Vidico

> جدولهای کل -معین و تفضیل رو تو اینجا طراحی کردم فقط مشکلی که وجود داره . حساب تفضیلی شناو هستش که نمیدونم باشون چ کارکنم.برای تفضیلهای ثابت مشکلی که وجود داره در هنگام استفاده از سند هستش .معینهایی که حساب تفضیل ندارن ثبت نمیشن .البته هدف جداول بانک بود واسه همین سورس رو ارسال نکردم . کسی خواست درخدمتم.
> آیا حسابهای شناور هم باید به معین جوین بشن؟
> اگر جوین نشن در ثبت سند مشکلی نست ولی در حساب ترازنامه مشکل ایجاد میشه
> اگرجوین بشن بازم مشکل بالاپیش میاد برای معینهایی که تفضیل ندارن
> http://s3.picofile.com/file/81927355...older.rar.html
> vs2010


مهندس جان سورسش رو هم لطف می کنید؟ ممنون میشم

----------


## cybercoder

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

ابتدائا بنده جداولی به صورت زیر ساختم:

codings: id,titile,essence
codings_map : id,coding_id,parent_coding_id

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

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

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

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

با تشکر.

----------


## qartallar

ممنون از بابت همه دوستان در این 5 سالی که در این تاپیک فعال بودند ولی بعد اینهمه یه سند زدن ساده هم گفته نشد.

----------


## basiry

منم كاملا با حرف شما موافقم :ناراحت:  :ناراحت:

----------


## sh

دوستان سلام

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


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

مطالب این سایت را بخوانید

http://accplus.blog.ir/1393/08/28/

(برای بزرگ نمایی عکسها آنها را در یک صفحه دیگر باز کنید)

یک تفضیلی درست کرد

فرض کنید کارمند A در زیر گروه تنخواه گردان ثبت می شود که در زمان ثبت سند متوجه شویم مربوط به فلان کارمند بوده

حال اگر بخواهیم مثلا به این کارمند وام بدهیم باید یک تفضیلی در قسمت وام های پرداختی که زیر گروه دارائی ها است باز به نام کارمد A ایجاد کنیم

و به همین ترتیب امکان دارد بخواهیم یک تفضیلی را در چند جا تعریف کنیم

پیشنهاد این سایت ایجاد جدول جداگانه حسابهای تفضیلی است

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

اگر دوستان تجربه ای در این خصوص دارند ممنون می شوم به شتراک بگذارند

----------


## chaabok

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

----------


## reza11_2005

سلام الان 1399 و چند روز دیگه میشه 1400 من به دلیل اینکه رشتم حسابداری و دارم یک سیستم حسابداری کوچک طراحی می کنم خیلی خوشحال شدم با این تایپیک برخورد کردام
حیف شد دیگه اپدید نشد
با اجاز جناب آشتیانی و دیگر اساتید محترم اگر مجالی بود بنده تجربیاتی که  در طراحی دیتابیس نرم افزار خودم به دست اوردم همینجا قرار می دهم

----------

