انجمن‌ها

با سلام و عرض ادب خدمت جناب اصفهانی عزیز.

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

ســـــــــــلام آقای مولایی

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

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

سلام

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

ارادت

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

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

مطلبی که عنوان شد بدلیل ارزش "قرارداد" و ماهیت آن (از دید شرکتهایی که تولیدات و خدمات آنها بسته به قرارداد است) بسیار حیاتی است.(حداقل در شرکت ما)

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

از نظر بنده حقیر جزییات یک برگه باید در خود آن باشد.

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

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

سلام

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

واحد انبار ( سیستم انبار ) واحد فروش ( سیستم فروش ) واحد دریافت و پرداخت و وصول (سیستم دریافت و پرداخت) واحد حقوق و دستمزد ( سیستم دستمزد)

واحد مالی ( سیستم حسابداری )

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

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

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

ارادت

سلام

قربان، تفاوتی نمی‌کند که چک را چه کسی وصول نماید (همان شخصی که فروش را انجام داده، مدیر مالی یا مسئول پیگیری مطالبات) - مهم از دید شرکت (نه سیستم مالی یکپارچه) این است که عمل دریافت چک در یک "سند دریافت و پرداخت" انجام شود - یعنی توسط یک کاربر که به عنوان ورود اطلاعات در سیستم دریافت و پرداخت مشغول کار باشد.

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

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

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

ارادت

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

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

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

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

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

ممنون.

سلام

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