Comments
We consider this a critical accounting issue. For customers using foreign currencies, the behavior introduced in 28.3 can negatively impact transparency, auditability, and confidence in the closing process. Financial year-end closing is one of the most sensitive accounting operations, and creating thousands of apparently identical entries makes validation and reconciliation unnecessarily complex. In our opinion, this increases the risk of accounting errors and can leave customers with the perception that the general ledger is no longer in a stable and trustworthy state. Microsoft should treat this as a high-priority issue and restore the previous behavior from version 28.2.
In our view, this is a bug, not a "by design" behavior. Based on the code, the intent of the 28.3 change appears to have been to generate one closing entry per G/L account AND per source currency, instead of just one per G/L account as before.However, the implementation seems flawed and instead creates a separate closing entry for every single G/L entry, resulting in thousands of duplicate lines with zero differences between them.We'd ask Microsoft to:Fix the underlying issue so that closing entries are properly aggregated again, and no longer multiply into thousands of near-identical lines per account.Beyond the fix, consider adding an option that lets customers choose whether closing entries should be split by source currency or not, similar to how closing by dimension is already an optional choice today. Not all customers will want their income statement closed at this level of granularity, and an opt-out would let each customer decide what fits their reporting needs.
Seems like this would work with purchase order the purchase order should flow all the way through till it’s done, currently purchase order number then changes to another number then another number and it’s so confusing, if type in po it can reference many different like posted purchase invoice and like.