با سلام
دوستانی که سیستم حسابداری نوشتن لطف کنند در مورد روش پیاده سازی سال مالی توضیح بدهند ...
من خودم که این روش رو پیاده کردم , میام واسه هر سال مالی یه DB می سازم ....
موفق باشید
با سلام
دوستانی که سیستم حسابداری نوشتن لطف کنند در مورد روش پیاده سازی سال مالی توضیح بدهند ...
من خودم که این روش رو پیاده کردم , میام واسه هر سال مالی یه DB می سازم ....
موفق باشید
مگه مي خواين چي كار كنيد كه مي خواين براي هر سال مالي يه DB بسازين؟؟؟!من خودم که این روش رو پیاده کردم , میام واسه هر سال مالی یه DB می سازم ....
دوره مالي در سيستم بايد به صورت يك فيلد dymond در حافظه هستش تا بر اساس اون فيلد يا متغير عمليات ها انجام بشه.
مثلاً براي سند زدن شما فقط تاريخ يا زمان دوره مالي فعلي رو مي خواين كه به صورت يه فيلد در DB مربوط به سند ذخيره بشه نه در جدول دوره مالي! يا مثلآً وقتي دوره مالي جديدي ساخته شد تا پايان اون دوره مالي به هيچ وجه نبايد منو يا form مربوط به دوره مالي فعال بشه و سيستم بايد منتظر پايان دوره مالي بمونه.
اگر مي خواين يه history از دوره هاي مالي خودتون داشته باشيد فقط احتياج به يك جدول دارين كه خيلي هم سبك هستش كه داخل تاريخ شروع دوره، تاريخ پايان دوره، عنوان دوره(اختياري) و ... ذخيره ميشه.
همين.
تا اونجایی که من میدونم , وقتی یک سال مالی در سیستم تعریف میشه تمام اسناد و حساب ها برروی اون سال مالی سوار هستند و بعد از اتمام سال مالی یک سند اختتامیه زده میشه و بعد از حساب های بسته میشه و بعضی از حساب ها مثل حساب های دریافتنی تجاری به سال جدید منتقل میشند ...
اگر اشتباه گفتم تصحیح کنید ..
موفق باشید
بلهوقتی یک سال مالی در سیستم تعریف میشه تمام اسناد و حساب ها برروی اون سال مالی سوار هستند
خيربعد از اتمام سال مالی یک سند اختتامیه زده میشه و بعد از حساب های بسته میشه و بعضی از حساب ها مثل حساب های دریافتنی تجاری به سال جدید منتقل میشند...
وقتي يك دوره مالي در سيستم تعريف ميشه مثلاً يك دوره مالي 3 ماهه يا يك ساله طبق فرمايش خودتون تمامي اسناد و حسابهاي جديد يا قديم بر اساس اون دوره مالي تعريف ميشن. به قول خودتون سوار هستن.
وقتي مي خوان يه حساب يا سندي رو افتتاح كنن تاريخ دوره مالي به عنوان يك فيلد در جدول مربوط به اون سند يا حساب ذخيره ميشه تا گزارشات بر اساس اون تاريخ دوره مالي باشه.
من اين گفته شما رو به دو قسمت تقسيم مي كنم:
وبعد از اتمام سال مالی یک سند اختتامیه زده میشه و بعد از حساب های بسته میشه
ممكن هست اين سند حتي خيلي قبل تر از دوره مالي سند اختتاميه بخوره و ممكنم هستش كه تا پايان دوره مالي سند اختتاميه بخوره ولي در پايان دوره مالي براي اينكه حسابها و اسناد به دوه مالي بعدي منتقل بشه يك سند اختتاميه قبل از پايان دوره مالي مي زنن يا اون حساب رو مي بندن و در شروع دوره مالي بعدي سند افتتاحيه اين سند زده ميشه.و بعضی از حساب ها مثل حساب های دریافتنی تجاری به سال جدید منتقل میشند...
پس: دوره مالي يك بازه زماني هستش كه تمامي عمليات هاي حسابداري فقط در اون دوره مالي امكان پذير هستش. حالا ممكن هستش بعضي عمليات ها در دوره مالي بعدي هم استفاده بشه. مثلاً يك سندي رو در نظر بگيريد كه در پانزدهم اسفند ماه افتتاح بشه و 29 اسفندماه تاريخ پايان دوره مالي باشه. اين سند در جدول مربوط به اسناد با دوره مالي همون سال ذخيره ميشه. 29 اسفند يه تاريخ اختتاميه براي اون سند زده ميشه. حالا دوره مالي جديد شروع ميشه. سند مال دوره مالي قبلي هستش اما سند جديدي افتتاح ميشه با دوره مالي جديد و در جدول بانك اطلاعاتي مربوط به اسناد نيز يك ركورد جديد ذخيره ميشه اما هميشه اين اسناد يه قسمتي دارن به نام توضيحات كه شما بايد در قسمت توضيحات اين سند جديد قيد كنيد كه اين سند همون سندي هستش كه در دوره مالي x ايجاد شده.
اگر دقت كنيد دوره مالي به عنوان يك فيلد ذخيره ميشه.
نقش حجم اطلاعات چی میشه ؟من شرکتی را می شناسم که در سال حدود 3000 سند داره و هر سند آن بطور متوسط دارای 180 آرتیکل می باشدنوشته شده توسط obalitjoOon
فکر نمی کنید گزارشات آن کند بشه و چند سال میتونه اطلاعات در آن ذخیره بشه؟
خيرفکر نمی کنید گزارشات آن کند بشه
متوجه نشدم.چند سال میتونه اطلاعات در آن ذخیره بشه؟
ببينيد تاريخ دوره مالي به صورت يك فيلد هستش و اين فيلد بايد همه جا چك بشه پس چه بهتر به جاي اينكه براي هر بار چك شدن بره بانك اطلاعاتي رو باز كنه و بخونه يك بار اين كار صورت بگيره و در حافظه قرار بگيره.
در گزارشات هم ميان بر اساس دوره مالي فعلي يا دوره مالي دلخواه گزارش گيري مي كنن. همش به عنوان يك فيلد يا متغير يا مقدار در سيستم ازش استفاده ميشه.
نمي دونم شما راجب به دوره مالي چي فكر مي كنيد!!! اميدوارم منظورم رو متوجه بشين.
گزارشات حسابداری بجز یکی دو گزارش معمولا مربوط به یک دوره مالی می شود بنا براین نیاز نیست که هردفعه فیلد سال مالی چک شود برعکس وقتی فیلد سال مالی داریم برای هرگزارش باید فیلد فوق چک شود
ضمنا تاریخ دوره مالی نمی تواند یک فیلد ساده باشد زیرا هر دوره مالی تاریخ شروع و تاریخ پایان دارد شما این دو تاریخ را چگونه در یک فیلد تعریف می کنید؟
دقيقاً. سيستم تاريخ فعلي رو با تاريخ پايان دوره مالي چك مي كنه اگر در اون بازه زماني بود اجازه صدور سند داده ميشه در غير اينصورت چه معني مي تونه داشته باشه؟ يعني سند بعد از دوره مالي مي خواد زده بشه!
وقتي يك سندي زده ميشه آيا نبايد اين دوره مالي به صورت فيلد ذخيره بشه؟ ببينيد سند يا حساب در يك جدول جداگانه ذخيره ميشه و در اين جدول يك فيلدي داريم به نام دوره مالي كه مقدارش رو از دوره مالي فعلي يا سندي كه در اون دوره مالي زده شده انتساب مي كنه.
فکر کنم منظور شما همانند عکس در ضمیمه پست است ...
اگر اونطوری که شما گفتید ما پیش بریم فقط کافی است که مشخصه سال مالی رو به سند و یا فاکتور بزنیم ...
اگر براتون امکان داره در مورد سند اختتامیه هم یه توضیح بدین .
موفق باشید
وقتی دیتا بیس هر سال مالی جدا باشه دیگر نیازی به فیلد سال مالی نیست
وقتی شما فیلد سال مالی داشته باشی در یک جدول دیگر هم باید تاریخ شروع سال مالی و تاریخ پایان سال مالی را داشته باشی
حتما توجه دارید که شروع و پایان سال مالی الزاما برابر با سال شمسی نیست
ضمنا در مورد حجم اطلاعات هم اظهار نظر نفرمودید؟
مشکلی که در این جدا کردن DB ها وجود داره , اینکه پشتیبان گیری ازش مشکل میشه ... و یک مشکل دیگه هم داره اینکه اطلاعاتی ماند لیست مشتری ها که بین همه سال مالی ها ثابت است دائما باید بین سال مالی ها انتقال داده بشه ... و مشکل دیگه اینکه در بعضی از جا ها در تعداد دیتابیس ها ممکن است محدودیت داشته باشیم ...
در مورد حجم اطلاعات هم میشه به این روش عمل کرد ... اول میاییم و جدول آرشیو میسازیم و هر سال که تموم شد اطلاعات رو میزنیم رو اون جدول و جدول سال جاری هم خالی میشه و سرعت هم پایین نمی آید ...
موفق باشید
اگر شما فکر می کنید پشتیبان گیری مشکل است که دیگر هیچ!!!
شما که می خواهید آرشیو کنید خوب دیتا بیس جداداشتن که خودش یک نوع آرشیو هم است
منظور شما را از دائما انتقال دادن نفهمیدم منظورتان همان سالی یکبار است دیگه
بعد شما مشکل کدینگ حسابهارا چکار می کنی با روش فیلد سال مالی شما کدینگ ثابت داری و انعطاف پذیری سیستم از بین می رود
شماره سند هم یک مشکل دیگر شما خواهد بود
منظورم اینکه , هر وقت که یک سال مالی تعریف میشه باید لیست هایی مانند لیست مشتریان و لیست صندوق ها و... به سال مالی جدید منتقل بشوند ... یعنی Cut و Paste
منظورتون رو متوجه نشدم ...
این مشکل رو میشه با کپی کردن اطلاعات به جدول آرشیو و دوباره Reset کردن شماره جدول حل کرد ...
موفق باشید
دوست عزیز شما تمام مسائل را می خواهی با آرشیو کردن حل کنی خوب بجای این کار اگر هر سال مالی در یک دیتابیس ایجاد شود تمام مشکلات حل است انتقال مانده حسابها از یک سال مالی به سال مالی بعد فکر نمی کنم از آرشیو کردن سخت تر باشد
منظور من از مشکل شماره سند این است که در هر سال مالی شماره اسناد از 1 شروع می شود بنابر این اگر هر سال مالی در دیتابیس جدا ذخیره گردد مشکل شماره سندهای یکسان نداریم
باور کنید نگاهداری حسابهای هر سال در دیتابیس های جداگانه خیلی راحتتر از تعریف فیلد سال مالی است
بخاطر اینکه تایپیک به بیراهه نرود ضمن احترام به عقیده جنابعالی و اینکه روش کار شما از نظر من غلط نیست ولی مشکل آفرین است که البته قابل حل خواهد بود ولی چرا ؟
من فکر می کنم تمام مطالب مورد نیاز را گفتم و دیگر قضاوت با دوستان برنامه نویس است که از چه روشی استفاده کنند.
استفاده از چند پایگاه به طور مجزا برای سالهای مالی متفاوت برخی مسائل را به سادگی حل میکند، اما در هنگامی که احتیاج به استخراج داده ها برای چند سال داریم، به مسائل اساسی برمیخوریم. تصور کنید میخواهید سیستم مالی خود را با یک سیستم CRM مجتمع کنید، به عنوان مثال، در این استراتژی تهیه گزارش عملکرد مالی مشتریان در طی چند سال گذشته به صورت نمودار میله ای و فصلی (3ماه - 3ماه) بسیار مشکل است.
وجود امکانات مربوط به مجتمع سازی برای سیستم های مالی امری حیاتی به نظر می آید و تصور میکنم که یکی از اصلی ترین قابلیت های سیستم مالی را با این استراتژی از دست میدهید.
در یک سیستم حسابداری تمام گزارشات اصلی مورد نیاز می باشند و آنچه برای حسابدار مهم است دسترسی سریعتر به گزارشات روزمره است که این گزارشات اکثرا و یا حتی تماما مربوط به یک دوره مالی است گزارشات دوره ای و مجتمع سازی در جای خود مهم می باشند ولی جزء گزارشات روزمره نیستند
ضمنا این گزارشات نیز در صورت وجود دیتا بیس های جداگانه برای سالهای مالی متفاوت قابل تهیه می باشند
خوب وقتی هم که شما از آرشیو استفاده کنی همین وضعیت پیش خواهد آمد با وجود این هر روشی که اتخاذ گردد مسلمل مزایا و معایب مخصوص خودش را خواهد داشت که انتخاب بهترین راه از مجموع همین نتایج بدست می آید
من فکر می کنم این تایپیک را اگر دوستان بیشتری همراهی کنند نتایج جالبی بدست بیاید
حتی شاید لازم باشد یک نظر سنجی بشود و دوستان نظرات خود را اعلام نمایند
البته بحثی در مورد مورد وجود مسائل در هر روشی نیست، در ثانی من تا به حال سیستم مالی با این روشی که شما میگویید را طراحی نکرده ام بنابراین مسائلی که مطرح میکم احتمالا خیلی سطح بالا هستند و یا به راحتی در هنگام بررسی دقیقتر، قابل حل! چیزی که در بیشتر مسائل مطرح شده هم به چشم میخورد.
مشکلی که من مطرح کردم یکی از مشکلات مطرح در این استراتژی بوده و هست. من به یک مثال در دنیای واقعی برخورد کردم:
در سیستم کارگزینی، مدیریت از تیم پیاده سازی میخواهد به دو صورت با مورد تغییر پارامترهای حقوقی برخورد شود،
روش اول: بعد از تغییر مبالغ جدید حقوق پرداختی محاسبه شده و طبق فرمول جدید اقدام به پرداخت حقوق شود. (اغلب موارد)
روش دوم: این تغییر باید مشمول حقوق های پرداخته شده هم بشود. به این معنی که با اصلاح پارامتر، باید حقوق های پرداخته شده نیز بررسی شود و بنا به نوع تغییر پارامتر، کسری حقوق و یا اضافه آن به حساب کارمند زده شود.
در ساختاری که شما مطرح میکنید، به نظر میرسد چنین عملیات هایی دارای پیچیدگی هایی باشد که شاید در حرف ساده باشد اما در پیاده سازی دردسر های فرآوانی خواهد داشت. به خصوص که مورد دوم معمولا بعد از تحویل مطرح شده و در فاز نگهداری باید به سیستم اضافه شود.
سوال اصلی در این تایپیک بحث سال مالی در سیستم حسابداری است و مطمئنا جوابها و مثال ها نیز باید مربوط به سیستم حسابداری باشد
مثال شما ربطی به سیستم حسابداری ندارد ولی چنانچه بتوان موردی مانند مثال فوق در سیستمهای حسابداری پیدا کرد حرف شما کاملا متین است
عملیاتی که در سیستم حسابداری انجام می شود عملیات مستقلی است که چه از نظر قوانین حقوقی و چه از لحاظ استانداردهای حسابداری تاریخ عملیات انجام شده دارای اهمیت بوده و برای مثال نمی توان سندی را که در سال گذشته صادر و ثبت گردیده تغییر داد لذا عملیات ویرایشی در سالهای مختلف مالی مجاز نمی باشدلذا اینگون محاسبات که مسلما دارای پیچیدگیهای فراوان است در سیستم حسابداری مشاهده نمی شود و یا حداقل من سراغ ندارم
تنها مواردی که نیاز به دسترسی همزمان به اطلاعات سالهای مختلف دارد گزارشات مختلفی مانند همان مثال عملکرد مشتریان در مقطع مشخص می باشد که تهیه گزارشات فوق چندان مشکل نیست ضمن اینکه جهت رفع اشکال حجم بالای اطلاعات وقتی که ما از فیلد سال مالی استفاده می کنیم دوستان نسخه آرشیو را پیشنهاد دادند که بنده هم عرض کردم وقتی آرشیو کنیم تمام مسائلی که شما فرمودید وجود خواهد داشت
در هر حال تا حدودی معایب و امتیازات هر روشی روشن شده است باید سبک و سنگین کرد و بهترین روش را پیدا نمود!!
البته صحبت شما صحیح است، این مثال خیلی مربوط به سیستم مالی نمیشد. چیز دیگری که به ذهنم رسید اینه که تفکیک پایگاه داده بر اساس سالهای مالی، عملا تمامی پیچیدگی های مربوط به آرشیو کردن اطلاعات را با خود به همراه دارد منتها در طراحی و پیاده سازی سیستم نیز موجب سادگی هایی می شود. من، برای خودم دو استراتژی در نظر گرفته ام که ممنون میشم راجع به اونا هم بحث کنیم:
1- اگر سیستمی احتیاج به آرشیو کردن پیدا نکند (برای سیستم کوچک) عملا تفکیک پایگاه داده به ازای سالهای مالی نباید چندان موثر باشد
2- اگر حجم اطلاعات در یک سال مالی به حدی باشد که ناچار باشیم از مدل های توزیع شده برای نگهداری اطلاعات استفاده کنیم (مانند سیستم مالی جامع برای تمامی واحد های شرکت راه آهن، به جهت گستردگی و حجم عملیاتی) باز هم نباید این سیاست چندان جالب نخواهد بود.
کاملا موافقم و سیستمهایی مثل هلو که در بازار هستند ازهمین روش یعنی فیلد مالی استفاده می کنند ولی این نرم افزارها بعنوان نرم افزارهای مالی حرفه ای بحساب نمی آیند
من خودم ترجیح می دهم که استفاده نکنم
راستش منظور شمارا متوجه نشدم ولی فکر می کنم نسبت به این مورد نظرم را گفته ام البته اگر اشتباه نکرده باشم منظور شما این است که در ایگونه موارد دیتابیس جداگانه بهتر است.
واقعیت امر این است که اولین بار که من یک سیستم حسابداری برای یک موسسه نوشتم تمام مسایل عنوان شده فوق مرا درگیر کرده بوددر نهایت پس از بارها کد نویسی و نمونه سازی بهترین راهکاری که کاملا جواب داد این بود که من یک دیتابیس عمومی برای جداول مشترک در سالهای ملی متفاوت مثل جدول کاربران و جدول پارامترهای سیستم مانند سالهای مالی که ایجاد می شوند و تاریخهای ابتدا و انتهای سال مالی و . . . ایجاد نمودم و در پی آن برای هرسال مالی که بتدریج ایجاد می شد یک دیتابیس ایجاد می کردم
بعد ها که سیستم را به سیستم چند شرکته تبدیل کردم حالا برای هر شرکت و در هر سال مالی باز هم یک دیتابیس ایجاد کردم
خوب لابد می گویید این همه دیتابیس ؟
ولی باور کنید تا حالا یعنی پس از حدود 5 سال هیچگونه مشکلی با نرم افزار ها نداشته ام
اکنون این نرم افزار در جندین موسسه کوچک و بزرگ کار می کند و مسئله ای بوجود نیامده است
از پیگیری شما متشکرم من فکر می کنم این مسئله مسئله مهمی است و اگر دیگر دوستان هم همفکری بکنند شاید راه سومی هم باشد؟؟
فکر میکنم دیگر دوستان چندان با این موضوع مواجه نشده اند.
در مورد دوم هم خواستم بگم که جاهایی وجود دارد که با استفاده از راهکار شما، باز هم به آرشیو کردن قسمتی از اطلاعات نیاز داریم. شاید بهتر باشد که چنین راهکاری (تفکیک بر اساس سال های مالی) را با توجه به میزان رشد اطلاعات در دوره های زمانی بررسی شود. میتوان گفت که اگر بحث آرشیو شدن اطلاعات پیش نیاید، نیازی به این امر هم نیست. اگر نیاز به آرشیو شدن باشد و با تفکیک پایگاه داد حل شود (در موارد زیادی به این صورت است) راه حل منطقی به نظر میرسد. اگر راه حل تفکیک به ازای سالهای مالی بازهم ما رو از بحث آرشیو کردن راحت نکنه(می دونم خیلی نادره اما دوست دارم یه راه حل کلی بدم) اونوقت بهتره پایگاه داده رو تفکیک نکنیم چون معایب هردو رو داریم.
[quote=mehdi_m1360;692491]جاهایی وجود دارد که با استفاده از راهکار شما، باز هم به آرشیو کردن قسمتی از اطلاعات نیاز داریم.[quote]
من جدا با آرشیو کردن اطلاعات سیستم حسابداری مخالفم زیرا که معمولا اطلاعات سالجاری مالی باید همیشه در دسترس باشد بنابر این باید راهکاری پیدا کرد که هیچوقت نیاز به آرشیو کردن نباشد
بگذارید یک مثال عملی بزنم
من در یک شرکت سیستمی نصب کرده ام که حدود 4 سال است کار می کند
در سال 86 تعداد سند صادر شده در این شرکت حدود 4250 تا و متوسط تعداد آرتیکل در هر سند حدود 35 می باشد یعنی جمع آرتیکلهای یک سال آن حدود 150 هزار است که این تعداد آرتیکل هیچ مشکلی برای گزارش گیری ندارد کند ترین گزارش آن که تراز حسابهای تفصیلی است در کلاینتها و در اوج ترافیک شبکه حدود 5 ثانیه طول می کشد
بانک مورد استفاده من اس کیو ال 2000 و برنامه با دلفی نوشته شده است
در شرکتهای بزرگتر مثل ایران خودرو و غیره با تجدید نظر در بانک اطلاعاتی و نحوه برنامه نویسی و گزارش گیری مناسب من فکر نمی کنم در یک سال مالی نیاز به آرشیو پیش بیاید
آخرین ویرایش به وسیله accpascal : چهارشنبه 28 اسفند 1387 در 19:50 عصر دلیل: اشتباه تایپ
من تقریبا با هردو مورد کار کردم هرکدام دارای معایب ومزایایی دارند و به طو رکلی به این نتیجه رسیدم که برای شرکت های بازرگانی که حجم کم است وکدینگ مالی تغیر نمی کند ونیاز برای دسترسی به سال مالی گذشته وجود دارد وگاهی اوقات گزارش تفضیلی از یک حساب را برای دو سال پیاپی مورد نیاز است از فیلد مالی استفاده شود چون اطلاعات بیشتر مربوط به شخصیت های خارج سازمانی است
ولی در مورد حسابداری های صنعتی که بیشتر اطلاعات مربوط به داخل سازمان وایجاد یک شناسنامه تولید واطلاعات مربوط به ساخت کالا (بهای تمام شده)می گردد ونیاز به ان است که هرساله بعضی از کدینگ مربوط به کالاهای ساخته شده به سال مالی بعد منتقل نشود واطلاعات هر سال با سالهای دیگر ارتباط کمتری دارند از الگوی دیتا بیس جدا استفاده شود
از اینکه افتخار داده و در بحث ما شرکت کرده ای منون.
مسئله انتقال حسابها از یک سال مالی به سال مالی بعد بنظر من خیلی در انتخاب نوع ایجاد سال مالی تاثیر ندارد
آنچه که بنظر من مهم است حجم اطلاعات و سادگی کار با سیستم و در مرحله آخر سادگی کد نویسی است که نحوه ایجاد سال مالی در هرکدام تاثیر بسزایی دارد
در شرکتهای صنعتی و بازرگانی تفاوت چندانی از نظر ثبت حسابها وجود ندارد زیرا که اطلاعات مربوط به کالاهای ساخته شده و تولید شده و در جریان ساخت و غیره تماما در سیستم جداگانه مثل انبار و سیستم بهای تمام شده نگهداری می گردد و آنچه که در سیستم حسابداری (که بر اساس آن دفاتر قانونی ثبت می گردد) نگاه داشته می شود ماحصل عملیات سیستمهای فوق است ولی در اینکه معمولا حجم عملیات در شرکتهای تولیدی بیشتر از شرکتهای خدماتی (نه بازرگانی) می باشد شکی نیست
وقتی یک حسابداری صنعتی می نویسیم که نرم افزار بهای تمام شده ندارد کاربران مجبورند پچ های تولید را در کدینک مالی وارد نماییند تا بهای تمام شده تقریبی انرا بدست اورندمسئله انتقال حسابها از یک سال مالی به سال مالی بعد بنظر من خیلی در انتخاب نوع ایجاد سال مالی تاثیر ندارد
حال در سال مالی بعد این کدینگ باید از بین برود تا پچهای تولید جدید را وارد نماییند .پچ های سال قبل در صورت وجود سربار ایجاد مکند واز راحتی کار می کاهد لذا در سیستم ها پیشنهاد می گردد که ه سال مالی را در یک دیتا بیس قرار داد
دوست عزیز
اولا چرا این کدها نباید به سال مالی بعد انتقال پیدا کند مگر در سال مالی بعد این کدها استفاده نمی شوند ؟
ثانیا کدهای انتقالی تک به تک منتقل نمی شوند که وجود این کدها سربار ایجاد کند و یا کار را سخت تر کند
من نمی دانم شما با حسابداری صنعتی چقدر آشنا هستیداولا چرا این کدها نباید به سال مالی بعد انتقال پیدا کند مگر در سال مالی بعد این کدها استفاده نمی شوند ؟
ولی در کد تفضیل حسابهای موقت معمولا کدینگ حسابهای بهای تمام شده قرار می گیرد که هر حساب مربوط به یک شناسنامه تولید یک کالا می باشد
مثلا کد کل 5 حسابهای موقت می باشد ومعین 2 بهای تمام شده کالا می باشد وتفضیل 9 شناسنامه تولید شلوار جین می باشد
حال در سال مالی بعد امکان دارد شلوار جین تولید نشود در نتیچه تفضیلیهای مربوط به هر سری تولید شلوار جین خالی میماند وامکان دارد شلوار جدیدی مثل فاستونی تولید شود لذا در هر سال مالی کد های مربوط به تفضیلی شناسنامه های تولید باید حذف شده و برای سال جدید از ابتدا ایجاد شود در غیر اینصورت بعد از یک دو سال دارای کدهای سربار زیادی می شوید ویکی از محاسن استفاده از دیتابیس جدا برای هر سال مالی جدانگهداشتن کدهای مالی از یکدیگردر سالهای مختلف است
امیدوارم بتوانم منظورم را رسانده باشم
من فکر میکنم اگر حجم داده ها ما را مجبور به استفاده از این راه حل نکند، می توان مشکلات مربوط به کدینگ را به راحتی حل کرد. در مورد سیستم های صنعتی هم وقتی با سیستم بزرگی روبرو میشوید که حجم اطلاعاتی آنها آنقدر زیاد است که در هر سال میبایست از پایگاه داده جدا استفاده نمود، طبیعتا زیر سیستم های زیادی در کنار سیستم مالی قرار میگیرند که کار آن سیستم را ساده تر میکنند. من تصور نمیکنم تنها با صنعتی شدن سیستم مالی، مجبور به استفاده از چند پایگاه داده شویم.
سلام به همه دوستان و تشکر از موضوع جالب
من برای خودم سیستم حسابداری را در سه سطح تقسیم بندی می کنم
1- فروشگاهی
2- تجاری و شرکتهای کوچک
3- سازمانی
اعتقادمن این است که برای 1و 2 از یک دیتابیس برای کل عمر شرکت استفاده کنیم و از روش آرشیو
اما برای گزینه 3 برای هر سال مالی یک دیتابیس
سلام دوستان
می خوام یک مطلبی رو مطرح کنم
سوال پیش میاد
آیا ما در برنامه حسابداری باید حساب سال قبل رو به صورت کامل ببندیم و اجازه ندیم کاربر تغیراتی در حسابهای قبل ایجاد کنه؟
خوب جواب این سوال رو اینطور خودم می گم آره نباید اجازه دستکاری داد.چون علم حسابداری اینو می گه.
سوال پیش میاد
ما برای کی ، چی و چرا برنامه می نویسیم؟
آیا برای علم حسابداری برنامه می نویسیم؟
آیا برای دل خودمون برنامه می نویسیم؟
آیا علم حسابداری چیزی به ما می دهد(منظورم پول هست)؟
خوب بازم خودم جواب می هم نه ما برای کاربر برنامه می نویسیم در ازای مبلغی
سوال پیش میاد
بین کاربر و علم حسابداری باید حرف کدوم شون رو قبول کنیم؟
خوب بازم خودم جواب می دم: نمی دونم کدوم
دوستان من قصد مزاح ندارم ولی واقعیتی هست که ما نمی دونیم برنامه حسابداری می نویسیم یا نه. مثلا کاربر از ما می خواد اگه انبار موجودی نداره باز هم اجازه صدور فاکتور فروش رو داشته باشه. که اصلا با حسابداری سازگار نیست علم حسابداری می گه: یعنی چی که موجودی کالا منفی باشه مگه کالا منفی می شه؟
یا مثلا شرکت طرفه نگار به نرم افزار ورژن فروشگاهیش پیشوند یا پسوندی از حسابداری نداده چون خودش می دونه این نرم افزار حسابداری نیست.
خوب برای اینکه خیلی از بحث اصلی یعنی سال مالی دور نشیم من هدفم فقط طرح یک سوال است.
آیا ما در برنامه حسابداری باید حساب سال قبل رو به صورت کامل ببندیم و اجازه ندیم کاربر تغیراتی در حسابهای سال قبل ایجاد کنه؟
چیزی که عرفه، همینطور هم مربوط به علم حسابداری میشه هم مربوط به کاربر میشه و هم کاربرد داره، اینه که در پایان سال مالی همه اسناد مالی تراز میشن و طبق روال حسابداری، سال مالی بسته میشه. گزارشاتی که در پایان سال مالی تهیه میشه مبنای خیلی از عملیات هاست، یه سند حقوقی محسوب میشه و نباید بعدها تغییر کنه، اصلا دائمی کردن سند و موقت و دائم بودن اونها به همین دلیله، خیلی از موسسات در چند روز آخر سال اسناد رو دائمی میکنن، اونم با نظر حسابداری که معتمد هیات مدیره هست و نه در استخدام شرکت که به این وسیله از صحت اطلاعات مالی مطمئن بشن. برای اصلاح اسناد قدیمی در سالهای بعد و یا اصلاح اسناد دائمی شده، حسابدار چه در دفاتر مالی و چه در سیستم های مالی موظف به زدن اسناد اصلاحی هستش و تغییر روی اسناد قبلی مجاز نیست. در نتیجه سیستم هم نباید اجازه چنین کاری بده، از اونجایی که تغییر در اطلاعات مالی حسابها از طریق ثبت اسناد صورت میگیره، در نتیجه تغییر در این اطلاعات هم در انتهای سال مالی و بعد از بسته شدن حسابها ممکن نیست.
ليست مشتري ها ثابت هست ؟
مثلا 5 سال پيش 2 تا حساب داشتي با يك فردي هنوز هم بايد اسمش تو ليست مشتريات وجود داشته باشه ؟
شايد اصلا اون شركت منحل شده باشه !
من فکر می کنم اگه تو نرافزار مون یک امکانی رو بزاریم که کاربر بتونه لیست افرادی یا مثلا کالاهای رو که در جا های که هجم کاری بیشتری هست خودش تنظیم کنه بهتره.
مثلا:
برای فاکتور زدن لازم هست از لیست اشخاص و کالا انتخابهای انجام بشه اگه این لیستها تا جای که امکان هست کوتاهتر بشه بهتره.
اونوقت کاربر می تونه افرادی رو که احتمالا فعلا با هاشون کاری نداره رو حذف نکنه ولی از نمایش اون جلو گیری کنه.
به نظر من حذف حسابی که براش سند خورده حتی اگه 10 سال پیش هم باشه درست نیست.
در ضمن اگه می شه عکسی که گذاشتی رو عوض کن ببخشید که فضولی می کنم
من نگفتم حذف بشن ولي در سال خودشون بايد باقي بمانند نه اينكه از روز اول تا آخر ليست مشتريا يكي باشه !
اگر db جدا باشه اون حساب تو 2 سال پيش هست ولي امسال كاربر مياد پاكش مي كنه ! ولي اگه 1 db باشه كاربر بايد وجود كلي اسامي يا كالا را تحمل كنه يا اينكه واسه اوناهم فيلد سال بزاريم !!!!!
دوست عزیز من منظورم ایجاد تنظیمات هست. حتی ممکنه یک شخص فقط یک با با ما حسابی داشته. اما به دیل هجم کاری که با ما داشته یا مانده حسابی که داشته باید اون شخص رو تعریف کنیم.
مثلا من یک آموزشگاه دارم یک کاراموز می اد برای مدت 6 ماه کلاس رایانه کار احتمالا همین یک بار هم هست. اگه نقدی پول پرداخت کرد اونو به عنوان مشتری گذری ثبت می کنم و قال قضیه کنده می شه ولی اگه بخواد قسطی پرداخت کنه باید تعریفش کنم. تا بدونم مانده حسابش چجوری هست.
من اینطور مواردی زیاد دارم تو آموزشگاه خوب اگه تو برنامه حسابداری اینچنین تنظیمی باشه لازم نیست حسابها یا کالاها حذف بشن و این خود کاربر هست که تصمیم می گیره که فعلا نمایش پیدا نکنه.
خوب اگه با روش شما کار کنیم اگه طرف دوباره مشتری شد یعنی باید دوباره تعریف بشه. یا اگه مانده حسابی داشت یکسال گذشته و نداده هنوز ، باید حذفش کرد؟ به نظرم این که شما می گید کار رو پیچیده می کنه هر چند عملی هست.
شما تو هر آموزشگاهی بری اگر کد دانشجویی قبلیت رو ندی یک حساب جدید باز می کنن برات !
بله هر حسابی باشه ایجاد میشه و تو همان سال می مونه مگر اینکه مشتری ثابت باشه ! و هر ثابتی هم بازه خاصی داره
سلام دوستان
من برای اولین بار هست دارم برنامه حسابداری می نویسم. البته چون اولین بار هست اشکالات زیادی هم دارد مثلا الان که برنامه من رو پایان هست تازه به فکر سال مالی افتادم.
یک سوال داشتم آیا اگه ما فقط از یک دیتا بیس استفاده کنیم و بجاش از فیلد سال مالی استفاده بشه. و با توجه به اینکه از این به بعد برای تهیه هر گونه گزارش باید از شرط سال مالی استفاده کرد آیا این شرطی که می زاریم (با توجه به اینکه همون اول فیلتری قوی اعمال می شود) باز هم سرعت خیلی کاهش پیدا خواهد کرد؟
دوستان فکر می کنم بحث سال مالی جا برای ادامه زیاد دارد. دوستانی که تجربه بیشتری دارند لطفا کمک کنن.
با سلام ، من تازه وارد این بحث شدم ، تقریبا اکثر نظرات را خواندم منتها پیاده سازی سال مالی بسته به نوع سیستم مالی و گردش حساب ها دارد .
ولی عمده سیستم های حسابداری سند های افتتاحیه و اختتامیه دارد که شروع و پایان دوره مالی را مشخص می نماید . در هر دوره مالی ممکن است عناوین حساب های در گردش با دوره مالی دیگر متفاوت باشد و نیز این نکته که در دوره مالی لیستی از عناوین نمی بایست در دوره ای دیگر قرار بگیرد و نیاز به حذف از لیست عناوین حساب است ، پس طراحی صحیح این را ایجا می نماید که در هر دوره مالی بانک اطلاعاتی مختص به خود را داشته باشد و در صورت نیاز اطلاعات سال های مالی در پایان دوره مالی منتقل گردند ، در مورد سیستم های مالی یکپارچه هم کاربر سیستم می تواند در پایان هر دوره مالی سال مالی خود را پایان دوره نزند و ادامه دهد . با تشکر از نظرات دوستان
با سلام خدمت تمامی دوستان گرامی
من برنامه نویس نیستم ولی مسئله سال مالی برای من خیلی جالب بود. طبق بررسی که روی دیتابیس نرم افزارهای مطرح مالی داشتم ، متوجه شدم که تقریباً در تمامی این نرم افزارها ( مثل همکاران سیستم، تدبیر ، نماد و ... ) اطلاعات کلیه سالهای مالی در یک DB نگهداری می شن. با توجه به این فکر می کنم پاسخ دوستان مشخص باشه.
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول
