طريقتان للتفكير في المخزون

قضينا مؤخرًا بعض الوقت في دراسة تصميم المخزون في TallyPrime.

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

أحد الأساليب الشائعة هو Periodic Inventory (الجرد الدوري).

عندما تشتري الشركة بضائع أو مواد خام، تسجّل Purchases؛ وعندما تبيع، تسجّل Sales. ولا يُفترض بالمخزون أن يدخل Inventory Ledger أو يخرج منه في الوقت الفعلي مع كل قيد محاسبي.

وفي الوقت نفسه، يمتلك Tally وحدة Inventory Module مستقلة تسجّل Stock Items والكميات والتقييمات. وفي تاريخ إعداد التقارير، يحسب النظام Stock-in-Hand بناءً على الجرد الفعلي، ويستنتج تكلفة البضائع المباعة عبر معادلة محاسبية كلاسيكية:

COGS = Opening Stock + Purchases − Closing Stock

هذا التصميم عملي حقًا.

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

هذه هي قوة Periodic Inventory: بسيط، ولا يفرض متطلبات كبيرة على العمليات اليومية.

الأسلوب الآخر هو Perpetual Inventory (الجرد المستمر).

مع كل عملية شراء، يزداد Inventory؛ ومع كل عملية بيع، ينقص Inventory ويُسجَّل COGS.

وبالتالي يمكن للنظام أن يجيب في أي لحظة:

كم لدينا من المخزون الآن؟ وكم قيمته؟ وكم كلفت البضائع التي بعناها بالفعل؟ وما هامش الربح الإجمالي في الوقت الفعلي؟

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

ولهذا فإن تصميم SnapLedger ليس ببساطة اختيار Periodic أو Perpetual، بل جعل الأساس يفهم Cost Flows مختلفة.

لأن الشركات الصغيرة في الواقع لا تنتمي كلها إلى النموذج نفسه.

شركة تجارة إلكترونية قد تحتاج إلى:

Purchase → Inventory → Sale → COGS

وشركة تجارية صغيرة جدًا قد تكون أكثر ارتياحًا مع:

Purchases → Period-End Stock Count → Closing Inventory

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

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

لمثل هذه الشركة، المسار الأكثر طبيعية هو في الحقيقة:

Customer Order → Project → Materials & Labour → WIP → Delivery → COGS

الأصل الأهم هنا قد لا يكون Stock-in-Hand التقليدي، بل Work in Progress (WIP، الأعمال الجارية).

لذلك في SnapLedger لا نريد أن يقرر البرنامج مسبقًا كيف يجب على الشركة إدارة مخزونها.

الأساس يمكنه دعم Perpetual Inventory وPeriodic Inventory، وكذلك Project Costing وWIP.

وما يجب أن يفهمه Snappy حقًا هو:

كيف تدير نشاطك التجاري فعليًا؟

هل تخزّن أولًا ثم تنتظر أن يشتري العملاء؟

أم تشتري فقط بعد أن يقدّم العميل طلبًا؟

هل تحتاج إلى معرفة مستوى مخزون كل SKU في أي لحظة؟

أم يهمّك أكثر كمية التكاليف التي استثمرها كل مشروع عميل حتى الآن، وكم يُتوقع أن يربح؟

غالبًا ما تبدأ برامج المحاسبة التقليدية بسؤال "How should inventory be recorded?"

نحن نفضّل أن نبدأ بسؤال مختلف:

"How does your business actually work?"

ثم ندع المعالجة المحاسبية تتكيّف مع العملية التجارية الحقيقية.

SnapLedger, your life easier.