Dynamics 365 Finance

Context: 

• Some purchases at GC are captured as standing orders (e.g. 10,000 Qty / 1 Unit Price) as the amount invoice is unknown at the time of PO creation.  

• Invoices for these orders come in as normal invoices (e.g. 1 Qty / 950 Unit Price) 

• Since the lines do not match, invoice capture needs to be trained to ignore them and process the invoice as a header only invoice. 

• Header invoices only contain information for the total amount, if there are multiple receipts available, the automation cannot tell which receipt is the right receipt. (Receipts only capture qty information and do not contain price values) 

Requirement: 

• Need to be able to map the product receipt in invoice capture to the product receipt field in D365, so it allows invoices to find the right receipt to match to.  

• Users can capture the product receipt number as the invoice number and in invoice capture. 

• Users can teach the model to capture the invoice number in the new product receipt field. 

• We can potentially utilize existing “Product Receipt” field from Invoice Capture side.

Customers have an additional delivery address in an other EU-Country, with a separate Tax exempt number.

When we create or edit a sales order and choose this delivery address, the Tax exempt number has also automatically be changed.

This must depend on the Delivery Term where we can select the source for the "Sales Tax address" and the account receivable parameter (Updates - Update Order lines)

Proposal:

Introduce a new feature allowing businesses to seamlessly include business documents as embedded attachments within e-Invoice files.

Current behavior:

When activating "eInvoice attachment" for a customer in D365FO, a copy of the invoice layout in PDF format from SSRS is embedded in the e-invoice file. However, there is an issue when using business documents instead of SSRS, as attaching the invoice file in PDF format is inaccurately executed.

<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="FreeTextInvoice.Report.pdf">JVBERi0xLjcNCjIgMC</cbc:EmbeddedDocumentBinaryObject>

Proposed Solution:

Upon activating "eInvoice attachment" on the customer card, the system will use the Report format specified in the print management setup and ER destination setup. It will convert the document into PDF, if "Convert to pdf" is activated on Electronic reporting destination, attach it to the invoice journal, and seamlessly embed it in the e-invoice file as an embedded document. This enhancement allows customers to include business documents designed in Excel or Word as attachments to e-Invoices, providing a more versatile and accurate solution.

There are currently few options available under bank reconciliation rules to set for finding and sorting bank transactions. Since each bank have its own way to produce statements and provide references in the statement, it is found that the current available fields are not enough to set up rules and would lead to do customer a manual reconciliation, which involves much human efforts and increase client cost to run the process.

It would be beneficial if bank reconciliation rules have the followings fields for the D365 bank transaction to setup additional criteria and grouping.

Voucher: A voucher on the customer/vendor payment line is mostly unique and can help to sort out the transactions easily.

Document number: A document number available on the customer/vendor payment line (not the deposit slip document number.

Method of payment and Payment specification, Category purpose, Charge bearer, Local instrument, Service level -

Methods of payment, payment specification, and various purpose selected on the journal lines could.

Cheque number - Cheque number on journal line.

Reason code - Reason code selected on journal line

FINANCIAL DIMENSIONS - financial dimension selected on journal line.

These fields are most commonly used for vendor/customer payment journal. Currently these are not available in additional criteria for bank reconciliation rules. With having these fields, it would be more easy to sort out the bank transaction and thus enables the bank transactions to match transaction with bank statement transactions. It reduce the client manual activity to find out the transactions manually.

Also, D365 should provide option to auto generate two field value in vendor payment journal / customer payment journal based on journal names and number sequence.

The field basis on the journal name will allow to fill a default fixed value on vendor payment journal / customer payment journal. This will help in the group condition setup, where a bank provide one line amount for multiple transactions.

The field basis on number sequence allow to have a value in vendor/customer payment journal which can be mapped to the file sent to bank for payment and thus getting the same value back in bank statement.

System is not calculating Prepaid expense amount correctly via Accrual schemes based on Number of days. A voucher is entered in the general journal on 1/17/2022 and then assigned the accrual schema. The result is that the system ends the calculations with date of 12/31/2022. The expectation is that the system would perform the calculations through 1/16/2023, utilizing the 365 days.

The customer is sending the R-2010 event tax obligation, but the system is sending data from different months in the same file, causing the record of this obligation to be rejected.

Error: MS1041, quando temos notas fiscais com data de emissão com períodos anteriores dentro do registro temos rejeição. 

Issue:

You have multiple leases for the same supplier (leasing company). But when you generate the journal for payment schedule for multiple asset leases, you get two separate journals with one journal / one line.

Expectation:

The option to be able to get one journal with multiple lines for the same supplier for the payments.

To have 1 journal with multiple lines for all the lease contracts which are related to the same supplier. This is a standard scenario in the leasing business. For example a company leases 20 cars with one leasing company. The leasing company will send only one invoice in the month and not 20 different invoices in spite of the fact there are 20 leased vehicles in the system.

Our customers are requesting the ability to configure notifications in Invoice Capture, such as emails or alerts, that can be sent to AP users. This would allow them to follow up on invoices with errors that have not been transferred to D365F&O.

Notifications would be extremely helpful, as they would eliminate the need for users to log into Invoice Capture or the workspace, which can sometimes be limiting.

Since multiple customers have requested this feature and we believe it would greatly benefit them, we would like you to consider this improvement for future versions

We are using reporting three duplicate of organization hierarchy.

We have two legal entities and many departments at dimension level. 

We are trying to consolidate financial statement with transaction level through reporting tree using, department financial dimensions, but financial reporter do generate consolidation report at financial, account level not at transaction level.

Even in consolidation at reporting tree, one issue we face again and again in Financial Reporter is consolidation across a large number of entities. We have three entities using D365 finance that will have issues when their report trees need a row for each entity and dimension combination. For example; we have 30 department's dimension values want a consolidated report view for their 3 entities . To make matters worse, they also want a drill-down by the department. While a tree becomes very big and almost unmanageable, because combinations must be created for each entity as a separate row (level) in the tree. 

Suggestion: We have @any in reporting tree which supported to generate consolidate report at financial details level but coming to account detail level, the consolidation would generate with three different legal entities level and transaction level we have to drill with each entity wise, If @any function is consolidating financial at same level, we drill down can see consolidated transaction for all legal entities with financial dimension might be very useful .

It basically instructs the reporting tree to use @any generating the report and requires to generate consolidation at transaction details level.