ما تحتاجه الورشة من نظامها، وما لن يعطيه إياها برنامج الفواتير

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

لماذا يحتاج عرض السعر إلى رقم خاص به؟

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

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

هل يجتمع الخام والأجرة في الطلب نفسه؟

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

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

ما الذي يتغير حين يدفع العميل على دفعات؟

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

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

ماذا تفعلون ببقايا اللوح؟

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

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

السؤال	ما يجيب عنه برنامج الفواتير	ما تحتاجه الورشة
ماذا تم الاتفاق عليه؟	سعر لمنتج	طلب بمقاسات ولوح وتشطيب
كم كلف الطلب؟	لا شيء	خام وساعات مرتبطة بالطلب
كم بقي؟	إجمالي لدى العميل	رصيد لكل طلب
ماذا تبقى من اللوح؟	لا شيء	بقايا في المخزون أو هدر

لماذا يناسب نظام على العداد أكثر من حزمة سحابية؟

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

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

ما الذي تحسمونه قبل مقارنة البرامج؟

اتبعوا هذا الترتيب، فكل خطوة تحول التالية من رأي إلى متطلب.

1. اكتبوا الطلب كما يحدث، وسجلوا أين ينتقل المستند من يد إلى يد — هناك يضيع الرقم.
2. افصلوا السعر عن الكلفة. لطلب أخير، حددوا ما استهلكه من ألواح ومن ساعات. وإن لم تستطيعوا، فالفارق نفسه هو المتطلب.
3. احسموا قاعدة البقايا لكل مادة: مقاس، وموضع، ومن يحق له إعادتها إلى المخزون.
4. اكتبوا طرق الدفع التي تقبلونها وما يجب أن تسميه كل دفعة، وهل تربطها بطلب في خطوة واحدة.
5. حددوا الترقيم قبل البيانات. اسألوا ماذا يحدث للتسلسل بعد إلغاء، ومن يحق له إنشاء رقم بيده.
6. اختبروا التصدير والاستعادة على جهاز نظيف، بالصيغة التي يقبلها محاسبكم.
7. بعد ذلك قارنوا البرامج. الحزمة التي تفشل في جوابين تظهر في عرض تجريبي لا في الشهر الثالث.

أين يخطئ هذا كله؟

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

ما لا يغطيه هذا المقال

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

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