نموذج بيانات فاتورة GST: الحقول الدنيا لـ HSN والطلبات

ما الذي يخطئ عادةً في فواتير GST

معظم مشكلات فواتير GST ليست "مشكلات ضريبية معقدة". هي مشكلات بيانات مفقودة أو غير متسقة. يفشل التدقيق عندما لا يمكن ربط الفاتورة بوضوح بما تم بيعه، لمن، أين تم التوريد، وكيف حُسبت الضريبة.

مسبب شائع هو غياب HSN أو كونه قديمًا أو تطبيقه على مستوى خاطئ. قد يخزن الفريق HSN على المنتج، لكن سطر الفاتورة يُنشأ من اسم SKU مختلف أو متغير، فتختفي قيمة HSN من المستند النهائي. مشكلة متكررة أخرى هي تقسيم الضريبة الخاطئ: احتساب IGST بينما كان ينبغي أن يكون CGST و SGST (أو العكس) لأن "مكان التوريد" تم التخمين من عنوان الشحن دون حفظ رموز الولايات المستخدمة في القرار.

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

فيما يلي الأنماط التي تتسبب في معظم آلام عدم التطابق:

• المنتج وأسطر الفاتورة لا يتشاركان نفس HSN، معدل GST، وحقول القيمة الخاضعة للضريبة.
• يتم حساب الضريبة في أكثر من مكان (سلة vs فاتورة) والنتائج تختلف.
• يتم تخزين الإجماليات فقط كـ "الإجمالي الكلّي" بدون تفصيل للقيمة الخاضعة والجزء الضريبي لكل مكوّن.
• ترقيم الفواتير قابل للتعديل أو مكرر عبر سلاسل.
• تُسجل الاستردادات كطلبات سالبة بدلًا من مذكرات ائتمان صحيحة.

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

أصغر مجموعة من السجلات التي تحتاجها

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

إليك السجلات الأساسية التي يحتاجها معظم الفرق من اليوم الأول:

• العميل: من اشترى (الاسم، الهاتف/البريد الإلكتروني، GSTIN إن كان B2B)
• العنوان: شحن وفوترة، بالإضافة إلى ولايات ومؤشرات مكان التوريد
• المنتج (أو الخدمة): ما بيع، مع الوحدة، السعر الأساسي، وHSN/SAC الافتراضي
• الطلب: الحدث التجاري (السلة، الخصومات، رسوم الشحن، الحالة)
• الدفع: كيف تحرك المال (مرجع بوابة، الطريقة، المبلغ المحتجز، التاريخ)

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

المرتكز لدقة الضريبة هو أسطر الفاتورة. يجب أن يحمل كل بند من بنود الطلب (ولاحقًا كل بند في الفاتورة) الكمية الدقيقة، سعر الوحدة، الخصم، وتفصيل الضريبة لذلك العنصر بالتحديد. هنا تطبيق HSN/SAC ومعدلات GST فعليًا.

تفصيل ينقذ فرق المالية: خزّن لقطات. عند توليد فاتورة، انسخ وصف المنتج وHSN/SAC ومعدل الضريبة والتسعير إلى أسطر الفاتورة. لا تعتمد على سجل المنتج الحالي لأن الأسعار والأسماء تتغير.

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

إذا بنيت هذا في Koder.ai، عامل كل كيان كشاشة بسيطة أولًا (إنشاء، عرض، تعديل)، ثم أضف توليد الفاتورة بعد أن تكون اللقطات وحقول مستوى السطر في مكانها.

HSN و SAC: أين يتوافقان مع النموذج

HSN (للبضائع) وSAC (للخدمات) ليسا تفاصيل "للفاتورة فقط". يبدآن في تعريف المنتج أو الخدمة، ثم يُنسخان إلى كل سطر فاتورة عند إصدار الفاتورة. هذا يحافظ على صحة السلات المختلطة ويسهّل التدقيق لأن كل سطر مستقل بذاته.

نموذج بيانات عملي أدنى هو:

• المنتج: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (اختياري للأسطر اليدوية), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

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

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

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

إدارة التغيير هي المكان الذي يتعثر فيه الناس. استخدم مجموعة قواعد صغيرة:

• لا تكتب فوق HSN/SAC في أسطر الفاتورة المصدرة أبدًا.
• إذا تغيّر HSN/SAC لمنتج، حدّث المنتج للطلبات المستقبلية فقط.
• إذا تعقبّت التاريخ، أضف سجلًا جديدًا مع effective_from بدل تعديل القديم.

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

تفاصيل الأطراف: GSTIN، العناوين، ومكان التوريد

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

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

الحقول الدنيا للتخزين (المشتري والبائع)

اجعل الحقول مملة وصريحة. هذه هي التي عادةً تظهر على الفاتورة وفي التقارير:

• الاسم القانوني (كما سيظهر على الفاتورة)
• اسم النشاط التجاري (اختياري، لكنه مفيد)
• GSTIN (مطلوب للبائع؛ المشتري قابل للترك فارغًا)
• هاتف/بريد إلكتروني (ليس دائمًا إلزاميًا، لكن يساعد الدعم)
• سطور العنوان، المدينة، الولاية، البلد، الرمز البريدي

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

الفوترة مقابل الشحن ومكان التوريد

التقط كلًا من عناوين الفوترة والشحن على الطلب، وليس فقط في ملف تعريف العميل. الملفات تتغير؛ الفواتير لا يجب أن تفعل.

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

B2B مقابل B2C: متى يكون GSTIN إلزاميًا

بالنسبة لـ B2B، عادة ما يكون GSTIN المشتري مطلوبًا ويجب التحقق من الطول والصيغة عند الإدخال. بالنسبة لـ B2C، يمكن ترك GSTIN فارغًا، لكنك لا تزال بحاجة لعنوان كامل وحالة لتحديد ما إذا كان CGST/SGST أم IGST ينطبق.

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

بائعون متعددو الكيانات (عدة GSTINs)

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

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

حقول حساب الضريبة التي يجب تخزينها

الانقسام الأكثر شيوعًا بسيط: إذا كان مكان التوريد في نفس ولاية المورد، الضريبة هي CGST + SGST. إذا كانت ولاية مختلفة، الضريبة هي IGST. نظامك لا يجب أن "يعيد الحساب لاحقًا من الإجماليات" لأن الاختلافات الصغيرة (تقريب، خصومات، شحن) هي بالضبط ما يسبب عدم التطابق.

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

حد أدنى عملي لكل سطر فاتورة في نموذج بيانات فاتورة GST يبدو كالتالي:

• taxable_value (بعد تخصيص الخصم على مستوى السطر)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (خزن الانقسام المستخدم)
• cgst_amount, sgst_amount, igst_amount (خزن المبالغ المحسوبة)
• line_total (taxable_value + مبالغ الضرائب)

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

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

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

بيانات مستند الفاتورة: الترقيم، التواريخ، الإجماليات، الحالة

بعد حساب الضريبة، لا تزال الفاتورة بحاجة إلى حقول "المستند" التي تجعلها صالحة وقابلة للتدقيق وسهلة المصالحة لاحقًا. عامل رأس الفاتورة كسجل قانوني: يجب أن يكون ثابتًا حتى لو تغيّرت بيانات المنتج أو العميل في المستقبل.

ابدأ بأساسيات الرأس: رقم الفاتورة، تاريخ الإصدار (التاريخ الوارد على الفاتورة)، نوع الفاتورة (فاتورة ضريبية، تصدير، B2B، B2C، إلخ)، والعملة. حتى إن كنت تفوّق غالبًا بالـ INR، تخزين العملة يتجنب حالات الحواف المعقدة للتصدير أو الأسواق متعددة العملات.

الترقيم هو المكان الذي يتعرض فيه الفرق للمشاكل. احتفظ بسلسلة أو بادئة (مثال "FY25-INV-"), خزّن السنة المالية، وفرض التفرد على مستوى قاعدة البيانات. خزّن أيضًا عناصر التحكم في "الرقم التالي" لكل سلسلة في الإدارة حتى لا يستطيع مسؤولان إصدار نفس الرقم في نفس الوقت.

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

يجب أن تعكس الحالات دورة الحياة الحقيقية وقفل السجل عند الحاجة:

• مسودة (قابل للتحرير)
• مُصدر (تم تعيين رقم، تم توليد PDF)
• مُلغى (محفوظ للمراجعة، ليس محذوفًا)
• مُسترد (إرجاع المدفوعات، قد يتطلب مذكرة ائتمان)
• تمت ملاحظة ائتمانية (مذكرة ائتمان مرتبطة صادرة)

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

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

شاشات الإدارة للمنتجات والضرائب وتفاصيل العملاء

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

سجل المنتج (من SKU إلى HSN/SAC)

سجل المنتج هو مصدر معظم عدم التطابق المستقبلي، فاجعله صارمًا. يجب أن يكون لكل SKU HSN افتراضي واحد (أو SAC للخدمات)، بالإضافة إلى معدل GST افتراضي وأي استثناءات تنطبق فقط لتواريخ محددة.

شاشة المنتج العملية عادة تحتاج:

• SKU واسم المنتج (كما تريد طباعته)
• رمز HSN/SAC، معدل GST، وفئة الضريبة (إن كنت تستخدمها)
• تواريخ التفعيل من/إلى (حتى لا تعيد كتابة الفواتير القديمة عند التغيير)
• تجاوزات الأسعار (لـ MRP خاص أو تسعير خاص بالقناة)
• الحالة (نشط/غير نشط) مع سبب واضح لتعطيل

إعداد الضريبة (معدلات ومدخلات داخلية مقابل بين الولايات)

تجنب واجهة "آلة حاسبة". بدلاً من ذلك، خزّن المدخلات التي يمكن لنظامك تطبيقها باستمرار: جداول المعدلات، قواعد مكان التوريد التي تتبعها، وكيف تقرر داخل الولاية مقابل بين الولايات (عادة بالمقارنة بين ولاية المورد وولاية جهة الشحن).

اجعل شاشة الضريبة تركز على: معدل الضريبة حسب الفئة/مجموعة HSN، تواريخ السريان، وما الذي يحدث عندما يقدم المشتري GSTIN صالحًا مقابل لا يقدم.

ملف العميل والشركة (من يظهر على الفاتورة)

شاشة العميل يجب أن تلتقط GSTIN وحالة التحقق منه، بالإضافة إلى عناوين الفوترة والشحن الافتراضية. لا تدع المستخدمين يكتبون الولايات نصًا حرًا؛ استخدم قائمة محكومة حتى لا تصبح "KA" و"Karnataka" قيمتين مختلفتين.

شاشة ملف شركتك مهمة بالمثل: الاسم القانوني، GSTIN، العنوان المسجل، وإعدادات سلسلة ترقيم الفواتير (البادئة، الرقم التالي، وحدود السنة المالية). قفل هذا مع الأذونات لأن التغييرات تؤثر على كل المستندات المستقبلية.

أساسيات سجل التدقيق (الثقة وتتبع التغييرات)

لا تحتاج نظامًا معقدًا، لكن تحتاج أثرًا. سجّل من غيّر HSN/SAC، معدلات GST، إعدادات سلسلة الفواتير، مع القيمة القديمة، القيمة الجديدة، الطابع الزمني، والسبب.

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

خطوة بخطوة: من الطلب إلى الفاتورة المطابقة

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

1) ثبّت ما اشتراه العميل فعليًا

قبل حساب الضريبة، قفل لقطة الطلب: البنود، الكميات، أسعار الوحدات، الخصومات، رسوم الشحن/المناولة، GSTIN العميل (إن وُجد)، عناوين الفوترة والشحن، وإشارات مكان التوريد. يجب أن لا تتغير اللقطة حتى لو تغيّر سعر المنتج أو تعيين HSN لاحقًا.

2) حوّل اللقطة إلى أسطر فاتورة (مع نسخ سمات الضريبة)

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

3) اصدر الفاتورة واجعلها غير قابلة للتعديل

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

4) أنشئ المستند النهائي وخزن الإجماليات

ولّد الـ PDF/عرض الطباعة من الفاتورة المصدرة، ثم خزّن الإجماليات النهائية التي ستُبلّغ: المجموع الخاضع، إجماليات CGST/SGST/IGST، التقريب، والإجمالي الكلّي. إذا أردت أمانًا إضافيًا، خزّن نسخة المستند أو checksum لإثبات تطابق الطباعة مع الأرقام المخزنة.

5) عالج التغييرات بالطريقة القانونية

بعد الإصدار، يجب أن تتبع التغييرات قواعد، لا تعديلات مباشرة:

• تصحيح سعر: اصدر مذكرة ائتمان (أو مذكرة مدين) تشير إلى الفاتورة الأصلية.
• إلغاء طلب بعد الإصدار: ألغي الفاتورة إن كان مسموحًا، وإلا اصدر مذكرة ائتمان.
• تحديث عنوان العميل بعد الإصدار: لا تعيد كتابة الفاتورة؛ صحّح عبر المستند المناسب واحتفظ بسجل التدقيق.
• استرداد جزئي: مذكرة ائتمان للأسطر/المبالغ المستردة فقط.
• شحنة بديلة: طلب/فاتورة جديدة، ليس تعديلًا صامتًا.

إذا دمجت هذا التدفق في شاشات الإدارة لديك (وضع التخطيط في Koder.ai مفيد لتخطيط الخطوات قبل البناء)، يمكن لفريقك توليد الفواتير بسرعة دون تحطيم المصالحة لاحقًا.

اجعل المصالحة سهلة: المدفوعات، الاستردادات، والسجلات

تصبح المصالحة فوضوية عندما تُعامل المدفوعات كعلم "مدفوع/غير مدفوع" واحد على الطلب. احتفظ بالمدفوعات والاستردادات كسجلات منفصلة تشير إلى الطلب والفاتورة، حتى تتمكن المالية من مطابقة التسويات البنكية دون إعادة كتابة التاريخ.

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

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

الحقول الدنيا التي تجعل المصالحة سهلة عادةً:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (اختياري لكن مفيد): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (إذا صدرت), gateway_refund_id, amount, reason, refunded_at, status
• مفاتيح المصالحة التي لا يجب إعادة استخدامها أبدًا: order_id, invoice_id, payment_id, refund_id, credit_note_id

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

عرض المالية والتقارير التي توفر ساعات

امنح المالية شاشة واحدة تجيب: ما الذي صدر، ما الذي دُفِع، ما الذي لا يزال مفتوحًا، وما الذي تم عكسه. أضف تقادمًا (0-7، 8-30، 31-60، 60+ يومًا) وخاصية تفصيل للسجلات المرتبطة بالدفعات والاستردادات.

التقارير التي تحتاجها معظم الفرق شهريًا:

• سجل الفواتير (المصدرة، الملغاة، المأخوذة بمذكرة ائتمان)
• ملخص الضريبة حسب المعدل وHSN/SAC (يدعم نموذج بيانات فاتورة GST)
• التسوية بين الدفع والفاتورة (invoice_id، إجماليات المدفوعات، الرصيد)
• سجل الاستردادات ومذكرات الائتمان
• تقرير تسوية بوابة الدفع (تطابق payout_id مع invoice/payment)

مثال: طلب بقيمة 10,000 روبية، دفعت 6,000 اليوم و4,000 الأسبوع القادم. تظل الفاتورة 10,000. يعرض عرض المالية الرصيد 4,000 حتى وصول التسوية الثانية، ثم تُعلمك بأنها مدفوعة بالكامل دون تغيير المستند المصدر.

الأخطاء الشائعة التي تسبب مشكلات التوافق وعدم المطابقة

معظم مشكلات فواتير GST ليست "منطق ضريبي" بل مشاكل حفظ سجلات: الأرقام على الـ PDF لا تطابق ما تصدره تقارير المالية، أو لا يمكن شرح الفاتورة بعد أشهر.

الفخ الأول هو حساب GST فقط عند العرض. إذا حسبت CGST/SGST/IGST في كل مرة يفتح فيها أحدهم فاتورة، ستنتهي النتائج مختلفة بعد تغيير معدل أو قاعدة تقريب أو إصلاح خطأ. خزّن تفصيل الضريبة المحسوب المستخدم عند إصدار الفاتورة حتى لو خزنت المدخلات أيضًا.

الفخ الثاني هو السماح بالتعديلات على فاتورة مصدرة. بعد أن تصبح الفاتورة نهائية، يجب أن تحدث التغييرات عبر مذكرة ائتمان أو تدفق بديل مع سجل تدقيق. وإلا سترى استفسارات "لماذا يختلف PDF العميل عن الدفاتر؟".

فيما يلي أنماط عدم التطابق التي تظهر غالبًا في نموذج بيانات فاتورة GST:

• مكان التوريد مفقود أو رمز الولاية خاطئ، فيُحتسب IGST بينما يجب CGST+SGST (أو العكس).
• تم تحديث HSN/SAC أو معدل الضريبة وأُعيد حساب الطلبات القديمة باستخدام القيمة الجديدة.
• تم تخزين الضريبة، لكن قواعد التقريب تختلف بين واجهة المستخدم، توليد الـ PDF، وتصدير CSV.
• تُطبق الخصومات بعد الضريبة في مكان و قبل الضريبة في مكان آخر.
• تُسجل الاستردادات كبنود سالبة بدون ربط واضح بالفاتورة الأصلية.

مثال سريع: تبيع لعميل في Karnataka، لكن عنوان الشحن في Maharashtra. إذا اختار نظامك حالة الفوترة لمكان التوريد عن طريق الخطأ، قد تفرض CGST+SGST بدلًا من IGST. إذا أعدت الحساب أيضًا عند العرض، قد "يصحح" ذلك الخطأ لاحقًا بصمت، تاركًا المالية بأرقام لا تطابق المستند المصدر.

عند بناء شاشات الإدارة (سواء مخصصة أو عبر منصة مثل Koder.ai)، أضف حواجز بسيطة: قفل الفواتير المصدرة، عرض مدخلات مكان التوريد بجانب نوع الضريبة المحسوب، والحفاظ على لقطة غير قابلة للتغيير لـ HSN، المعدل، وقواعد التقريب المستخدمة عند الإصدار.

قائمة تحقق سريعة وخطوات تالية

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

فحوصات لكل فاتورة (قبل الإصدار)

• HSN/SAC موجودة على كل سطر وتطابق المنتج أو الخدمة المباعة.
• قواعد GSTIN مطبقة بشكل صحيح (B2B مقابل B2C)، وتفاصيل الفوترة والشحن لا تتناقض.
• مكان التوريد مخزن وتقسيم الضريبة منطقي (CGST/SGST مقابل IGST).
• الإجماليات تجمع تمامًا: القيمة الخاضعة، كل مكوّن ضريبي، التقريب، والإجمالي الكلّي.
• عند الإصدار، تُقفل الفاتورة (لا تعديلات صامتة). تُصلح الأمور عبر مذكرة ائتمان أو تدفق إلغاء، لا بإعادة كتابة التاريخ.

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

فحوصات البيانات + سير العمل (للحفاظ على نظافة المالية)

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

الخطوات التالية: نفّذ الشاشات والتحققات أولًا، ثم كرّر. في Koder.ai، ابدأ بوضع التخطيط لرسم السجلات وشاشات الإدارة (منتجات مع تعيين HSN/SAC، تفاصيل العميل/GSTIN، قواعد الضريبة، والفواتير). ولّد التطبيق، اختبر بعض الطلبات الحقيقية من البداية للنهاية، ثم استخدم اللقطات وآليات التراجع لتحسين سير العمل بأمان. عندما تحتاج تخصيصًا أعمق أو مراجعات، صدّر الشفرة المصدرية واستمر في تطويرها وفق عمليتك المعتادة.