فارسی و لاتین

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

تغییرات و نکات جدید

1- امکان انتقال اسناد انبار در قالب تکست به سیستم انبار همکاران سیستم مهیا شده است. امیدوار بودم این انتقال از طریق بانک اطلاعاتی مقدور شود، چنان که افتد و دانی، نشد. برای این منظور دو فرم جدید (به راهنمای Bl_Txt.HLP مراجعه کنید) طرح شده است که در هنگام صدور بارنامه (انبار محصول) ارسال، و در زمان ایجاد صورتحساب نتیجه برگشت تکست می شود. فعال بودن این امکان بستگی به وضعیت فیلد " انتقال اطلاعات بارنامه " در مدیریت – مشخصات سیستم – ارتباط با بانک اطلاعاتی دارد. چون در این فرمها به اطلاعات جرئی تر از کالاها نیاز داشتیم ناچار از تغییر اطلاعات تکمیلی فروشندگان، عاملین و کالاها شدم. فرمهای اوریجینال ایمیل خواهد شد. لطفا اگر از کدهای 601, 602, 603 در فرمها استفاده کرده اید به راهنمای فرمها مراجعه کنید، تغییرات کوچکی لازم دارند.

2- فرمی تحت عنوان IPF در داخل بارنامه داریم که بسیار کاربردی است. تابستان امسال ایجاد شده که معرفی آن را فراموش کرده ام . این فرم به طور کلی کمک می کند وضعیت سفارشهای بارنامه در داخل بارنامه را چاپ کنیم. در راهنمای بارنامه Bl.Hlp به کدهای 161 تا 163 مراجعه فرمائید. چند نمونه آماده در فرمهای اوریجینال گذاشته شده است. توجه داشته باشید که IPF تمام امکانات فرم سفارش را به وراثت می برد از جمله جمع قابل پرداخت سفارشهای یک بارنامه به تفکیک نوع پرداخت، که چاپ آن در زیر بارنامه میتواند بسیار قابل توجه باشد.

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

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

5- دوستانی که مخصوصا روی لب تاپهای خود ویندوز 7 دارند، توجه فرمایند که این ویندوز با Pervasive_8 کار نمی کند. Pervasive_9 را دریافت و نصب کنید. توجه فرمائید که پس از نصب باید از محل PSVW\BIN فایل BTRVDD.DLL را به System32 کپی کنید. احتمالا این اشکال در ورژنهای جدیدتر برطرف شده است.

ریز پرداختی عاملین و فاکتورهای بارنامه

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

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

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

حتی اگر نوشته های من حوصله تان را هم سر می برید اظهار نظر کنید. به من ایراد میگیرید سیستم راهنمای کاربری ندارد اما یک سوزن هم به خودتان بزنید که اصلا حوصله خواندن چه می شود؟ در خصوص برنامه های اجرائی پستی نوشتم و مسئله SLOCAL را توضیح دادم ، MGR,LOCALIZE جدید را به همراه برنامه اجرائی سیستم برای همه فرستادم. اما با این وجود به جزء چند مورد محدود باز ناچار از توضیح دوباره شدم. خوشبختانه وبلاگ مزیتی که بر ایمیل دارد این است که اختیار پاک کردن آن با خودم هست !! این که ایمیل را نخوانده پاک کنیم و بلافاصله بگوئیم ما دریافت نکرده ایم!! داشت تبدیل به سنت سیئه ای می شد. لذت می برم از اینکه برای بعضی از دوستان، چندین و چند بار لینک مطلب را می فرستم تا شاید!! و البته شاید!! بپذیرند که قرار نیست مدام جوال دوز حواله کنند! فرصتی می شود تا سوزنی نیز به خود بزنند. که بعله حال خواندنش و حتی دیدنش نبود!!.

کاهنده های هوشمند

در کاهنده های هوشمند چند تغییر مناسب برای استفاده بهینه داده شده است :

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

2- در نتیجه هر ستون امکان "خروج" هم گذاشته شده است. فرض کنید محدوده یک تا صد منجر به اشانتیون کالای 11 می شود و محدوده 101 تا 200 به کالای 12 ، در این صورت مجبور به تعریف دو جدول هستید. چون کنترل جداول از بیشترین مقدار به پائین هست، اگر بخواهید اپراتور سفارش هیچ دخالتی در انتخاب اشانتیون نداشته باشد باید در جدول اول محدوده جدول دوم را با نتیجه "خروج" مشخص کنید.

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

آنچه در این آیتم ضروری است، ذخیره دوباره کاهنده های هوشمند است بقیه موارد در صورت عدم نیاز هیچ اقدامی لازم ندارد.

ترکی با لهجه فارسی

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

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

گزارش چند سطحی و سالهای مالی گذشته

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

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

پیشنهاد دوم اخیرا در فرد آذربایجان که زیاد از این گزارش استفاده می کنند، اضافه کردن مقایسه سال مالی بود. دو راه حل برای این مسئله بود، اول اینکه مقایسه با سال مالی گذشته مثل خیلی از گزارشها، اضافه و شکل ظاهری آن هم ستونی طرح شود. بالطبع امکاناتی مانند مقایسه و درصد پیشرفت و پسرفت هم جزو لاینفک آن بود. راه حل بعدی امکان رفتن به چندین سال قبلی به انتخاب کاربر بود، که گزارش را به شکل سطری تولید کند. من این راه حل را انتخاب کردم. قبول دارم که در نگاه اول شکل ستونی مطلوب است ولی چون کاربرد چنین گزارشی معمولا مدیریتی است، میتواند کاربرد فوق العاده ای در ساخت گزارشهای خلاصه و بسیار مرتب داشته باشد. دوستانی که با SQL-2005 به بالا کار کرده اند می دانند که امکانی بنام Pivoting دارد با چند خط Script میتوان همین گزارش را به شکل ستونی و بسیار زیبا برگرداند و هر چند سال مالی را که مد نظر باشد گزارش دهی کرد. تصور بفرمائید اگر تاریخ هم یکی از سطوح انتخابی باشد چه گزارشهای کاربردی و مقایسه ای زیبائی میتوان تولید کرد.

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

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

پی نوشت 1 :

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

محاسبه مجدد و مانده فروشنده

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

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

برنامه های اجرائی

بدلایلی و چنان که افتد و دانی سیستم در ابتدای شروع به کار دسترسی نسبتا بالائی از دو محل C:\ و C:\SLOCAL لازم دارد. دومی قابل تحمل است ولی اولی امنیت ویندوز را که معمولا هم روی دوایو سی نصب می شود پائین می آورد. معمولا به شکل پیش فرض هم این مسیر برای کاربر غیر ADMIN بسته است، علاوه بر آن در بسیاری از مراکز توزیع متولیان کامپیوتر مستقیما حضور ندارند و اعمال این دسترسیها کم دردسر ساز نبوده است . متاسفانه در شرایط فعلی ریشه این مسئله کندنی نیست ولی نیاز به محل اولی یعنی C:\ را کاملا حذف کردم . اکنون لازم است دسترسی کامل برای شروع به کار سیستم فقط به فولدر C:\SLOCAL در کامپیوتر کاربر داده شود. توجه فرمائید که برای این منظور هر سه برنامه اجرائی MGR,LOCALIZE,SEL را که ایمیل خواهم کرد باید همزمان دریافت و نصب کنید. شایان ذکر است که در حال حاضر همه به این مسیر دسترسی دارند و هیچ ضرورتی به دستکاری دسترسی کاربران نیست.

عاملین فروش تکراری

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

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

بستن حساب عاملین راکد

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

گزارش چند سطحی عوامل

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

اولین مطلب – بهترین موفقیت در پپسی مشهد

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