پیشنهاد در مورد طراحی جداول

[Alyas_Tet]

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

[hedayat]

اين روشي كه شما با اون دارين كار مي كنين حسابدارا بهش مي گن كدينگ مرتبط با كدينگ وابسته
حالا مشكل طراحي شما توي اين روش كه ابيته قديمي شده اينه كه اگه يك حساب مانند سرمايه كه فقط داري كل و معيينه رو بخواين ثبت بزنين ديگه با اين روش چون فقط لينك تفضيلي رو دارين مشكل دارين و نمي تونين اين ثبت رو انجام بدين.
بنابراين با فرض همين روش مرتبط بهتر اينه كه شما يك table براي همه حسابهاي كل و معين و تفضيلي در نظر بگيرين و فقط اونا را با يك فيلد مثلا به نام Type جدا كنين كه type 1 يعني كل و 2 معين و ...

و اون وقت فيلد شماره حساب رو به جدول Detail اسناد حسابداري ربط بدين
موفق باشي

[Alyas_Tet]

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

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

[Alyas_Tet]

کسی نیست کمک کنه ؟

[Arghavan_Reza]

دوست گرامی, توجه شما را به چند نکته جلب می کنم:
- جهت طراحی یک سیستم حسابداری لازم است حسابداری بلد باشید.
- با این حال, سیستم حسابداری ساده حداقل دارای مشخصات زیر است:
1 - جدول حساب ها ( گروه, کل, معین و ...) با تفکیک نوع حساب
2 - جدول تفصیلی ها (مثل شخص, پروژه, قرارداد و ...) که شناور بوده و وابسته به حسابی نیست.
3 - جدول سند.
4 - جدول جزئیات سند (با لینک به جدول حسابها و یک لینک به جدول تفصیلی ها)
* لینک به جدول حساب ها اجباری و لینک به تفصیلی ها اختیاری باشد.
(یعنی هر ردیف سند حتما به حساب معین ربط دارد ولی ممکن است تفصیلی نداشته باشد (مثل صندوق))
5 - با امکانات زبان برنامه نویسی امکان انتخاب حساب معین را با روش های مختلف در اختیار کاربر قرار دهید.

موفق باشید.

[Alyas_Tet]

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

[Arghavan_Reza]

* روش مذکور روش عمومی است و قریب به اتفاق طراحان از این روش استفاده میکنند!
* در روش های حرفه ای این شیوه استفاده نمی شود و تعداد انگشت شماری از هزاران سیستم حسابداری از روش جدید استفاده می کنند. ( مثل 3D Account )
* پاسخ سوال اول مثبت است.
* جدوال خرید و فروش و برگشتی و ... را یکی کنید و از فیلد کمکی برای تفکیک آنها استفاده کنید.
موفق باشید

[Microsoft.net]

دوست گرامی, توجه شما را به چند نکته جلب می کنم:
- جهت طراحی یک سیستم حسابداری لازم است حسابداری بلد باشید.
- با این حال, سیستم حسابداری ساده حداقل دارای مشخصات زیر است:
1 - جدول حساب ها ( گروه, کل, معین و ...) با تفکیک نوع حساب
2 - جدول تفصیلی ها (مثل شخص, پروژه, قرارداد و ...) که شناور بوده و وابسته به حسابی نیست.
3 - جدول سند.
4 - جدول جزئیات سند (با لینک به جدول حسابها و یک لینک به جدول تفصیلی ها)
* لینک به جدول حساب ها اجباری و لینک به تفصیلی ها اختیاری باشد.
(یعنی هر ردیف سند حتما به حساب معین ربط دارد ولی ممکن است تفصیلی نداشته باشد (مثل صندوق))
5 - با امکانات زبان برنامه نویسی امکان انتخاب حساب معین را با روش های مختلف در اختیار کاربر قرار دهید.

موفق باشید.

معين هم اجباري نيست خيلي از حسابها كل آخرين سطح آنها ممكن است باشد

[linux]

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

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

[Arghavan_Reza]

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

[Alyas_Tet]

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

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

[linux]

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

ممنون می شم اگر بیشتر توضیح بدهید ، اصلاحاتی که برای حساب ها لازم هست و فیلدهای اصلی doc_master و doc_Detail .

[linux]

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

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

شما باید یک چیزی شبیه treeview به کاربر نشان بدهی که خودش بیاد حساب را انتخاب کنه حالا ممکنه کاربر root را انتخاب کند یا child رتبه 10 ام را.

[Khalil morradi]

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

0001 

00010001 

00010002 

00010003 

000100010001 

000100010002 

000100020001 

000100020002

000100020003

0001000200030001

به این ترتیب شما میتوانید n رده را بر حسب طول فیلد طراحی کنید بدون اینکه نیاز به جداول اضافی داشته باشید تنها ایراد این نوع طراحی لزوم کد نویسی زیادتر اون است که این کار رو من توی sql server با sp انجام دادم در ضمن اینکه کلیه کنترلها رئ در سطح دیتا بیس انجام دادم

[linux]

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

0001 

00010001 

00010002 

00010003 

000100010001 

000100010002 

000100020001 

000100020002

000100020003

0001000200030001

به این ترتیب شما میتوانید n رده را بر حسب طول فیلد طراحی کنید بدون اینکه نیاز به جداول اضافی داشته باشید تنها ایراد این نوع طراحی لزوم کد نویسی زیادتر اون است که این کار رو من توی sql server با sp انجام دادم در ضمن اینکه کلیه کنترلها رئ در سطح دیتا بیس انجام دادم

این تقریبا همان جدول accCoding هست که من اینجا گذاشتم.برای یک حساب باید چه چیز دیگری را کنترل کرد؟

[Dariuosh]

PL =گروه
GL = کل
SL = معين
DL = تفضيل
DLFive=سطح پنجم
DLSix=سطح ششم
AccVchItm=آيتمهاي سند حسابداري
AccVchItm=هدر سند حسابداري

[linux]

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

[Alyas_Tet]

PL =گروه
GL = کل
SL = معين
DL = تفضيل
DLFive=سطح پنجم
DLSix=سطح ششم
AccVchItm=آيتمهاي سند حسابداري
AccVchItm=هدر سند حسابداري

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

[linux]

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

این حساب ها را در نظر بگیرید
-11 داراييهاي جاري
|- 1110- موجودي نقد وبانك
|--- 111001 صندوق ريالي-
|----11100101 صندوق ریالی 1
|----11100102 صندوق ریالی2
|--- 111002 صندوق ارزي
|--- 111003 تنخواه گردانهاي ريالي
|--- 111004 تنخواه گردانهاي ارزي
|--- 111005 موجودي بانكهاي ريالي
|--- 111006 موجودي بانكهاي ارزي
|--- 111007 وجوه در راه
|--- 111008 موجودي واريز نامه هاي ارزي
اگر بخواهیم این حساب ها را در ی ک جدول ذخیره کنیم با جدولی که من پیشنهاد دادم
اینطور عمل می کنیم که
آیدی حساب،نام حساب،آیدی والد حساب،بقیه مشخصات حساب
1،داراییهای جاری،Null
2،موجودی نقدوبانک،1
3،صندوق ریالی،2
4،صندوق ریالی یک،3
5،صندوق ریالی دو،3
6،صندوق ارزی،2
و....
حالا اگر موقع ثبت سند آیدی حساب را ذخیره کنی هر کدام از این حساب ها را خواستی می توانی در سطع کل و معین و تفضیلی و ... استفاده کنی.

[Dariuosh]

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

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

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

لطف ميکنيد ايرادش رو بفرمائيد تا به اشتباهم پي ببرم پيشاپيش ممنون که وقت ميزاريد

[linux]

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

لطف ميکنيد ايرادش رو بفرمائيد تا به اشتباهم پي ببرم پيشاپيش ممنون که وقت ميزاريد

راستش گفتم که من چون از حسابداری چیزی نمی دونم این مسایل وقتی پیچیده می شه چیزی سر در نمی آرم،ولی چرا vchDate و year , Month تکرار شدند؟
در این جداول مستر و دیتیل چه چیزهایی باید ذخیره شوند؟

[Arghavan_Reza]

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

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

[linux]

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

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

[Arghavan_Reza]

در ساده ترین حالت:
Account: ID, ParentID, Account_Code, Account_Name
Doc_Master: ID, Doc_Master_Date, Doc_Master_Code, Doc_Master_Description
Doc_Detail: ID, Doc_Master_ID, Account_ID, Doc_Detail_Description, Debit, Credit
جدول حساب نیاز به فیلدی جدا جهت مشخص نمودن نوع حساب ندارد! از فیلد Memo در یک جدول Levelsکمک بگیرید
تا همین اندازه کافیه، بقیه فیلدها را برحسب نیاز اضافه نمایید.
موفق باشید....

[Alyas_Tet]

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

[Arghavan_Reza]

اصل اینه که حساب دارای زیرحساب انتخاب نشه . سطحش مهم نیست.

[linux]

در ساده ترین حالت:
Account: ID, ParentID, Account_Code, Account_Name
Doc_Master: ID, Doc_Master_Date, Doc_Master_Code, Doc_Master_Description
Doc_Detail: ID, Doc_Master_ID, Account_ID, Doc_Detail_Description, Debit, Credit
جدول حساب نیاز به فیلدی جدا جهت مشخص نمودن نوع حساب ندارد! از فیلد Memo در یک جدول Levelsکمک بگیرید
تا همین اندازه کافیه، بقیه فیلدها را برحسب نیاز اضافه نمایید.
موفق باشید....

کاش یک مثال برای این دوتا جدول مستر و دیتیل می زدید.
به نظرم ID در Doc_Detail زیادی هست چون با کلید تعریف کردن Doc_master_ID و Account_ID مشکل حل میشه و هم اینکه میشه جلوی تکراری بودن اطلاعات را گرفت

[Dariuosh]

راستش گفتم که من چون از حسابداری چیزی نمی دونم این مسایل وقتی پیچیده می شه چیزی سر در نمی آرم،ولی چرا vchDate و year , Month تکرار شدند؟
در این جداول مستر و دیتیل چه چیزهایی باید ذخیره شوند؟

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

[linux]

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

همکاران سیستم همین کار ها را کرده که این همه مشکل داره تو سیستم هاش

[Alyas_Tet]

اصل اینه که حساب دارای زیرحساب انتخاب نشه . سطحش مهم نیست.

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

[Arghavan_Reza]

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

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

[mosavi12]

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

با تشكر از كليه دوستان به خصوص جناب Arghavan_Reza مي‌شه يك مثال عملي بنويسيد.