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.

Cash and Bank management > bank statement reconciliation > Bank transaction form

Here there is an option for reconcile, but no option for un-reconcile.

It is really helpful if the option can be added.

Belgian companies need to annually file a VAT list with all Belgian tax dutiful customers listed by enterprise number, their turnover and the total VAT amount charged. The report is to be generated as an xml file and has to uploaded to the Intervat website.

A report is available for this in D365FO (menu Tax, report 'invoice turnover report - Belgium') and an ER format (Invoice turnover report (BE)). This works fine in legal entities with just one VAT number.

When using multiple VAT registrations there is no option to link the report to just one of the company's registration ID's as you can do with the VAT declaration, the EU sales list and the Intrastat declaration.

The result is that in the annual listing all turnover to Belgian customers is included, not limited to the sales done from the company's Belgian VAT number.

The Belgian annual VAT listing is a legally required declaration, just like the monthly declaration, EU sales list and Intrastat, therefor it should be supported by multi VAT as well.

It happens that Vendors do ship goods/services from different countries as they might have several warehouses in Europe and depends where the service/goods are vailable from.

This means that when the Invoice is received in D365, (no matther the PO created), different sales tax group might apply depending where the goods came from, Domestic, withing EU, etc, so this should also have an impact on the VAT applied.

It is supposed to be handled with Delivery terms, which does not work for the Vendor Invoices as it does with Customer Invoices.

It should be possible, when the Invoice it is received, to change the Delivery address of the Vendor and this address should have an impact on changing the Sales Tax group automatically.

Could we release a new report which like AP ageing report or Accrued purchases excluding GST where there is a cut-off date. such as the AP invoice registered in March, then approved in May. but the user needs to print it in April, that's mean they need to print "Invoices not approved" report with backed date.

The detailed from end user required. as below. Customer uses AP register and approval for AP invoices.

There is GL code that that holds the balance for invoices that are registered but not approved but requires to reconcile with the AP submodule. There is an existing report under the AP module "Invoices not approved". this report prints only the current invoices not approved. Auditor is requesting one report to match the March TB as at 31st march but the existing report cannot print back dated. 

We need something like the AP ageing report or Accrued purchases excluding GST where there is a cut-off date.

Create a parameter that if a royalty is already included in a contract, it does not lead to another one.

This is important because if a royalty is generated from a paid invoice, but then left open and re-settled in a different period, that royalty is generated again.

It's possible to use custom code in the reports in a Tier 1 environment, however, in the Tier 2+ environments, using the same custom code you receive the following error:

"The report server has RDLSandboxing enabled and the report contains custom code. Remove the code element from the report definition"

As workaround is possible to remove the code and use datasets, however, it should be very interesting to find a way to allow this custom code in the future.

According to Mexico government requirements, for Electronic Invoice CFDI 4.0, the attribute / tag Unit Price (ValorUnitario) can contain from zero to six decimal places.

It should be desirable to add a parameter to let the user specify the number of decimal places to be printed / shown in XML file. Any value from 0 to six decimal places.

So far, this attribute is printed with 6 decimal places.

See for reference the following issues:

747313 MEXICO_CFDI 40 XML is Rejected due rounding issues in field ValorUnitario

675641 MEXICO_CFDI 40 Attribute ValorUnitario should use 6 decimals

When using Tax Calculation Service, best practice is to maintain customers' and vendors' VAT numbers as Registration ID's on address records, however the tax exempt number on the master is also required, when posting in journals.

It would be great when creating VAT numbers on primary business adresses with purpose "business" that the VAT ID of that adresse would be defaulted to the tax exempt number on the master.

"The original card payment details cannot be retrieved" error:

1. A return order gets processed but fails at the end of invoicing due to incorrect address while posting fiscal document.

2. Payment gets refunded in Adyen but the whole transaction gets rolled back.

3. For Brasil InvoiceId number sequence is the same as Nota fiscal number sequence and it has to be continuous. 

4. During next posting system tries to find out whether there's anything to be refunded and there's a condition that invoice id on CreditCardAuthTrans should be different from the current invoice Id. In our case it's the same as number sequence is continuous so it doesn't find already refunded payment which means that there's something to be refunded. In the comment it states "Failed invoicing will rollback journal" which is true but with continuous number sequence and no other invoices in the meantime a new invoice will get the same InvoiceId and the condition won't be met - there will be amount returned to be processed. Method: private McrCustPaym_CreditCard.getUnprocessedRefundAmount(Amount _amountToRefund, SalesTable _salesTable) (attached picture)

5. If previous payment not found then it tries to refund order amount again leading to the error.

6. I made a test and changing Nota fiscal number sequence to non-continuous fixed the problem.