انجمن‌ها

سلام

ممنون از لطف شما

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

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

2. جستجویی که اشاره فرمودید به صورت پیش‌فرض در حالت "آزاد" انجام می‌شود و کلمات داخل متن را هم جستجو می‌کند. اما صحیح می‌فرمایید که فاصله‌ی بین کلمات و احیانا پس و پیش بودن کلمات را پشتیبانی نمی‌کند. پیشنهاد بسیار خوبی است و حتما روی آن کار خواهیم کرد.

3. اینکه موجودی و رزرو کالاها همزمان با جستجو ارائه شود (یعنی برای همه‌ی کالاهای فهرست شده) اصلا کارآمد نیست. طبیعی است که این اطلاعات فقط برای یک کالا (همان که برایش جستجو می‌کنیم) مورد نظر است. به همین دلیل برای ارائه‌ی این داده‌ها از یک فرمان جداگانه (خلاصه اطلاعات کالا) استفاده شده است. این فرمان با Alt+F11 در همه‌ی بخش‌های سیستم و در قرار گرفتن روی هر کالایی قابل اجرا است (جستجو، گزارش‌ها، تنظیم برگه‌ها...). در همانجا همه‌ی اطلاعات مورد نیاز ارائه می‌شوند - البته در حالت کلی به تفکیک انبارها. بهای فروش با ترتیبات مفصلی از مشخصات برگه (مثلا پیش‌فاکتور یا فاکتور) و بسته به نوع و مرکز فروش یا روش پرداخت یا نحوه‌ی تحویل یا طرف بدهکار یا محل جغرافیایی... و با استفاده از تعرفه‌ها و قوانین تغییر تعرفه مشخص می‌شود و در بیرون از آن محیط قابل ارائه نیست. اگر در روش کار شما بهای هر کالا ثابت و مشخص است می‌توانید آن بها را به عنوان بهای نرمال در مشخصات کالا درج کنید و در همان Alt+F11 مشاهده فرمایید.

4. در حالت کلی، لیست قیمت تامین کننده برای مقایسه‌هایی که اشاره فرمودید کارایی ندارد (چون بسیاری از هزینه‌های دیگری که در تامین کالا متحمل شده‌اید را شامل نمی‌شود). مبنای مقایسه‌ی مناسب، بهای ورود کالا به انبار است. مقایسه‌ای که فرمودید در گردش و موجودی کالاها و با مقایسه‌ی ارزش موجودی‌ها با ارزش فروش قابل دریافت است.

5. همان گزارشی که در آیتم 1 اشاره کردیم در اینجا هم کاربرد خواهد داشت.

مجددا از لطف شما ممنونم

ارادت

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

جناب آقای مومنی ,از پیگیری و پاسخگویی جنابعالی بسیار سپاسگزارم.

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

آیا امکان کپی نحوه پرداخت پیش فاکتور در فاکتور نیست؟

مورد دوم:

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

راه حلی وجود دارد که در همان درخواست کالای مشتری , تاریخ اعتبار پیش فاکتور کنترل شود؟

پیشاپیش از حسن توجه شما سپاسگزارم.

سلام

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

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

با این مقدمات و توضیحاتی که فرمودید به نظر می‌رسد که شرط تاریخ اعتبار (که در فاکتور لحاظ شده است) را بهتر است در برگه‌های درخواست و تحویل هم لحاظ کنیم.

از لطف شما ممنونم
ارادت

با سلام،

 

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

 

با ارادت