14/5/2026

Bug Fixes

#1 [Self Billed][Direct Upload] - Bugs: Reinvestigate Non-consol self-billed invoice stuck in Draft on the second attempt for submission

Overview

This update improves the handling of self-billed invoices uploaded via CSV.

Previously, if a non-consolidated self-billed invoice failed during submission and users re-uploaded the corrected invoice, the invoice could remain stuck in Draft status and would not be resubmitted automatically.

With this enhancement, corrected invoices will now automatically move back into the processing queue for resubmission, reducing manual intervention and improving processing reliability.

1. What Has Changed
1. Automatic Reprocessing for Corrected Invoices

The system can now detect previously failed or draft invoices during CSV upload.

When users re-upload corrected invoice data:

- The invoice status will automatically be updated to Queue
- The system will automatically pick it up again for submission processing

This removes the need for manual status updates or re-triggering.

2. Reset of Previous Submission Information

To avoid conflicts from earlier failed submissions, the system now automatically clears old submission-related information before retrying.
This ensures the invoice is treated as a fresh submission attempt.

3. Improved Validation During CSV Upload

Additional validation has been added during CSV processing to ensure:

- Buyer information is properly validated
- Supplier information is properly validated
- Multi-line invoices are processed more consistently

This helps improve overall data accuracy and reduces submission issues.

2. Where This Is Reflected in the Portal
CSV Invoice Upload Process

Users uploading corrected self-billed invoices via CSV will now experience:
- Automatic reprocessing of previously failed invoices
- Improved validation checks during upload
- Reduced cases of invoices remaining stuck in Draft status

3. Impact
- Reduced manual intervention for failed invoice resubmissions
- Faster recovery for corrected invoices

#2 [Production] Consol invoice issue date got changed due to the 72 hours limitation bypass feature

Overview

This update improves how the system handles invoice dates during submission, especially for consolidated invoices and Request E-Invoice processes.

Previously, the system could automatically replace the original invoice date with the submission date due to the 72-hour validation bypass logic. This behaviour was intended for standard invoices but unintentionally affected consolidated documents as well.

With this enhancement, consolidated invoices will now retain their original invoice dates correctly.

1. What Has Changed
1. Improved Invoice Date Handling

The system now applies automatic invoice date adjustment only for standard invoices.
For:
- Consolidated invoices
- Request E-Invoice processes

The original invoice date will now remain unchanged.

2. Original Invoice Date Is Now Preserved

When the system performs a submission date override for eligible invoices, the original invoice date will still be stored internally for reference and audit purposes.
This improves traceability and data accuracy.

3. Improved Consistency Across Submission Methods

The enhancement has been applied across multiple submission channels, including:
- CSV uploads
- SFTP integrations
- Manual submissions
- Automated background processing

This ensures consistent behaviour regardless of how invoices are submitted.

2. Where This Is Reflected in the Portal
Request E-Invoice Module

Users will notice:

- Original invoice dates are preserved correctly
- Reduced unexpected invoice date changes
- Consolidation Module

Consolidated invoices will now maintain the intended invoice dates during submission and processing.

Integration Flows (CSV / SFTP)

Backend processing for uploaded and integrated invoices now follows the corrected date-handling logic consistently.

3. Impact
1. Standard invoices will continue following the existing 72-hour validation bypass process
2. Consolidated invoices are now excluded from automatic date override logic
3. Prevents unintended invoice date changes for consolidated documents
4. Improves compliance and data accuracy

#3 [Bugs-Perm Fix] [API] [Customer/Supplier] Logic Mismatch in is_foreign_company Validation During API Creation

Overview

This update improves how the system identifies Malaysian and foreign companies.

Previously, some Malaysian companies were incorrectly marked as foreign companies due to inconsistent data values. This could cause incorrect behaviour in certain validation and processing flows.

With this enhancement, the system now better recognizes Malaysian companies even when older or inconsistent values exist in the data.

1. What Has Changed
Improved Company Classification Logic

The system logic has been updated to better detect companies that should be classified as Malaysian companies.

Additional validation has been added to:
- Support older existing data values
- Correctly recognize companies marked as “Malaysia”
- Prevent Malaysian companies from being incorrectly treated as foreign companies

This helps maintain more accurate company information and processing behaviour.

2. Where This Is Reflected
Company Profile & Invoice Processing

Users may notice more accurate behaviour in flows that depend on company classification, including:
- Validation processes
- Invoice-related processing
- Country-based logic and checks

This improvement works in the background and does not introduce any UI changes.

3. Impact
- Improves data consistency
- Existing Malaysian companies with inconsistent values will now continue to work correctly
- No manual action is required from users

#4 [Ticket: 59829: JomeInvoice Response to Supply Chain Attack Due to Tampering of Software Component "axios"

Overview

This update is related to a security review triggered by reported Axios vulnerabilities (CVEs flagged by SHAPM HQ).

After investigation, it was confirmed that the JomeInvoice system is not exposed to these vulnerabilities. The affected CVEs apply to specific server-side Node.js usage patterns, which are not used in our system.

Even though there is no active security risk, we are upgrading the Axios library as a precaution and to ensure compliance with security scanning tools.

1. What Has Changed
1. Security Review Completed

A full assessment was performed on how Axios is used in the system. The findings confirmed:
- The backend is built using PHP/Laravel (not Node.js)
- Axios is only used on the frontend for internal API calls
- All API calls are restricted to our own system endpoints

2. Additional Protection Confirmed

The system already includes safeguards that prevent the reported vulnerabilities from being exploited:
- Requests only go to internal application endpoints
- CSRF protection is enabled for all requests
- Requests require valid session-based security tokens

3. Axios Library Upgrade

The Axios dependency has been upgraded from version 1.6.8 to 1.15.0 as a preventive measure and to clear security scanner warnings.

2. Where This Is Reflected in the Portal
- Frontend Application (Web Portal)
- This update applies to the web interface where Axios is used for API communication.
- Users will not see any visible changes in the UI or workflow.

3. Impact
- Ensures system is aligned with security best practices
- Removes false-positive vulnerability flags from security scanners
- Strengthens long-term maintenance of frontend dependencies
- Confirms system is not exposed to reported Axios CVEs