மலேசியாவில் e-Invois LHDN சட்ட விதிகள்: சிறு வணிக வழிகாட்டி 2026

முதலில் தெரிந்துகொள்ள வேண்டிய பதில் என்ன?

மலேசியச் சிறு வணிக உரிமையாளருக்கான சுருக்கமான பதில் இதுதான்: உங்கள் வணிகம் LHDN வெளியிட்டுள்ள தற்போதைய நடைமுறைக் கட்டத்துக்குள் வந்தால், தகுதியான பரிவர்த்தனையின் விற்பனைத் தரவை MyInvois-க்கு அனுப்பி, அதன் சரிபார்ப்பு முடிவைப் பதிவு செய்து, வாடிக்கையாளருக்கான ஆவணத்துடன் தொடர்புபடுத்த வேண்டும். ஒரு சாதாரண PDF அல்லது அச்சு விலைப்பட்டியலை மட்டும் உருவாக்குவது இந்த முழுச் செயல்முறைக்கு மாற்றாகாது.

இதை ஒரு வரித் துறைக்கான தனி வேலை என்று ஒதுக்கிவிடாதீர்கள். e-Invois உங்கள் விற்பனைப் பதிவு, வாடிக்கையாளர் அடையாளம், பொருள் அல்லது சேவை விவரம், வரிக் கணக்கீடு, கடன் குறிப்புகள் மற்றும் ரத்துச் செயல்முறை ஆகியவற்றைத் தொடுகிறது. தவறான அடிப்படைத் தரவை வேகமாக அனுப்பும் மென்பொருள் இணக்கம் அல்ல; சரியான தரவை கட்டுப்பாட்டுடன் அனுப்பி, பதிலைத் தொடர்ந்து கண்காணிப்பதே இணக்கமான பணிச்சுற்று.

யார் இணங்க வேண்டும், தொடக்க நேரத்தை எப்படித் தீர்மானிப்பது?

LHDN e-Invois-ஐ கட்டங்களாக நடைமுறைப்படுத்துகிறது. பொருந்தும் கட்டம் பொதுவாக வரி செலுத்துநரின் ஆண்டு வருவாய் அல்லது விற்பனை அளவுடன் தொடர்புடையது; வெளியிடப்பட்ட விலக்குகள் மற்றும் சிறப்பு விதிகளும் முடிவை மாற்றக்கூடும். எனவே “என் நண்பரின் கடை இன்னும் தொடங்கவில்லை” அல்லது “என் வணிகம் சிறியது” என்பவை சட்டத் தீர்மானம் அல்ல.

உங்கள் முடிவை ஆவணப்படுத்த இந்த நடைமுறையைப் பின்பற்றுங்கள்:

1. சமீபத்திய முடிக்கப்பட்ட நிதியாண்டின் வருவாய் அல்லது விற்பனைத் தொகையை நிதி அறிக்கைகள் மற்றும் வரி பதிவுகளிலிருந்து எடுத்துக்கொள்ளுங்கள்.
2. எந்தச் சட்ட நிறுவனத்திற்காக முடிவு எடுக்கிறீர்கள் என்பதைத் தெளிவுபடுத்துங்கள். ஒரே உரிமையாளரின் இரண்டு நிறுவனங்களின் பெயர்கள், TIN-கள் மற்றும் பதிவுகள் ஒன்றாகக் கலக்கக்கூடாது.
3. LHDN-இன் அதிகாரப்பூர்வ நடைமுறைக் கால அட்டவணையில் அந்த அளவுக்கான கட்டத்தையும் பொருந்தும் விலக்கையும் பார்க்கவும்.
4. தற்போதைய e-Invois Guideline மற்றும் Specific Guideline-இல் உங்கள் வணிக வகை அல்லது பரிவர்த்தனைக்கு தனி நடைமுறை உள்ளதா எனச் சரிபார்க்கவும்.
5. நீங்கள் பார்த்த வழிகாட்டுதலின் பதிப்பு, பார்த்த தேதி மற்றும் எடுத்த முடிவை ஒரு இணக்கப் பதிவில் வைத்திருங்கள்.

இந்தக் கட்டுரை குறிப்பிட்ட கட்டத் தேதிகளை மீண்டும் பட்டியலிடவில்லை. காரணம், LHDN அட்டவணையும் வழிகாட்டுதல் பதிப்புகளும் புதுப்பிக்கப்படலாம். உங்கள் நடைமுறை தொடக்கத் தேதிக்கு அதிகாரம் LHDN வெளியிட்டுள்ள அன்றைய தகவல்தான்.

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

PDF விலைப்பட்டியல் வாடிக்கையாளர் படிக்க உதவும் காட்சி ஆவணம். e-Invois என்பது வணிகப் பரிவர்த்தனையின் கட்டமைக்கப்பட்ட தரவு. LHDN விளக்கும் மாதிரியில், வழங்குநர் MyInvois Portal அல்லது API வழியாகத் தரவை அனுப்புகிறார்; MyInvois அதைச் சரிபார்த்து, வரலாற்றுப் பதிவாக அணுகக்கூடிய நிலையை உருவாக்குகிறது.

அதனால் மூன்று தனித்தனி ஆதாரங்களைப் பாதுகாக்க வேண்டும்:

• உங்கள் கணக்கியல் அமைப்பிலுள்ள மூல விற்பனைப் பதிவு;
• MyInvois-க்கு உண்மையில் அனுப்பப்பட்ட கட்டமைக்கப்பட்ட ஆவணம்; மற்றும்
• LHDN திருப்பிய சமர்ப்பிப்பு அடையாளம், ஆவண அடையாளம் மற்றும் நிலை.

வாடிக்கையாளருக்கு அழகான PDF கிடைத்தது என்பதனால் MyInvois சமர்ப்பிப்பு வெற்றியடைந்தது என்று கருத முடியாது. அதேபோல் API கோரிக்கை அனுப்பப்பட்டது என்பதனால் ஆவணம் Valid ஆனது என்றும் கருத முடியாது. உருவாக்கம், சமர்ப்பிப்பு, ஏற்றுக்கொள்ளல் மற்றும் சரிபார்ப்பு ஆகியவை தனித்தனி நிலைகள்.

ஒரு e-Invois-இல் எந்தத் தகவல்கள் இருக்க வேண்டும்?

சரியான புலங்களும் அவற்றின் கட்டாயத் தன்மையும் பரிவர்த்தனை வகை மற்றும் தற்போதைய LHDN வழிகாட்டுதலால் தீர்மானிக்கப்படுகின்றன. நடைமுறையில், ஒரு SME குறைந்தபட்சம் பின்வரும் தரவுக் குழுக்களைத் துல்லியமாகப் பராமரிக்க வேண்டும்.

தரவுக் குழு	தயார் செய்ய வேண்டிய வணிகத் தகவல்	GetPay உருவாக்கும் முக்கிய UBL புலங்கள்
வழங்குநர்	சட்டப் பெயர், TIN, வணிகப் பதிவு எண், முகவரி, பொருந்தினால் SST மற்றும் MSIC	AccountingSupplierParty, PartyIdentification, PartyLegalEntity, PostalAddress
வாங்குபவர்	பெயர், TIN, பதிவு எண், தொடர்பு மற்றும் பரிவர்த்தனைக்குத் தேவையான முகவரி	AccountingCustomerParty, PartyIdentification, Contact
ஆவணம்	தனித்துவ விலைப்பட்டியல் எண், வெளியீட்டுத் தேதி/நேரம், ஆவண வகை, நாணயம்	ID, IssueDate, IssueTime, InvoiceTypeCode, DocumentCurrencyCode
விற்பனை வரிகள்	விளக்கம், அளவு, அலகு, அலகு விலை, வரிக்கு முன் வரித் தொகை	InvoiceLine, InvoicedQuantity, Price, LineExtensionAmount
வரி மற்றும் மொத்தம்	வரித் தொகை, வரிக்கு முன் மொத்தம், வரியுடன் மொத்தம், செலுத்த வேண்டிய தொகை	TaxTotal, TaxExclusiveAmount, TaxInclusiveAmount, PayableAmount

GetPay-இன் தற்போதைய சாதாரண விற்பனை விலைப்பட்டியல் வரைபாடு UBL Invoice வகை 01, பட்டியல் பதிப்பு 1.1 மற்றும் MYR நாணயத்தை உருவாக்குகிறது. ஒவ்வொரு வரிக்கும் வரிசை எண், அளவு, அலகு, விளக்கம், அலகு விலை, வரிக்கு முன் தொகை மற்றும் ஒதுக்கப்பட்ட வரி மதிப்பு சேர்க்கப்படுகிறது. ஆவண மொத்தம் வரிகளின் தரவுடன் கணக்கியல் ரீதியாகப் பொருந்த வேண்டும்.

இவை “எந்தப் புலத்திலும் ஏதாவது உரை இருந்தால் போதும்” என்ற பட்டியல் அல்ல. தவறான TIN-ஐ சரியான வடிவில் அனுப்பினாலும் அது தவறான அடையாளமே. மற்றொரு நிறுவனத்தின் பதிவு எண்ணைப் பயன்படுத்தினாலும் தொழில்நுட்பச் சமர்ப்பிப்பு வணிக உண்மையைப் பிரதிபலிக்காது.

B2B மற்றும் B2C வாங்குபவர் தரவை எவ்வாறு கையாள வேண்டும்?

B2B விற்பனையில் வாடிக்கையாளரின் சட்டப் பெயர், TIN மற்றும் வணிகப் பதிவு அடையாளத்தை வாடிக்கையாளர் பதிவில் சரிபார்த்து வைத்திருங்கள். விற்பனை நேரத்தில் பணியாளர் ஊகித்து நிரப்பும் பழக்கத்தைத் தவிர்க்கவும். ஒரே வாடிக்கையாளரின் கிளைப்பெயர் மற்றும் சட்ட நிறுவனப் பெயர் வேறுபட்டால், LHDN ஆவணத்தில் எந்த நிறுவனம் வாங்குபவர் என்பதைத் தெளிவுபடுத்த வேண்டும்.

சாதாரண மலேசிய B2C விலைப்பட்டியலில் வாங்குபவர் TIN இல்லாதபோது, GetPay-இன் தற்போதைய வரைபாடு EI00000000010 என்ற பொதுமக்கள் TIN-ஐப் பயன்படுத்த முடியும். இதை B2B வாடிக்கையாளரின் காணாமல் போன TIN-ஐ மறைக்கப் பயன்படுத்தக்கூடாது. மேலும் EI00000000030 என்பது எல்லா வெளிநாட்டு வாங்குபவர்களுக்கும் பொதுவான மாற்று அல்ல; GetPay-இல் அது மலேசிய TIN இல்லாத தகுதியுள்ள வெளிநாட்டு தனிநபர் வழங்குநருக்கான குறிப்பிட்ட சுய-விலைப்பட்டியல் நடைமுறையில் மட்டுமே வருகிறது.

முக்கிய கட்டுப்பாடு: “புலம் காலியாக இருக்கக் கூடாது” என்பதற்காக தவறான பொதுத் தரவை நிரப்பாதீர்கள். B2B, B2C, வெளிநாட்டு பரிவர்த்தனை மற்றும் சுய-விலைப்பட்டியல் ஆகியவற்றுக்கு ஒரே அடையாள விதியைப் பயன்படுத்துவது பின்னர் திருத்த வேண்டிய தவறுகளை உருவாக்கும்.

MyInvois Portal மற்றும் API-இல் எது SMEக்கு ஏற்றது?

LHDN இரண்டு முக்கிய அனுப்பும் வழிகளை வழங்குகிறது: MyInvois Portal மற்றும் API. Portal குறைந்த பரிவர்த்தனை அளவுள்ள, தனி ERP அல்லது கணக்கியல் இணைப்பு இல்லாத வரி செலுத்துநருக்கு நேரடி தேர்வாகும். LHDN வழங்கும் Portal-ஐ கட்டணமின்றி பயன்படுத்தலாம்; ஆனால் உங்கள் கணக்கியல் அமைப்பிலுள்ள தரவை மீண்டும் கைமுறையாக உள்ளிட வேண்டிய நேரமும் கட்டுப்பாடும் கணக்கில் கொள்ளப்பட வேண்டும்.

API என்பது உங்கள் விற்பனை அல்லது கணக்கியல் அமைப்பிலிருந்து MyInvois-க்கு நேரடித் தரவு பரிமாற்றம். இது அதிக அளவிலான விலைப்பட்டியல்களுக்கு மட்டும் அல்ல. தினமும் குறைந்த எண்ணிக்கையிலான விற்பனை இருந்தாலும், மீண்டும் தட்டச்சு செய்வதால் வாடிக்கையாளர் TIN, தொகை அல்லது வரியில் தவறுகள் ஏற்படுகின்றன என்றால் இணைப்பு பயனுள்ளதாக இருக்கலாம்.

தேர்வு செய்யும்போது இந்த நான்கு கேள்விகளைக் கேளுங்கள்:

• மாதந்தோறும் எத்தனை ஆவணங்கள் உருவாகின்றன?
• ஒரே தரவு எத்தனை முறை, எத்தனை அமைப்புகளில் தட்டச்சு செய்யப்படுகிறது?
• நிராகரிப்பு அல்லது முடிவு தெரியாத சமர்ப்பிப்பை யார் ஆய்வு செய்வார்?
• அனுப்பிய JSON, LHDN பதில் மற்றும் நிலை மாற்றத்தை மென்பொருள் பாதுகாக்கிறதா?

API என்பது “ஒரே பொத்தானில் அனைத்தும் முடிந்தது” அல்ல. தரவு சரிபார்ப்பு, அணுகல் சான்று, பாதுகாப்பான சமர்ப்பிப்பு, நிலை வாசிப்பு மற்றும் மனித ஆய்வு ஆகியவை சேர்ந்த பணிச்சுற்று.

மென்பொருள் வழியாக e-Invois சமர்ப்பிப்பு எப்படி இயங்குகிறது?

GetPay-இன் நடைமுறை நிரலில் ஒரு சாதாரண API சமர்ப்பிப்பு பின்வரும் வரிசையில் நடக்கிறது:

1. ஒவ்வொரு வணிக நிறுவனத்திற்குமான MyInvois clientId, clientSecret மற்றும் sandbox அல்லது production சூழல் தனித்தனியாக நிறுவனப் பதிவிலிருந்து பெறப்படுகிறது.
2. விலைப்பட்டியல், வரிகள், வழங்குநர் மற்றும் வாங்குபவர் தரவிலிருந்து UBL 2.1 JSON ஆவணம் உருவாக்கப்படுகிறது.
3. அந்த UBL ஆவணம் JSON.stringify() மூலம் ஒருமுறை மட்டுமே உரையாக மாற்றப்படுகிறது.
4. அதே UTF-8 தரவிலிருந்து SHA-256 documentHash கணக்கிடப்படுகிறது; அதே உரை Base64 document ஆக மாற்றப்படுகிறது.
5. format: "JSON", document, documentHash மற்றும் உள்ளூர் விலைப்பட்டியல் எண் codeNumber கொண்ட சமர்ப்பிப்பு உறை உருவாக்கப்படுகிறது.
6. InvoicingAPI scope உடைய client-credentials அணுகல் சான்று பெற்று, ஆவணம் MyInvois-க்கு அனுப்பப்படுகிறது.
7. பதிலிலுள்ள submissionUid, ஏற்றுக்கொள்ளப்பட்ட ஆவணத்தின் uuid, அல்லது நிராகரிக்கப்பட்ட ஆவணத்தின் LHDN பிழை விவரம் பாதுகாக்கப்படுகிறது.
8. ஆவண விவரத்தை வாசித்து அதன் நிலை தொடர்ந்து புதுப்பிக்கப்படுகிறது.

SHA-256 கணக்கிட ஒரு JSON உரையையும், அனுப்ப வேறொரு மாற்றப்பட்ட JSON உரையையும் பயன்படுத்தக்கூடாது. ஒரு எழுத்து மாறினாலும் hash அனுப்பப்பட்ட ஆவணத்தை விவரிக்காது. அதனால்தான் GetPay ஒரே canonical உரையிலிருந்து hash மற்றும் Base64 இரண்டையும் உருவாக்குகிறது.

சமர்ப்பிப்புக்கு முன் எந்தச் சோதனைகள் அவசியம்?

முதலில் நிறுவன அமைப்பைச் சரிபார்க்கவும். வழங்குநரின் TIN, வணிகப் பதிவு எண், சட்டப் பெயர், முகவரி, அஞ்சல் குறியீடு, மாநிலம் மற்றும் பொருந்தும் MSIC/SST தகவல் முழுமையாக இருக்க வேண்டும். ஒரு குழுமத்தில் பல சட்ட நிறுவனங்கள் இருந்தால், விற்பனை செய்த நிறுவனத்தின் சான்றுகளையே பயன்படுத்துங்கள்.

அடுத்ததாக வாடிக்கையாளர் பதிவைப் பாருங்கள். B2B வாங்குபவரின் TIN மற்றும் பதிவு எண்ணை விற்பனை ஊழியர் குறிப்பிலிருந்து கண்மூடித்தனமாக நகலெடுக்காதீர்கள். வாடிக்கையாளரிடமிருந்து உறுதிப்படுத்தப்பட்ட விவரத்தை மையப் பதிவில் வைத்து, அடுத்த விலைப்பட்டியலும் அதையே பயன்படுத்துமாறு செய்யுங்கள்.

பின்னர் கணக்கியல் கணிதத்தைச் சரிபார்க்கவும்:

• ஒவ்வொரு வரியின் quantity × unit_price மற்றும் பதிவான வரித் தொகை பொருந்துகிறதா?
• அனைத்து LineExtensionAmount மதிப்புகளும் ஆவணத்தின் TaxExclusiveAmount உடன் ஒத்துப்போகிறதா?
• வரி ஒதுக்கீடுகளின் கூட்டுத்தொகை TaxTotal உடன் சரியாகப் பொருந்துகிறதா?
• TaxInclusiveAmount மற்றும் PayableAmount வணிக ஆவணத்தின் உண்மையான மொத்தத்தைப் பிரதிபலிக்கிறதா?
• தொகைகள் சென் அளவுக்கு நிலையாக உள்ளனவா?

சிறிய வரித் தொகையை பல வரிகளுக்கு வகுக்கும் போது ஒவ்வொரு வரியையும் தனித்தனியாக round செய்தால் ஒரு சென் வேறுபாடு உருவாகலாம். GetPay Hamilton largest-remainder முறையைப் பயன்படுத்தி வரித் தொகையை ஒதுக்குகிறது: முதலில் ஒவ்வொரு பங்கையும் கீழ்நோக்கி முழுமைப்படுத்தி, மீதமுள்ள சென்களை அதிக fractional remainder உள்ள நேர்மறை வரிகளுக்கு வழங்குகிறது. இதனால் எந்த வரியிலும் எதிர்மறை வரி வராது; வரிகளின் கூட்டுத்தொகை ஆவண வரியுடன் சரியாக முடியும்.

MyInvois பதிலை எவ்வாறு வாசிக்க வேண்டும்?

சமர்ப்பிப்பு HTTP வெற்றி பெற்றது என்பதையும், ஒவ்வொரு ஆவணமும் ஏற்றுக்கொள்ளப்பட்டதையும் ஒன்றாகக் கருதாதீர்கள். GetPay எதிர்பார்க்கும் சமர்ப்பிப்பு பதிலில் acceptedDocuments மற்றும் rejectedDocuments தனித்தனியாக உள்ளன. ஏற்றுக்கொள்ளப்பட்ட ஆவணத்திற்கு uuid கிடைக்கலாம்; நிராகரிக்கப்பட்ட ஆவணத்திற்கு LHDN வழங்கிய code மற்றும் message இருக்கலாம்.

ஆவண விவர வாசிப்பில் GetPay Submitted, Valid, Invalid, Cancelled ஆகிய நிலைகளை அறிகிறது. அவை உள்ளூரில் முறையே நிலுவை, செல்லுபடியாகும், செல்லாதது அல்லது ரத்தானது எனத் தொடர்புபடுத்தப்படுகின்றன. அறியாத நிலை வந்தால் வெற்றி என்று ஊகிக்காமல் செயல்முறை நிறுத்தப்பட வேண்டும்.

Invalid என்றால் முதலில் உண்மையான validation step, பிழைக் குறியீடு மற்றும் செய்தியைப் படியுங்கள். “TIN பிழையாக இருக்கும்” என்று ஊகித்து பல புலங்களை ஒரே நேரத்தில் மாற்றினால் மூல காரணம் மறைந்துவிடும். ஒரு மாற்றம் செய்து, புதிய ஆவணத்துக்கும் முந்தைய நிராகரிப்புக்கும் தெளிவான audit trail வைத்திருங்கள்.

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

அணுகல் சான்று பெறுதல் மற்றும் ஆவண நிலை வாசித்தல் போன்ற பாதுகாப்பான செயல்கள் இடைவெளியுடன் மீண்டும் முயற்சிக்கப்படலாம். ஆனால் ஆவணச் சமர்ப்பிப்பு ஒரு மாற்றத்தை ஏற்படுத்தும் செயல். MyInvois ஆவணத்தை ஏற்றுக்கொண்ட பிறகு அதன் பதில் உங்கள் சேவையகத்தை அடையாமல் போகலாம். அந்த நேரத்தில் அதே POST கோரிக்கையைத் தானாக மீண்டும் அனுப்பினால் இரண்டாவது ஆவணம் உருவாகும் அபாயம் உள்ளது.

GetPay சமர்ப்பிப்புக்கு முன் உள்ளூர் விலைப்பட்டியல் நிலையை அணு முறையில் SUBMITTING எனக் கோருகிறது; இது ஒரே விலைப்பட்டியலை இரண்டு இணை கோரிக்கைகள் அனுப்புவதைத் தடுக்கிறது. இருப்பினும் தொலைந்த வலைப்பின்னல் பதிலின் முடிவை அந்த உள்ளூர் நிலை நிரூபிக்காது.

நேர வரம்பு முடிந்தால்:

1. அதே ஆவணத்தை உடனே மீண்டும் அனுப்பாதீர்கள்.
2. அனுப்பிய canonical JSON, hash, நேரம் மற்றும் உள்ளூர் நிலையைப் பாதுகாக்கவும்.
3. submissionUid அல்லது uuid கிடைத்ததா எனப் பார்க்கவும்.
4. uuid இருந்தால் ஆவண விவர வாசிப்பில் உண்மையான நிலையைப் பெறவும்.
5. அடையாளம் எதுவும் வரவில்லை என்றால் MyInvois செயல்பாட்டுப் பதிவுடன் ஒப்பிட்டு மனித ஆய்வுக்கு அனுப்பவும்.

“பதில் இல்லை” என்பது “LHDN பெறவில்லை” என்பதற்கான ஆதாரம் அல்ல.

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

1. கடமையை உறுதிசெய்யுங்கள்: LHDN கால அட்டவணை, தற்போதைய வழிகாட்டுதல் மற்றும் உங்கள் வருவாய் ஆதாரத்தை ஒரே இணக்கக் கோப்பில் வைத்திருங்கள்.
2. சட்ட நிறுவனத்தைப் பிரியுங்கள்: ஒவ்வொரு நிறுவனத்திற்கும் தனி TIN, பதிவு, வாடிக்கையாளர் தரவு மற்றும் MyInvois சான்றுகளை வைத்திருங்கள்.
3. வாடிக்கையாளர் master data-ஐ சுத்தப்படுத்துங்கள்: B2B சட்டப் பெயர், TIN மற்றும் பதிவு எண்ணை முன்கூட்டியே உறுதிப்படுத்துங்கள்.
4. பொருள்/சேவைப் பதிவைத் தயார் செய்யுங்கள்: விளக்கம், விலை, வரி வகை மற்றும் தொகை கணக்கீடு ஒரே முறையில் வருமாறு அமைக்கவும்.
5. Portal அல்லது API-ஐத் தேர்ந்தெடுங்கள்: தற்போதைய எண்ணிக்கையை மட்டும் அல்ல, அடுத்த பன்னிரண்டு மாத விற்பனை அளவையும் பணியாளர் நேரத்தையும் கருதுங்கள்.
6. Sandbox-இல் முயற்சி செய்யுங்கள்: உண்மையான production சமர்ப்பிப்புக்கு முன் பிரதிநிதித்துவமான B2B, B2C மற்றும் வரியுள்ள/வரியற்ற எடுத்துக்காட்டுகளைச் சோதியுங்கள்.
7. பொறுப்பாளரை நியமியுங்கள்: நிராகரிப்புகள், முடிவு தெரியாத சமர்ப்பிப்புகள் மற்றும் வாடிக்கையாளர் திருத்தக் கோரிக்கைகளை யார் கையாள்வார் என்பதை எழுதிவையுங்கள்.
8. ஆதாரத்தைப் பாதுகாக்குங்கள்: உள்ளூர் விலைப்பட்டியல், அனுப்பிய ஆவணம், LHDN அடையாளம் மற்றும் இறுதி நிலையை ஒன்றோடொன்று இணைக்கவும்.
9. அன்றாட கண்காணிப்பை அமைக்குங்கள்: SUBMITTING, PENDING அல்லது INVALID நிலையில் சிக்கிய ஆவணங்களுக்கு செயல்பாட்டு பட்டியல் வைத்திருங்கள்.
10. வழிகாட்டுதல் மாற்றத்தை மீளாய்வு செய்யுங்கள்: LHDN புதிய guideline பதிப்பை வெளியிடும் போதும் உங்கள் புலங்கள், பணிச்சுற்று மற்றும் பயிற்சிக் குறிப்புகளைப் புதுப்பிக்கவும்.

தமிழ் பயனர் இடைமுகம் நடைமுறையில் ஏன் முக்கியம்?

இணக்கப் பொறுப்பு உரிமையாளரிடம் இருந்தாலும், அன்றாடத் தரவை விற்பனைப் பணியாளர், நிர்வாகி அல்லது கணக்குப் பணியாளர் உள்ளிடலாம். திரை முழுவதும் அறிமுகமில்லாத மொழியில் இருந்தால் TIN, வாங்குபவர் வகை, வரி அல்லது சமர்ப்பிப்பு நிலையின் பொருள் தவறாகப் புரியலாம். மொழி வசதி ஒரு அலங்கார அம்சம் அல்ல; சரியான தரவு உள்ளீடு மற்றும் பிழை கையாளுதலுக்கான செயல்பாட்டுக் கட்டுப்பாடு.

GetPay தமிழ் அகராதியைத் தயாரிப்பின் சொந்த நிரல் தொகுப்பில் வைத்திருக்கிறது. வழிசெலுத்தல், விலைப்பட்டியல், LHDN MyInvois, வங்கி ஒப்புமை, சம்பளம், அறிக்கைகள் மற்றும் வலைப்பதிவு குறிச்சொற்கள் தமிழில் வழங்கப்படுகின்றன. இதனால் தமிழ் பேசும் தொழில்முனைவோர் தங்கள் பணிமொழியில் பணிபுரிய முடியும்; API-யில் செல்லும் அதிகாரப்பூர்வ புலப்பெயர்கள் மற்றும் குறியீடுகள் மாற்றமின்றி இருக்கும்.

தமிழ் இடைமுகம் சட்ட ஆலோசனைக்கு மாற்றாகாது. ஆனால் உரிமையாளர் “இந்த ஆவணம் அனுப்பப்பட்டதா?”, “LHDN அதைச் செல்லுபடியாக ஏற்றதா?”, “எந்த வாடிக்கையாளர் தகவல் குறைகிறது?” என்ற கேள்விகளைத் தெளிவாகக் கேட்டு, பதிலைத் திரையில் புரிந்துகொள்ள உதவுகிறது.

உரிமையாளரின் இறுதி ஆய்வுப் பட்டியல்

• என் நடைமுறை தொடக்கத் தீர்மானம் தற்போதைய LHDN அட்டவணை மற்றும் வழிகாட்டுதலில் ஆவணப்படுத்தப்பட்டுள்ளதா?
• சரியான சட்ட நிறுவனத்தின் TIN, பதிவு, முகவரி மற்றும் MyInvois சூழல் பயன்படுத்தப்படுகிறதா?
• B2B வாடிக்கையாளர் விவரங்கள் உறுதிப்படுத்தப்பட்டவையா; B2C மாற்று சரியான சூழலில் மட்டுமே பயன்படுத்தப்படுகிறதா?
• வரிகள், வரி ஒதுக்கீடு மற்றும் ஆவண மொத்தம் சென் அளவுக்கு ஒன்றோடொன்று பொருந்துகிறதா?
• hash மற்றும் Base64 ஒரே canonical JSON-இலிருந்து உருவாகிறதா?
• accepted, rejected, Submitted, Valid, Invalid மற்றும் Cancelled நிலைகளின் வேறுபாடு பணியாளர்களுக்குத் தெரியுமா?
• நேர வரம்பு முடிந்த சமர்ப்பிப்பு தானாக மீண்டும் அனுப்பப்படாமல் மனித ஆய்வுக்குச் செல்கிறதா?
• LHDN அடையாளம் மற்றும் இறுதி நிலை உள்ளூர் விலைப்பட்டியலுடன் இணைக்கப்பட்டுள்ளதா?

இந்த எட்டு கேள்விகளுக்கும் ஆதாரத்துடன் “ஆம்” என்று பதிலளிக்க முடிந்தால், உங்கள் e-Invois நடைமுறை வெறும் மென்பொருள் நிறுவலாக இல்லாமல் கட்டுப்படுத்தப்பட்ட வணிகச் செயல்முறையாக மாறத் தொடங்கியுள்ளது.