Description

Background

Currently, the Malaysian E-Invoicing implementation in Dynamics 365 F&O only supports customer invoice journals, with no standard functionality to submit other types of General Journals as E-Invoices to the Malaysian Tax Authority. This represents a significant gap affecting many businesses across various industries.

Requested Enhancement

We request Microsoft to develop comprehensive functionality that supports:

1. E-Invoice generation and submission for ALL types of General Journals in D365 F&O
2. Support for journals originating from various sources, including but not limited to:

• External systems (POS, banking, third-party applications)
• Manually entered journals
• Recurring journals
• Allocation journals

1. Proper mapping of all journal transaction data to meet Malaysian tax authority requirements
2. Complete validation and error handling for all journal types

Business Impact

This enhancement is critical because:

• The current limitation only supporting customer invoice journals is insufficient for comprehensive compliance
• Businesses must report various types of transactions to Malaysian tax authorities, not just customer invoices
• Without this functionality, organizations face costly custom development or risk non-compliance
• Manual processing of excluded journal types increases error risk and operational costs
• Many businesses interface with external systems and rely on various journal types for their operations

Urgency

This is a significant issue affecting numerous businesses operating in Malaysia. As e-invoicing requirements become mandatory, the absence of support for all journal types creates a substantial compliance risk and operational burden for companies across all sectors.

When creating an automation process for ledger settlements, users can define criteria to automatically match general ledger debit and credit transactions. The main account and posting layer options are required matching criteria. Additionally, financial dimensions and financial tags can be included as optional matching criteria.

However, there is currently no option to exclude transactions that lack values in Financial dimensions or Financial tags. As a result, transactions with empty values are being incorrectly matched and settled.

This proposal suggests adding the ability to exclude blank values in Financial dimensions and Financial tags from the matching process.

Ability to Import and automate the inbound XML(Invoice) in Dynamics 365 Invoice Capture solution.

Necessity for this?

1. It is recommended that business users monitor inbound e-invoices in D365 Finance

2. While the information in the XML (Invoice) is sufficient for approval by business users, it should be presented in a more visually appealing format, such as a PDF

3. The majority of European Union customers need above mentioned points as Out-of-the-Box feature in Invoice capture

4. A country like Italy considers Inbound XML (invoice) as "legal" invoice

These are few missing components in the out-of-the-box solution:

The current invoice capture solution lacks this functionality

1. A custom solution is needed to import and view the inbound invoices

2. Customer need OOB feature instead of relying on ISV solutions such as Exflow, for an invoice approval process

We request this functionality to be available in Invoice capture solution, to make it easier for business users to view the inbound invoices and carry out their day-to-day activities.

Regards,

Rakesh Darge

The following topics should be automatically setup in the Prepayment Invoice of the Sales Orders:

1. Customer Posting Profile which is setup in the accounts Receivable Parameter (Ledger and Sales Tax - Posting profile with prepayment journals) - automatically put in the header of the prepayment invoice
2. Item sales tax group from the sales category -automatically put in the lines of the prepayment invoice
3. sales tax group from the customer account --automatically put in the header of the prepayment invoice

When using "Generate voucher" in Advanced bank reconciliation, it asked user to define description for the generated transaction. However, the defined description is only applied to one voucher transaction with posting type of "Bank statement". And the other voucher transaction with posting type of "Bank" still has the auto description as "Bank statement line post table". The defined description should be applied to both voucher transactions. This causes a difficulty in managing the financial database of end users.

When the customer has more than one CT-e for different Vendors within the month and for each situation, a different Credit base source is used.

Due to this scenario, when records D101 and D105 are generated, in the 5th field called NAT_BC_CRED, only the first information in the Credit base source field is generated.

e.g Vendor BRMF-000003

|D100|0|1|2_BRMF-000003_58871657000104|57|00|057||572110001|35231058871657000104570575721100017533544564 |21102023|2110202 3|0||3300,00|0,00|0 |3300,00|3300,00|594,00|||5.1.1.3.08|

|D101|2|3300,00|56|13|3300,00|1,6500|54,45|5.1.1.3.08|

|D105|2|3300,00|56|13|3300,00|7,6000|250,80|5.1.1.3.08|

e.g Vendor BRMF-000002

|D100|0|1|2_BRMF-000002_11613525000119 |57|00|057||231002357|35231011613525000119570572310023570283340309|21102023|21102023|0||2150,00|0,00 |0 |2150,00|2150,00|387,00|||5.1.1.3.08|

|D101|9|2150,00|56|13|2150,00|1,6500|35,48|5.1.1.3.08|

|D105|9|2150,00|56|13|2150,00|7,6000|163,40|5.1.1.3.08|

We have a business scenario where we receive credit notes from vendors for prepayments which we will never pay, or which were paid partially. At the time we receive the credit note, the prepayment invoice is already posted through the PO. However, if the credit note is posted and settled with the prepayment invoice, this prepayment amount is shown as available in the Open prepayments form and it's available to apply invoices to it, even though the payment was never made and the prepayment invoice was canceled via the received credit note from vendor.

We would like Microsoft to consider and enable this business scenario because the current functionality enables wrong postings and invoice applications for prepayments which never happened.

Quando criamos um produto, ao exportar no arquivo texto o registro 0200 está considerando o campo SEARCH NAME ou INVÉS do campo PRODUCT NAME.

Exemplo:

Item number = BRMF010

Search name = BRMF010

Product name = Caixa acústica padrão 100W

Arquivo texto gerado registro 0200

|0200|BRMF010|BRMF010|||pcs|04|85182200||85||12,00||

Deveria carregar na 3 coluna = Caixa acustica padrão 100W.

Title

Support for Vendor-Related Entries in Malaysian E-Invoicing System for D365 F&O

Description

Background

Currently, the Malaysian e-invoicing implementation in Dynamics 365 Finance and Operations provides limited functionality for linking invoices to their source documents. As confirmed by Microsoft Support, the system does not support linking e-invoices to employee or vendor-related entries.

Requested Enhancement

We request Microsoft to extend the Malaysian e-invoicing globalization features in D365 F&O to include:

1. Full traceability between e-invoices and vendor-related transactions
2. Support for linking vendor entries to e-invoices generated in the system
3. Comprehensive audit trail functionality for vendor transactions in the e-invoicing workflow

Business Impact

This enhancement would:

• Improve compliance with Malaysian tax regulations
• Streamline audit processes for finance teams
• Reduce manual reconciliation work
• Enhance reporting capabilities for vendor-related transactions

Urgency

As Malaysian e-invoicing requirements continue to evolve, this functionality is becoming increasingly critical for businesses operating in the region.