When implementing Microsoft Dynamics NAV in a manufacturing environment this question is always discussed; should the time posted against production orders be according to the expected values (e.g. the setup and run times in the routings, sometimes also referred to as nominal values) or should it be according to the actual time (entered by a user)? In my mind the answer to this should be driven by business requirements and should not be determined by the functionality available in a software (just like many other things when it comes to implementing an ERP system).

My experience is that 3 out of 4 companies prefers to use the expected values and not the actual values. Most of the time the argument against using actual times are that it would be hard to capture it in a way that you can rely on the information (and base your financials on it). Things like operators that are running multiple jobs on different machines at the same time (for example) could complicate capturing how much time that are actually spent on the different operations for each of the jobs. It does not have to be one or the other either, maybe some types of operations/machines are posted with the expected values while other type of operations are being posted with the actual values.

Companies that choose to use the expected values then instead have procedures in place that keeps the expected values as accurate as possible. Those procedures could for example be to do time studies on individual operations and/or to follow up on how many hours that are posed in a period of time verses how many hours you have payroll in the same period (as an example).

Companies that choose to use actual hours are doing it to get more accurate numbers in Dynamics NAV, both in order to get realistic costs of the products and also to have a place to follow up and report on what is actually spend on the different operations (which in the long term could improve planning).

Below are some methods of capturing the actual and expected times in Dynamics NAV. The examples are described using the output journal, but the same functionality would also apply to the production journal.

Posting of Actual Production Time

When you post actual production time the user will either have to enter the time as setup/run time or enter the starting time, ending time and the concurrent capacity.

If you enter the starting time, ending time and concurrent capacity then Dynamics NAV will automatically calculate the run time for you in the journal (where the concurrent capacity represent the number of resources used). With this method there is no way to record it as a setup time, it will always be recorded as run time. The cost will be the same but if you want to do some kind of reporting on setup vs. run time then you probably want to do a small modification to allow this (maybe to add a ‘setup starting time’ field that will calculate the setup time).

One thing that is worth knowing is that if an operation starts on one day and finishes on another day, then you need to enter multiple lines in the output journal for the same operation with different posting dates (or you post the journal twice). Something like below.

This is a bit hard to enter in a production journal since you can’t have multiple lines in it for a single operation (without making a modification that is), but it works well in the output journal.

If you prefer to enter the setup and run times directly then you just enter this in their individual fields and you leave the starting and ending times empty.

Practically, posting actual times are typically either done by the operators themselves, or a production supervisor that enters the information based on filled out job cards received from the operators.

An alternative option to record actual production times is to have functionality that will record when operations are stopped and started. Programming this is actually easier that it sounds, one good/simple way of doing it is to create a transactional table where stop and start entries are recorded and then having a function in the output journal that is similar to the standard explode routing function that will populate the times based on the entries in the new table. If you use a barcode solution (like my shop floor barcode system), then you can have barcodes that are scanned to stop and start operations. If you create a page for the table and publish it as a web service you can have other application (such as a 3rd party scanning solution or a PLC system) populating it. I might actually do a future post with a solution like this.

Posting of Expected Time

If you typically produce the same quantities as on the production orders and you want to post the capacity according to the expected times from the routing, then the far easiest way to do this is to backflush the operation (something like scenario A in my previous blog post about flushing methods). If you backflush operations then there is no need to do any type of posting in the output or production journal, all you need to do is to finish the production order and the capacity and output will be posted automatically by NAV.

If you happen to be in an environment where you frequently produce quantities that are not the same as the production order quantity or if you have production orders open for a longer period of time and want to record output multiple times against the same order then backward flushing will not work. Here you need to use either the output or production journal and enter the output quantity along with the setup and run time. To streamline this task you can make a small change and have Dynamics NAV to calculate the setup and run time based on the quantity entered as output and scrap. Below is and example of how this can be done.

Create a new function in table 83 – Item Journal Line, call it something like UpdateTimes. The function will be called when the output or scrap quantity is entered in the output journal and it should then calculate the setup and run time for the journal line based on the expected values in the production order routing. The below code is kind of self-explained; it grabs the production order routing line record and calculates the run time by multiplying the run time from the routing by the output plus the scrap quantity. The setup time is entered if there are no other transaction on the operation, if there is then it is zero (the concept with a setup time is that is supposed to be only once per production order). There is also a way to turn the calculation on/off through a new field in the manufacturing setup table, I always do modifications so they can exists together with how the standard functionality works (if you for example have additional companies in the same database that don’t want to use it this way).

Next you add the call to the function in the OnValidate triggers of the output quantity and scrap quantity fields like below.

Now when you enter the output or scrap quantity in the output or production journal the setup time and run time is automatically calculated and populated by Dynamics NAV according to the expected values. Nice! 🙂

That was all for this post, remember to share it on social media! 🙂