தமிழ் வணிக உரிமையாளர்களுக்கான LHDN e-Invois கணக்கு வழிகாட்டி

தமிழ் வணிக உரிமையாளர் முதலில் அறிய வேண்டிய பதில் என்ன?

LHDN e-Invois இணக்கத்தின் மையம் “விலைப்பட்டியல் உருவாக்கினோம்” என்பதல்ல; “சரியான சட்ட நிறுவனத்தின் சரியான பரிவர்த்தனைத் தரவை MyInvois-க்கு அனுப்பி, கிடைத்த முடிவை மூல விற்பனை மற்றும் கணக்குப் பதிவுடன் மீண்டும் இணைத்தோம்” என்பதே. வாடிக்கையாளருக்குக் கொடுக்கும் PDF, கணக்கியல் அமைப்பிலுள்ள invoice, MyInvois-க்கு அனுப்பிய UBL JSON மற்றும் LHDN திருப்பிய நிலை ஆகியவை தொடர்புடையவை; ஆனால் அவை ஒரே பொருள் அல்ல.

ஒரு கட்டுப்படுத்தப்பட்ட நடைமுறையில் குறைந்தது நான்கு ஆதாரங்கள் இருக்க வேண்டும்:

1. விற்பனை உருவானதை நிரூபிக்கும் order, receipt அல்லது service record;
2. வாங்குபவர் மற்றும் வழங்குநரின் சரிபார்க்கப்பட்ட அடையாளத் தகவல்;
3. MyInvois-க்கு அனுப்பப்பட்ட exact document மற்றும் அதன் hash;
4. submissionUid, ஆவண uuid, சமர்ப்பிப்பு நேரம் மற்றும் இறுதி validation நிலை.

உங்கள் வணிகம் எந்த அமலாக்கக் கட்டத்தில் வருகிறது என்ற statutory முடிவை இந்தக் கட்டுரை ஊகிக்கவில்லை. ஆண்டு வருவாய் அல்லது விற்பனை அளவு, விலக்கு, பரிவர்த்தனை வகை மற்றும் நடைமுறை தேதி ஆகியவற்றை LHDN-இன் அன்றைய அதிகாரப்பூர்வ timeline, General Guideline மற்றும் Specific Guideline-ல் சரிபார்க்க வேண்டும். அடிப்படையை முதலில் புரிந்துகொள்ள விரும்பினால் தமிழ் SME e-Invois அறிமுக வழிகாட்டியை படித்து, பின்னர் இங்குள்ள தினசரி செயல்முறையை அமைக்கலாம்.

பதிவு மற்றும் அமைப்பு தொடங்குவதற்கு முன் என்ன தயாரிக்க வேண்டும்?

முதலில் “எந்த வணிகம் சமர்ப்பிக்கிறது?” என்ற கேள்வியைத் தீர்க்கவும். ஒரே உரிமையாளர் பல sole proprietorship, Sdn. Bhd. அல்லது LLP வைத்திருக்கலாம். அவற்றின் TIN, பதிவு எண், SST நிலை, வங்கி, வருவாய் மற்றும் MyInvois credentials தனித்தனியானவை. ஒரு நிறுவனத்தின் client secret அல்லது supplier profile-ஐ மற்றொன்றில் பயன்படுத்துவது தொழில்நுட்பப் பிழை மட்டும் அல்ல; தவறான வரி செலுத்துநரின் பெயரில் ஆவணம் உருவாகும் அபாயம்.

API-இணைந்த அமைப்புக்கான தயாரிப்பு பட்டியல்:

• சட்டப் பெயர், TIN மற்றும் வணிகப் பதிவு எண்;
• முகவரி வரிகள், நகரம், அஞ்சல் குறியீடு மற்றும் மாநிலக் குறியீடு;
• பொருந்தினால் SST பதிவு எண்;
• வணிகச் செயல்பாட்டிற்கான MSIC தகவல்;
• தொடர்பு தொலைபேசி மற்றும் மின்னஞ்சல்;
• MyInvois client_id, client_secret மற்றும் சரியான environment;
• யார் invoice உருவாக்கலாம், யார் issue செய்யலாம், யார் LHDN-க்கு submit செய்யலாம் என்ற பொறுப்பு பிரிப்பு;
• தோல்வி, rejection மற்றும் correction-ஐ யார் தினமும் கவனிப்பார் என்ற exception owner.

GetPay-இன் native TypeScript இணைப்பு ஒவ்வொரு tenant-க்கும் தனித்தனி credentials மற்றும் sandbox அல்லது production environment-ஐப் பயன்படுத்துகிறது. Token கோரிக்கையில் client credentials grant மற்றும் InvoicingAPI scope பயன்படுத்தப்படுகிறது. LHDN திருப்பும் expires_in மதிப்பை வைத்தே token expiry கணக்கிடப்படுகிறது; token எப்போதும் ஒரு fixed நேரம் வாழும் என்று கருதப்படவில்லை. 60 வினாடிகளுக்கு மேல் காலம் மீதமிருக்கும் cached token மட்டுமே மீண்டும் பயன்படுத்தப்படுகிறது.

Sandbox சோதனை வெற்றி production பதிவு வெற்றி என்று பொருளல்ல. Production-க்கு மாறும் நாளில் environment, supplier profile மற்றும் invoice numbering-க்கு தனி sign-off வைத்திருங்கள்.

தினசரி விற்பனையில் எந்தத் தரவை முதலில் சேகரிக்க வேண்டும்?

தரவு invoice உருவாக்கிய பின் தேடப்படக்கூடாது. Customer onboarding அல்லது checkout நேரத்திலேயே sale வகையைப் பிரிக்கவும்:

நிலை	சேகரிக்க வேண்டிய அடிப்படைத் தரவு	தவிர்க்க வேண்டிய shortcut
B2B நிறுவனம்	சட்டப் பெயர், TIN, பதிவு எண், முகவரி, தொடர்பு	பொதுமக்கள் TIN-ஐ எல்லா நிறுவனங்களுக்கும் பயன்படுத்துதல்
அடையாளம் வழங்காத சாதாரண B2C	receipt அல்லது invoice எண், தேதி, பொருள் அல்லது சேவை, subtotal, tax, total	தெரியாத buyer தகவலைக் கற்பனை செய்தல்
foreign அல்லது சிறப்பு பரிவர்த்தனை	LHDN வழிகாட்டுதல் கோரும் country மற்றும் identification	Malaysian B2C fallback-ஐ உலகளாவிய fallback எனக் கருதுதல்
adjustment	மூல invoice number, LHDN uuid, காரணம், திருத்தத் தொகை	ஏற்கனவே சமர்ப்பித்த invoice-ஐ edit செய்தல்

GetPay-இன் சாதாரண invoice mapper, buyer TIN கிடைக்காத தகுதியான Malaysian B2C சூழலில் EI00000000010 என்ற general-public TIN-ஐப் பயன்படுத்தலாம். இது உண்மையான TIN கொண்ட B2B buyer-ஐ மறைக்கப் பயன்படும் default அல்ல. அதேபோல் மற்றொரு general TIN-ஐ எல்லா வெளிநாட்டு buyer-களுக்கும் பயன்படுத்த முடியாது; GetPay code-ல் foreign general TIN ஒரு குறிப்பிட்ட self-billed individual-supplier flow-க்குள் மட்டுமே உள்ளது.

ஒவ்வொரு line item-க்கும் விளக்கம், quantity, unit price மற்றும் line amount தெளிவாக இருக்க வேண்டும். Invoice அளவில் subtotal + tax = total என்பது sen அளவுக்கு பொருந்த வேண்டும். GetPay line-level tax-ஐ document tax total-க்கு ஒதுக்கும் போது largest-remainder முறையைப் பயன்படுத்துகிறது. இதனால் ஒவ்வொரு line tax-மும் negative ஆகாமல், அனைத்து line tax-களின் கூட்டுத்தொகை document tax-க்கு சரியாகப் பொருந்துகிறது.

ஒரு நாளாந்த e-Invois பணிச்சுற்று எப்படி இருக்க வேண்டும்?

ஒரு சிறிய retail அல்லது service business பின்வரும் எட்டு நிலைகளை standard operating procedure ஆக எழுதலாம்:

1. Capture: விற்பனை, buyer வகை, line items, tax basis மற்றும் payment terms-ஐ பதிவு செய்யுங்கள்.
2. Verify: supplier profile, buyer TIN அல்லது B2C தகுதி, invoice number, issue date, subtotal, tax மற்றும் total-ஐ இரண்டாவது பார்வையில் சரிபார்க்கவும்.
3. Issue: audit trail கொண்ட local invoice-ஐ ISSUED நிலைக்கு மாற்றுங்கள். GetPay submission core line items இல்லாத invoice-ஐ மறுக்கிறது.
4. Build: UBL 2.1 JSON-ல் AccountingSupplierParty, AccountingCustomerParty, InvoiceLine, TaxTotal மற்றும் LegalMonetaryTotal உருவாக்கப்படுகின்றன.
5. Submit: ஒரே canonical JSON string-லிருந்து SHA-256 documentHash மற்றும் Base64 document உருவாக்கி, format: "JSON" மற்றும் local codeNumber உடன் அனுப்புங்கள்.
6. Record acceptance: LHDN acceptedDocuments திருப்பினால் submissionUid, முதல் accepted uuid, submitted time மற்றும் local PENDING நிலையைச் சேமிக்கவும். rejectedDocuments இருந்தால் LHDN கொடுத்த code மற்றும் message-ஐ மாற்றாமல் வைத்திருக்கவும்.
7. Check validation: Status read மூலம் Submitted, Valid, Invalid அல்லது Cancelled நிலையைப் பெறுங்கள். தெரியாத status-ஐ “success” என்று மாற்றாதீர்கள்.
8. Close or correct: Valid ஆவணத்தை customer document மற்றும் ledger-க்கு இணைக்கவும்; Invalid ஆவணத்தில் actual reason-ஐத் திருத்தி கட்டுப்படுத்தப்பட்ட retry செய்யவும்.

Token பெறுதல் மற்றும் status read ஆகியவை side-effect இல்லாத செயல்கள் என்பதால் GetPay retry-with-backoff பயன்படுத்துகிறது. Document submission mutation என்பதால் timeout இருந்தாலும் automatic retry செய்யப்படவில்லை. Network பதில் தொலைந்திருந்தால் LHDN ஆவணத்தை ஏற்கனவே பெற்றிருக்கலாம்; உடனடி இரண்டாவது POST duplicate filing அபாயத்தை உருவாக்கும்.

அதனால் timeout-க்கு SOP இதுவாக இருக்க வேண்டும்: local claim மற்றும் payload evidence-ஐ பாதுகாக்கவும்; uuid கிடைத்திருந்தால் status படிக்கவும்; கிடைக்கவில்லை என்றால் submission record மற்றும் MyInvois evidence-ஐ reconcile செய்யவும்; முடிவு தெரியாமல் “failed” அல்லது “success” என்று குறிக்க வேண்டாம்.

UBL ஆவணத்தின் புலங்கள் கணக்குடன் எப்படி பொருந்த வேண்டும்?

GetPay சாதாரண invoice-க்கு MyInvois TypeCode 01, list version 1.1 மற்றும் MYR currency-ஐ உருவாக்குகிறது. Supplier TIN மற்றும் registration AccountingSupplierParty-ல் செல்கின்றன. Buyer identity AccountingCustomerParty-ல் செல்கிறது. ஒவ்வொரு invoice item-மும் தனி InvoiceLine; line amount tax-exclusive மதிப்பாகவும், line tax தனி TaxTotal ஆகவும் இருக்கிறது.

மூன்று reconciliation சமன்பாடுகளை submission-க்கு முன் இயந்திரமாகவும் மனித sample review மூலமும் பார்க்க வேண்டும்:

• அனைத்து line extension amount-களின் கூட்டுத்தொகை = invoice subtotal;
• அனைத்து line tax amount-களின் கூட்டுத்தொகை = invoice tax amount;
• subtotal + tax = total மற்றும் payable amount.

Hash கட்டுப்பாடும் அதே அளவு முக்கியம். GetPay JSON.stringify() மூலம் உருவாக்கிய ஒரே string-ன் UTF-8 bytes-ஐ SHA-256 hash செய்கிறது; அதே string-ஐ Base64 encode செய்கிறது. Hash உருவாக்கிய பின் object-ஐ மாற்றி மறுபடியும் encode செய்தால் documentHash அனுப்பப்பட்ட document-ஐ விவரிக்காது.

Raw secret-ஐ log செய்யாமல், failing operation, HTTP status, bounded response text, local invoice number, submission identifier மற்றும் validation error-ஐ audit evidence ஆகப் பாதுகாக்க வேண்டும்.

கணக்குப் பதிவுகள் e-Invois நிலையிலிருந்து எவ்வாறு வேறுபடுகின்றன?

e-Invois validation ஒரு statutory document நிலை; debit மற்றும் credit என்பது double-entry ledger நிலை. இரண்டையும் ஒரே status ஆகக் கருதக்கூடாது. உதாரணமாக invoice LHDN-ல் Valid ஆனாலும் payment இன்னும் வராமல் இருக்கலாம்; payment வந்தாலும் தவறான buyer data கொண்ட ஆவணம் Invalid ஆக இருக்கலாம்.

ஒரு வரியுள்ள credit sale-க்கான அடிப்படை journal வடிவம்:

நிகழ்வு	Debit	Credit
Invoice issue	Accounts Receivable — total	Revenue — subtotal; SST Payable — tax, பொருந்தினால்
Customer payment	Bank — பெற்ற தொகை	Accounts Receivable — பெற்ற தொகை
முழு credit note	Revenue reversal — subtotal; SST Payable reversal — tax, பொருந்தினால்	Accounts Receivable — total

இவை account பெயர் மற்றும் direction-ஐ விளக்கும் implementation pattern; உங்கள் chart of accounts code-களை இந்தக் கட்டுரை கற்பனை செய்யவில்லை. GetPay-இன் posted-ledger credit-note builder-லும் revenue மற்றும் பொருந்தும் SST debit செய்யப்படுகின்றன; total Accounts Receivable-க்கு credit செய்யப்படுகிறது. subtotal + tax = total sen அளவில் பொருந்தாவிட்டால் journal உருவாக்கம் மறுக்கப்படுகிறது.

ஒரு common mistake என்னவென்றால் credit note வெளியிட்ட பின் மூல sale row-ஐ delete செய்வது. மூல invoice, LHDN uuid, credit note, காரணம் மற்றும் ledger reversal ஆகியவை ஒன்றாக இருந்தால்தான் முழு audit trail கிடைக்கும். Correction என்பது history அழிப்பது அல்ல; original-ஐ reference செய்து புதிய adjustment உருவாக்குவது.

Credit note எப்போது, எப்படி உருவாக்க வேண்டும்?

விலை குறைப்பு, return, overbilling correction அல்லது invoice-ல் இருந்த தொகையைச் சுருக்க வேண்டிய காரணம் ஏற்பட்டால் முதலில் மூல invoice-ன் நிலையைப் பார்க்கவும். LHDN-ன் தற்போதைய வழிகாட்டுதல்படி cancellation பொருந்துமா, credit note தேவையா என்பதைத் தீர்மானிக்கவும். காலவரம்பை நினைவிலிருந்து ஊகிக்காமல் அதிகாரப்பூர்வ guidance-ஐச் சரிபார்க்கவும்.

GetPay mapper credit note-க்கு TypeCode 02, version 1.1 பயன்படுத்துகிறது. BillingReference-க்குள் மூல invoice_number மற்றும் மூல ஆவணத்தின் LHDN uuid சேர்க்கப்படுகிறது. மூல invoice-க்கு lhdn_uuid இல்லாவிட்டால் mapper credit note-ஐ உருவாக்க மறுக்கிறது; submission route மூல invoice LHDN-ல் VALID ஆக இருக்க வேண்டும் என்றும் சரிபார்க்கிறது.

Credit note பணிச்சுற்று:

1. மூல invoice மற்றும் customer-ஐத் தேர்ந்தெடுக்கவும்.
2. காரணத்தை தெளிவாக எழுதவும்; “correction” மட்டும் audit-க்கு போதாது.
3. subtotal, tax மற்றும் total குறைப்பு தொகையைப் பதிவு செய்யவும்.
4. cumulative adjustment மூல invoice அளவை மீறாதா என்பதைச் சரிபார்க்கவும்.
5. local credit note number மற்றும் date உருவாக்கவும்.
6. TypeCode 02 document-ஐ original UUID reference உடன் submit செய்யவும்.
7. புதிய submissionUid, uuid மற்றும் validation status-ஐ தனியாகப் பதிவு செய்யவும்.
8. ledger-ல் revenue, tax மற்றும் receivable reversal-ஐ post செய்யவும்.

“Invoice-ஐ edit செய்து மீண்டும் அதே எண்ணில் அனுப்புவது” credit note அல்ல. “Customer-க்கு WhatsApp-ல் புதிய PDF அனுப்பிவிட்டோம்” என்பதும் MyInvois adjustment அல்ல. Statutory document மற்றும் accounting reversal இரண்டும் நிறைவடைந்ததா என்பதைத் தனித்தனியாகச் சோதிக்க வேண்டும்.

ஒருங்கிணைந்த B2C e-Invois-ஐ எப்படி கட்டுப்படுத்துவது?

பல பொதுமக்கள் cash sales அல்லது individual B2C receipts-ஐ தற்போதைய LHDN விதிகள் அனுமதிக்கும் வகையில் ஒருங்கிணைக்கும் போது, முதலில் தகுதி தீர்மானம் வேண்டும். ஒருங்கிணைப்பு என்பது buyer data சேகரிப்பைத் தவிர்க்கும் பொதுவான வழி அல்ல. B2B buyer கேட்ட individual e-Invois, ஏற்கனவே individually filed sale அல்லது வழிகாட்டுதலில் consolidation-க்கு தடை செய்யப்பட்ட பரிவர்த்தனை சேரக்கூடாது.

GetPay consolidated draft candidate-ஐத் தேர்வு செய்யும் போது buyer TIN empty அல்லது general-public ஆகவும், status ISSUED, PAID அல்லது OVERDUE ஆகவும், தேர்ந்தெடுத்த மாதத்துக்குள் இருக்கவும் பார்க்கிறது. உருவான snapshot ஒவ்வொரு source invoice-ன் invoice_id, invoice_number, tax-exclusive subtotal, tax_amount, total, tax_type மற்றும் tax_rate-ஐ வைத்திருக்கிறது.

UBL consolidated document-ல்:

• TypeCode 01 மற்றும் version 1.1 பயன்படுத்தப்படுகின்றன;
• buyer GENERAL PUBLIC மற்றும் general-public TIN ஆக இருக்கிறார்;
• ஒவ்வொரு source invoice-க்கும் தனி InvoiceLine உருவாகிறது;
• line description source invoice number-ஐத் தக்கவைக்கிறது;
• line subtotal மற்றும் tax தனித்தனியாக அனுப்பப்படுகின்றன;
• tax category அடிப்படையில் document TaxSubtotal தொகுக்கப்படுகிறது;
• issue date மற்றும் time உண்மையான submission நேரத்திலிருந்து பெறப்படுகின்றன.

Unknown tax_type வந்தால் GetPay mapper ஒரு category-ஐ ஊகிக்காமல் fail closed செய்கிறது. service, sales மற்றும் exempt என்ற அறியப்பட்ட local values மட்டுமே அதன் தற்போதைய mapping-ல் ஏற்கப்படுகின்றன. இது LHDN statutory rate பட்டியல் அல்ல; உங்கள் source invoice-ல் tax basis தவறாக இருந்தால் mapper அதை business judgment கொண்டு சரிசெய்யாது.

Submission முன் இரண்டு double-filing checks அவசியம். Draft உருவான பின் source invoice தனியாக MyInvois-க்கு அனுப்பப்பட்டிருக்கலாம்; submit நேரத்தில் மீண்டும் live check செய்ய வேண்டும். மேலும் பழைய accounting system-லிருந்து archive ஆக வந்த sale ஏற்கனவே வேறு அமைப்பில் தாக்கல் செய்யப்பட்டிருக்கலாம். GetPay இத்தகைய migrated provenance-ஐ மறுபடியும் LHDN-க்கு அனுப்பாமல் தடுக்கிறது.

அதிகம் நிகழும் பிழைகள் என்ன, அவற்றை எப்படி தவிர்ப்பது?

தவறான entity: ஒரே owner என்பதால் இரண்டு நிறுவனங்களின் TIN அல்லது credentials கலப்பது. ஒவ்வொரு tenant-க்கும் supplier master மற்றும் MyInvois credentials தனியாக இருக்க வேண்டும்.

General-public TIN overuse: B2B buyer-ன் உண்மையான TIN கிடைத்தும் B2C fallback பயன்படுத்துவது. Sale வகையை checkout-லேயே கேளுங்கள்; month-end-ல் ஊகிக்காதீர்கள்.

PDF-ஐ validation எனக் கருதுதல்: Customer copy உருவானதும் statutory filing முடிந்தது எனக் குறித்தல். uuid மற்றும் இறுதி LHDN status-ஐத் தனியாகப் படிக்கவும்.

Timeout-க்கு blind retry: பதில் வராததால் submit தோல்வி என நினைத்து மீண்டும் அனுப்புதல். முதலில் unknown outcome ஆகக் கையாளுங்கள்.

Wrong totals: line subtotal, tax மற்றும் document total ஒரு sen வேறுபடுதல். Decimal precision மற்றும் rounding allocation-ஐ submission முன் சோதிக்கவும்.

Submitted invoice edit: Valid ஆவணத்தின் customer, date அல்லது amount-ஐ audit trail இல்லாமல் மாற்றுதல். பொருத்தமான cancellation அல்லது adjustment document பயன்படுத்தவும்.

Credit note without original UUID: Local invoice number மட்டும் வைத்து statutory link போதுமானது என நினைத்தல். BillingReference-க்கு original LHDN uuid தேவை.

B2C double filing: Individual e-Invois-ல் சென்ற source-ஐ consolidated filing-லும் சேர்த்தல். Draft நேரமும் submit நேரமும் exclusion check செய்யவும்.

Tax category guessing: Legacy value புரியாதபோது அருகிலுள்ள category தேர்வு செய்தல். Source record-ஐ ஆய்வு செய்து சரியான classification-ஐ உறுதிசெய்யும் வரை submission நிறுத்தவும்.

Rejected response மறைத்தல்: “LHDN error” என்ற பொதுச் செய்தி மட்டும் வைத்தல். Actual operation, HTTP status மற்றும் LHDN கொடுத்த code/message-ஐப் பாதுகாக்கவும்.

30 நாள் செயல்படுத்தல் திட்டம் எப்படி இருக்கலாம்?

நாள் 1–5 — scope: சட்ட நிறுவனம், LHDN தொடக்கக் கடமை, விற்பனை channel, B2B/B2C விகிதம், adjustment வகைகள் மற்றும் பொறுப்பாளர்களை எழுதுங்கள். அதிகாரப்பூர்வ வழிகாட்டுதலின் version மற்றும் பார்த்த தேதியைப் பதிவு செய்யுங்கள்.

நாள் 6–10 — master data: Supplier TIN, registration, address, SST, MSIC மற்றும் contacts-ஐச் சுத்தப்படுத்துங்கள். Customer form-ல் business buyer identity மற்றும் ordinary consumer பாதையைப் பிரிக்கவும். Tax type மற்றும் rounding rules-ஐப் பரிசோதிக்க sample sales தேர்வு செய்யுங்கள்.

நாள் 11–15 — sandbox: குறைந்தது ஒரு B2B invoice, ஒரு தகுதியான B2C invoice, tax உள்ள மற்றும் tax இல்லாத sample, rejection case மற்றும் network uncertainty SOP-ஐச் சோதியுங்கள். Hash மற்றும் Base64 ஒரே canonical document-லிருந்து வருகிறதா என்பதை உறுதிசெய்யுங்கள்.

நாள் 16–20 — corrections: Original Valid invoice-ஐ reference செய்யும் credit note flow, காரணப் பதிவு, ledger reversal மற்றும் customer document-ஐ ஒன்றாகச் சோதியுங்கள். Edit permission-ஐ submitted documents-க்கு மூடுங்கள்.

நாள் 21–25 — consolidation: ஒரு மாத B2C candidates-ஐ preview செய்து source values-ஐ sample receipts-க்கு எதிராகப் பாருங்கள். Individually filed sales exclusion, source count, subtotal, tax, total மற்றும் category grouping-ஐச் சரிபார்க்கவும்.

நாள் 26–30 — production readiness: Production credentials, access, alerts, daily status review, evidence retention மற்றும் escalation owner-க்கு sign-off பெறுங்கள். முதல் production வாரத்தில் ஒவ்வொரு submission-ஐயும் மனிதர் review செய்யுங்கள்.

GetPay-இன் public website தமிழ் மொழித் தேர்வு, தமிழ் e-Invois விளக்கம் மற்றும் தமிழ் blog அனுபவத்தை வழங்குகிறது. தினசரி operational dashboard முழுவதும் தமிழாக்கப்பட்டுள்ளது என்று repository ஆதரிக்காததால், இந்தக் கட்டுரை அத்தகைய கூற்றைச் செய்யவில்லை. எந்த மொழி UI பயன்படுத்தினாலும், LHDN-க்கு செல்லும் TIN, registration, document type, amounts, hash, uuid மற்றும் status ஆகிய கட்டுப்பாடுகள் ஒரே துல்லியத்தில் இருக்க வேண்டும்.

முடிவில் உங்கள் தினசரி dashboard கேட்க வேண்டிய கேள்வி எளியது: “இன்று உருவான ஒவ்வொரு தகுதியான விற்பனைக்கும் சரியான entity, சரியான buyer வகை, சமநிலையான தொகைகள், ஒரே submission, பதிவான LHDN முடிவு மற்றும் தேவைப்பட்டால் traceable adjustment இருக்கிறதா?” இந்தக் கேள்விக்கு evidence உடன் பதில் கிடைத்தால், e-Invois ஒரு month-end panic ஆகாமல் தினசரி கணக்குச் செயல்முறையாக மாறும்.