GST চালান ডেটা মডেল: HSN ও অর্ডারের জন্য ন্যূনতম ফিল্ডসমূহ

সাধারণভাবে GST চালানে কোথায় ভুল হয়

অধিকাংশ GST চালান সমস্যা "জটিল কর" বিষয় নয়। এগুলো সাধারণত অনুপস্থিত বা অসমঞ্জস্ত ডেটার কারণে হয়। অডিট ব্যর্থ হয় যখন চালানটি পরিষ্কারভাবে দেখা যায় না যে কী বিক্রি হয়েছে, কার কাছে, কোথায় সরবরাহ হয়েছে, এবং কর কীভাবে হিসাব করা হয়েছে।

একটি সাধারণ কারণ HSN অনুপস্থিত থাকা, পুরোনো থাকা বা ভুল স্তরে প্রয়োগ করা। টিমগুলো প্রোডাক্টে HSN সংরক্ষণ করতে পারে, কিন্তু যখন ইনভয়েস লাইনটা ভিন্ন SKU নাম বা ভ্যারিয়েন্ট থেকে তৈরি হয়, তখন HSN কখনো ফাইনাল ডকুমেন্টে পৌঁছায় না। আরেকটা ঘন সমস্যা হল কর বিভাজন ভুল হওয়া: "place of supply" কে শিপিং ঠিকানার থেকে অনুমান করে IGST চার্জ করে নেয়া যখন আসলে CGST+SGST হওয়া উচিত (বা উল্টোটাও হতে পারে) — কারণ সিদ্ধান্ত নেয়ার জন্য ব্যবহৃত state code সংরক্ষিত থাকে না।

ফাইন্যান্স টিমরা এইটা তৎক্ষণাৎ অনুভব করে। রিকনসিলিয়েশন প্রতিদিনের ক্লিনআপ কাজ হয়ে যায়: ইনভয়েস মোট অর্ডারের সাথে মেলে না, অর্ডার পেমেন্ট গেটওয়ে সেটেলমেন্টের সাথে মেলে না, এবং রিফান্ডগুলো ম্যানুয়াল নোটের একটি চেইন হয়ে ওঠে। এমনকি লাইন আইটেমগুলিতে ছোট রাউন্ডিং পার্থক্যও ইনভয়েস PDF, GST রিপোর্ট এবং লেজারের মধ্যে মিল খামতি তৈরি করতে পারে।

নিচে সেই প্যাটার্নগুলো দিলাম যেগুলো সবচেয়ে বেশি মismatch করে:

• প্রোডাক্ট ও ইনভয়েস লাইন একই HSN, GST রেট এবং taxable value ফিল্ড শেয়ার করে না।
• ট্যাক্স একাধিক স্থানে গণনা করা হয় (cart বনাম invoice) এবং ফলাফল ভিন্ন হয়।
• শুধু "grand total" সংরক্ষণ করা হয়, taxable value এবং প্রতিটি ট্যাক্স কম্পোনেন্টের ব্রেকডাউন ছাড়া।
• ইনভয়েস নম্বর ইডিটেবল বা সিরিজ জুড়ে ডুপ্লিকেট।
• রিফান্ডগুলোকে নেগেটিভ অর্ডার হিসেবে রেকর্ড করা হয়, সঠিক ক্রেডিট নোট না করে।

GST চালান ডেটা মডেলের লক্ষ্য সরল: অর্ডার, প্রোডাক্ট, পার্টি, ট্যাক্স, ইনভয়েস এবং ক্রেডিট নোটের একটি ন্যূনতম সেট সংরক্ষণ করুন যাতে প্রতিটি সংখ্যা পরে পুনরুত্পাদন ও ব্যাখ্যা করা যায়। ছোট রাখুন, কিন্তু এমন ফিল্ড বাদ দেবেন না যা আইনিকভাবে কর ধরার ধরন, হার এবং রিপোর্টিং নির্ধারণ করে।

সবচেয়ে ছোট রেকর্ড সেট যা দরকার

যদি আপনি চান GST চালান তৈরি করা সহজ হোক এবং পরে রিকনসিলিয়েশন সহজ হয়, তাহলে একটি ছোট সেট অবজেক্ট দিয়ে শুরু করুন এবং প্রতিটি অবজেক্টকে একটি একক কাজ করতে দিন। একটি পরিষ্কার GST চালান ডেটা মডেল অনেক টেবিল থাকার চেয়ে সময়ের সাথে तथ्यগুলো স্থিতিশীল রাখার ওপর বেশি নির্ভর করে।

দিন একের জন্য বেশিরভাগ টিমকে যে মূল রেকর্ডগুলো দরকার তা হলো:

• Customer: কে কিনেছে (নাম, ফোন/ইমেইল, B2B হলে GSTIN)
• Address: শিপিং ও বিলিং, সাথে state এবং place of supply সংকেত
• Product (or Service): কী বেচেছেন, unit, base price, এবং ডিফল্ট HSN/SAC
• Order: কমার্শিয়াল ইভেন্ট (cart, discounts, shipping চার্জ, স্ট্যাটাস)
• Payment: কিভাবে টাকা লেনদেন (gateway reference, method, captured amount, date)

Invoice অবশ্যই Order থেকে আলাদা হওয়া উচিত। অর্ডার বদলে যেতে পারে (ঠিকানা আপডেট, আইটেম বাতিল ইত্যাদি)। ইনভয়েসগুলো পরিবর্তনশীল হওয়া উচিত নয়। তাদের স্থিতিশীল নম্বরিং, তারিখ এবং মোট দরকার যা পরে "ড্রিফট" হবে না কারণ কেউ পরে অর্ডার আপডেট করেছে।

ট্যাক্স সঠিক রাখার মূল হলো Line Items। প্রতিটি অর্ডার লাইন আইটেম (এবং পরে প্রতিটি ইনভয়েস লাইন আইটেম) নির্দিষ্ট পরিমাণ, ইউনিট প্রাইজ, ডিসকাউন্ট এবং ঐ নির্দিষ্ট আইটেমের জন্য ট্যাক্স ব্রেকডাউন ধারণ করা উচিত। এখানেই HSN/SAC এবং GST রেট বাস্তবে প্রয়োগ হয়।

একটি ছোট কিন্তু গুরুত্বপূর্ণ ধারণা: snapshots সংরক্ষণ করুন। যখন আপনি ইনভয়েস তৈরি করেন, তখন প্রোডাক্টের বিবরণ, HSN/SAC, ট্যাক্স রেট এবং প্রাইসিং ইনভয়েস লাইনগুলিতে কপি করে নিন। কারেন্ট প্রোডাক্ট মাস্টারের উপর নির্ভর করবেন না, কারণ রেট ও নাম বদলে যেতে পারে।

বিকল্পভাবে, সাধারণত শুরুতেই যোগ করা উচিত: Returns, Refunds, এবং Credit Notes আলাদা রেকর্ড হিসেবে রাখা। উদাহরণ: একজন কাস্টমার দুটি আইটেমের অর্ডারের মধ্যে থেকে একটি ফিরিয়ে দিলে আপনি চাইবেন একটি ক্রেডিট নোট যা মূল ইনভয়েস লাইনের রেফারেন্স দেয়, আর পেমেন্ট রিফান্ড রেকর্ড গেটওয়ে ট্রান্জেকশনের রেফারেন্স দেয়। এগুলোকে স্পষ্ট অবজেক্ট হিসেবে রাখা মাস এক শেষে GST রেজিস্টারে ম্যানুয়াল ফিক্স এড়িয়ে দেয়।

যদি আপনি এটা Koder.ai-তে বানান, প্রত্যেক অবজেক্টকে প্রথমে একটি সরল স্ক্রিন হিসেবে বিবেচনা করুন (create, view, edit), তারপর ইনভয়েস জেনারেশন যোগ করুন কেবল যখন snapshots এবং লাইন-লেভেল ফিল্ডগুলো স্থাপন করা হয়েছে।

HSN এবং SAC: মডেলে কোথায় ফিট করে

HSN (পণ্যগুলোর জন্য) এবং SAC (সেবার জন্য) "শুধু ইনভয়েস-অনলি" ডিটেইল নয়। এগুলো প্রোডাক্ট বা সার্ভিস ডিফ�nিশন থেকে শুরু হয়, এবং ইনভয়েস ওঠানোর সময় প্রতিটি লাইনে কপি করা হয়। এটি মিক্সড কার্টগুলোকে সঠিক রাখে এবং অডিট সহজ করে কারণ প্রতিটি লাইন নিজে থেকেই দাঁড়ায়।

একটি ব্যবহারিক ন্যূনতম ডেটা মডেল হলো:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (optional for manual lines), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Product-এ HSN/SAC রাখা অ্যাডমিন টিমকে এক জায়গায় তা মেইনটেইন করতে সাহায্য করে। InvoiceLine-এ কপি করা অতীত ইনভয়েসগুলোকে স্থিতিশীল করে। প্রোডাক্ট পরে বদলে গেলেও ইনভয়েস দেখায় কোন তথ্য সেই বিক্রয়ের সময় সত্য ছিল। এটি এমন একটি GST চালান ডেটা মডেলের হৃৎপিণ্ড যা রিকনসিলিয়েশনে ভাঙে না।

HSN সংরক্ষণের জন্য সরলতা রাখুন: code প্রয়োজনীয়, description ঐচ্ছিক, এবং effective_from date ঐচ্ছিক যদি আপনি পরিবর্তনের ইতিহাস ট্র্যাক করতে চান। বেশিরভাগ টিম প্রতিটি লাইন আইটেমে description চাইবে না, তবে ব্যতিক্রমগুলো ফাইন্যান্স চেক করার সময় সাহায্য করে।

মিক্সড কার্ট স্বাভাবিক: একটি ইনভয়েসে একাধিক লাইন আইটেম হতে পারে এবং তাই একাধিক HSN/SAC কোড থাকতে পারে। এক ইনভয়েসে এক কোড জোর করে দেবেন না। মোটগুলো ইনভয়েস লেভেলে রোল-আপ হয়, ক্লাসিফিকেশন লাইন লেভেলে থাকে।

চেঞ্জ ম্যানেজমেন্টেই লোকেরা সমস্যায় পড়ে। একটি ছোট রুল সেট ব্যবহার করুন:

• জারি করা ইনভয়েস লাইনে কখনো HSN/SAC overwrite করবেন না।
• যদি প্রোডাক্টের HSN/SAC বদলে যায়, প্রোডাক্টটি ভবিষ্যত অর্ডারের জন্য আপডেট করুন।
• যদি আপনি ইতিহাস ট্র্যাক করেন, পুরোনো রেকর্ড এডিট না করে নতুন effective_from রেকর্ড যোগ করুন।

অ্যাডমিন স্ক্রিন দিক থেকে, প্রোডাক্ট ট্যাক্স ফিল্ড এডিট করার জন্য আপনাকে মাত্র একটি জায়গা লাগবে, প্লাস ইনভয়েস লাইনের read-only ভিউ যাতে যখন ইনভয়েস তৈরি হয়েছে তখন কি ধারণ করা হয়েছিল তা দেখানো যায়। দ্রুত স্ক্রিন বানালে Koder.ai-এর মতো টুলগুলি এই মডেল থেকে মৌলিক CRUD পেজ এবং ডেটা টেবিল জেনারেট করতে পারে খুব কম প্রচেষ্টায়।

পার্টি বিবরণ: GSTIN, ঠিকানা, এবং place of supply

GST চালান ডেটা মডেল সবচেয়ে বেশি ব্যর্থ হয় পার্টি বিবরণে। যদি বায়ার বা সেলার পরিচয় সামান্য হলেও ভুল থাকে, আপনার ইনভয়েস কাগজে বৈধ হতে পারে কিন্তু রিটার্ন ও রিকনসিলিয়েশনে যন্ত্রণাদায়ক হবে।

শুরুতেই "seller", "buyer" এবং "ship-to" কে আলাদা পার্টি হিসেবে ধরুন, এমনকি তারা একই ব্যক্তি হলেও। এটি পরে যখন কাস্টমার ভিন্ন শিপিং ঠিকানা যোগ করে বা আপনি একাধিক GST রেজিস্ট্রেশন থেকে বিক্রি করেন তখন হ্যাকগুলো আটকায়।

সংরক্ষণ করার ন্যূনতম ফিল্ড (বায়ার ও সেলার)

বোরিং ও এক্সপ্লিসিট ফিল্ড রাখুন। এগুলো সাধারণত ইনভয়েস ও রিপোর্টে দরকার হয়:

• Legal name (যেমন ইনভয়েসে প্রদর্শিত হবে)
• Trade name (ঐচ্ছিক, তবে দরকারি হতে পারে)
• GSTIN (সেলার প্রয়োজনীয়; বায়ার nullable)
• Phone/email (সবসময় বাধ্যতামূলক নয়, তবে সাপোর্টের জন্য সহায়ক)
• Address lines, city, state, country, PIN/postal code

State উভয়ে মানব-পঠিত নাম ও state code হিসেবে সংরক্ষণ করুন, কারণ রিপোর্টিং ও place-of-supply নিয়মগুলো প্রায়ই কোডের উপর নির্ভর করে।

Billing বনাম shipping এবং place of supply

অর্ডারে প্রোফাইল ছাড়াও billing ও shipping ঠিকানা কপি করে রাখুন। প্রোফাইল বদলে যায়; ইনভয়েস বদলে যাওয়া উচিত নয়।

Place of supply ইনভয়েসে একটি নির্দিষ্ট state code হিসেবে সংরক্ষিত থাকা উচিত (invoice তৈরির সময়ে order থেকে কপি করা)। পরে এটি "রিক্যালকুলেট" করবেন না। যদি আপনার রুল "ship-to state" হয়, তাহলে সেই ফলটি এবং সিদ্ধান্ত নেয়ার জন্য ব্যবহৃত state সংরক্ষণ করুন। এতে অডিট ও বিতর্ক সহজ হয়।

B2B বনাম B2C: কখন GSTIN বাধ্যতামূলক

B2B-এর জন্য সাধারণত বায়ার GSTIN বাধ্যতামূলক এবং entry করার সময় দৈর্ঘ্য ও ফরম্যাট ভ্যালিডেট করা উচিত। B2C-তে GSTIN ফাঁকা থাকতে পারে, কিন্তু আপনি তখনও পূর্ণ ঠিকানা ও স্টেট দরকার যাতে CGST/SGST না হলে IGST প্রযোজ্য কি না ঠিক করা যায়।

একটি সরল রুল যেটা বেশিরভাগ সিস্টেমে কাজ করে: যদি বায়ার GSTIN থাকে, সেটি B2B হিসেবে বিবেচনা করুন; না থাকলে B2C হিসেবে ধরা হবে। যদি আপনি ব্যতিক্রম চান, explicit customer_type ফিল্ড সংরক্ষণ করুন।

মাল্টি-এন্টিটি সেলার (একাধিক GSTIN)

যদি আপনার ব্রাঞ্চ বা বিজনেস ইউনিট থাকে যাদের আলাদা GST রেজিস্ট্রেশন আছে, তাহলে "Seller Entity" কে আলাদা রেকর্ড হিসেবে মডেল করুন যাতে প্রতিটি এন্টিটির নিজস্ব GSTIN ও ঠিকানা থাকে। প্রতিটি অর্ডারটি একমাত্র seller entity রেফার করবে, এবং প্রতিটি ইনভয়েস ঐ ডিটেইল কপি করবে যাতে ইতিহাসগত ইনভয়েসগুলো সঠিক থাকে যদিও পরে seller ঠিকানা বদলে যায়।

Koder.ai-এর মতো টুলগুলি দ্রুত এই রেকর্ডগুলোর অ্যাডমিন ফর্ম জেনারেট করতে পারে, তবে মূল কাঠামো হলো: আলাদা seller entity, অর্ডার-সময় স্ন্যাপশট, এবং explicit place-of-supply state code।

আপনি যে ট্যাক্স গণনার ফিল্ডগুলো অবশ্যই সংরক্ষণ করবেন

সবচেয়ে সাধারণ বিভাজন সোজা: যদি supplier এবং place of supply একই রাজ্য হয়, ট্যাক্স CGST + SGST; অন্য রাজ্য হলে IGST। আপনার সিস্টেম পরে "টোটাল থেকে পুনর্গণনা" করা উচিৎ নয় কারণ ক্ষুদ্র পার্থক্য (রাউন্ডিং, ডিসকাউন্ট, শিপিং)ই মিসম্যাচের কারণ।

ন্যূনতমভাবে ট্যাক্স নম্বরগুলো ইনভয়েস লাইন লেভেলে সংরক্ষণ করুন, শুধুমাত্র ইনভয়েস হেডারে নয়। এভাবে আপনি ইনভয়েসের প্রতিটি রুপিয়া ব্যাখ্যা করতে পারবেন এবং সেটা প্রোডাক্ট, HSN এবং রেভিনিউ-র সাথে মিলাতে পারবেন।

প্রতি ইনভয়েস লাইনের জন্য ব্যবহারিক ন্যূনতম ক্ষেত্রগুলো দেখতে এভাবে:

• taxable_value (লাইন-লেভেল ডিসকাউন্ট আলোকেশন পর)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (ব্যবহৃত স্প্লিট সংরক্ষণ করুন)
• cgst_amount, sgst_amount, igst_amount (গণনা করা এমাউন্টগুলো সংরক্ষণ করুন)
• line_total (taxable_value + tax amounts)

ডিসকাউন্টগুলোই এমন জায়গা যেখানে সিস্টেমগুলো জটিল হয়ে পড়ে। একটি রুল ঠিক করুন এবং সেটিকে স্পষ্টভাবে সংরক্ষণ করুন। যদি ডিসকাউন্ট ট্যাক্সের আগে মূল দাম কমায় (সাধারণত আইটেম ডিসকাউন্ট ও কুপন ক্ষেত্রে), তাহলে মূল গ্রস এমাউন্ট, ডিসকাউন্ট এমাউন্ট, এবং ফলাফল taxable value সংরক্ষণ করুন। যদি অর্ডার-লেভেল কুপন থাকে, সেটিকে লাইনগুলোর উপর বরাদ্দ করুন (সাধারণত প্রতিটি লাইনের প্রি-ডিসকাউন্ট ট্যাক্সেবল ভ্যালু অনুযায়ী تناপাতিকভাবে) এবং প্রতিটি লাইনের আলোকিত ডিসকাউন্ট সংরক্ষণ করুন যাতে ট্যাক্স ম্যাথ ব্যাখ্যাযোগ্য থাকে।

রাউন্ডিং সঙ্গতিপূর্ণ হওয়া উচিত এবং রেকর্ড করা উচিত। আপনি লাইন লেভেলে রাউন্ড করবেন নাকি কেবল ইনভয়েস লেভেলে, সেটি অবশ্যই নির্ধারিত করুন এবং আপনি যে রাউন্ডিং ফলাফল প্রিন্ট করেছেন তা সংরক্ষণ করুন। অনেক টিম লাইন অনুযায়ী ট্যাক্স গণনা করে, দুই দশমিকের কাছে রাউন্ড করে, তারপর একটি চূড়ান্ত invoice_rounding_adjustment ফিল্ড প্রয়োগ করে নির্দিষ্ট পে-অ্যাবল অ্যামাউন্টে যেতে।

শিপিং ও হ্যান্ডলিংকে লুকানো অতিরিক্ত হিসেবে বিবেচনা করবেন না। এগুলোকে একটি আলাদা ইনভয়েস লাইন হিসেবে বিবেচনা করুন যার নিজস্ব HSN/service কোড এবং ট্যাক্স রেট রুল। উদাহরণ: দুইটি প্রোডাক্ট এবং একটি শিপিং ফি আছে এমন অর্ডার তিনটি লাইনে রূপান্তরিত হবে, প্রতিটিতেই ট্যাক্সেবল ভ্যালু ও ট্যাক্স কম্পোনেন্ট এমাউন্ট রাখা থাকবে, ফলে ফাইন্যান্স রিকনসিলিয়েশন অনেক সহজ হয়।

ইনভয়েস ডকুমেন্ট ডেটা: নম্বরিং, তারিখ, মোট, স্ট্যাটাস

একবার ট্যাক্স গণনা হলে, ইনভয়েসের এমন "ডকুমেন্ট" ফিল্ডগুলো দরকার যা এটিকে বৈধ, অডিটঅযোগ্য, এবং পরে রিকনসিল করতে সহজ করে। GST চালান ডেটা মডেলে ইনভয়েস হেডারকে একটি আইনি রেকর্ড হিসেবে দেখুন: এটি স্থির থাকা উচিত যদিও প্রোডাক্ট বা কাস্টমার ডেটা পরে বদলে যায়।

হেডারের বেসিক্স দিয়ে শুরু করুন: invoice number, issue date (ইনভয়েসে যা লেখা থাকবে), invoice type (tax invoice, export, B2B, B2C ইত্যাদি), এবং currency। যদিও বেশিরভাগ ইনভয়েস INR-এ হোক, currency সংরক্ষণ করলে এক্সপোর্ট বা মাল্টি-কারেন্সি মার্কেটপ্লেসের জন্য সমস্যা কমে।

নম্বরিংতে টিমগুলো পুড়ে যায়। একটি সিরিজ বা প্রিফিক্স রাখুন (উদাহরণ: "FY25-INV-"), আর ফাইন্যান্সিয়াল ইয়ার সংরক্ষণ করুন এবং ডাটাবেস স্তরে uniqueness বজায় রাখুন। অ্যাডমিনে প্রতিটি সিরিজের জন্য "next number" কন্ট্রোলও রাখুন যাতে দুটি অ্যাডমিন একসাথে একই নাম্বার ইস্যু করতে না পারে।

টোটালগুলো স্পষ্টভাবে সংরক্ষণ করুন, কেবল ডিরাইভ করা নয়। subtotal (taxable value), total tax, grand total, এবং আলাদা round-off amount সংরক্ষণ করুন। যদি আপনি লাইন আইটেম থেকে পরে পুনর্গণনা করেন, একটি ছোট রুল পরিবর্তন পুরোনো ইনভয়েসগুলোকে ফাইল করা রিটার্নের সাথে মেলানো বন্ধ করতে পারে।

স্ট্যাটাসগুলো বাস্তব জীবনচক্র প্রতিফলিত করবে এবং প্রয়োজন হলে রেকর্ড লক করবে:

• Draft (সম্পাদনাযোগ্য)
• Issued (নম্বর বরাদ্দ, PDF জেনারেট)
• Cancelled (অডিটের জন্য রাখা, মুছে ফেলা নয়)
• Refunded (পেমেন্ট উল্টানো হয়েছে, ক্রেডিট নোট লাগতে পারে)
• Credit noted (লিঙ্ক করা ক্রেডিট নোট ইস্যু করা হয়েছে)

অবশেষে, জেনারেট করা আর্টিফ্যাক্ট মেটাডেটা সংরক্ষণ করুন: PDF টেমপ্লেট ভার্সন, জেনারেশন টাইমস্ট্যাম্প, এবং একটি ফাইল আইডেন্টিফায়ার। একটি হ্যাশ ঐচ্ছিক, কিন্তু যদি আপনি প্রমাণ করতে চান যে PDF পরিবর্তন করা হয়নি তাহলে উপকারী।

উদাহরণ: যদি একটি সাপোর্ট এজেন্ট টেমপ্লেট আপডেটের পরে PDF পুনরায় জেনারেট করে, ইনভয়েস মোট ও নম্বর একই থাকা উচিত, কিন্তু সংরক্ষিত টেমপ্লেট ভার্সন ব্যাখ্যা করবে কেন PDF লেআউট ভিন্ন দেখা যাচ্ছে।

প্রোডাক্ট, ট্যাক্স, ও কাস্টমার ডিটেইলের জন্য অ্যাডমিন স্ক্রিন

ফাইল ক্রিৎ GST ইনভয়েস চাইলে ইনভয়েস স্ক্রিন থেকেই শুরু করবেন না। ইনপুটগুলো যেখান থেকে আসে সেই অ্যাডমিন পেজগুলো থেকে শুরু করুন। একটি ভাল GST চালান ডেটা মডেল ছোট থাকে যখন এই ইনপুটগুলো নিয়ন্ত্রিত ও সঙ্গতিপূর্ণ থাকে।

Product master (SKU থেকে HSN/SAC পর্যন্ত)

প্রোডাক্ট মাস্টার হলো যেখানে ভবিষ্যতের বেশিরভাগ মismatch শুরু হয়, তাই এটাকে কড়াকড়ি রাখুন। প্রতিটি SKU-তে একটাই ডিফল্ট HSN (বা সার্ভিসের জন্য SAC), প্লাস ডিফল্ট GST হার এবং কেবল নির্দিষ্ট তারিখগুলোর জন্য প্রযোজ্য কোনো ব্যতিক্রম থাকা উচিত।

একটি বাস্তবিক প্রোডাক্ট স্ক্রিন সাধারণত এসব দরকার:

• SKU এবং প্রোডাক্ট নাম (যেভাবে আপনি প্রিন্ট করতে চান)
• HSN/SAC কোড, GST রেট, এবং ট্যাক্স ক্যাটেগরি (যদি ব্যবহার করেন)
• Active from/to তারিখ (তাই পরিবর্তন পুরোনো ইনভয়েসগুলোকে পুনরায় লেখা না করে)
• Price overrides (বিশেষ MRP বা চ্যানেল-নির্দিষ্ট প্রাইসিংয়ের জন্য)
• স্ট্যাটাস (active/inactive) এবং নিষ্ক্রিয় করার পরিস্কার কারণ

Tax setup (রেট এবং ইনট্রা বনাম ইন্টার-স্টেট ইনপুট)

একটি "ক্যালকুলেটর" UI এড়ান। বরং এমন ইনপুট সংরক্ষণ করুন যা আপনার সিস্টেম ধারাবাহিকভাবে প্রয়োগ করতে পারে: রেট টেবিল, আপনি যে place of supply রুল অনুসরণ করেন, এবং আপনি কীভাবে ইনট্রা-স্টেট বনাম ইন্টার-স্টেট নির্ধারণ করেন (সাধারণত supplier state ও ship-to state তুলনা করে)।

ট্যাক্স স্ক্রিনকে ফোকাস রাখুন: ক্যাটেগরি/HSN গ্রুপ অনুযায়ী ট্যাক্স রেট, effective dates, এবং যখন বায়ার বৈধ GSTIN দেয় তখন কি ঘটবে সেই নিয়ম।

Customer এবং company প্রোফাইল (কে ইনভয়েসে আছে)

কাস্টমার স্ক্রিনে GSTIN এবং তার validation স্ট্যাটাস, প্লাস ডিফল্ট বিলিং ও শিপিং ঠিকানা থাকা উচিত। ব্যবহারকারীদের ফ্রি-ফর্ম স্টেট টাইপ করতে দেবেন না; একটি নিয়ন্ত্রিত তালিকা ব্যবহার করুন যাতে "KA" এবং "Karnataka" দুইটি আলাদা মান না হয়।

আপনার কোম্পানি প্রোফাইল স্ক্রিন একইভাবে গুরুত্বপূর্ণ: আইনগত নাম, GSTIN, নিবন্ধিত ঠিকানা, এবং ইনভয়েস সিরিজ সেটিংস (প্রিফিক্স, পরবর্তী নম্বর, এবং অর্থবছরের সীমানা)। পারমিশন দিয়ে এটাকে লক করুন কারণ পরিবর্তনগুলি ভবিষ্যত প্রতিটি ডকুমেন্টকে প্রভাবিত করে।

অডিট লগ বেসিক (ট্রাস্ট ও ট্রেসাবিলিটি)

কঠিন সিস্টেম দরকার নেই, কিন্তু ট্রেইল দরকার। দেখুন কে HSN/SAC, GST রেট, invoice series সেটিং পরিবর্তন করেছে, পুরোনো মান, নতুন মান, টাইমস্ট্যাম্প এবং কারণসহ লগ রাখুন।

যদি আপনি এই স্ক্রিনগুলো Koder.ai-তে তৈরি করছেন, অডিট লগিং এবং effective dates-কে প্রথম শ্রেণির ফিল্ড হিসেবে বিবেচনা করুন। এগুলো শুরুতেই যোগ করা খরচ কম কিন্তু পরে ফাইন্যান্স রিভিউয়ে অনেক সময় বাঁচায়।

ধাপে ধাপে: অর্ডার থেকে কনপ্লায়েন্ট ইনভয়েস

একটি কনপ্লায়েন্ট ইনভয়েস ফরম্যাটিং নয় বরং সঠিক সময়ে সঠিক তথ্য স্থির করে ফেলার ব্যাপার। যদি আপনি আপনার GST চালান ডেটা মডেলকে এই ফ্লোর চারপাশে ডিজাইন করেন, ফাইন্যান্সের কাজ মিলিয়ে দেখা নয় বরং সহজ ম্যাচিং হবে।

1) গ্রাহক আসলে কী কিনেছে তা ফ্রিজ করুন

ট্যাক্স গণনার আগে অর্ডারের স্ন্যাপশট লক করুন: আইটেম, পরিমাণ, ইউনিট প্রাইস, ডিসকাউন্ট, শিপিং/হ্যান্ডলিং চার্জ, কাস্টমার GSTIN (যদি থাকে), বিলিং ও শিপিং ঠিকানা, এবং place of supply সংকেত। এই স্ন্যাপশট পরিবর্তন করা উচিত না এমনকি প্রোডাক্ট প্রাইস বা HSN ম্যাপিং পরে বদলে গেলেও।

2) স্ন্যাপশটকে ইনভয়েস লাইনে পরিণত করুন (ট্যাক্স অ্যাট্রিবিউট কপি করে)

স্ন্যাপশট থেকে ট্যাক্স গণনা করে ইনভয়েস লাইন জেনারেট করুন। প্রতিটি ইনভয়েস লাইন ঐ মুহূর্তে HSN/SAC, ট্যাক্স রেট(গুলি), taxable value, এবং ব্যবহৃত ট্যাক্স এমাউন্ট কপি করবে, লাইভ পরে লুকআপ করার পরিবর্তে।

3) ইনভয়েস ইস্যু করে এটিকে অপরিবর্তনীয় করুন

ইনভয়েস নম্বর ও ইস্যু তারিখ নির্ধারণ করুন, তারপর ইনভয়েসকে issued হিসেবে মার্ক করুন। এই পয়েন্ট থেকে ইনভয়েস রেকর্ডে প্রাইসিং, ট্যাক্স রেট, HSN কোড, এবং ঠিকানায় সম্পাদনা ব্লক করুন। যদি কিছু অনুমোদন দিতে হয়, সেটি সীমাবদ্ধ করুন কেবল নন-ফাইন্যান্সিয়াল নোট ও আভ্যন্তরীণ ট্যাগ পর্যন্ত।

4) চূড়ান্ত ডকুমেন্ট তৈরি করুন এবং মোটগুলো সংরক্ষণ করুন

জারি ইনভয়েস থেকে PDF/প্রিন্ট ভিউ জেনারেট করুন, তারপর রিপোর্ট করার জন্য চূড়ান্ত মোটগুলো সংরক্ষণ করুন: taxable total, CGST/SGST/IGST মোট, রাউন্ডিং, ও গ্র্যান্ড টোটাল। অতিরিক্ত নিরাপত্তা চাইলে ডকুমেন্ট ভার্সন বা চেকসাম সংরক্ষণ করুন যাতে আপনি প্রিন্টআউট এবং সংরক্ষিত সংখ্যাগুলোর মিল প্রমাণ করতে পারেন।

5) আইনি পথে পরিবর্তনগুলোর হ্যান্ডলিং

ইস্যুর পরে পরিবর্তনগুলো নিয়ম অনুযায়ী হওয়া উচিত, সরাসরি এডিট পড়ার পরিবর্তে:

• গ্রাহক চায় প্রাইস কারেকশন: মূল ইনভয়েস রেফারেন্স করে ক্রেডিট নোট (বা ডেবিট নোট) জারি করুন।
• অর্ডার ইস্যুর পরে বাতিল: ইনভয়েস বাতিল করুন যদি আইনীভাবে অনুমতি আছে, নচেৎ ক্রেডিট নোট ইস্যু করুন।
• গ্রাহক ইস্যুর পরে ঠিকানা আপডেট করে: ইনভয়েস পুনঃলিখন করবেন না; সঠিক ডকুমেন্টের মাধ্যমে করেকশন করুন এবং অডিট ট্রেইল রাখুন।
• পার্শিয়াল রিফান্ড: শুধুমাত্র রিফান্ড করা লাইনের জন্য ক্রেডিট নোট।
• রিপ্লেসমেন্ট শিপমেন্ট: নতুন অর্ডার/ইনভয়েস, নীরব এডিট নয়।

আপনি যদি এই ফ্লোকে আপনার অ্যাডমিন স্ক্রিনে বিল্ড করেন (Koder.ai-এর Planning Mode মানচিত্রটি আগেভাগে স্টেপগুলো স্কেচ করতে সহায়ক), আপনার টিম দ্রুত ইনভয়েস জেনারেট করতে পারবে বিনা রিকনসিলিয়েশন ভাঙবার।

রিকনসিলিয়েশনকে সহজ করুন: পেমেন্ট, রিফান্ড এবং রেজিস্টার

রিকনসিলিয়েশন জটিল হয়ে যায় যখন পেমেন্টগুলোকে অর্ডারের উপর একটি "paid/unpaid" ফ্ল্যাগ হিসেবে দেখা হয়। পেমেন্ট ও রিফান্ড আলাদা রেকর্ড রাখুন যা অর্ডার ও ইনভয়েসকে পয়েন্ট করে, যাতে ফাইন্যান্স ব্যাংক সেটেলমেন্ট মিলাতে পারে ইতিহাস না মুছেই।

পেমেন্ট ও রিফান্ড আলাদা রেকর্ড রাখুন (ইনভয়েস এডিট করবেন না)

একটি কনপ্লায়েন্ট ইনভয়েস ইস্যুর পরে স্থিতিশীল থাকা উচিত। যদি গ্রাহক কিস্তিতে পে করে, বা পরে রিফান্ড করা হয়, সেই মুভমেন্ট পেমেন্ট বা রিফান্ড এন্ট্রি হিসেবে রেকর্ড করুন, ইনভয়েস মোট পরিবর্তন করে না।

রিকনসিলিয়েশন সহজ করতে সাধারণত দরকারি ফিল্ড:

• 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 (if issued), gateway_refund_id, amount, reason, refunded_at, status
• Reconciliation keys যা কখনই পুনরায় ব্যবহার করা উচিত নয়: order_id, invoice_id, payment_id, refund_id, credit_note_id

যদি গ্রাহক একটি আইটেম ফিরিয়ে দেয়, ইনভয়েস "কমিয়ে" দেবেন না। মূল ইনভয়েসটি লিঙ্ক করে ক্রেডিট নোট ইস্যু করুন। ইনভয়েস রেজিস্টার পরিষ্কার থাকবে এবং রিফান্ড ক্রেডিট নোটের সাথে টিকে থাকবে।

ফাইন্যান্স ভিউ এবং এক্সপোর্ট যা সময় বাঁচায়

ফাইন্যান্সকে এমন একটি সিংগেল স্ক্রিন দিন যা উত্তর দেয়: কী ইস্যু হয়েছে, কী পে হয়েছে, কী খোলা আছে, এবং কী উল্টানো হয়েছে। এতে ageing (0-7, 8-30, 31-60, 60+ দিন) এবং সংশ্লিষ্ট পেমেন্ট ও রিফান্ড এন্ট্রিগুলোর ড্রিল-ডাউন রাখুন।

মাসিকভাবে বেশিরভাগ টিম যে এক্সপোর্টগুলো প্রয়োজন:

• ইনভয়েস রেজিস্টার (issued, cancelled, credit-noted)
• ট্যাক্স সামারি রেট ও HSN/SAC অনুযায়ী (আপনার GST চালান ডেটা মডেল সমর্থন করে)
• পেমেন্ট বনাম ইনভয়েস রিকনসিলিয়েশন (invoice_id, payment totals, balance)
• রিফান্ড ও ক্রেডিট নোট রেজিস্টার
• গেটওয়ে সেটেলমেন্ট রিপোর্ট (payout_id থেকে invoice/payment ম্যাপিং)

উদাহরণ: একটি অর্ডার Rs 10,000, আজ Rs 6,000 পে করা হয় এবং পরের সপ্তাহে Rs 4,000। ইনভয়েস থাকবে Rs 10,000। আপনার ফাইন্যান্স ভিউ দেখাবে ব্যালান্স Rs 4,000 যতক্ষণ না দ্বিতীয় সেটেলমেন্ট আসে, তারপর তা পুরো পেমেন্ট হিসেবে চিহ্নিত হবে পরিবর্তন না করে।

সাধারণ ফাঁদ যা কমপ্লায়েন্স এবং মিসম্যাচ সমস্যা করে

অধিকাংশ GST চালান সমস্যা "ট্যাক্স লজিক" সমস্যা নয়। এগুলো রেকর্ড-কিপিং সমস্যা: PDF-এ থাকা সংখ্যা ফাইন্যান্স এক্সপোর্টের সাথে মেলে না, অথবা ইনভয়েস পরে বোঝানো যায় না।

প্রথম ফাঁদ হলো ভিউ করার সময়ই GST গণনা করা। যদি আপনি CGST/SGST/IGST প্রতিবার ইনভয়েস খোলার সময় গণনা করেন, একটি দিন পরে রেট পরিবর্তন, রাউন্ডিং পরিবর্তন বা বাগ ফিক্সের কারণে ফলাফল ভিন্ন হবে। ইনভয়েস ইস্যুর সময় ব্যবহার করা ট্যাক্স ব্রেকডাউনটি সংরক্ষণ করুন, যদিও আপনি ইনপুটগুলোও সংরক্ষণ করেন।

একটি দ্বিতীয় ফাঁদ হলো ইস্যুকৃত ইনভয়েস এডিট করা। একবার ইনভয়েস চূড়ান্ত হলে পরিবর্তনগুলো ক্রেডিট নোট বা রিপ্লেসমেন্ট ফ্লোয়ের মাধ্যমে হওয়া উচিত, সরাসরি এডিট করে নয়। নচেৎ আপনি দেখবেন "কেন কাস্টমারের PDF বইয়ের সাথে আলাদা?"—এরকম তর্ক।

নিচে এমন মismatch প্যাটার্নগুলো দিলাম যা সবচেয়ে বেশি দেখা যায়:

• place of supply অনুপস্থিত বা state code ভুল, ফলে IGST প্রয়োগ করা হয় যেখানে CGST+SGST হওয়া উচিত (বা উল্টোটা)
• প্রোডাক্ট HSN/SAC বা ট্যাক্স রেট আপডেট করা হয় এবং পুরোনো অর্ডারগুলো নতুন মান দিয়ে পুনর্গণিত হয়
• ট্যাক্স সংরক্ষণ করা আছে, কিন্তু UI, PDF জেনারেশন এবং CSV এক্সপোর্টের মধ্যে রাউন্ডিং নিয়ম ভিন্ন
• ডিসকাউন্ট এক জায়গায় ট্যাক্সের আগে প্রয়োগ হচ্ছে এবং অন্য জায়গায় ট্যাক্সের পরে
• রিফান্ডগুলো নেগেটিভ লাইন আইটেম হিসেবে রেকর্ড করা হচ্ছে মূল ইনভয়েসের সাথে স্পষ্ট লিঙ্ক ছাড়া

একটি দ্রুত উদাহরণ: আপনি Karnataka-র একজন কাস্টমারে বিক্রি করেন, কিন্তু শিপিং ঠিকানা Maharashtra-তে। যদি আপনার সিস্টেম ভুল করে billing state কে place of supply হিসেবে নেয়, আপনি CGST+SGST চার্জ করতে পারেন IGST এর বদলে। যদি আপনি পরে লাইভে ট্যাক্স পুনর্গণনা করেন, ঐ ভুলটা নিরবে পরে "স্বয়ংক্রিয়ভাবে ঠিক" হয়ে যেতে পারে, ফলে ফাইন্যান্সের সামনে সংখ্যাগুলো ইনভয়েসের সাথে মেলে না।

যখন আপনি অ্যাডমিন স্ক্রিন বানাবেন (কাস্টম বা Koder.ai-এর মাধ্যমে), ছোট গার্ডরেইল যোগ করুন: ইস্যুকৃত ইনভয়েস লক করুন, place-of-supply ইনপুট পাশে প্রদর্শন করুন যাতে ব্যবহারকারী ট্যাক্স টাইপ দেখেন, এবং ইস্যু সময়ে ব্যবহৃত HSN, রেট ও রাউন্ডিং-র immutable স্ন্যাপশট রাখুন।

দ্রুত চেকলিস্ট এবং পরবর্তী ধাপ

কাস্টমারকে ইনভয়েস পাঠানোর বা এটিকে "issued" চিহ্ন করার আগে দ্রুত কিছু চেক চালান। ছোট ভুলগুলোই পরবর্তীতে বড় রিকনসিলিয়েশন মাথাব্যথা তৈরি করে। যদি আপনি একটি GST চালান ডেটা মডেল বানাচ্ছেন, এই চেকগুলো ভ্যালিডেশন রুল ও অ্যাডমিন UI-তে বেক করা মূল্যবান।

প্রতি ইনভয়েস চেক (ইস্যুর আগে)

• প্রতিটি লাইনে HSN/SAC আছে এবং সেটা প্রকৃত বিক্রিত প্রোডাক্ট/সেবার সাথে মিলছে
• GSTIN নিয়ম সঠিকভাবে প্রয়োগ হয়েছে (B2B বনাম B2C), এবং বিলিং ও শিপিং বিবরণ পরস্পরবিরোধী নয়
• place of supply সংরক্ষিত আছে এবং ট্যাক্স স্প্লিট যথাযথ (CGST/SGST বনাম IGST)
• মোটগুলো একেবারে মিলছে: taxable value, প্রতিটি ট্যাক্স কম্পোনেন্ট, রাউন্ডিং, ও গ্র্যান্ড টোটাল
• একবার ইস্যু করলে ইনভয়েস লক করা হয় (কোনো নীরব এডিট নয়)। সমাধানগুলো ক্রেডিট নোট বা বাতিল ফ্লোর মাধ্যমে করা হবে, ইতিহাস পুনঃলিখন করে নয়

একটি সরল উদাহরণ: গ্রাহক পেমেন্ট করার পরে তাদের শিপিং ঠিকানা আপডেট করে এবং স্টেট বদলে যায়। আপনি যদি একই ইনভয়েস নম্বর পুনরায় ইস্যু করে নতুন ট্যাক্স প্রয়োগ করেন, আপনার রেজিস্টার ও পেমেন্ট রেকর্ড মিল বন্ধ করে দেবে। নিরাপদ উপায় হল মূল ইনভয়েস অপরিবর্তিত রাখা এবং সামঞ্জস্য ডকুমেন্ট তৈরি করা।

ডেটা + ওয়ার্কফ্লো চেক (ফাইন্যান্সকে পরিষ্কার রাখার জন্য)

• ইনভয়েস নম্বরিং ইউনিক ও নীতিমতো সিকোয়েন্সিয়াল, এবং কেবল "issue" সময়েই জেনারেট হয়
• আপনি যে ট্যাক্স এমাউন্টগুলো ব্যবহার করেছেন সেগুলো সংরক্ষণ করুন, কেবল রেট নয়, যাতে রিপোর্টগুলো স্থিতিশীল থাকে রেট পরে বদলালেও
• স্পষ্ট স্ট্যাটাস স্টেপ থাকা উচিত: draft -> issued -> cancelled (এবং আলাদা ক্রেডিট নোট ডকুমেন্ট)
• রিপোর্টগুলো সময়ে মিলবে: ইনভয়েস রেজিস্টার টোটালস পে-অ্যাবল, প্রক্রিয়াজাত রিফান্ড ও আউটস্ট্যান্ডিং রিসিভেবলসের সাথে মেলে
• অডিট ফিল্ড সবসময় থাকা উচিত: created by, issued at, এবং বাতিল বা ক্রেডিট নোটের কারণে নোট

পরবর্তী ধাপ: প্রথমে স্ক্রিন ও ভ্যালিডেশনগুলো ইমপ্লিমেন্ট করুন, তারপর পুনরাবৃত্তি করুন। Koder.ai-তে Planning Mode ব্যবহার করে records ও অ্যাডমিন স্ক্রিন (প্রোডাক্টের HSN/SAC ম্যাপিং, কাস্টমার/GSTIN ডিটেইল, ট্যাক্স রুল, ইনভয়েস) স্কেচ করুন। অ্যাপ জেনারেট করুন, কয়েকটি বাস্তব অর্ডার এন্ড-টু-এন্ড টেস্ট করুন, তারপর স্ন্যাপশট ও রোলব্যাক ব্যবহার করে সেফ ভাবে ওয়ার্কফ্লো পরিমার্জান করুন। যখন ডিপার কাস্টমাইজেশন দরকার পড়বে, সোর্স কোড এক্সপোর্ট করে আপনার স্বাভাবিক প্রক্রিয়ায় সেটি বিকাশ করুন।