• "Customer balance list report" and "Customer auditor report" with wrong main account

    The reports "Customer balance list" (Credit and collections > Inquiries and reports > Customers > Customer balance list report) and "Customer auditor report" (Accounts receivable > Inquiries and reports > Customers > Customer auditor report) display the wrong main account, if the customer Group was changed, so the customer balance is shown under the wrong main account. The same issue arises with ‘vendor balance list’ too.
  • Withholding tax amounts calculation on Purchase Invoice

    The need is to calculate the withholding tax amounts during the Purchase invoice process, without the posting on withholding tax accounts. The reasons for this requirement are: 1) Not all the items/main accounts are to be included in the calculation of the withholding tax base amount. 2) During the invoice phase, the people who is posting the invoice is aware of the correct withholding tax amount. 3) The person who posts the invoice is different from the one who pays the invoice. 4) Starting from 2019, vendor invoices are received through electronic .xml document. This calculated amount should be inherited during the payment process (invoice settlement), for the following reasons: 5) The person who posts the payment is different from the one who posts the invoice. 6) The person who posts the payment does not have the invoice pdf/xml. 7) In 95% of the cases, the D365 calculation is not coherent with the archived invoice.
  • [Italy] Fiscal Journal - Calculation of number of transactions for stamp duty

    For Italian requirements (D.L. n.34 del 2019 - "Decreto crescita"), the Fiscal Journal may be kept in two different ways: 1) In paper form: the stamp duty is paid on the number of pages of the book by physically affixing the stamp mark 2) On an electronic medium: the stamp duty is paid for every 2500 registrations or fractions of them always in the amount of 16 euro (or 32 euro) In order to respond to the second scenario requirement, there is a need to calculate the number of transactions (vouchers) within the fiscal year for which the fiscal journal is printed on electronic medium.
  • Possibility to change Number sequence group on Pending vendor invoices

    The user who checks and posts the pending vendor invoice should have the possibility to change the Number sequence group on the header of the pending invoice. At the moment, the user must go back to the purchase order, change that information, confirm again the order and generate again the invoice. But because of segregation issue, often the user who checks and posts the invoice (administration office) do not have the permission to modify the purchase orders, moreover this information (number sequence group) is typically in charge of the administration office. Moreover, in Italian companies, the number sequence group vehicles the Sales tax book section where the invoice must be posted for VAT declaration purpose. So it's important to be able to change the NSG on the pending invoice.
  • Payment Reference on Advanced ledger settlement function

    At the moment, the field “payment reference” is available in the form Ledger settlement only if the “Advanced ledger settlement” function is off. Once you activate the “Advanced ledger settlement” functionality, the field “Payment reference” is not available anymore. The functionality is basically the same, so it should be important to have the “payment reference” both in basic and advanced ledger settlement functionality, considering that: 1) the advanced ledger settlement should improve the basic ledger settlement function and not to get worse. 2) in a real environment, you have largely used the “Payment reference” fields; this field is available on Ledger Journals, and you have used a lot in all your previously posted transactions. 3) “Payment reference” is used a lot by all the customers for reconciliation purpose. 4) Both the functionalities, basic and advanced, rely on the same table General journal account entry, where there is the field “payment reference”. 5) Both the functionalities are launched from the same menu item (GL > Periodic tasks > Ledger settlements) It could be a good idea, add the “Payment reference” field on the “Ledger advanced settlement” table and form.
  • Entity for RetailTransactionTenderDeclarationTrans Table

    In order to import in D365 Retail Tender Declaration transactions from external systems, through Data management, it's needed to have the related entity. This entity at the moment is not available from the entities list.
  • Income/expense inquiry in retail Statement

    As per the Sales transactions and Payment transactions, there is a need to have an Income/expense inquiry in order to check the incomes or expenses included in the specific Statement. At the moment, it is not easy and clear for the customer to verify the list on incomes and expenses included in the specific statement.
  • Financial dimensions on Income/expense accounts

    The customers require to have the financial dimensions tab in the Income/expense account form, because, such as for the payment methods and the cards ID, also for the income/expense there is the need to manage the financial dimensions.