Manufacturing Execution and Advanced Warehousing

Manufacturing execution functionality handles the registration of actual hours for Production order routing operations. Theoretically a production order can go through Start and Report as Finished  status by just using the registration functionality. With Advanced Warehousing, that has become a little different.

Controlling the “Start” and “RAF” status for production orders via Time registration terminals requires the right parameter settings. In all cases, the Release will have to be done by the production office or supervisor.

Without release, a production order will not show up in the registration terminals (Job card Device or Job card Terminal).

Let’s see how the “Production order defaults (by site)” make it possible to manage the “Start” and “Report as Finished” status via the time registration terminal.

The parameters are found in Production order control/Setup/Manufacturing execution/Production order defaults (by site)

The parameters in this area control the behavior of production orders during the time registration process. They are valid for all users (in a site or in a company). The settings in “General” are not relevant for this blog.

Settings in the “Start” section

The biggest decision is the first parameter “Update start on- line.”

For real time production order status, it makes sense to have the value “Status + quantity.” The process will be straightforward. The production office (the supervisor) releases the production order. The first registration worker that starts working on operation 10 of this order automatically starts the production order with the quantity entered for operation 10.

This means that any Production BOM materials that have a flushing principle “Start” will now be backflushed.

With Advanced Warehousing, what is different with the automated “Start” process of a Production order in manufacturing execution?

The key thing is that we now are dealing with a “picked” status for each Prod-BOM item.

At release time or via a batch the system creates Warehouse work for “raw material picking”. This warehouse work will change the inventtrans status of each Prod-BOM line to “picked”.  Without advanced warehousing the status ‘picked” was never used for Production order BOM materials.

After picking, the items still have to be “deducted.” Only using the flushing principle “Available on location” guarantees that the system only deducts the items/quantities that were picked. If we use the principle “Start” with advanced warehousing, we will run the risk of errors when not all items in the Prod-BOM were picked and we start the Production order with “Flushing principle” in the Bom-consumption field. “Available on location” is called this way because the Warehouse picking work has put the picked items in the put location which is the input location of the Resource group of operation 10, or to which operation the materials were linked. The items are “available in the input location of the Resource group.” The completion of the warehouse picking work moved them from their warehouse storage location to that put location that is the “input location” in the Resource group. They are now sitting there, ready to be backflushed.

When using Advanced warehousing with Production orders, use the flushing principle “Available on location” on the BOM lines and make sure that the resource group in the routing operation has an input warehouse and an input location. With advanced warehousing, the flushing principle “available on location” is the only principle that is aware of the status “Picked” in the invent trans table and will only flush (= deduct from inventory) what was picked.  If we would use the principle “Finish,” we would have an issue just like we would have with “Start.” If not every item was picked yet, the system will not see that and will try to backflush all  items with principle “Finish.” The principle “Available on location” will politely flush (= deduct) all inventory that had been picked and put the picked quantity into the input location of the Resource group.

NOTE

If we have to pick additional items later for the same production order (because some items arrived later), the system will almost instantly create and post a picking list after the warehouse picking work has been completed. (it takes a few minutes). This avoids having to manually post additional Picking lists for a production order. The parameter setting shown in the screen shot below will make this happen. It is the standard setting for backflushing, nothing special.

Automatic BOM consumption: Flushing principle (which will be “Available on Location” which works like “Start” with the important difference that it will only flush what is in status “picked.”)

Post picking list now: This is obviously a Yes.

As always we avoid the “End-mark picking list” and “Physical reduction,” “Pick negative,” and “Complete picking list journal” parameters like the plague (End-mark = yes would say that we will have no more picking for this Production order, “physical reduction” reduces the quantity on the Prod BOM to whatever we happen to have on-hand, Pick negative would only work if we allow negative physical inventory in the Item Model group, which we typically do not and “Complete” is creating a picking Journal for all lines in the Prod-BOM regardless their pick status or their on hand availability which would disrupt our process).

Now we will discuss the next fast tab in the Production order defaults (per site), “Operations.”

Settings in the “Operations” section

The Operations parameters screen has a few critical sliders:

Job level: this decides whether a Route card or a Job card is being posted. The setting should be “Route” if we use Operation scheduling to create the jobs for our time registration and it should be “Job” if we use Job scheduling.

Post automatically: any actual hour registered in Job card device or Job card terminal is posted as an auto-created Route card journal.

Setup = Yes

Process = Yes

This means that we only report actuals on the most common time segments in a routing operation: setup and process time.

Automatic BOM consumption: Flushing principle. When materials are linked to later operations, like 20, 30, this parameter will make sure that these materials are flushed at that later time.

When we started the production order, only materials with a blank operation or with operation 10 (or whatever the first operation in the Prod Routing is) would be flushed.

With Advanced Warehousing, what is different with the “Operation” process of a Production order in manufacturing execution?

Nothing new that was not mentioned already under the “Start” section. It is the backflush principle “Available on location” that will make sure we only backflush what has been picked earlier. When we have materials linked to operations 20, 30, etc., the backflushing of materials is tied to the “start” of these operations. Because backflushing only works when a quantity of the end item is given to the system for which to backflush the components, the registration user needs to have a started quantity for operation 20, 30. (The job card device defaults a started quantity, the Job card terminal requires the user to type it in.)

Next we are moving to the trickiest section of the Production order defaults (per site): the “Report as Finished” fast tab.

Settings in the Report as Finished section

Update finished report on-line:  We do not really have a choice here: we have to say “No” to this because any other value would require that each production order already has an in-dock  location (a license-plate controlled location) and a license plate number defined on the order. This location is not a put away location. Additional transfer would be needed from this in-dock to a storage/put away location after completion of RAF. With an in-dock location and a license plate in the Prod order,  the time registration employee would be able to do an instant RAF transaction when completing the last operation of the production routing. Giving the shop floor operator this power to create end-item inventory via RAF transaction makes a lot of sense in high volume repetitive manufacturing environments, yet Advanced warehousing makes this difficult. With advanced warehousing, we really want to use the handheld menu item “Report as finished and put away” that generates a new license plate number and allows to choose scan a put away location.

Engineer-to-Order, Make-to-Order manufacturing companies that I know would never allow the shop floor worker to have the power of RAF. In those industries, with low volume,  Report as finished transactions are typically done  by a warehouse worker who handles receiving , or in the production office.

With Advanced Warehousing, what is different with the “Report as Finished” process of a Production order in manufacturing execution?

There is a very important detail here: even with the first parameter set to “No,” the other parameters in this section are still applicable for the handheld RAF transaction! The handheld RAF transaction has no parameters anywhere else. This manufacturing execution screen serves as parameter screen for the handheld RAF transaction. ! In order to set the right values, you temporary have to switch from “No” to another value and then return the value to “No.”

Automatic route consumption:  Labor backflushing is out of the question when we use Manufacturing execution. So this has to be “never” to avoid extra labor being backflushed in addition to registered hours. (the system would do this without warning). It could be “routing group dependent” if we have vendor operations in the routing that need to be completed automatically during RAF (route group of that operation would be set up for labor backflushing and automatic completion).

End-mark Route: “Yes” will prevent errors when un-completed routing operations exist (they will be completed with zero time) but we may want that error  so we can catch any missing feedback of actual hours on operations in Manufacturing execution. Therefore we typically leave it at “No.”

Automatic BOM consumption:  With advanced warehousing we use the flushing principle “Available on location” for all normal items, which works like the “Start” principle. So there is nothing to flush anymore by the time we have arrived at RAF. But we can have service items on the BOM  that represent floor stock that we want to flush at the end. Subcontract service items that were “received” on a subcontract PO have to be flushed at Finish also.

Service items are never picked so Advanced Warehousing is not a factor. When we say “Flushing principle” here, the handheld RAF transaction will create Picking list journals and post them for any service items in the BOM with principle “Finish.”

End job: This is the default value in the RAF transaction. If most production orders are Reported as Finished with their full quantity (no partial completion) the default should be “Yes.” If the opposite is the case, we say “No.” This parameter works exclusively for the handheld RAF transaction.

For the regular Report as Finished, we have the parameter in the user defaults of the RAF transaction that could have become the default for all users.

Accept error:  This parameter also works exclusively for the handheld RAF transaction. It should be “No.” There are a few situations where we have to say “Yes” for an individual production order. With “Yes” the system no longer checks the “Remaining quantity” field in the Prod BOM and will change the order status to RAF and even to “Ended” without any errors for missing materials. This is most definitely not recommended, and I would call this even a dangerous setting.

The last tab is Quantity validation. Look close to realize this is about quantity tolerances in the Start quantity and in the RAF quantity.

Settings in the Quantity validation section

The four parameters for “Startup quantity validation” kick in when the registration worker starts the order indirectly via the time registration. It will make sure the registration worker puts in a started quantity at least equal to what the deviation allows. If the order quantity is 1, the worker will have to put in 1. For higher order quantities, he can get away with a smaller quantity, based on the percentage in “Accepted deviation.”

In general we do not recommend to use a start quantity that is lower then the order quantity. The user tends to forget to start the remaining quantity and then an error will come up at the time of RAF.

The Feedback quantity validation is about the RAF quantity and for us, users of Advanced warehousing, this means that these parameters work for the RAF handheld transaction.

The values can only be set if we temporarily switch the previous parameter “Update Finish report on-line” in the Report as finished tab from “No” to something else, then quickly return to set it back to “No.”

As you can see in the screenshot, the percentages of “surplus” and “shortage” cannot be edited at this moment. We have to return to the Report as finished tab first.

Below we see an example with surplus and shortage allowances. This feature is quite important for fabrication production orders where I make something out of a raw material. Factory workers often want to “run out” a raw material so there are no left-over sections of this raw material. This means increasing the RAF quantity without modifying the Order quantity (factory worker would not have the possibility to do that).The feedback quantity parameter is needed when the quantity of raw material in the BOM is correct but it turns out you can make a few more items out of it. We are not talking about changing the order quantity.  These parameters are not relevant if we change the order quantity to be equal to the higher/lower RAF quantity. In that case the system would prompt us to re-estimate and calculate a different quantity of raw material needed.

This completes the description of how to work with two functionalities: one is the quite old functionality of Manufacturing execution that has been with us since the early Axapta releases. The other is the added functionality since AX 2012 R3: advanced warehousing. It was a surprise to me that the handheld menu item “Report as Finished and put away” is controlled by the parameters in the Production order defaults but it makes sense, given the fact that the traditional RAF transaction triggered by Manufacturing execution is no longer practical.

Have any questions? Please contact one of our experts today!