يكسان بودن وضعيت استاندارد پذيري و روش تعيين بهاي الگوهاي عمليات مالي بين xml و پايگاه اطلاعاتي كنترل مي‌شدند. اين درحالي است كه قرار است الگوها خوانده شوند و سپس كالاهاي مربوط به اين الگوها خوانده شوند و در نهايت عمليات مربوط به آن كالاها نيز خوانده شوند. در واقع، عمليات كالاهاي مزبور از استانداردپذير بودن و روش تعيين بها متاثر خواهند شد. اين عمليات همواره به صورت پيش نويس خوانده مي‌شوند و حتي اگر مشكلي در اين زمينه وجود داشته باشد، اين مشكلات همگي در زمان عملياتي شدن برگه‌ها برطرف خواهند شد. به همين دليل بد نديديم كه تفاوت‌هاي پيش گفته را تحمل كنيم.

يعني در صورت علامت گذاري گزينه "تحمل شود"، اولا تفاوت مشخصات فوق در بين الگوهاي موجود در xml و متناظر آن الگوها در پايگاه اطلاعاتي بدون اهميت خواهند شد و ثانيا تفاوت الگوي كالاهاي موجود در xml با الگوي كالاهاي موجود در پايگاه اطلاعاتي نيز تحمل خواهند شد. اين تحمل، مثلا براي خواندن اطلاعات از يك سيستم مقداري كه اطلاعات مالي مختصر و ناكاملي دارد در يك سيستم ريالي، نقش بسيار مهمي را ايفا مي‌كند.

البته يك استثناي بسيار مهم در اين ميان وجود دارد: تفاوت روش تعيين بها از شناسايي ويژه به غير آن و برعكس تحمل نمي‌شود. يعني اگر يك الگو در xml شناسايي ويژه باشد و الگوي داراي همان كد در پايگاه مثلا ميانگين يا LIFO باشد (يا برعكس)، اين وضعيت غيرقابل تحمل فرض مي‌شود.

همين عدم تحمل در تفاوت الگوي عمليات مالي يك كالاي به خصوص نيز اعمال مي‌شود. رخدادهاي خروج كالاهاي شناسايي ويژه بايد حتما داراي "مرجع" باشند و به همين دليل تفاوت از شناسايي ويژه به غير آن يا برعكس، منجر به بي‌اعتبار شدن رخدادهاي موجود در xml خواهد شد.



•    اصلاح الگوهاي عمليات مالي كالاها با محدوديت‌هاي بسيار زيادي مواجه بود و در اين نسخه تغيير اساسي كرده است. پيش از اين هر تغييري در الگوي عمليات مالي كالايي كه داراي رخداد باشد ممنوع بود. اين در حالي است كه اگر رخدادهاي كالا پيش نويس باشند، با همان منطقي كه در بند قبل گفتيم، مي‌توانيم بسياري از تغييرات و اصلاحات را مجاز بدانيم:

o    تغيير الگوي عمليات مالي كالايي كه داراي رخداد غيرپيش نويس باشد ممنوع است. اين محدوديت به اين سختي در مورد رخدادهاي پيش نويس وجود ندارد.

o    حذف الگوي عمليات مالي كالايي كه داراي رخداد است – حتي رخداد پيش نويس – ممنوع است.

o    اگر كالا فقط داراي رخداد پيش نويس است، الگوي عمليات مالي آن نبايد به نحوي تغيير كند كه الگوي قبلي شناسايي ويژه بوده و الگوي جديد شناسايي ويژه نباشد (يا برعكس). توضيح اين مورد بسيار مشابه موردي است كه قبلا براي فراخواني از xml شرح داديم.



•    اصلاح واحدهاي مقدار يا تعدادي كه در كالاها بكار رفته بودند، قبلا بسيار سخت و با كنترل‌هاي زياد مواجه بود. واحدهاي مزبور اصولا قابل اصلاح نبودند – حتي نام. اين وضعيت را تغيير داديم:

o    يك "امكان" براي كاربران اضافه كرديم: "اصلاح واحد بكار رفته در كالاها". كاربري كه اين امكان را نداشته باشد با همان محدوديت‌هاي پيش گفته مواجه خواهد شد و نمي‌تواند واحد را اصلاح كند.

o    تغيير واحد كالايي كه رخداد نداشته باشد بلامانع است.

o    كماكان از تغيير واحد اصلي و نيز واحدهاي فرعي در كالاهايي كه داراي رخداد هستند ممانعت مي‌كنيم.



•    در نسخه 200، تنها روشي كه براي ايجاد يكباره موجودي ابتداي دوره در سال جديد داشتيم، فراخواني برگه موجودي انتهاي دوره سال قبل بود. حال كه در سيستم مقداري، برگه موجودي انتهاي دوره نداريم، بايد ابزاري به صورت جايگزين تعبيه نماييم. به اين منظور، امكان پر كردن برگه موجودي ابتداي دوره با موجودي كالاها در انتهاي سال مالي قبل را پياده كرديم. يك item در منوي افزودن (+) در برگه مزبور اضافه شده است.

اين امكان، همچنين براي انتقال موقت موجودي‌ها به سال جديد در يك سيستم ريالي هم كاربر دارد. تا پيش از آماده شدن موجودي انتهاي دوره سال قبل، مي‌توان موجودي‌ها را با اين ابزار به سال جديد انتقال داد. البته برگه‌هاي سال قبل بايد پيش‌نويس بمانند. همچنين استفاده از اين روش براي كالاهاي شناسايي ويژه بسيار خطرناك است. يعني اگر موجودي كالاهاي شناسايي ويژه را با اين روش منتقل كنند و بعدا اين موجودي‌هاي موقتا انتقال يافته را با رخدادهاي خروج، خارج نمايند، سطرهاي موقت به عنوان مرجع شناسايي ويژه بكار خواهند رفت و بعدا قابل حذف نخواهند بود. بايد موارد كاربرد آنها را بعدا اصلاح نمايند و موجودي اصلي منتقل شده را به عنوان مرجع انتخاب كنند.



•    تعيين خودكار بچ براي كالاهاي صادره – اين ابزار در برگه‌هاي خروج، نقل و انتقال و انبارگرداني پياده شده است (نه در برگه‌هاي شمارش كالا و نه در ساير انواع برگه‌ها). يك item در منوي افزوده (+) در اين برگه‌ها به همين منظور تعبيه شده است. در صورتي كه رخداد خروج براي يك كالاي بچ پذير درج شده باشد، اين ابزار براي تعيين بچ و يا تفكيك مقدار خروج به تعدادي بچ بكار خواهد رفت.

فهرستي از بچ‌هايي كه داراي مانده از كالاي تحت مكان‌نما مي‌باشند را ارائه مي‌كند. بچ‌ها به ترتيب تاريخ انقضا و تاريخ بچ بازنمايي مي‌شوند. براي هر بچ يك مقدار مصرف از بچ در اين فهرست وجود دارد كه توسط كاربر قابل تعيين است. در ابتدا با توجه به مقداري كه در سطر برگه درج شده بوده است، تلاش مي‌شود تا از ابتداي فهرست، مقدار مزبور با بچ‌هاي داراي موجودي تامين شود. در نهايت مقاديري كه كاربر در مقابل هر بچ درج يا اصلاح كرده است ملاك خواهند بود. پس از تصويب، مقادير تعيين شده در برگه درج خواهند شد. مقدار اول در همان سطري كه در دست تدوين بوده است درج خواهد شد. سپس براي مقادير ديگر، ابتدا همان سطر، كپي (مشابه Alt+Enter) مي‌شود . سپس بچ و مقدار مصرف از بچ به عنوان مقدار در سطر جديد درج خواهند شد.

كاربرد اصلي اين ابزار در مواردي است كه مي‌خواهيم كالايي را به مصرف كننده تحويل دهيم و برايمان فرقي نمي‌كند كه از كدام بچ به وي تحويل دهيم – فقط مقدار تحويل و كالا را مي‌دانيم. سيستم به صورت خودكار، مقدار موردنظر را از بچ‌هاي قديمي‌تر تامين مي‌كند. واضح است كه انباردار بايد پس از استفاده از اين ابزار، كالاها را از همان بچ‌هايي كه سيستم تشخيص داد است (يا خودش اصلاح كرده است) به مصرف كننده تحويل نمايد. اين ابزار داراي فرم نمايش و يك item اختصاصي در امكانات كاربران مي‌باشد.



•    تعيين خودكار مرجع شناسايي ويژه براي كالاهاي صادره. اين ابزار دقيقا همانند تعيين خودكار بچ عمل مي‌كند ولي براي كالاهاي شناسايي ويژه و براي تعيين مرجع آنها بكار مي‌رود. به صورت يك item در منوي (+) در برگه‌هاي خروج، نقل و انتقال و انبارگرداني قابل استفاده است. داراي فرم نمايش و item اختصاصي در امكانات كاربران نيز مي‌باشد. براي اينكه اين ابزار قابل استفاده باشد، مجبور شديم تغيير كوچكي نيز در نحوه برخورد سيستم با رخدادهاي خروج كالاهاي شناسايي ويژه بدهيم. پيش از اين، مرجع رخدادهاي مزبور حتما بايد تعيين مي‌شد وگرنه امكان درج سطرها در برگه وجود نداشت. اما در نسخه 201، اين كنترل به زمان ذخيره برگه منتقل شده است – مي‌توان سطرها را بدون مرجع درج نمود اما پيش از ذخيره كردن برگه حتما بايد مرجع را تعيين نمود (مثلا با همين ابزاري كه در اين بند شرح داده شد).



•    كنترل وجود موجودي كافي براي كالاهاي رزرو شده، در نسخه قبلي بسيار حساس فرض شده بود. به هيچ وجه امكان كم كردن موجودي كالاهاي رزرو شده به غير از تحويل آن به مركزي كه عمل رزرو را انجام داده است وجود نداشت. اين وضعيت مشكلاتي را به همراه داشت: از همه مهمتر اين بود كه تنظيم رخدادهاي موجوي انتهاي دوره براي اين كالاهاي رزرو شده ميسر نبود (چون موجودي را صفر مي‌كرد) – همين مشكل در نقل و انتقال و انبارگرداني هم وجود داشت. ديگر اينكه هيچ كاربري با هيچ درجه‌اي از اختيارات نمي‌توانست كالاي رزرو شده را در اختيار مركز ديگري قرار دهد.

براي برطرف كردن اين مشكلات، مكانيزم كنترل موجودي كالاهاي رزرو شده را تغيير داديم. اولا فقط در زمان ذخيره برگه‌هاي خروج اين كنترل انجام مي‌شود. ثانيا در client كنترل مي‌شود و به اين ترتيب امكان تعريف يك "اختيار كاربر" براي تجاوز از اين خطا (و تحويل كالا به ديگري) فراهم شده است. اين اختيار با عنوان "كمتر كردن موجودي كالا نسبت به مقدار رزرو شده" تعريف شده است.

در مقابل، يك item با عنوان "تنظيم يا تدوين درخواست‌هاي رزرو" نيز در اختيارات كاربران تعريف كرديم كه عملا بايد از ابتدا وجود مي‌داشت و فراموش شده بود. كل اين موارد يك محدوديت بسيار بزرگ در سيستم بوجود آورده‌اند كه در بند بعدي شرح داده‌ايم.



•    پيش از اين مي‌توانستيم مقدار رخدادهاي انبار متصل به رخدادهاي درخواست را بيشتر از مقدار درخواست تنظيم كنيم. اين وضعيت بسيار مطلوب بود و باعث مي‌شد كه در زمان اعلام خريد كالاهاي درخواستي يا تحويل كالاهاي درخواستي به مراكز، محدوديت كمتري داشته باشيم. متاسفانه با اين وضعيت نمي‌توانستيم كنترل رزروها را با سياست جديد در client انجام دهيم و به همين دليل از اين پس ديگر مقدار تحويلي به انبار يا به مركز نمي‌تواند بيشتر از مقدار درخواست باشد. اين حالت حتي در زماني كه يك رخداد درخواست توسط چند رخداد انبار تحويل مي‌شود نيز كنترل شده است.



•    در خلاصه اطلاعات كالاهاي نسخه 201 ، بچ‌پذير بودن كالا، مقدار رزرو كالا و موجودي كالا پس از كسر رزروها نيز بازنمايي مي‌شوند.



•    اگر از يك بهاي استاندارد در تعيين بهاي رخدادهاي انبار استفاده شده باشد، ديگر امكان اصلاح يا حذف آن بهاي استاندارد را به كاربر نمي‌دهيم. همچنين درج بهاي استاندارد جديد در تاريخي كه منجر به بي‌اعتبار شدن رخدادهاي موجود در آن تاريخ يا تاريخ‌هاي بعد شود نيز ميسر نبود (آن رخدادها حتما از بهاي استاندارد قبلي استفاده كرده‌اند و درج بهاي استاندارد در تاريخي كه با آنها هم‌پوشاني داشته باشد منجر به خرابي بهاي آن رخدادها خواهد شد).

اما رخدادهاي موجودي ابتداي دوره (و نيز موجودي انتهاي دوره) از بهاي استاندارد استفاده نمي‌كنند. اگر در يك تاريخ، فقط از اين نوع رخدادها وجود داشته باشد، اصلاح، حذف يا درج بهاي استاندارد در همان تاريخ‌ها نبايد با محدوديت مواجه مي‌شد – در نسخه ابتدايي تمام كنترل‌هاي مزبور به اشتباه براي اين رخدادها نيز انجام مي‌شد.



•    امكان ذخيره برگه‌هاي انبار در فايل وارده XP براي برگه‌هاي ورود، خروج، ابتداي دوره، انتهاي دوره و انبارگرداني فراهم شده است. فايل حاصله، يك فايل xml با مدل ساده و مبتني بر كد خواهد بود. در زمان فراخواني چنين فايلي، صرف وجود كالا، انبار، مركز، بچ، حساب و تفصيلي‌ها با كدهاي مندرج در فايل xml كافي خواهد بود و كنترل‌هاي اساسي و متداول در فراخواني فايل‌هاي صادره در مورد آنها انجام نخواهد شد.

برگه‌هاي موجودي انتهاي دوره توانايي فراخواني فايل را ندارند (اين برگه‌ها اصولا قابل تدوين نيستند و به صورت خودكار ايجاد مي‌شوند). اما مي‌توان فايل ايجاد شده از يك برگه موجودي انتهاي دوره را به عنوان موجودي ابتداي دوره فراخواني نمود.

رخدادهايي كه طبق تعريف داراي مرجع مي‌باشند قابل فراخواني از فايل وارده XP نيستند. اينها شامل تمام انواع رخداد برگشت دوره جاري مي‌باشند. تمام اين رخدادها به صورت برگشت دوره قبل فراخواني خواهند شد. البته كاربر مي‌تواند پس از فراخواني و پيش از ذخيره‌سازي برگه، اصلاحات لازم را (حتي در نوع رخداد) انجام دهد. همچنين رخدادهاي خروج كالاهاي شناسايي ويژه نيز به صورت بدون مرجع خوانده مي‌شوند و لازم است تا پيش از ذخيره برگه به روشي (مثلا با استفاده از ابزاري كه جديدا آماده كرده‌ايم) براي آنها مرجع تعيين شود.

سطرهاي آزاد و طرف حساب عمومي برگه‌ها نيز با اين فايل قابل تبادل مي‌باشند. فراخواني اين اجزاء به خواست كاربر ميسر است. در صورتي كه برگه‌ها از نظر رخدادهاي داخلي با هم مطابق نباشند (مثلا فايلي از يك برگه ورود تشكيل شده و در يك برگه خروج خوانده شود)، كماكان طرف حساب عمومي و سطرهاي آزاد قابل فراخواني خواهند بود.



•    در گزارش گردش و موجودي كالاها، فيلدهاي مقدار رزرو شده از كالا و نيز موجودي كالا پس از كسر رزرو اضافه شدند. اين فيلدها در فرم استاندارد "موجودي و درخواست" در همان گزارش تعريف شده‌اند. به اين ترتيب مي‌توان از گردش و موجودي كالاها براي اخذ گزارش سرجمع از درخواست‌ها و رزروها نيز استفاده نمود.



•    در همان گزارش گردش و موجودي كالاها، يك option با عنوان "فقط كالاهاي رزرو شده بازنمايي شوند" نيز اضافه شد. به اين ترتيب، همين گزارش (با فرم مناسب) به جاي گزارش از كالاهاي رزرو شده نيز قابل استفاده خواهد بود. البته امكان مزبور فقط براي كالاهاي عملياتي (سطح آخر) بكار خواهد رفت.



•    دو item به اختيارات كاربران اضافه شد كه فكر مي‌كنم نياز به توضيح نداشته باشند (در برگه‌ها / تنظيم برگه‌هاي انبار):

o    تنظيم رخدادهاي ورود مستقل از درخواست

o    تنظيم رخدادهاي خروج مستقل از درخواست



•    درخواست‌هاي جاري در يك سال مالي، پس از خاتمه سال مالي بلاتكليف مي‌مانند. اين درخواست‌ها بايد به روشي به سال جديد منتقل گردند. به اين منظور يك item در منوي برگه‌ها تعريف كرديم: "انتقال درخواست‌هاي جاري از سال مالي قبل". روش كار معلوم است. درخواست‌هاي جاري و داراي مانده در سال قبل بررسي مي‌شوند و به اندازه مانده درخواست‌هاي باقي‌مانده، درخواست‌هاي جديد در سال مالي جاري تنظيم مي‌شود. درخواست‌ها به تفكيك "نوع برگه درخواست" بررسي مي‌شوند و به ازاي هر نوع برگه يك برگه جديد در سال مالي جديد درج مي‌شود. شرح و تاريخ اين برگه‌ها از كاربر پرسيده مي‌شود.

قاعدتا بايد فقط رخدادهاي تاييد شده را به سال جديد منتقل كنيم – با اين همه اين امكان را به كاربر داده‌ايم كه رخدادهاي تاييد نشده را نيز به سال جديد منتقل نمايد. همچنين، براي جلوگيري از تكراري شدن درخواست‌ها بايد ترتيبي دهيم كه درخواست‌هاي منتقل شده از سال مالي قبل به وضعيت "خاتمه يافته" درآيند. البته اين عمل نيز بنا به خواست كاربر ممكن است انجام داده نشود.

تعداد سطرهاي برگه‌هايي كه از اين فرآيند حاصل مي‌شود، ممكن است بسيار زياد شود و مي‌دانيم كه در كار با برگه‌هاي بزرگ همواره با مشكل مواجه هستيم. كاربر مي‌تواند در صورت تمايل ترتيبي دهد كه تعداد سطرهاي برگه‌هاي حاصله محدود باشد.

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