The route group in Microsoft Dynamics AX is a mandatory field in every routing operation. All AX users have seen the error that comes up when you do not immediately choose a value for this route group while creating a routing operation.
We strongly advise users to fix it right away because the error will keep haunting you. But maybe you already know that.
What is the role of the route group? Let us start with the top half of the screen
1. Estimation and costing: This section controls the inclusion of a routing operation in the cost estimate of the production order. Note that the Setup time and Run time represent the traditional routing, where I define how much time is needed to produce a quantity of x pieces. The vast majority of Dynamics AX customers do it that way. The quantity is the alternative approach where I define how many pieces I can produce per hour (piecework). These are mutually exclusive approaches. The three fields should never be all checked, it is either or. Using regular routings, no piecework, I only check setup time and run time here. This means I leave the operation rate for “quantity” in my setup tab of the routing operation, blank.
2. Automatic route consumption: This section controls the automatic back-flushing of labor times and the automatic completion of operations. If I want back-flushing of routing times to happen, I have to check the boxes for setup and run time. If I also want the quantity of the order to go to the quantity field in the routing card (and I should want that) I check the quantity box in addition. This quantity box has nothing to do with the earlier mentioned “piecework.” The production order Start and the Report as Finished screen both have the option to backflush the labor hours using the settings on the Route group. You can say that the route group is the “flushing principle” for labor!
A special route group with these backflush checkboxes checked is often used for subcontract operations that are obviously not receiving any actual hours from a Time and Attendance system. To make sure they complete automatically and any hours in there post automatically, we use a special route group. The regular route group for regular operations would not have the backflush boxes checked. We report actual time for these operations.
3. Feedback: This parameter controls whether during back-flushing the routing operation is also declared completed, which is called “report operation as finished”, somewhat confusing for the user. “Report as finished” should be a term that is used only when talking about the production order itself. But this ambiguity exists in the Production Control module. Two screen shots to show this.
Above screen shows the Production route “Feedback tab” where we see that all operations are completed, and here it is called “reported as finished”.
In the route card shown above, it is called ‘Operation completed’, but it is exactly the same thing.
Let us now explore the bottom half of the Routing Group screen.
Setup: Activation: This controls whether a route/job type of a routing operation can be used. It controls everything. If a row is not active, you can’t schedule these hours, you also cannot report actual hours against it. The routing card will refuse this time to be reported. Automatic back-flushing for this time element will fail. This has nothing to do with operation or job scheduling. This is the error you would get:
Setup: Job management: This column is exclusively for job scheduling. The checked time elements will become a job that can be scheduled and reported against in Time and Attendance. We have seen a few cases where queue time before or after are becoming a job. Most of the time it is just setup and run that are checked here.
Setup: working time: This column determines whether the times in the routing operation are actually using the calendar defined for the resource. The help text says this:
If the check box is selected, the system uses the working calendar to plan the operation. If the check box is cleared, the system uses the standard 24-hour Gregorian calendar.
This works as designed. Why we would ever NOT check this box? For setup and process time, it would be strange to not check it, indeed. But keep reading, at the end of the article you will see an excellent example of when not to check this box.
Setup: Capacity: This is another checkbox that is normally checked. The system will include the hours of our production order operations as “reserved hours” on the resource or resource group.
I remember a customer that wanted to exclude a certain operation from the reserved hours on a resource. Unchecking this box will do that, but make sure toalso uncheck the working time checkbox. These two checkboxes work in sync, either check them both or check none. If you uncheck the “working time” you will see capacity go away also. But not the reverse! The following is a WARNING to the public.
CLR ERROR: If the user has “Capacity” checked with the neighboring field “Working time” unchecked, MRP will produce a CRL error that would look like this:
If you read the first line of the error “Cannot reserve capacity when working times are not used” you will see that this exactly our situation and we want to avoid it.
Let us return to our screenshot of the bottom half of the route group screen:
The checkboxes for the bottom half of the route group as shown above are the system defaults. Take note of the fact that for active Route/Job Types, ALL checkboxes horizontally across are checked. This is strongly recommended. The AX designers assumed that you want to only have set up and process times to become jobs when job scheduling.
For any scheduling, you want to make sure that overlap and transport are using the calendar of the Resource group or Resource.
For Queue before and after you use a 24 hr Gregorian calendar. This makes a lot of sense. If I am waiting in a queue, I am indeed using a 24 hr Gregorian calendar.
Capacity management is only checked for Set up and Process time. This makes a lot of sense also.
The conclusion is that the default checkboxes of the bottom half of the route group are typically right for the regular discrete production situation. The information in this article will help you if for some reason you want to deviate from this default setting.
