Frank Paaskesen Scales Group A/S Sr consultant D365FO

When a product has been configured in relation to a sales orders, the configuration details can be accessed through the sales order. This a however the only way in the system to access the configuration details.

I my view the configurational details should be more accessible from other areas in the system e.g from the production orders or from the inventory.

However i would like to suggest that the configuration can be accessed from the product dimension table. If the product is a contraint based product master there should be a menu item to open the "configurator".  It should even be possible to create a new configuration from this form.

We have recognized a GAP in the forecasting system for Companies using configured Products.

For certain product the number of configurations can be very high or unlimited. These products must therefore be forecasted on either a "planning item" with at BOM representing the different configurational outcomes or through an item allocation key which is composed of "typical configurations".

The problem is that if the product is sold in a new configuration which does not match the forecasted items exactly on configuration ID, the forecast will not be reduced.

My suggestion is to make a new parameter in Requirement Group called "Forecast reduction on product level":   Yes/No.

If this parameter is set, the forecast reduction will work on the forecasted item INDEPENDENT of the sold product configuration. The effect of this will be that the "planning item" forecasted quantity will be properly reduced by all sold configurations for the product.    

I suggest to improve the new lifecycle status on released items with some extra toggle functions on the table .

Stopped for sales       Yes/No

Stopped for inventory  Yes/No

Stopped for purchase  Yes/No

When the product lifecycle status is changed the corresponding flags  in the default order settings (all combinations) will be "overwritten"

This will enable full control over the products accesibility in the system. If a new combination is required a new product life cycle code can be created. 

The message handling functionality in the job card device is currently missing. I would like to propose that this is implemented  

Some companies requires enterprise based purchase agreements, both on price level and on quantity level.

In D365FO the quantity limit functionality is only active on local company level.

I suggest to extend the functionality to enterprise level including these functions:

The agreement is made on product level. Prices are defined for each local vendor per company.

Lead times for each local vendor can be set on the agreement, and will be used in the MRP, while the agreement is active.   

We  can see that for French governmental rules we are able to track a global agreements, but this seems only to be a reference. 

When a note is generated for a configuration, all the attributes in the model are transferred to the note. it should be possible to control which of the attributes to transfer. Some if the attributes might be technical variables which are totally irrilevant for the buyer e.g. calculation attributes for assembly times. I suggest that it should be possible to set a flag on the attribute in the model for "external" or "internal". Only external attributes should be transferred to the note. I dont recommend to use the "hidden stribute", since some hidden attributes might be "external".

You define an attribute of type decimal and sets up limit for this attribute. You then use the attribute type in a product model because you want this value in the configuration dialogue to be delimited by the limits. But these limits are not used, so the user can type any value in the field. So my suggestion is to enable these limits either by looking up in the model or secondary give posiibility to define some limits on the attribute in the model.

In the charge system should be possible to choose the "Term of delivery". These is a huge difference between sending goods DDP (delivery duty pays) or AW (customer pays transport and dutys).

The safety stock journal is only capable of calculating safety stock based on historic values, which is not sufficient for a lot of industries. We need an additional feature in the create lines function, where the lines are created from a forecast plan or master plan. The plan should adeally This means the calculated Average Issue per month and standard deviation is read from the forecast plan The Calculate proposal needs no improvement, since we can calculate from Average issues or service level (but now based on forecasted values) It should not be too much effort to implement this very useful function Here the user could

Today charges can be based on Delivery mode. It seems very logical to expand the auto charges also to be based on Terms of delivery, since these terms directly will be connected to an additional cost on the order. This means that charges can be setup for the different incoterms ...a huge improvement. This should surely also work for purchase orders.