there is a special need for having different weight and length units on the Released Products level (Released Products / Manage inventory). The products at some customers are very light (Inventory Unit pieces and Pairs, stockings weighing 20g) There is a big demand have separate units.
D365 itself has no unit on those fields and Microsoft is currently not planning this functionality.We should have the possibility to chose the unit for the weight and dimensions on the item sheet and on the packing list for both side purchase and sales.
On the item sheet the fields unit would be required for the weight measurement and for the physical dimensions
In the parameter of account receivables and account payables, the default unit for packing slip would be entered
On the packing slip/ Product receipt the unit is defaulted from the parameter, but can be changed.
The default weight and dimensions are defaulted from the calculation from the item sheet and the unit conversion. The weight and dimension can be manually overwritten.
Unit of measure conversions are set up per Variant in a product. When adding a purchase line or sales line, an error is shown saying "Product variant unit conversions are not supported for this process". This should be possible.
Released Product properties can be defaulted by a selected category from the Retail hierarchy. This has recently been extended with most of the properties needed to create a released product.
This functionality should be made available for customers that are not using the Retail configuration key and therefore cannot use the functionality.
This approach should replace the item templates.
Manufacturers and supply chains need the ability to revise products and product variants, 01, 02, A, B, C, etc., for procured and manufactured products, then plan, procure, produce, cost, transact, and stock by revision.
A good solution might be to create an additional product variant dimension called Revision, where the revisions could be stored and tracked through D365 for Operations during the planning, procurement, production, costing and stocking of products by revision.
Please, make this a core capability, rather than an ISV solution.
When, as a consequence of a user choice, a model becomes not feasible, a generic error is displayed "The model is in contradiction". It would be very useful (almost necessary) to have some additional explanations.
I would suggest:
1) Show the attributes that need to be modified in order to resolve the contradiction
2) Give the possibility to associate an user message to each constraint and, when the model is in contradiction, display the message(s) associated with the failing constraint rule(s)
It would be great if you were able to record a product's life cycle status based on a customer-defined status list. It would be useful, if this information was also able to be used in both the release function and as part of an approval workflow. You should be able to override this status by legal entity to allow a product to be in different life cycle stages depending on market. Ideally, you should be able to associate policies with each life cycle to determine behaviour. This feature is useful across a number of industries including manufacturing, distribution and retail.
We come across requirements where the default order settings are to be configured by a group of items for a customer / vendor or group of the same. Companies in retail / distribution create such contracts based on minimum sales / purchases for every order based on the item group (such as a specific brand) to specific groups of customers / vendors. Furthermore lead times can be assigned to the same contracts. The default order settings are item based and do not support configuration for group of items / customer or vendor groups. It also takes a lot of time to configure lead time on trade agreements in case we need to work with specific lead times by vendor or customer. This can also create configuration errors as prices need to be considered when creating such lead times. A company which sells 1000s of SKUs finds this hard to manage.
Would be good to have some standard function to assist in completing such a configuration which is not dependent on the trade agreements as well as enhances the default order settings setup to incorporate groups
Description of problem:
When using circularity check at line level in inventory module general parameters , there is no circularity check at formula level when adding the same item in Co-product line and in formula line level.
As a conclusion:
It would require a Change Request:
• In case of level circularity at line level:
- If item added at Formula/co-product level and exists in formula line> return a circularity message
- If item added at Formula line level and exists in formula/co-product level > return a circularity message.
On released products, the user can validate the product to check if all essential fields have been filled in (Item group, model group etc).
But he actual validation is hard-coded into the class method EcoResProductValidator.isEssentialFieldValuesSet()
It would be nice to have a more dynamic approach to validate a product, where each customer can define what is mandatory to fill inn before a product can be validated.
So the idea is to have a product validation functionallity where theese rules can be defined by the masterdata managers.