انجمن‌ها

تفصیلی یونیک:
زمانی که کدینگ حسابداری طراحی می‌شود به تفصیلی‌هایی برمی‌خوریم که در چندین زیرگروه حساب بصورت مشابه به‌ کار می‌روند، مثلاٌ شرکت آلفا هم جزء مشتریانی می‌باشد که به او می‌فروشیم و در مقابل فروش باید پولی از آن بگیریم( حساب‌های دریافتنی) هم در مقابل خرید از او چک می‌گیریم ( اسناد دریافتنی) هم چک او را به حساب می‌خوابانیم (اسناد در جریان وصول) هم پیگیر نقد شدن چک او می‌شویم و....
از این نمونه تفصیلی‌ها به وفور دیده می‌شود، وجود این تفصیلی‌ها جدا از این‌که کدینگ حساب¬های ما را شلوغ می¬کند و کاربر را در تشخیص آن‌ها با مشکل مواجه می‌سازد، به دلیل پراکنده بودن و یکتا نبودن آن‌ها، گزارش‌گیری بهینه و یکتا از تفصیلی را با مشکل مواجه می‌سازد.
فرض کنید جناب آقای علیرضا محمدی را یکبار در سیستم با کد 300123 یکبار با کد 600127  یک بار در سیستم به نام آقای محمدی یکبار با نام علی رضا محمدی یک بار با نام آقای محمدی و... به کار بردیم حال اگر بخواهیم از آقای علیرضا محمدی گزارش بگیریم که با چه حساب‌هایی درگیر بوده و گردش داشته است چه باید بکنیم؟ می‌بینید که به دلیل یکتا نبودن آنها در گزارشگیری دچار مشکل خواهیم شد. لذا وجود تفصیلی یونیک و منفک از درخت حسابها با کد یکتا جوابگوی نیاز ما برای حل این مشکل می‌باشد.
تفصیلی شناور:
زمانی که تفصیلی یونیک می‌شود به دلیل همین یکتایی آن با تمام حساب‌ها درگیر نخواهد بود و باید بصورت شناور با بعضی از حساب‌های مربوط به آن در ارتباط باشد، مثلاٌ شرکت آلفا بصورت شناور هم با حساب‌های دریافتنی هم با اسناد دریافتنی هم با اسناد در جریان وصول هم با اسناد واخواستی در ارتباط است. پس یونیک بودن و شناور بودن لازم و ملزوم یکدیگرند.

چند سطح تفصیلی یونیک مورد نیاز است:

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

آیا تفصیلی دارای ماهیت مالی می‌باشد:
تفصیلی به تنهایی و بدون حساب مرتبط با آن دارای ماهیت مالی نمی‌باشد، آقای علی اکبری زمانی معنی دارد که مثلاٌ بگوییم چک‌های دریافتنی- آقای علی اکبری یا وام دریافتنی- آقای علی اکبری یعنی ماهیت بدهکار یا بستانکار شدن آن به حساب معین مرتبط با آن بستگی دارد.

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

سلام

با تشکر از مطلب شما

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

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

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

ارادت

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

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

با سلام؛
برای آشنایی بیشتر با تفصیلی ها و مثالهای و گزارشات کاربردی از طریق لینک زیر  اقدام نمایید:

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

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

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

 نکته: در  سیستم مالی یکپارچه نوسا برای کاربری راحت کاربر و استفاده بهینه از مفهوم مرکز، در قبال هر مرکز تامین و مصرف نقشی متناظر با آن نیز  وجود دارد که در امر کاربری سیستم تسهیل می‌نماید.

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

با سلام و عرض ادب خدمت شما.

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

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

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

با عرض سلام
تو نمونه سندی که زدید
حقوق-واحد تولید پارچه-سفارش کار 8562 این یک نمونه سند حقوق دستمزده یا سند عوامل هزینه تولید؟

با سلام و احترام

 

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

 

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

 

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

 

نظر شما چیست؟ امکان اجرای چنین راه حلی وجود دارد؟

 

سلام

هم اکنون همین وضعیت در سیستم وجود دارد.

ارادت

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

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

سلام

بحث فرق کرد!
اتوماتیک و الگو در کار نیست.

سطرهای همه سندهای سیستم (شامل فروش) می‌توانند برچسب داشته باشند. این برچسبها باید توسط کاربر در سند مربوط تعیین شوند و البته در حسابداری به ارث خواهند رسید.