Comments
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.
Could solve a common issue:Production input location with and without LP. Very common issue with posting picking lists when the LP is not found by MS logic.And it would solve this not so common but vert relevant scenario:Scenario with production orders where the same raw material can be two times in the ProdBOM. Staging of LPs to a production input location. One pallet at the time can be picked, the work is split to get one work per line in ProdBOM. Its staging which means that the warehouse worker might pick a pallet which will quantity wise cover both lines. The second work will then automatically be cancelled. Not the desired outcome as the pallets are placed at different physical locations on the shopfloor. We need two pallets - one per line in the ProdBOM.
We would also need that the UK HMRC Making Tax Digital extension to be made available for Microsoft Dynamics 365 Business Central in the UAE region. Our head office is based in Dubai, and this functionality is essential for our operations. Kindly consider enabling this extension for our localization to support our business needs more effectively.
This issue creates inconsistencies which Business Users latch onto and causes distrust of the data. With the newer advances of Synapse Link / Fabric Link and capabilities within fabric, including the new deltalake change data feed, a cascading update solution could be built.Stating the lookup fields are not supported in a FAQ document is NOT sufficient. We went around for 3+ months on a support case, trying to figure out why Fabric Link had data mismatches from CRM. It took months until a tech finally pointed out the small entry in the FAQ which has been slightly revised since this happened now: https://experience.dynamics.com/ideas/idea/?ideaid=56c55490-151a-ee11-913b-0003ff4588ed#submit-commentThis needs to be front and center for anyone enabling Synapse Link or Fabric Link for Dataverse / CE. It needs to be made clear what fields are lookup fields and that they may be wrong. I would have honestly preferred that the fields not be presented at all via Syn/Fabric Link if they could be inaccurate.Users need this data to be accurate and we would like to ask the Microsoft takes further steps to ensure accuracy.
I would prefer that this was either a Company Parameter OR, even better, a setting on the Purchased Item's Coverage Group. Some may want to get an Alert that the PO needs reconfirming so that they can address new date mismatches rather than just an Action message. Unfortunately, most Manufacturers are not on top of Action messages, ignore them, or even have them switched off.
This idea would be very interesting for the Essentially license and the assembly orders, since I’m implementing the “assemble-to-order” functionality for my clients, but there’s no standard solution for sales return orders. I think it’s more than necessary, otherwise the functionality remains incomplete.
This idea would be very interesting for the Essentially license and the assembly orders, since I’m implementing the “assemble-to-order” functionality for my clients, but there’s no standard solution for sales return orders. I think it’s more than necessary, otherwise the functionality remains incomplete.