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.

in the current implementation of the ER configuration of the electronic invoice import 'Vendor invoice Mapping to destination', when an item cannot be identified by the external item number, the mapping uses an item called 'DEFAULT_ITEM' as a replacement.

We would like very much, that this Item can be replaced by a default procurement category since the options to assign the correct ledger account are way more comfortable using a procurement category instead of an item.

I would kindly note that fields in table CustParameters are not mapped in Data entity CustomerParametersEntity so we are unable to export/import fields via standard function "copy to legal entity", nor by export/import project in Data management.

We would appreciate that fields, which are mandatory to be used in several countries can be used as they are supposed to be used, especially in project phases such as migration.

The list of the missing fields:

MandatoryVATNum, AdvanceInvoiceCreditCorrection_W, AdvanceInvoiceReversalCorrection_W, InvoiceIdEditing_W, PercentCustomersPerBatchTask, TaxGroup_RU, TaxItemGroup_RU

Hi,

To comply with Indian legislation, it is mandatory to have a daily backup of the Indian company data on a server which is physically located in India.

Since this is part of Indian legislation and Indian company audit, the idea is that Microsoft provides such a functionality.

As a finance ERP it would be nice and preferred, they provide all parts of financial audits (or can comply with Indian legislation). That way the Indian company data can remain inside MS (architectural) boundaries.

This can be helpful for many customers since the MS process would be audited and not the company individual processes to comply to the Indian legislation.

This should also be possible for companies with 250 legal entities, where only 1 legal entity is India based. So only the data of the Indian legal entities can/should be saved on the server which is physically located in India.

Many thanks!

Currently an applied prepayment amount is not taken into account, when an imported invoice is submitted to workflow and the "Require the calculated totals to equal the imported totals for workflow submission" parameter is set to yes in accounts payable parameters (tab invoice -> invoice workflow)

For invoices an prepayment is applied to the calculated invoice amount is reduce by the prepayment amount. Based on that the calculated total differs from the imported total. For those invoices the functionality should also take the applied prepayment totals into account. Otherwise those invoices are blocked for workflow submission and the parameter must be deactivated each time to process invoices.

Idea on sales order invoice summary control

Multiple sales orders can be summarized on one invoice using the Summary update for parameter on the Posting invoice form:

In cases where a lot of sales orders are created for a customer which are delivered, this could result in an invoice with a large amount of lines.

Some customers want to avoid having such large invoices, but still want to generate these invoices in batch using the “Late selection” functionality, instead of splitting the sales orders using the query and creating multiple batch jobs manually.

The idea is to add an additional parameter to the Posting invoice form where users can specify the maximum number of invoice lines in case sales orders are grouped on one invoice.

This functionality should keep track of the amount of lines that are grouped under a single sales order header (and one invoice). Once the maximum specified number of lines is reached, the current sales order that was being added should be added in total (to avoid splitting one sales order over two invoices), and the next sales order will become the new sales order header where the next sales orders will be grouped underneath until the specified maximum of lines is reached, or until all selected sales orders are allocated under a sales order header.

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.

Hi Microsoft,

in some cases, the business has many financial dimensions and their values. It is not unusual, that the accounting wants to exclude only one dimension value from posting on specific account. e.g. on Account Revenue EU, there should be no posting with dimension for Inland.

For now, you have to specify all allowed values for the accounts in the structure. If there is any new value created, you need to add this into the structure firstly.

With the possibility to exclude values, it will be easier to maintain Account structures, because all newly added values will be automatically allowed.

K.

Today Dynamics F&O only supports Type G - Daily Ledger and we need it to serve other Indicators  = R, A, B and Z.

R - Journal with Summary Bookkeeping (with auxiliary bookkeeping).

A - Journal Book Auxiliary to the Journal with Summary Bookkeeping.

B - Balance Sheet Book Daily and Balance Sheets.

Z - Auxiliary General Ledger (Accounting Book Auxiliary according to layout defined in records I500 to I555

Follow the link to the SPED ECD manual, check page 101 - record I010

http://sped.rfb.gov.br/estatico/A8/AA5DF23EBFCB8A669E3EA36904E0719A5DAD42/Manual_de_Orienta%c3%a7%c3%a3o_da_ECD_Leiaute_9_Atualiza%c3%a7%c3%a3o_Nov_2024.pdf