مستندات العمليات في المبيعات والمشتريات (Sales and Purchase Operations Documents)

ثماني شاشات صغيرة تحيط بدورة البيع والشراء، تؤدي كل واحدة منها مهمة واحدة بعينها: تسجيل نقص اصطدم به البائع للتو، واستبدال بضاعة تحت اعتماد، وإلغاء حجز، ونقل مجموعة من العملاء إلى مندوب آخر، وإعادة تحديد حالة أمر شراء، ووضع حد لما يمكن للعميل شراؤه، وإعادة تسعير المشتريات بعد الاتفاق على خصم. ليست أي منها مستندًا كبيرًا كالفاتورة، وليست أي منها نقطة البداية لمستخدم جديد — ولهذا بالذات هي التي يُسأل عنها الدعم.

والسؤال الذي يراود القارئ أمام هذه الشاشات واحد دائمًا: لماذا أستخدم هذه الشاشة بدلًا من فتح السجل وتعديله مباشرة؟ والجواب في العادة أحد ثلاثة. فإما أن الحقل ليس حقلًا تكتبه أنت أصلًا (حالة أمر الشراء، أو الكمية المحجوزة)، وإما أن التغيير يجب أن يطال خمسين سجلًا دفعة واحدة، وإما أن أحدهم سيحتاج لاحقًا أن يعرف من غيّر ومتى. فالمستند يعطيك رقمًا وتاريخًا ودفترًا ومسار اعتماد وسجل تعديل؛ أما التعديل المباشر فلا يعطيك شيئًا من ذلك.

الشاشة	مكانها	ما تفعله
مستند نواقص طلبات العملاء	المبيعات ← المستندات ← مستند نواقص طلبات العملاء	يجمّع سطور المبيعات التي تعذّر تنفيذها ويحوّلها إلى أمر شراء
طلب استبدال مبيعات	المبيعات ← المستندات ← طلب استبدال مبيعات	مرحلة الاعتماد التي تسبق الاستبدال الفعلي للبضاعة
سند إلغاء حجز	المخازن ← سندات الحجوزات ← سند إلغاء حجز	يفرج عن جزء من الحجز دون المساس بالطلب
سند تحديث مندوب المبيعات	المبيعات ← المستندات ← سند تحديث مندوب المبيعات	ينقل العملاء إلى مندوب أو مسؤول آخر
مستند تغيير حالة أمر الشراء	المشتريات ← المستندات ← مستند تغيير حالة أمر الشراء	يحدد حالة أمر شراء واحد أو أكثر
تحديد كميات الصنف للعميل	المبيعات ← قوائم الأسعار والعروض ← تحديد كميات الصنف للعميل	يضع حدًا أقصى لما يشتريه العميل من صنف، أو يمنعه تمامًا
تعديل الخصومات	المشتريات ← المستندات ← تعديل الخصومات	يطبّق خصم مورد بأثر رجعي على مستندات شراء محددة
أعادة حساب الخصومات	المشتريات ← المستندات ← أعادة حساب الخصومات	يعيد تشغيل التسعير على دفعة من مستندات الشراء

حول دورة المبيعات

هذه الثلاثة كلها تتعلق بمستند مبيعات موجود بالفعل. وهي شاشات «وماذا حدث بعد ذلك»: الطلب تعذّر تنفيذه، أو العميل يريد صنفًا آخر، أو المخزون المحجوز له لم يعد مطلوبًا.

مستند نواقص طلبات العملاء (Customers Requests Shortage Document)

البائع على الهاتف. العميل يريد اثنتي عشرة وحدة والمتاح أربع. الأربع تُفوتر، والثماني غير الموجودة هي الجزء المثير للاهتمام — فهي طلب حقيقي، باسم عميل وبتاريخ، وفي معظم الشركات يتبخر لحظة انتهاء المكالمة.

مستند النواقص هو المكان الذي يذهب إليه بدلًا من ذلك. وأنت لا تنشئه من القائمة في العادة. ففي فاتورة مبيعات تحمل قائمة المزيد أمر إضافة السطر الحالي الي مستند النواقص (وتحمله أيضًا عدة شاشات مبيعات في مركز الخدمة). تختار السطر الذي تعذّر تنفيذه وتضغط الأمر، فيُضاف السطر — الصنف والكمية والعميل والأسعار، مع مرجع تم إنشاؤه بناءا علي يعود إلى الفاتورة — إلى مستند نواقص.

وأي مستند نواقص يُضاف إليه السطر هو الجزء الذكي، ويُضبط على توجيه مستند المبيعات، في مجموعة اسمها طريقة إنشاء سند النواقص:

الإعداد	ما يحدده
دفتر مستند نواقص طلبات العملاء	الدفتر الذي يُنشأ فيه مستند النواقص
توجيه مستند نواقص طلبات العملاء	التوجيه الذي يُنشأ به
طريقة البحث عن مستند نواقص طلبات العملاء	كيف يُبحث عن مستند نواقص قائم قبل إنشاء مستند جديد

والأخير يقبل التاريخ فقط أو المستخدم فقط أو التاريخ و المستخدم. فمع التاريخ و المستخدم تجتمع نواقص كل مستخدم في اليوم على مستند واحد؛ ومع التاريخ فقط تجتمع نواقص الجميع. وإذا وُجد مستند مطابق أُضيف السطر إليه، وإلا أُنشئ مستند جديد ووُسم بالمستخدم الحالي في حقل المنشئ.

الإعدادات الثلاثة كلها مطلوبة

إذا نقص الدفتر أو التوجيه أو طريقة البحث من التوجيه، يرفض أمر إضافة السطر الحالي الي مستند النواقص برسالة بدلًا من أن يعمل بصمت دون أثر. وهذا هو السبب المعتاد لشكوى العميل بأن الزر «لا يعمل».

والمستند نفسه قائمة عمل بسيطة. يفتحه المشتريات، ويؤشّر على عمود اختيار في السطور التي يريد توفيرها، ثم ينفّذ إنشاء أمر شراء للسطور المحددة فقط من قائمة المزيد. فيُبنى أمر شراء من السطور المؤشَّر عليها فقط، حاملًا مخزن مستند النواقص وتاريخه الفعلي، ويُفتح أمامك. أما مفتاح الأصناف توفرت فهو علامة لاستعمال المشتري نفسه — طريقة لتمييز السطور التي تمت تغطيتها لاحقًا.

فجواب سؤال «لماذا لا أنشئ أمر الشراء مباشرة» هو التوقيت: البائع يسجّل الطلب والعميل ما زال على الخط، دون أن يعرف من سيكون المورد أو يهتم بذلك، وتصل حصيلة يوم كامل من هذه المكالمات إلى المشتريات كقائمة واحدة.

طلب استبدال مبيعات (Sales Replacement Request)

استبدال المبيعات ينفّذ التبديل في خطوة واحدة: المقاس المتوسط يعود، والكبير يخرج، ويُسوّى فرق السعر. وهذا يصلح حين يكون صنف الاستبدال متاحًا على الرف ولا يحتاج الأمر إلى اعتماد أحد.

أما حين لا يكون الأمر بهذه البساطة — صنف الاستبدال يجب طلبه، أو التبديل مطالبة ضمان تحتاج توقيع مشرف، أو العميل سيدفع جزءًا من الفرق الآن وجزءًا لاحقًا — فإن طلب استبدال مبيعات هو المرحلة السابقة له. وله نفس شكل الاستبدال نفسه: السطور ذات الكمية السالبة هي ما يعود، والسطور ذات الكمية الموجبة هي ما يخرج، إضافة إلى صفحة تحصيل فيها سطور الدفعات وجدول الأقساط، وصفحة للشروط النمطية.

وهو يشترك مع استبدال المبيعات في نفس التوجيه، فتنطبق القاعدتان نفسهما على الاثنين:

• يجب وجود سطور بيع و سطور مردود معا — يُرفض المستند ما لم يحمل سطرًا سالبًا واحدًا على الأقل وسطرًا موجبًا واحدًا على الأقل، حتى لا يتحول «الاستبدال» بهدوء إلى مردود في اتجاه واحد.
• منع الحفظ إذا كان الصنف المستبدل غير موجود في بناء على — الصنف الراجع يجب أن يكون موجودًا في المستند الذي بُني الطلب عليه.

وإذا كان إعداد التوجيه يحمل حساب مدين أو دائن، أنشأ الطلبُ أثره المحاسبي عند المعالجة، وهذا ما يتيح لك تحصيل نقود مقابله قبل أن تتحرك البضاعة. ولهذا بالذات تحمل قائمة المزيد فيه إنشاء سند قبض وتجميع سندات القبض.

وحين يُنشأ استبدال المبيعات الفعلي من الطلب لاحقًا، تنتقل سطور الطلب معه، ويُخفَّف شرط أن يكون السطر المستبدل سالبًا بالنسبة للسطور القادمة من الطلب — فالطلب قد حدّد بالفعل ما يسير في أي اتجاه.

سند إلغاء حجز (Reservation Cancellation Document)

أمر بيع حجز 100 وحدة. والعميل خفّض الطلب إلى 60. فأربعون وحدة محجوزة مقابل وعد لم يعد قائمًا، وهي غير مرئية لكل من يحاول بيعها. وتشرح صفحة نظام الحجز كيف نشأ الحجز؛ أما هذا السند فهو الطريقة التي تفرج بها عن جزء منه.

وأنت لا تكتبه من الصفر. بل تولّده من المستند الذي يحمل الحجز، بحيث يشير بناءا على إليه ويصلك جدول التفاصيل معبّأً: سطر لكل سطر محجوز، والكمية معبّأة مسبقًا بما هو محجوز فعلًا. ثم تُدخل الكمية المُلغاة التي تريد الإفراج عنها في كل سطر وتحفظ. وإذا كان التوجيه يحمل حذف سطور بناء على إذا كانت الكمية المحجوزة تساوي صفر مفعّلًا، حُذفت أثناء التوليد السطورُ التي لا حجز عليها بدلًا من بقائها بصفر.

وعند المعالجة لا يتوقف النظام عند المستند الذي ولّدت منه. فتوجيهه يحمل إعادة حفظ المستندات الأعلي من النوع، وهو يسمّي نوع مستند؛ فيتتبّع النظام سلسلة بناءا على صعودًا حتى يصل إلى مستند من ذلك النوع، ويطابق كل سطر إلغاء بالسطر المقابل هناك، وينقص من الكمية المحجوزة في ذلك السطر مقدارَ الكمية المُلغاة، ثم يعيد حفظه. ولهذا تتحرك الكمية المحجوزة على أمر البيع لا على مستند التسليم الوسيط — أنت من يخبر النظام إلى أي مستوى يصعد.

يرفض الإفراج عن أكثر مما لم يُسلَّم بعد

إذا كانت الكمية المتبقية من التسليم في السطر الهدف أقل من الكمية التي تلغيها، فشل الحفظ وذُكر اسم المستند والكميتان معًا. فلا يمكنك الإفراج عن مخزون خرج فعليًا.

وإلغاء سند إلغاء الحجز يعكس أثره: تعود الكمية المحجوزة كما كانت. وهذه القابلية للعكس هي السبب الكامل لعدم تعديل الطلب مباشرة — فالطلب يظل يعبّر عمّا طلبه العميل، والإفراج عن المخزون تصرّف منفصل، مؤرَّخ، وقابل للتراجع.

تعديل سجل يعمل بالفعل

المستندان التاليان موجودان لأن أحدهم يحتاج إلى تغيير حقل في سجلات تعمل بالفعل، والتغيير يستحق رقمًا وتاريخًا.

سند تحديث مندوب المبيعات (Sales Man Update Document)

مندوب يستقيل. منطقة تُقسَّم بين شخصين. حساب متنامٍ يُسلَّم إلى مسؤول حسابات كبرى. وفي كل حالة يجب أن يتغير الحقلان نفسهما في ملف العميل — مندوب المبيعات والمسئول عن العميل — عبر ما بين ثلاثة عملاء وثلاثمائة.

يحمل الرأس مندوب المبيعات الذي تنقل العملاء إليه، والعميل اختياريًا لحالة العميل الواحد، ومن تاريخ وإلى تاريخ، وخمس خانات مرفقات للمذكرة التي أجازت النقل. وتحته مجموعة تجميع العملاء بنطاقات من/إلى — العميل، ومندوب المبيعات، والمسئول عن العميل، والفرع، والقطاع، والإدارة، والمجموعة التحليلية — ويملأ زر تجميع العملاء الجدولَ بكل عميل يقع داخل هذه النطاقات (والمقارنة بالكود). ويجب ملء نطاق واحد على الأقل وإلا رفض الزر العمل.

اترك حقل العميل في الرأس فارغًا عند التجميع

عند كل حفظ تُدفع قيم الرأس إلى كل سطر في الجدول: مندوب المبيعات ومن تاريخ وإلى تاريخ في الرأس تملأ السطور، والعميل في الرأس يستبدل العميل في كل سطر. وهذا مريح حين يكون المستند لعميل واحد، ومدمّر مباشرة بعد تجميع العملاء — إذ سيُعاد كتابة المائتي عميل الذين جمعتهم للتو إلى ذلك العميل الواحد. فاملأ عميل الرأس، أو اجمع قائمة؛ لا الاثنين معًا.

ويجب أن يحمل كل سطر مندوب المبيعات أو المسئول عن العميل (أو كليهما)، ولا يجوز أن يكون من تاريخ فيه بعد إلى تاريخ. والفحص نفسه ينطبق على تاريخي الرأس.

وعند المعالجة يمر النظام على السطور، ولكل سطر تقع فترته بين من تاريخ وإلى تاريخ شاملةً اليومَ، يكتب مندوب السطر والمسؤول عنه في ملف العميل. أما السطر الذي لم تبدأ فترته بعد، أو انتهت، فلا يغيّر شيئًا. فالتواريخ إذن ليست جدولًا سيتصرف النظام بناءً عليه لاحقًا — بل هي حارس يقرر ما إذا كان السطر ينطبق الآن.

وشاشة العميل تعرض عليك هذه السطور: ففي صفحة الإحصائيات توجد قائمة سندات تحديث مندوب المبيعات بكل سطر تحديث مسّ هذا العميل، مع المستند والموظفَين والفترة. وهذا السجل هو الجواب على سؤال «من نقل هذا الحساب ومتى» — وهو سبب القيام بذلك عبر مستند بدلًا من تعديل العملاء واحدًا واحدًا.

مستند تغيير حالة أمر الشراء (Purchase Order Status Change)

يحمل أمر الشراء الحالة: مبدئي أو مؤكد أو توريد جزئي أو توريد كلي أو ألغيت. وهذه الكلمات تحكم كيف تقرأ بقية المنشأة الأمرَ، فالسؤال المهم ليس ما تعنيه بل من يحق له تغييرها وبناءً على أي دليل.

وهذا المستند هو تلك الآلية. ولا يحتاج توجيهًا. وجدوله بأربعة أعمدة: أمر الشراء، والحالة السابقة (تُملأ لك لحظة اختيار الأمر، فترى مما تغيّر)، والحالة الجديدة، وملاحظات لسبب التغيير.

وعند المعالجة يفعل النظام شيئًا أدقّ من مجرد كتابة الحالة الجديدة على الأمر. فلكل أمر مذكور، يجمع كل مستندات تغيير الحالة غير الملغاة التي تذكر ذلك الأمر، ويرتّبها بالتاريخ الفعلي ثم بتاريخ الإنشاء، ويطبّق حالة الأحدث منها. ويترتب على ذلك أمران، وكلاهما مفيد:

• التأريخ بأثر رجعي يعمل. فإذا اكتشفت أن الأمر أُكِّد في الثالث لا في العاشر، أمكنك إدخال مستند بتاريخ الثالث، فينتهي الأمر بالحالة التي يقولها القرار الأحدث فعلًا — لا التي حُفظت أخيرًا.
• إلغاء تغيير الحالة يعيد الأمر إلى الوراء. فإذا حذفت أمرًا من المستند، أو ألغيت المستند، أُعيد حساب الحالة مما تبقّى: يعود الأمر إلى الحالة التي حددها المستند السابق، أو إلى بلا حالة إذا لم يبقَ مستند آخر.

ولأن المعالجة تعيد حساب الحالة من المستندات، فإن حالة تُكتب مباشرة على أمر الشراء تظل مؤقتة — ففي المرة التالية التي يُعالَج فيها أو يُلغى أي مستند تغيير حالة لذلك الأمر، تكون الغلبة للمستندات.

قواعد وأسعار ترتدّ إلى الوراء

الثلاثة الأخيرة تغيّر ما يحسبه النظام، لا مستندًا بعينه. واثنان منها يرتدّان إلى مستندات شراء محفوظة بالفعل.

تحديد كميات الصنف للعميل (Limit Sales Qty)

بعض الأشياء لا تُباع بحرية: منتج مدعوم بحصة شهرية لكل عميل، أو صنف مقيَّد، أو صنف في عرض ترويجي يجب ألا يستأثر به عميل واحد. وتحديد كميات الصنف للعميل هو الملف الرئيسي الذي يعبّر عن هذه الحدود، والنظام هو من يفرضها نيابة عنك عند حفظ فاتورة المبيعات.

وهو ملف رئيسي لا مستند — كود ومجموعة واسم عربي وإنجليزي — ورأسه في معظمه للتيسير. فكل ما تملؤه في الرأس (العميل، تصنيف العميل، فئة العميل، الأولوية، غير نشط، الفترة (أيام)، تصنيف 1–تصنيف 10، فئة الصنف1–فئة الصنف5) يُدفع إلى كل سطر ترك ذلك العمود فارغًا. أما القواعد نفسها فتسكن جدول التفاصيل.

كل سطر تفصيلي قاعدة واحدة، وله نصفان:

النصف	الأعمدة	معنى العمود الفارغ
على من تنطبق	العميل، تصنيف العميل، فئة العميل	أي عميل
على ماذا تنطبق	الصنف، قسم الصنف، تصنيف 1–تصنيف 10، فئة الصنف1–فئة الصنف5	أي صنف

ثم يقول السطر ماذا يحدث. فإما أن يؤشّر منع البيع — هذه التركيبة لا تُباع إطلاقًا — وإما أن يحمل الحد الأقصى للعميل مع الفترة (أيام). والشاشة تفرض الاختيار: فالسطر الذي فيه منع البيع يجب أن يترك الحد الأقصى للعميل فارغًا، والسطر الذي بلا منع يجب أن يملأه. والسطران اللذان يصفان التركيبة نفسها يُرفضان كتكرار، مع ذكر رقمي السطرين.

وعند حفظ فاتورة مبيعات يأخذ النظام كل سطر في الفاتورة ويبحث عن أول قاعدة تطابقه، بترتيب الأولوية — الرقم الأصغر أولًا — عبر كل ملفات تحديد الكميات غير المؤشَّر عليها بـغير نشط. وتنطبق تلك القاعدة وحدها؛ وتُهمَل البقية. فإذا كانت تقول منع البيع فشل الحفظ مع ذكر الصنف. وإلا جمع النظام كمية ذلك الصنف المفوترة على ذلك العميل عبر كل نافذة متحركة بطول الفترة (أيام) تلامس تاريخ الفاتورة، وأضاف إليها كمية الفاتورة الجاري حفظها، وفشل إذا تجاوزت أي نافذة الحدَّ — مع ذكر الصنف والحد والعميل والنافذة الزمنية التي تجاوزته بالضبط.

يجب ملء الفترة (أيام) وإلا لم يفعل الحد شيئًا

النافذة المتحركة مبنية على الفترة (أيام). فإذا تركتها فارغة (أو صفرًا) في سطر يحمل الحد الأقصى للعميل، لم تُفحص أي نافذة إطلاقًا، فلا يُفرض الحد ولا تظهر أي رسالة. أما منع البيع فلا يتأثر — إذ يُفحص قبل منطق الفترة.

ولا تُحتسب في الرصيد الجاري إلا فواتير المبيعات المرحَّلة، مضافًا إليها الفاتورة التي تحفظها. فعروض الأسعار وأوامر البيع لا تستهلك الحصة؛ الفاتورة هي التي تستهلكها.

أما جدول المضاعفات فهو متنفّس المواسم. كل سطر فيه يطابق على العميل أو تصنيف العميل أو فئة العميل، وعلى نافذة من تاريخ–إلى تاريخ تُقارن بتاريخ الفاتورة، ويضرب الكمية المسموح بها في مضاعفات الحد الأقصى للعميل — فالعميل المحدود عادة بعشرة في الأسبوع يمكن منحه ثلاثة أضعاف ذلك في رمضان دون تعديل القاعدة. وإذا حمل سطر المضاعفة الفترة (أيام) أيضًا، حلّت تلك الفترة محل فترة القاعدة طوال المدة. أما السطر التفصيلي المؤشَّر عليه بـعدم تطبيق المضاعفات فيبقى خارج ذلك كله ويحتفظ بحده المجرّد.

ولتعطيل مجموعة قواعد، أشّر غير نشط على الملف بدلًا من حذفه — فالسطور غير النشطة تُتخطّى تمامًا عند تحميل القواعد.

تعديل الخصومات (Discount Update)

انتهى الربع، ورُحّلت فواتير الشراء، والمورد يمنحك الآن 3% مرتجعة على ماركة واحدة على كل ما اشتريته منه منذ يناير. وتعديل تلك الفواتير يدويًا ليس خيارًا حقيقيًا: فخصومات الشراء تغذّي تكلفة الصنف، والتكلفة تغذّي كل ما بعدها.

وتعديل الخصومات مستند (لا يحتاج توجيهًا) يقول «هذا الخصم، على مستندات الشراء هذه». وله ثلاثة أجزاء.

الخصم يقع في مجموعة التفاصيل: حقل مرجع واحد باسم الفاتورة (فاتورة مشتريات أو أمر شراء)، ومن تاريخ وإلى تاريخ للفترة التي يسري فيها الخصم، والخصم | النوع بقيمة قيمة أو نسبة مركبة أو نسبة ثابتة مع قيمة الخصم، ثم الحقلان اللذان يحددان الحساب:

• وقت حساب التخفيض في الفاتورة — في أي خانة من خانات الخصم الثماني في سطر الفاتورة يقع الخصم، من ** خصم 1** حتى ** خصم 8**.
• يحتسب من — الأساس الذي يُحسب منه: تلقائي، أو السعر الإساسي، أو سعر مرجع 1، أو صافي بعد خصم 1 حتى صافي بعد خصم 7.

وتُرفض تركيبتان عند الحفظ، وكلتاهما للسبب نفسه — لا يمكنك الحساب من نتيجة ينتجها هذا الخصم بذاته. فـصافي بعد خصم 1 وصافي بعد خصم 2 لا يمكن أن يقعا في ** خصم 1**، وصافي بعد خصم 2 يجب أن يقع في ** خصم 3**.

وإلى جوارهما الأولوية التي ترتّب هذا الخصم بين بقية الخصومات التي يجدها محرك التسعير، وإيقاف التخفبضات الأخرى الذي ينهي السلسلة بمجرد تطبيق هذا الخصم.

نطاق الخصم هو مجموعة مجال التعديل — الماركة وفئة الصنف1–فئة الصنف5 والصنف. وهي تضيّق الخصم ليطال جزءًا من كل مستند؛ واتركها كلها فارغة فيطال كل السطور. (واختيار صنف يفرّغ الفئات، فالاثنان بديلان.)

المستندات هي جدول الفواتير. يمكنك تسمية مستند واحد في حقل الرأس، أو ملء الجدول، أو الاثنين. وتملأ مجموعة معايير تجميع الفواتير مع زر Collect الجدولَ نيابة عنك: تختار نوع الفاتوره المجمعه (أمر شراء أو فاتورة مشتريات — وهو مطلوب)، ثم تضيّق اختياريًا بنطاقات القطاع والفرع والإدارة والمجموعة التحليلية والمورد، وبنطاق تاريخ.

Collect لا يُرجع إلا المستندات التي عليها تطبيق خصومات الموردين

هذه الشاشة وشاشة أعادة حساب الخصومات كلتاهما لا تجمّعان إلا مستندات الشراء التي فُعِّل فيها تطبيق خصومات الموردين، ومحرك التسعير أصلًا لا يطبّق خصومات الموردين إلا على تلك المستندات. فالجدول الفارغ بعد Collect يعني غالبًا أن هذا الخيار مغلق على المستندات التي كنت تتوقعها.

ويتحقق الحفظ من أن كل مستند مذكور هو مستند شراء وله مورد، وأن هناك مستندًا واحدًا على الأقل. ثم يسجّل مدخل خصم واحدًا لكل مستند مذكور، مربوطًا بهوية ذلك المستند. وهذا الربط هو ما يفصل هذه الشاشة عن خصم المورد الدائم: فبقية فواتير المورد نفسه لا تُمسّ، لأن المدخل لا يطابق إلا المستندات التي ذكرتها والمستندات المولَّدة منها.

غير أن الحفظ وحده لا يغيّر أي سعر. تطبيق هو ما يفعل ذلك — ويجب أن يكون المستند محفوظًا أولًا — فيعيد حفظ كل مستند شراء متأثر، حتى يلتقط محرك التسعير الخصم الجديد وتُعاد حساب تكاليف الأصناف. ولأمر الشراء الموجود في القائمة، يعيد أيضًا حفظ فواتير المشتريات المولَّدة من ذلك الأمر، فيصل الخصم إلى الفواتير لا إلى الأمر وحده.

وحذف مستند تعديل الخصومات يعكس كل ذلك: تُصفَّر مدخلات الخصم وتُعاد فواتير المشتريات المتأثرة إلى الحفظ، فتعود الأسعار كما كانت. وإعادة الحساب والتتابع وقابلية العكس مجتمعةً هي سبب كون هذا مستندًا لا تعديلًا.

أعادة حساب الخصومات (Discounts Recalculation)

الشاشة الشقيقة تجيب عن سؤال آخر. فلا شيء في هذا الخصم قد تغيّر — الذي تغيّر هو البيانات التي تحته. فقد صُحّح ملف خصم مورد، أو أُصلحت قائمة أسعار شراء، أو أُعيد تصنيف فئة، ودفعة من مستندات الشراء المحفوظة قبل التصحيح ما زالت تحمل الأرقام القديمة.

وأعادة حساب الخصومات (وهي أيضًا بلا توجيه) تعيد ببساطة تشغيل التسعير على دفعة. تسأل صفحتها الأساسيات عن مورد ونوع الفاتورة (أمر شراء أو فاتورة مشتريات) ونطاق من تاريخ–إلى تاريخ، وتحمل مجموعة الاختيارات بأربعة مفاتيح تحدد بالضبط كم يُسمح لكل سطر أن يتحرك:

الخيار	أثره
تحديث السعر	إعادة حساب سعر الوحدة
تحديث الخصم العادي	إعادة حساب الخصم الرئيسي في السطر
تحديث الخصم 1	إعادة حساب الخصم 1
تحديث خصم 2	إعادة حساب الخصم 2

وتحمل صفحة التفاصيل الزرّين. يملأ Collect الجدولَ من المورد ونطاق التاريخ ونوع الفاتورة — بنفس شرط تطبيق خصومات الموردين الموضّح أعلاه — وعمودا الجدول الفاتورة والتاريخ الفعلي غير قابلين للتعديل، لأنهما نتيجة البحث لا شيء تكتبه أنت. أما تطبيق، على مستند محفوظ، فيعيد حفظ كل مستند مدرج بالنطاق الذي أشّرت عليه، مضافًا إليه فواتير المشتريات المولَّدة من أي أمر شراء في القائمة.

وسبب فعل ذلك هنا بدلًا من فتح كل مستند وإعادة حفظه هو النطاق: يمكنك تحديث الخصومات دون المساس بأسعار جرى التفاوض عليها يدويًا، أو تحديث الأسعار دون المساس بالخصومات، ويبقى بعدها مستند مرقَّم يقول أي دفعة أُعيد تشغيلها ومتى.

أيهما أحتاج؟

استخدم تعديل الخصومات حين يكون هناك خصم جديد تريد إدخاله وربطه بمستندات شراء بعينها. واستخدم أعادة حساب الخصومات حين تكون قواعد الخصم صحيحة بالفعل ولا تحتاج إلا أن تلحق بها المستنداتُ المحفوظة. وكلتاهما تنتهيان بـتطبيق، وكلتاهما تتركان الحساب الفعلي لمحرك تسعير المشتريات.