Annaik Boudin Microsoft SR SUPPORT ENG EMEA

Belgium has posting journal. Each posting journal can be linked to a journal type (purchase, sales, financial or other).

This is a legal requirement to have these reports printed.

But it is not possible to print purchase journal by journal type purchase. Journal code should be selected and print one by one.

This can be painful if customer has lot of journals to be printed.

Belgium journal should have option to print by journal type or select several journals code.

user may receive information that fixed asset should be disposed after some times.

Depreciation have been posted and fiscal periods are closed for transaction.

Nonetheless fixed asset disposal should be considered on correct date even if posting date is different.

There is no way to differentiate posting date from disposal date.

example

Fixed asset depreciations have been run up to January 2023.

in January, user has information that fixed asset has been scrap in October 2022.

But periods are closed.

Fixed asset disposal should be posted in January 2023.

Depreciation for January 2023, December 2022, November and prorate October should be reversed.

Disposal amount should be calculated based on October date but posted in January.

System should be able to manage disposal date independently of posting date.

For some business reason, posting layer is used to post sales tax transactions.

This possibility allows customer to track correction via posting layer.

But when sales tax payment is generated, the voucher is posted on Current layer, whatever posting layer used on sales tax transactions.

it is expected posting layer to follow initial transaction

• sales tax payment
• settlement transactions
• ....

Fixed asset acquisition is done through purchase order. But several invoices should be included in acquisition. each invoice has a specific quantity acquired.

Fixed asset quantity is only updated with first invoice while it is expected to be populated with all quantities acquired with all invoices.

On France localization, system is controlling customer invoice date posting.

if invoice is posted before last invoice date, warning will show (Posting with reason code)

If invoice is posted after system date, warning will show.

this function could be generalized to all countries based on setup from AR parameters.

Example

Invoice date 01/01/2023 for customer FR_SI_0001 is earlier than last posted invoice date 02/01/2023. To proceed further, reason codes must be defined either on invoice header or invoice line level.

Invoice date 30/03/2023 for customer FR_SI_0001 is later than current system date 25/01/2023.

On French report Transactions list by account option to include settled transactions is available.

With new year end closing Awareness between ledger settlement and year-end close settlement will be with opening transactions.

As consequence, if option include settled transaction is Yes, ledger account balance will then be incorrect

The report should consider this new feature and provide correct report with and without settled transactions.

Consequence if settled transaction are removed

=> opening balance may change but total balance on ledger account will be correct

same goes for accounts payable and accounts receivable.

on vendor master data, invoice account can be linked to order account.

When purchase order is created, dimension on purchase order will be from order account.

Option to select dimension from order account or invoice account should be possible.

Customer will then be able if dimension on transactions will be from vendor account or invoice account (example of vendor dimension)

It may happen that company negotiates currency contracts.

Then they may book transactions with fixed exchange rate (enter manually). These transactions should not be revaluated as part of currency contracts. The amount should not vary based on daily exchange rate.

Other scenario can be that invoices have different currencies. Customer may have input currency manually.

Payment is posted with total amount as per exchange rate from initial transactions.

When settlement is posted, then system should not generate exchange rate gain/loss as total in company currency is 0.

But so far, even if exchange rate is manually input on transactions, system considers the daily exchange rate during revaluation or settlement. Then artificial revaluation voucher is posted.

Workaround: when transactions is settled, amount in foreign currency should be marked as primary payment. Then no gain/loss amount is calculated.

But this has its limitation.

Include Portugal in D365 localization