كيف تسجّل عملية بيع

ما الذي تنشئه فعلاً عندما تسجّل عملية بيع

عملية البيع في Skyline Nexus صفّ واحد في جدول المعاملات من نوع «بيع»، ومعه مجموعة من بنود البيع، ومعهما صفر أو أكثر من سجلات الدفع. والفصل بين هذه الثلاثة مقصود: الفاتورة هي المطالبة على العميل، والبنود هي ما خرج من الرفوف، والدفعات هي المال الذي وصل. ومعظم الالتباس الذي يواجهه الناس مع المبيعات في أنظمة ERP مصدره التعامل مع هذه الثلاثة كأنها حدث واحد، لأنها عند كاونتر المحل تقع عادةً في الثانية نفسها.

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

لذلك فالسؤال العملي عند تسجيل البيع ليس فقط أيّ الأزرار تضغط، بل: أيّ هذه العناصر الثلاثة أنشئه الآن، وأيّها أتعمّد ألّا أنشئه بعد؟ والجواب يحدده بالكامل تقريباً حقل واحد في النموذج، هو حقل «الحالة» الذي نتناوله أدناه.

ثلاثة مداخل إلى المستند نفسه

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

تظهر المستندات المكتملة في «جميع المبيعات» (/sells) أيّاً كان المدخل الذي استخدمته. أما المسودات وعروض الأسعار فلكلٍّ منها قائمته الخاصة، «قائمة المسودات» (/sells/drafts) و«قائمة عروض الأسعار» (/sells/quotations)، لأنها ليست فواتير حقيقية بعد ولا ينبغي أن تزدحم بها قائمة المبيعات. وتظهر إيصالات نقطة البيع كذلك وحدها في «قائمة نقطة البيع» (/pos).

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

• «نقطة بيع» (/pos/create) شاشة الكاونتر المصممة للّمس: عميل واحد، وشبكة منتجات، ولوحة دفع، وتنتهي العملية في ثوانٍ. وهي المدخل المناسب للتجزئة والمطاعم وكل بيع مباشر عبر الكاونتر.
• «إضافة فاتورة مبيعات» (/sells/create) نموذج الفاتورة الكامل، وتظهر فيه الحقول كلها: تصميم الفاتورة، والعملة، وفترة الدفع، والشحن، والحقول المخصصة، وعدة صفوف للدفع. وهي المدخل المناسب لفاتورة بين المنشآت، أو لبيع يعتمد على التوصيل، أو لأي بيع بشروط ائتمان.
• «بيع مباشر» (/sells/direct/create) نسخة مختصرة من «إضافة فاتورة مبيعات» للفواتير البسيطة.
• «إضافة مسودة» (/sells/create?status=draft) و«إضافة عرض سعر» (/sells/create?status=quotation) هما النموذج نفسه مرة أخرى، يُفتح والحالة محددة مسبقاً حتى لا تعتمد الفاتورة نهائياً عن طريق الخطأ.
• «إضافة أمر بيع» (/sells/create?sale_type=sales_order) يسجّل طلب عميل ستصدر فاتورته لاحقاً، ولا يظهر إلا إذا كانت أوامر البيع مفعّلة في إعدادات نقطة البيع.

تعبئة شاشة «إضافة فاتورة مبيعات»

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

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

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

الحالة تحدد كل شيء تقريباً

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

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

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

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

كيف تُحسب الضريبة على البيع

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

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

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

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

الدفعة سجلّ منفصل عن الفاتورة

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

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

حالة الدفع في المستند مشتقة لا مكتوبة يدوياً. فهي «مدفوعة» عندما يبلغ إجمالي المقبوض إجمالي الفاتورة على الأقل، و«جزئية» عندما يُقبض شيء دون الكل، و«مستحقة» عندما لا يُقبض شيء. ويُعاد هذا الاشتقاق كلما أُضيفت دفعة أو عُدّلت أو حُذفت، ولهذا ينبغي تحصيل الدفعات اللاحقة عبر «إضافة دفعة» من قائمة المبيعات (/payments/add_payment/{id}) لا بتعديل الفاتورة. فتعديل الفاتورة لتتطابق الأرقام تصرّف خاطئ، ويتناوله الدليل الخاص بإلغاء المعاملات وتصحيحها.

ما الذي يفعله البيع بالمخزون

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

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

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

ما الذي يُرحَّل إلى دفتر الأستاذ العام

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

يجب أن تتحقق ثلاثة شروط مجتمعة وإلا لم يُرحَّل شيء، ومن المفيد فحصها كلها قبل الحكم بأن دفتر الأستاذ معطوب. أولاً، أن يكون البيع «نهائي»؛ فالمسودات وعروض الأسعار والفواتير الأولية تُتخطّى عن قصد. ثانياً، أن يكون «ترحيل تلقائي لمعاملات المبيعات» مفعّلاً في إعدادات المحاسبة على /accounting/settings. ثالثاً، أن تكون الحسابات مربوطة: حساب الذمم المدينة، وحساب الإيراد، وحساب ضريبة المخرجات، ويُضبط ذلك على /accounting/settings/mapping. وغياب الربط لا يُفسد شيئاً، بل يرفض الترحيل ببساطة.

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

الفوترة الإلكترونية حيث تنطبق

في المملكة العربية السعودية، تُنشئ وحدة الفوترة الإلكترونية الفاتورة وترسلها تلقائياً عند حفظ البيع بحالة «نهائي». وتُفعَّل لكل فرع من فروع المنشأة لا للمنشأة كلها، فتستطيع الشركة تشغيل فرع ضمن نظام الفوترة الإلكترونية بينما لم يُسجَّل فرع آخر بعد. ويوجد الإعداد على /zatca/configuration.

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

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

بعد الحفظ

يظهر البيع في «جميع المبيعات» برقم فاتورته، والعميل، والإجمالي، وحالة الدفع، وحالة الفاتورة الإلكترونية حيث تنطبق. ومن قائمة إجراءات الصف تستطيع عرضه، وطباعته، وإضافة دفعة، وعرض دفعاته، أو بدء مرتجع عليه. وتعرض شاشة التفاصيل على /sells/show/{id} البنود وتفصيل الضريبة وسجل الدفعات في مكان واحد، وهي الشاشة التي تفتحها حين يسألك أحد عمّا جرى في فاتورة بعينها.

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

قائمة تحقق مختصرة

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