The case of a missing flushing principle

The case of a missing flushing principle

This article is about material consumption in a manufacturing scenario where Manufacturing execution terminals are used with a WHS – enabled (advanced) warehouse in Dynamics 365 for Finance and Operations, and how BOM flushing principles work on different devices.

BOM Flushing principles

Typically, materials are backflushed upon completion of a finished item, i.e. automatically consumed at a ratio defined in the Bill of materials. 4 flushing principles are applicable to a raw material:

In the BOM line the 5th flushing principle is available: <None>. It means the consumption should fall back to the either one of the 4 principles specified in the item master.

Here is how different actions in D365FO react to the flushing principles (ME stays for manufacturing execution i.e. shop floor control, and WHS for the mobile scanner device running the advanced Warehouse management front-end), all in a neat matrix:

 ManualAvailable
at location
StartFinish
Prod. order release (x)  
WHS picking (pick)    
WHS picking (put) x  
Prod. order Start  (x) 
WHS Start production order  (x) 
Route card + Auto BOM consumption(x)(x)(x)(x)
ME Job terminal – Start  (x) 
ME Job terminal – Feedback Operations   (X)
ME Job terminal – Manual consumption feedback(x)(x)(x)(x)
ME Job terminal – Feedback RaF   (X)
Prod. order Report as finished   (X)
WHS Report as finished (put)   X
WHS Report as finished (put away)    

The actions where the material consumption is optional and configurable are put in brackets: (X). For example, one may configure whether the classic production start is accompanied by forward-flushing and how: for all BOM lines or only those with the Flushing principle = Start.

Another example: a manufacturing execution Job card terminal may be configured to consume materials on the current operation (ME Job terminal – Feedback Operations), on the last operation only (ME Job terminal – Feedback RaF), or never. Activating both is clearly not an option, since every production order has a last operation on the route, and triggering both is going to result in double consumption.

I tend to say the intersection between:

  1. ME Job terminal – Feedback Operations
  2. ME Job terminal – Feedback Report as Finished and
  3. WHS Report as finished

is highly problematic, and here is why.

Job card terminals in conjunction with Mobile devices

Consider the following scenario: every machine along the production route is equipped with a Job terminal to report time and WIP quantity output, while packaging and labeling on a mobile device is only required at the last station:
Operations route
On a long-running operation it may be beneficial to consume materials at the run time, i.e. with the help of (1) the ME Job card terminal, “Feedback operations”. However, with the unconditional consumption at (3) the mobile scanner Report as finished, this may only happen at the scanner. Otherwise the consumption is going to be double.

Moreover, the mobile scanner only accepts the “good quantity”, while the ME Feedback offers both the “good quantity” and the “error quantity” i.e. scrap for entering. Since the mobile scanner always consumes raw material, the material consumption is going to be too low. The Production scrap WHS menu is not a good replacement, since it requires the extra consumption of every material SKU to be entered manually.

Now consider a sophisticated environment where packing is performed by a robot, and the operation 30 “Packing” is not managed by the Manufacturing execution module. The WHS “Report as finished” function is triggered as full boxes or pallets pass a simple photoelectric sensor or a bar code reader:
Operations route (no packing)
While the Op. 10 and Op. 20 materials are captured at the Job terminals, it might be tempting to backflush the packaging materials at the ‘non-operation’ Report as finished. This is not possible, because (A) the WHS “Report as finished” unconditionally consumes all materials with the Flushing principle = Finish, and (B) a material with no operation number is accredited to the first operation on the route.
A split of the Finish flushing principle into 2 could have addressed this scenario:

  • Operation finish
  • Production finish

where the mobile device only considered the latter.

Finally, imagine the 3 operations running in dedicated production orders, with tangible semi-finished goods (SFG) exchanged between the machines:
Production order route
This is a common scenario in process manufacturing where the SFG batches can hardly be quantized and bear no labels. The output and input resource locations in the middle (10-20, 20-30) are not license plate controlled and do not have to be equipped with mobile scanners, as there is nothing to scan.

Here we have a different dialectic between semi-finished goods reported as finished at Job devices, and finished goods reported from Mobile scanner devices. This configuration – whether to trigger Reporting as finished in Manufacturing execution or not – is available at the Site level only, not a single Resource level. Yet an Advanced warehouse process cannot span multiple warehouses, let alone sites. This would end up either in full blown transfer orders between machines, or in an inability to track actual time at the Job card device.

Conclusion

At first, there must be an option to turn off material consumption on the mobile scanner, and let the system only backflush materials at the Job card terminal. The Mobile menu items Report as finished and put away and Report as finished must be extended for non-compulsory material consumption.
Ultimately, the error-prone recording of the material consumption is an internal planning and controlling requirement, while labeling and shipping generates revenue. One does not want to see label printing failing just because one screw is missing in the ledger.
Please vote for this idea!

Secondly, advanced scenarios may require a distinction between an “Operation finish” and “Production finish” as opposed to a single flushing principle “Finish”. This is hard to achieve through an extension to D365FO, as the respective enumeration is not extendable.
Please vote for this idea!

Thirdly, the D365FO configuration is not granular enough to divide the Manufacturing execution RaF and the Warehouse management RaF (reporting as finished), and should better be enhanced.
Please vote for this idea!

Hope this helps.

Overwrite a read-only configuration in D365FO

Overwrite a read-only configuration in D365FO

Updating an arbitrary read-only field in a configuration table in may pose a challenge in Dynamics 365 for Finance and Operations, especially in the production environment.

Many options may only be set once, for example the Use warehouse management processes mode of a warehouse, or the Revenue recognition accounting rule in a project group. Yet the data export / import both in D365FO and AX2012 may bypass the AOS validation as long as a data entity exists.

Here is how: open the Data management workspace and create an Export data project. Pick the respective data entity. Optionally, reduce the number of exported fields in the mapping to the minimum: the entity key and the read-only parameter in question.

Drill down into the Entity structure and turn off the Run business validations checkbox:

Then use the Modify target mapping button to clear the Call validate Field method checkbox from the entity attribute:

Export the data, download the ZIP data package, extract the Excel file and amend the parameter in the file as desired. Then re-pack the ZIP data package with the updated file (replace the original), create an Import data project, upload and import the package. With a high probability the Data management engine is going to bypass any application logic and update the existing record without further asking.

As a matter of fact, this method is even more brutal than the table browser (RIP, dear table browser, you are truly missed), since it ignores field properties set at the table metadata level and breaks the database consistency.

Electronic Reporting (ER) Cookbook 2: new tips from the kitchen

Electronic Reporting (ER) Cookbook 2: new tips from the kitchen

Since my last blog in 2017 a few things have changed. The developers in Moscow have been extending the module massively, and they seem to have fully embraced the Continuous delivery approach. Every new version or hotfix bears surprises, both pleasant and unpleasant. Here is a small personal excerpt:

      1. Configurations may be declared dependent on a particular application version or even hotfix. Should the developer of a configuration have failed to declare a dependency, the following message may appear on an attempt to import the configuration: “Method parmXXX not found in class ERxxx”, for example “Method parmERTextFormatExcelTemplate not found in class ERTextFormatExcelFileComponent”. It means the configuration definition cannot be de-serialized from an XML file in this old application version.
      2. From version 7.3 onward, parts of the application logic of the ER module had been extracted to the Microsoft.Dynamics365.LocalizationFramework .NET assembly for better performance. Now not only the configuration relies on a particular application version, but the application too demands a certain binary hotfix. For example, the SEPA camt.054 bank statement requires application hotfixes KB4096419, KB4092831, KB4089190, KB4077379, while the designer UI will not start without the ER cumulative update KB4090174 i.e. binary version 7.0.4709.41183
      3. From version 7.3 it had become possible to create inbound electronic formats i.e. those reading files instead of writing them. In 7.2 you could configure the same, but it was simply failing to work properly. It was not giving you any errors but failing to traverse records in the CSV file.
      4. Since version 7.2 you may define a Sharepoint folder destination (Organization administration > Electronic reporting > Electronic reporting destination). Consider the following scenario: the electronic report runs in a batch and saves files in a Sharepoint folder. A client-side process synchronizes the folder with the local network, and a local daemon picks up the files to push them through a legacy banking software or a tax authority middleware.
      5. When reading or writing data in D365FO, the ER is able to scan 1:n and n:1 table and entity relations for foreign keys. However, your new tables and entities are not going to appear under the Relations node of the data model mapping in the Designer, as the ER module maintains its own list of table relations in the database. Even worse, it may import and run a custom configuration with no errors but silently skip the custom table on reading and writing. Apply Organization administration > Electronic reporting > Rebuild table references to make your custom tables available.
      6. When developing or customizing configurations, it is not necessary to Complete the versions every time to test them. The ‘integration point’ e.g. a payment journal may execute the latest Draft version of the format too. Use the button Advanced settings / User parameters / Run settings, then flip the Run draft slider that appears.
      7. After upgrading to 7.3 you may find yourself unable to edit configurations anymore. The reason may be the new parameter Enable design mode available at the Electronic reporting workspace, form Electronic reporting parameters.
      8. It seems that they’ve protected configurations made by Microsoft from editing in one of the recent updates. Instead, you are supposed to always derive a configuration from the base one, and assign it a custom Provider. This corresponds to the extension paradigm as opposed to ‘overlayering’ of a configuration. Now, what are you going to do with your existing customized formats? Create an own provider (Organization administration > Electronic reporting > Configuration provider table), give it a name and a web address of your organization. Make this provider Active at the ER workspace. Export your configuration into an XML file, then delete it from the list of solutions in ER. Replace the XML tag with your provider, then re-import the configuration from the file. The system creates a new Draft version you are now able to edit.