Microsoft Dynamics 365
This is an important function required for efficiency for the customer. Without this functionality the customer will be unable to use the bundle items on a project quotation and item requirement (sales order).
Actually for some use cases it does make sense, but as a general approach it may help with provideing more flexibility in how enterprises are using your platform and how they apply existing processes in your solution. Example as follows:
We create cases automatically and we map work orders to cases in a 1 to 1 scenario.
We automatically assign the work orders based on SLAs, tech availability and user preference etc.
We also automatically populate knowledge in Dynamics 365 from external systems, because of the multitude of systems that the techs need to act upon.
Our techs work directly inside the work order, using "checklists" that involve interaction with multiple "products" that need to work on (think about IT field services, where the work order can consist of steps that span multiple products: backup the device using product X, reimage the device using product Y etc.) and other components specific to the work order.
For them to access the knowledge and be able to use the "search" engine associated with this knowledge module, they need to go back to the actual case and lookup the knowledge article that may apply to what their work order entails, then navigate back to the work order to continue their "intervention". This creates an inefficiency in the process, as the technician has to go back and forth from case to work order etc.
This is an important function required for efficiency for the customer. Without this functionality the customer will be unable to use the bundle items on a project quotation and item requirement (sales order)
A simple and quick win would be to show Service Lines on the Service Order page. The Service Rep have everything needed on one page. (similar to showing the Sales Price table on the Item card)
Chris DeRusha, no negative side effects by disabling the Force Doc. No balance. Restrict this option to the deposit batch only. Your journal entries will always balance per batch, even if they don't balance by doc. no.
MS, you should uncheck that flag onValidate of the Journal type when it's deposit, document this and close this request.
This is a bug, try to import it in English and it will work. Any other language will fail and you'll have this error: You cannot import the same information twice. The combination G/L Account No. - Dimensions - Date must be unique."
I have the same issue on v16.2 Canadian - French language. But works fine in english
Business Logic by using different no series is not recommended. Why not a field ''Document type'' where you select what ever other information that you need?
I would add to that Fixed Asset and Fixed Asset GL journals
Consultant here: The Recurring type entry is pretty much not usable without this feature. That would add a lot of value for speeding up month-end process.
User story: A company has 2 business unit and 5 department (both dimensions). We want to speed up the pruchase invoice entry process by telling the AP clerks to fill only the Business Unit dimension and not the department
Each business unit has specific allocation keys for the department dimension (based on head count for example). BC will credit the expenses for each BU and re-allocate those to right departments.
This is the most important and basic need for Commerce anywhere in the world