1.28.47 Release

31/3/2026

Bug-Fixes

#1 Missing MSIC code 47520 in SME & UAT Environment (SME)
Overview

We have added the missing MSIC code 47520 - Retail sale of construction materials, hardware, paints and glass into the system. This ensures users can correctly select the appropriate business classification in the SME environment.

  1. What Has Changed
    MSIC Code Added:
    The MSIC code 47520 - Retail sale of construction materials, hardware, paints and glass has been added to the system.
    Users can now select this code where applicable during setup or configuration.

  2. Where This Is Reflected in the Portal
    This update applies to:
    - Business / Company Information (MSIC Code Selection)


    Environments updated:
    - SME UAT
    - UAT
    - SME Production


    Users will now:
    - Be able to find and select MSIC code 47520 from the available list

  3. Impact
    Ensures completeness of MSIC code listing in SME environment
    Allows affected users to correctly classify their business activity
    Prevents workaround or incorrect code selection



#2 Buyer TIN Not Updating in Invoice Resubmission

Overview
We have resolved an issue where resubmitted invoices were sending outdated buyer TIN information to LHDN. The system now ensures that the latest buyer data is used when invoices are resubmitted.

1. What Has Changed
Buyer TIN Sync Logic Corrected for Resubmissions:

  • The system has been updated to always retrieve the latest buyer TIN from the database during invoice resubmission.

  • When a buyer’s TIN is updated in the Customer Listing, the system will now use the updated TIN in the JSON payload sent to LHDN.

  • This ensures that corrected data is properly reflected during resubmission.

Previously, the system continued to send the old TIN value even after it was updated, causing repeated rejections from LHDN. This issue has been fixed.

2. Where This Is Reflected in the Portal
This fix applies to invoice resubmission flows, including:

  • SFTP submissions

  • Manual resubmissions

When users:
Update buyer information (e.g., TIN), and
Resubmit the invoice

The system will now:
Use the latest buyer data from the database in the submission payload

3. Impact
Prevents repeated submission failures due to outdated buyer information, improves data accuracy in LHDN submissions, and ensures a smoother resubmission process for users.

#3 Buyer Validation Enhancement for Duplicate Profile ID Handling (API Invoice Submission)

Overview

  • We have resolved an issue where multiple buyer records sharing the same Profile ID could lead to incorrect buyer information being submitted to LHDN and reflected in the generated PDF invoice.

  • The system has been enhanced to improve buyer validation during API invoice submission, ensuring the correct buyer data from the payload is consistently used.

What Has Changed

  • The buyer identification logic has been strengthened with a strict sequential validation process to ensure accurate matching of buyer records.

  • The system now validates using Buyer Email, Company Name, Business Registration Number (BRN), and Tax Identification Number (TIN).

  • If a unique buyer cannot be identified after these checks, the invoice will be moved to an Error status with the message: “A duplicate buyer information found in our system. Please verify the data and contact JomeInvoice Support for further action.”

  • In such cases, a Slack alert will also be triggered to notify the CS team.

  • The CS team will then coordinate with the client to obtain correct buyer details.

  • If required, Tech will create a new buyer profile based on existing data to allow processing to continue.

Where This Is Reflected in the Portal

  • This update applies to the Sales API invoice submission flow.

  • During API submission, the system will validate buyer records associated with the same Profile ID and block processing when duplicates are detected.

  • Only validated buyer records will proceed.

  • The buyer information from the payload will be used for both LHDN submission and PDF invoice generation.

Impact

  • Prevents incorrect buyer submissions to LHDN.

  • Ensures accurate data is reflected in PDF invoices.

  • Enhances overall buyer data validation.

  • Improves system reliability by preventing duplicate buyer conflicts during invoice processing.

#4 Buyer Validation Enhancement for Duplicate Profile ID Handling (API Invoice Submission)


Overview

  • We have resolved an issue where multiple buyer records sharing the same Profile ID could result in incorrect buyer information being submitted to LHDN and reflected in the generated PDF invoice.

  • The system has been enhanced to strengthen buyer validation during invoice submission, ensuring the correct buyer information from the invoice payload is consistently used during processing.

What Has Changed

  • The buyer identification process has been improved with a stricter sequential validation logic to ensure accurate matching of buyer records during invoice processing.

  • The system now evaluates Buyer Email, Company Name, Business Registration Number (BRN), and Tax Identification Number (TIN) in sequence.

  • If a unique buyer cannot be identified after these validations, the invoice will automatically be moved to an Error status with the message: “A duplicate buyer information found in our system. Please verify the data and contact JomeInvoice Support for further action.”

  • At the same time, a Slack alert will be triggered to notify the Customer Support team for immediate investigation.

  • CS will then coordinate with the client to obtain the correct buyer details.

  • If required, Tech will create a new buyer profile based on existing information to allow processing to continue.

Where This Is Reflected in the Portal

  • This update applies to the Sales API invoice submission flow.

  • During API submission, the system will validate buyer records associated with the same Profile ID and prevent processing when duplicate records are detected.

  • Only validated buyer records will proceed.

  • The buyer information provided in the invoice payload will be used for both LHDN submission and PDF invoice generation.

Impact

  • Prevents incorrect buyer submissions to LHDN.

  • Ensures accurate buyer information is reflected in PDF invoices.

  • Improves overall data validation during invoice processing.

  • Strengthens system reliability by reducing risks caused by duplicate buyer records.