حقل المال الوحيد

عمّ تدور هذه الدورة

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

ويسأل هذا الدرس سؤالاً أضيق أوّلاً، وجوابه هو الذي يقرّر الباقي كلّه. أيّ مال يحمله هذا البرنامج فعلاً؟ لا ما يحمله نظام مصنع عادةً. بل ما يحمله هذا، في جداوله هو، اليوم.

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

راتمالغودا أباريلز (Ratmalgoda Apparels) مصنع ملابس كاجوال منسوجة ومحبوكة في كاتوناياكي (Katunayake) بسريلانكا. يشغّل ستّة خطوط خياطة ويبيع إلى شمال أوروبا. ويظهر خمسة أشخاص في هذه الدورة.

• سانجيوا أماراسينغي (Sanjeewa Amarasinghe) هو المالك. يدخل بدور المالك / المدير العام، والدرس الخامس يبيّن لماذا يهمّ ذلك هنا أكثر من أيّ مكان آخر في التطبيق.
• ناديشا غوناراتني (Nadeesha Gunaratne) هي منسّقة التجارة التي تملك الطلبيّة.
• ثيليني سيناناياكي (Thilini Senanayake) تقود الجودة.
• تشاميندا ديساناياكي (Chaminda Dissanayake) مسؤول التوريد.
• تشاثورا راجاباكشا (Chathura Rajapaksha) يخطّط الخطوط.

والطلبيّة المتتبَّعة عبر الدروس الخمسة كلّها ORD-1358 لصالح بريكستاد ريتيل (Brekstad Retail)، وهي سلسلة نرويجية للملابس الخارجية والكاجوال. والموديل STY-347، سترة نسائية بقلنسوة من قطن ممشَّط، 12,000 قطعة.

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

واحد وستون عموداً، ومبلغ واحد

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

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

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

من أين يأتي الرقم

هناك طريقان لوصوله، وهما غير متساويين في الوثوق.

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

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

ماذا يثبت المستند الأوّلي

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

وتفصيلان على تلك الصفحة أثمن من الحساب.

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

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

لاحظ ما ليس في ذلك الجدول. لا سطر خصم ولا سطر اقتطاع ولا بدل ولا مطالبة ولا إشعار دائن. والمستند يستطيع التعبير عن سعر واحد وكمية واحدة. ولا شيء يقع بعد ذلك يستطيع تغيير ما يطبعه.

المال تواريخَ

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

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

خطّ المال، مفروضاً في الشيفرة

أوضح بيان لهذا كلّه في تكامل نظام الموارد. فيستطيع مصنع لصق تغذية دفع مصدَّرة من نظامه المحاسبي، صفّاً لكلّ سطر، ويطابق التطبيق الصفوف بالطلبيّات برقم الطلبيّة.

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

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

ساعدني في معرفة أيّ من أسئلتي المالية عن طلبيّة في MerchandiserOS يستطيع التطبيق الإجابة عنه، وأيّها يجب أن يُجاب في مكان آخر.

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

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

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

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

وأخيراً حذّرني من أيّ رقم قد أخطئ فأحسبه جواباً. وكن محدّداً بشأن الشاشة التي ستضلّلني، ولماذا.