Comments
With creation of new role centers for Accounts Receivables and Accounts Payables, General Ledger Setup received 2 additional fields Account Receivables G/L Account (Sub) Category and Account Payables G/L Account (Sub) Category. However, there might be several sub categories that can be considered as accounts receivable or accounts payables for financial reporting purposes. To my opinion, it would be more beneficial to add a new column in G/L Account categories with the same principal as Additional Reporting Definition for Cash Flow Statement, where an accountant could assign certain grouping principle to the G/L Account subcategories, that would help to identify which subcategories are Accounts Receivable, Accounts Payable (may be a new role center for Inventory Accountant to be created, that would require to identify G/L Account sub categories that are related to inventory; or Fixed Asset Manager etc.)
And I also want to mention again that many customers would like to indicate the discount percentage on there business papers (like e.g. the invoice), but this information is not on the sales line if we use retail pricing or UPM. We have made customizations and created a new field where we calculate the percentage back from the total discount, but if I remember properly we also had some rounding issues because of the current way how MSFT is calculating the discount value. Hence I voted for this idea to perhaps have another choice of the calculation method. BTW: The current discount calculation is like this:221.85*16*0.49=1739.304 which is rounded to 1739.30Hence the net amount will be 221.85*16-1739.30=1810.3
I've had to employ a similar workaround. I work in IT, and our Finance team needs to be able to do a revenue flash on Business Day 1 of the new period, which means all of the end of month deferral processing needs to be completed by the time users come in at 8:00 AM. Since implementing Subscription Billing, I've been starting at midnight on the last day of the month to begin chunking the data up into ~50k records per job. Our offshore team takes over while I sleep, then I resume postings until completed. Other points I would add:The Recognition Batch Processing job needs to be multithreaded. It is crazy that the job is single-threaded when there are hundreds of thousands of records created in a single commit.The job needs error handling. It does not make sense for a >50k line journal to be rolled back because a single transaction had a suspended financial dimension. Why doesn't this job utilize the standard journal posting functionality that allows moving lines with errors into a separate journal?There should be a line limit for the journals created by the job. If processing 100k+ lines, much of the time is going to be spent on posting validation. This ties back to #2 where I would rather see three 20k line journals post successfully before the job failed due to a data issue than none of the 100k lines post at all.
This issue goes to data quality and the proper care and feeding of the data estate. It is surprising that this has been allowed to linger for this long without resolution. If we can't trust the data in child records when an update occurs to a parent record, it calls into question the usage of the data in the dataverse for enterprise production purposes. This is critically important for further usage of the dataverse.