Sales invoice pricing issue: what happened, why, and the fixمشكلة تسعير فواتير المبيعات: ما حدث، وسببه، والإصلاح

The invoice (posting date 15/10/2026, a draft awaiting approval) was created on 5/11/2026 at 11:01 and then saved four more times within eleven minutes. The problem is on line 4, item 18527 (خلطة المحشى كيس 50 جم). Times are as recorded on the invoice.

الفاتورة (تاريخ الترحيل 15/10/2026، مسودة في انتظار الاعتماد) أُنشئت يوم 5/11/2026 الساعة 11:01 ثم حُفظت أربع مرات أخرى خلال إحدى عشرة دقيقة. المشكلة في السطر رقم 4، الصنف 18527 (خلطة المحشى كيس 50 جم). الأوقات كما هي مسجلة على الفاتورة.

After the change at 11:05, saves that only touched other lines were enough to multiply line 4 again: by 36, then by 1,296, then by 1,679,616 compared with its price list rate. The amount in words and the payment schedule still show 678,572 because they had been filled in before the last recalculation. Line 7 (item 18581) shows the same pattern on a small scale: 140.44 instead of 140.36.

بعد التغيير الذي تم الساعة 11:05 كان حفظ الفاتورة بسبب تعديل سطور أخرى كافيًا لمضاعفة السطر 4 مرة أخرى: 36 ضعفًا، ثم 1,296 ضعفًا، ثم 1,679,616 ضعفًا مقارنة بسعر القائمة. وما زال المبلغ بالحروف وجدول السداد يعرضان 678,572 لأنهما حُسبا قبل إعادة الحساب الأخيرة. ويظهر نفس النمط بشكل بسيط في السطر 7 (الصنف 18581): 140.44 بدلًا من 140.36.

Three things came together:

1. The trigger. When the unit on line 4 was changed from carton to box of 12, the price list rate followed (130.80) but the rate stayed at the carton price (784.80). Why the screen kept the old rate is still being looked into; the new check described in section 4 now catches this every time it happens.
2. ERPNext records a rate above the price list rate as a margin (here 654.00). One of the system's customizations also turned the same difference into a negative discount (−500%).
3. A second customization then put the rate back to the price list rate, but left the margin and the negative discount on the line. The next calculation applied both: (130.80 + 654.00) × (1 + 500%) = 4,708.80.

From then on every save repeated this on the new rate, so each save multiplied the rate by (rate ÷ price list rate): 6 times, then 36, then 1,296, then 1,679,616 times the price list rate.

Not the cause: the price list (every other line on the invoice is priced correctly), the 7% wholesale discount (pricing rule PRLE-0017, valid on the posting date and applied correctly) and VAT.

Sales Orders and Quotations have the same defect in a different form: the rate column shows the price list rate while the line amount doubles on every save. This was reproduced on the test environment; Sales Orders and Quotations on production have not been checked yet.

اجتمعت ثلاثة أمور:

1. البداية. عند تغيير وحدة السطر 4 من كرتونة إلى علبة 12 كيس تغيّر سعر القائمة إلى 130.80، لكن السعر في السطر بقي سعر الكرتونة (784.80). سبب احتفاظ الشاشة بالسعر القديم ما زال قيد الفحص، والفحص الجديد الموضح في القسم 4 يكتشف هذه الحالة في كل مرة تحدث فيها.
2. يسجّل ERPNext السعر الأعلى من سعر القائمة على أنه هامش (هنا 654.00)، وكان أحد التخصيصات في النظام يحوّل نفس الفرق أيضًا إلى خصم بالسالب (−500%).
3. ثم كان تخصيص ثانٍ يُرجع السعر إلى سعر القائمة لكنه يترك الهامش والخصم السالب على السطر، فطبّق الحساب التالي الاثنين معًا: (130.80 + 654.00) × (1 + 500%) = 4,708.80.

ومن بعدها كان كل حفظ يكرر ذلك على السعر الجديد، فيُضرب السعر في كل مرة في (السعر ÷ سعر القائمة): 6 أضعاف، ثم 36، ثم 1,296، ثم 1,679,616 ضعف سعر القائمة.

ليست سببًا: قائمة الأسعار (كل السطور الأخرى في الفاتورة مسعّرة صحيحًا)، وخصم الجملة 7% (قاعدة التسعير PRLE-0017 سارية في تاريخ الترحيل ومطبقة صحيحًا)، وضريبة القيمة المضافة.

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

We searched vendors.k.frappe.cloud on 5 November 2026 (12:29 UTC, read-only) for invoice lines carrying this defect's mark, a negative discount percentage. 54 invoices (59 lines) have it, excluding cancelled ones.

تم البحث في vendors.k.frappe.cloud يوم 5 نوفمبر 2026 (الساعة 12:29 بتوقيت UTC، قراءة فقط) عن سطور الفواتير التي تحمل علامة هذا الخلل، وهي نسبة خصم بالسالب. 54 فاتورة (59 سطرًا) بها هذه العلامة، بدون الفواتير الملغاة.

These have no accounting effect yet. Please do not approve or save them before the fix is on production: every save multiplies the rate again.

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

ACC-SINV-2026-09596 and ACC-SINV-2026-09438 are clear cases: item 13038 at 17,024.00 per jerrycan against a price list rate of 66.50 (256 times), about 84,787.50 too much on each, and both unpaid. The other lines need a line-by-line review. Payment status was read on 5 November 2026.

ACC-SINV-2026-09596 و ACC-SINV-2026-09438 حالتان واضحتان: الصنف 13038 بسعر 17,024.00 للجركن مقابل سعر قائمة 66.50 (256 ضعفًا)، أي زيادة حوالي 84,787.50 في كل منهما، وكلتاهما غير مسددة. باقي السطور تحتاج مراجعة سطرًا بسطر. حالة السداد كما هي يوم 5 نوفمبر 2026.

Rates slightly above the price list rate, for example 842.40 or 843.18 against 842.14. Together the difference is 2,208.99 EGP before discount and VAT.

أسعار أعلى قليلًا من سعر القائمة، مثل 842.40 أو 843.18 مقابل 842.14. إجمالي الفرق 2,208.99 جنيه قبل الخصم والضريبة.

The fix was applied on the test environment egeu.datavalue.app on 5 November 2026 and tested there. It is not yet on vendors.k.frappe.cloud.

What changes for users

• A line with no pricing rule whose rate is above the price list rate is set back to the price list rate on save. Its margin and discount are cleared with it, so it can no longer grow. An orange message names each line that was set back.
• A negative discount is no longer created from such a line, and one left by an earlier save is removed.
• The amount in words and the payment schedule are refreshed after the recalculation, so they always match the total.
• Sales Orders and Quotations are recalculated as well, so the line amount always equals rate × quantity.
• New check when a Quotation, Sales Order, Delivery Note or Sales Invoice is saved or submitted: if a line's unit or item was changed but its rate stayed at the old price, the user is warned (or, if you choose, the save is refused). This covers the trigger of this incident, including a rate left below the price list rate.

New settings page: ECS Pricing Settings

تم تطبيق الإصلاح على بيئة الاختبار egeu.datavalue.app يوم 5 نوفمبر 2026 واختباره عليها، ولم يُطبَّق بعد على vendors.k.frappe.cloud.

ما يتغير للمستخدمين

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

صفحة إعدادات جديدة: ECS Pricing Settings

“Keep the entered rate” is only for a deliberate sale above the price list without a pricing rule. With it the rate stays as entered and no longer grows, and the new check still warns when the rate is left over from a previous unit or item.

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

Each test document was saved three times, first with the code as it was before the fix and then with the fix. All test data was rolled back, so nothing was left on the test environment. Values are shown after save 1 → save 2 → save 3.

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

In every test after the fix, the amount in words and the payment schedule matched the total. Reference TASK-2026-17756; code changes committed in ecs_egeu f8efa33 and egeu_mobile ffcac75, not yet deployed to production.

في كل الاختبارات بعد الإصلاح تطابق المبلغ بالحروف وجدول السداد مع الإجمالي. المرجع TASK-2026-17756؛ تعديلات الكود محفوظة في ecs_egeu f8efa33 و egeu_mobile ffcac75، ولم تُنشر على الإنتاج بعد.

1. Approve the deployment to production (vendors.k.frappe.cloud). The deployment creates the settings page and makes the fix live.
2. Drafts in table A: please do not approve or save them before the deployment. After it, one save sets the affected lines back to the price list rate; check each line and its unit before approving. If one has to go out sooner, delete the affected line, add it again choosing the unit first, and check that the rate equals the price list rate before saving.
3. Posted invoices in tables B and C: how to correct them (credit notes, or cancel and re-issue) is a finance decision. We can prepare a line-by-line list with the correct amounts.
4. We will also check Sales Orders and Quotations on production, and your other site egeu2025.frappe.cloud, which runs the same customizations.
5. Keep the default “Set back to the price list rate” unless you deliberately sell above the price list without a pricing rule.

1. الموافقة على النشر على بيئة الإنتاج (vendors.k.frappe.cloud)، وبه تُنشأ صفحة الإعدادات ويصبح الإصلاح فعالًا.
2. المسودات في الجدول (أ): يُرجى عدم اعتمادها أو حفظها قبل النشر. بعد النشر يكفي حفظ واحد لإرجاع السطور المتأثرة إلى سعر القائمة؛ يُرجى مراجعة كل سطر ووحدته قبل الاعتماد. وإذا لزم إصدار إحداها قبل ذلك: احذفوا السطر المتأثر، ثم أضيفوه من جديد مع اختيار الوحدة أولًا، وتأكدوا أن السعر يساوي سعر القائمة قبل الحفظ.
3. الفواتير المرحّلة في الجدولين (ب) و(ج): طريقة تصحيحها (إشعارات دائنة، أو إلغاء وإعادة إصدار) قرار مالي لديكم، ويمكننا تجهيز قائمة سطرًا بسطر بالمبالغ الصحيحة.
4. سنقوم أيضًا بفحص أوامر البيع وعروض الأسعار على الإنتاج، وموقعكم الآخر egeu2025.frappe.cloud الذي يعمل بنفس التخصيصات.
5. يُفضَّل الإبقاء على الخيار الافتراضي «إرجاعه إلى سعر القائمة» إلا إذا كنتم تبيعون عمدًا بسعر أعلى من القائمة بدون قاعدة تسعير.