رسالة واحدة، ونظام الكاشير محدَّث.

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

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

طلبنا من Reacard الوصول إلى الواجهة البرمجية، دون نتيجة. فبنينا طريقنا الخاص.

وهي أربعة مواضع: قائمة بصيغة لا يعرفها النظام بعد؛ ورد مكتوب بحرية على استفسار؛ ورسالة دون قائمة يجب تصنيفها؛ ومرة في الأسبوع تعليق قصير على التحليل.

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

كل قائمة تسجّل البضاعة الواردة، وكل حصيلة يومية من نظام الكاشير تسجّل ما خرج. ويمكن إدخال جرد في لوحة التحكم، فتحل القيمة المعدودة محل المخزون المحسوب.

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

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

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

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

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