Managing production scheduling and workload (capacity) in Sage X3 V12’s Manufacturing module involves three key functions: Scheduling (FUNMAUTJ) for work orders, Loads Inquiry (CONSMWK) for reviewing capacity utilisation, and Load Recalculation (FUNMIWL) for keeping workload data in sync. In this guide, we’ll explain the correct setup for these functions, the tables and logic behind them, best practices for using them effectively, and how to troubleshoot inconsistencies. 

Prerequisites and Setup for Scheduling & Loads

Before using the scheduling and load management functions, ensure the following setup is in place:

• Site Scheduling Parameters: Define the period breakdown for load calculations under Parameters > Manufacturing > Scheduling. You can specify bucket intervals in days, weeks, or months, e.g. 7 days or 4 weeks, which determine the time periods for capacity and load “buckets”. If Automatic adjustment is enabled, the system may adjust the first period so that buckets align to full calendar periods. For example, if periods are set to 4 weeks and 3 months and you run a calculation mid-month (say 15th Feb), the first “month” bucket would only cover 15–28 Feb. With automatic adjustment on, instead the system would split into shorter weekly buckets (e.g. 6 weeks of data) so that the first full month bucket begins 1st April. This avoids having a partial first period.

• Calendars and Capacity: Set up your work centres with appropriate Weekly Structures and Time Table Schemas (via Parameters > Manufacturing > Weekly structures and Time-table). These define working days, shifts, and daily working hours for each work centre. Every working day in a weekly structure should have an assigned time table (shift pattern). If any working day is left blank (no schema), Sage X3 will use the default schema defined by the DEFDIH parameter (Chapter GPA, Group LOA). Best practice: Ensure DEFDIH is set to a standard daily pattern matching your normal work day length – this way, if a day in the calendar is unintentionally left blank, the scheduling calculation will still apply a reasonable number of hours. Inconsistencies here (e.g. a blank schema with no DEFDIH default) can lead to incorrect scheduling or load figures.

• Work Centre Capacity: For each work centre (under Manufacturing > Technical data > Work centres), define the capacity such as number of resources (machines or labour units) and allocate the weekly structure. This capacity figure is used when computing load percentages and overloads in the inquiry. If you later change a work centre’s capacity or calendar, you will need to re-synchronise the workload data (explained later).

• Manufacturing Parameters: Review relevant manufacturing general parameters in Group LOA (Scheduling/Load). For example, SCHEDHOR (Scheduling horizon) controls how far out work orders can be scheduled. The SCHEDWPO parameter (Schedule wait and post-op time) determines if wait/post-operation times are included fully in scheduling. Also note GPERCOMP (% lead time reduction default) and GTPSCOMP (Slack time compression) – these can allow automatically compressing certain non-load times (prep, wait, post-op) during load calculations. Ensure these are set appropriately for your scheduling policy (in many cases the defaults will suffice).

Once these prerequisites are configured, you’re ready to use the scheduling and load functions. Below we delve into each function in detail, explaining how they work, which database tables they use, and how to interpret their results.

1. Scheduling Work Orders (FUNMAUTJ)

Scheduling in Sage X3 is the process of sequencing work order operations over time based on routing data (operation durations, overlaps, etc.) at a given production site. In Sage X3 V12, the FUNMAUTJ (Scheduling) function is used to automatically schedule or reschedule work orders. This function assigns start and end dates/times to each operation in selected work orders, effectively planning their production timeline.

1.1 Using the Scheduling Function

When you open the Scheduling function, you are presented with selection criteria to choose which work orders to process and how:

• Work Order Selection: You can filter by work order number range, product, project, or other criteria (including formulas). Leaving selection fields blank will include all applicable work orders. Typically, you would target work orders that are not yet scheduled or those marked for reschedule.

• Scheduling Mode: Choose whether to process Not scheduled orders, Reschedule orders, or All:

  • Scheduling – schedules all work orders currently at status “Not scheduled”.
  • Rescheduling – re-schedules work orders currently flagged as “To be rescheduled”.
  • All – includes both not scheduled and to-be-rescheduled orders.\ For example, after MRP generates new planned orders, you might run in Scheduling mode to schedule those newly created orders. If certain released orders were manually marked for reschedule (perhaps due to a change in priorities or BOM), use Rescheduling mode.

• Date Range (Horizon): You can specify a cut-off End date – only orders with an end date on or before this will be processed. This is useful to schedule only work within a certain horizon. By default, the system may propose a horizon based on the scheduling parameters (like the Scheduling horizon or a date you enter).

• Work Order Status Filters: You may restrict by work order status (firm, planned, etc.) or source (whether generated by MRP/MPS) using checkboxes. For instance, you can include or exclude planned orders or suggestions from the scheduling run. (By default, suggestions might not be scheduled unless you explicitly include them or turn on load calculation in MRP.)

Once your criteria are set, clicking OK will launch the scheduling process. This can also be run in batch mode unattended (the batch task FUNMAUTJ corresponds to this function).

What happens during scheduling? Sage X3 will go through each selected work order and calculate operation start/end dates according to the routing and work centre calendars:

• It uses each operation’s run time, setup time, and inter-operation times (move, wait, post-operation) as defined in the routing. All these contribute to the scheduled timing. Wait and post-operation times are taken into account if parameter SCHEDWPO is enabled (as noted above).

• Operations are sequenced based on their scheduling code (the dependency relationship to the next operation). By default, operations chain one after the other (finish-to-start). X3 supports overlap scheduling if configured: if an operation’s scheduling code indicates an overlap, you can specify an overlap time or overlap quantity so that the next operation can start before the previous one fully ends. The scheduling engine will then overlap those operations accordingly. (E.g. if an operation has an overlap of 50%, the next operation might start when the previous one is halfway done.)

• The function schedules each work order independently. The standard FUNMAUTJ scheduling is an infinite capacity scheduler. It does not delay or stagger work orders based on overall resource load; it assumes unlimited capacity per work centre, scheduling each order as early as possible based on its own constraints. Thus, if two orders use the same machine, their operations might end up overlapping in time on that machine in the initial schedule. Capacity conflicts are identified later by the load inquiry (see Section 2), since FUNMAUTJ itself doesn’t resolve those conflicts (resolving overloads would require finite capacity scheduling or manual adjustment).

• The scheduling can be forward or backward depending on the requested dates on the work order. By default, X3 schedules from the work order’s planned start date forward to compute the end date. If a work order has a required due date (end date) in the past or if you explicitly choose backward scheduling, X3 could schedule backward. However, ordinarily the work order’s start date is the driver: if a WO’s start date is in the future, operations start at that date; if a start date is in the past, that’s problematic (discussed below). In all cases, the operation sequence and any lead times are respected.

After processing, the selected work orders will have updated planned start and end dates at both the header and operation levels. The work order’s Scheduling status field (SCDFLG in table MFGHEAD) typically changes from “Not scheduled” to “Scheduled”. These dates are used by other functions (material planning, load calculations, etc.) and can be viewed in work order inquiries.

1.2 Results and Key Tables

The Work Order Header (table MFGHEAD) stores overall planned dates (fields like Start date, End date, Required end) and status flags. After scheduling, the Start date and End date in MFGHEAD are set (the end date is often called the “current objective” date). The Work Order Operations (table MFGOPE) store each operation’s start and end date/time (fields OPESTR and OPEEND). These are calculated in line with the routing times and any overlaps. The operation records also carry flags or codes influencing scheduling (e.g. scheduling code, overlap values).

It’s important to note Sage X3 also has an internal Scheduling file/table (as indicated in technical docs) for the scheduling process, but the key outputs are reflected in MFGHEAD/MFGOPE. Additionally, if using the legacy Production Scheduler (which we are not covering here), there were temporary files (like OPTMFG, OPTOPE) used to interface with that scheduling engine; however, in core usage FUNMAUTJ updates the standard tables directly.

Work Order Dependencies: All operations in a work order are scheduled relative to each other, but by default separate work orders are not linked. If you have manufacturing constraints that link different work orders (e.g. a sub-assembly WO that feeds a higher-level WO just-in-time), those won’t be automatically recognised by FUNMAUTJ. (That would require planning logic or finite scheduling with constraints.)

1.3 Best Practices for Scheduling

• Keep Work Orders “in the future”: The scheduling run will skip any work orders whose start date is earlier than today.  Essentially, you cannot schedule something that should have already started. In the log, such orders will be “omitted from the run” due to a start date issue. Before running scheduling, adjust any WO with a past start date to either today or a future date (or mark it for reschedule so that the reference date can be updated when we do a load recalculation). If not, the system will not schedule it. Likewise, ensure the work order’s BOM and Routing versions are effective for the start date: if the WO is tied to a BOM version that isn’t valid on the new start date, the scheduler will also refuse to process it. The system log will indicate if a version inconsistency prevented scheduling. In such a case, either adjust the work order to use a valid version or change the start date to fall within the version’s effective range.

• Check the Log for Errors: After running FUNMAUTJ, always review the log output. Apart from skipped orders (as above), other messages can appear:

  • “The end range is prior to the start range” – if you entered an invalid range filter.
  • “Modification in process on another workstation” – if a work order couldn’t be updated due to a record lock by another user.
  • “No work order processed” – indicates that nothing met your criteria (for example, perhaps no orders were in the selected status/range).\ If locks or errors occur, you may need to rerun the scheduling when the records are free, or investigate database issues if a rollback error appears.

• Work Order Start Dates and Priorities: Normally, FUNMAUTJ schedules each order independently at the earliest possible time based on its given start date. If you want to prioritise certain orders, you can manipulate their start date or priority level. For instance, marking an urgent order with today’s start and others a week later would naturally make the urgent one scheduled first. (X3 also has a priority field on work orders, but in infinite scheduling this doesn’t reorder them; it’s more relevant in finite scheduling or MRP). If using the scheduling function in batch regularly, consider scheduling in groups (e.g. high-priority orders daily, lower priority weekly) to ensure important ones get attention first.

• Parallel Resources: If a routing operation specifies multiple resources (machines or labour) used in parallel (for example, an operation can run on 2 machines simultaneously to halve the time), make sure the number of resources field is set appropriately and that the work centre’s capacity reflects that. The scheduling function will divide the operation load by the number of resources (so duration may shorten if multiple resources are available). However, if the operation’s resource count exceeds the work centre’s defined capacity, it may not actually shorten the time – and it can cause load calculation anomalies later. Always keep an operation’s resource requirement ≤ the defined capacity of the assigned work centre. Otherwise, you will see chronic overload indications (e.g., one operation alone showing 200% load) because the system planned more units of work than the work centre can handle in parallel.

• Enter Routing Times as Total Effort (Man-Hours): When defining operation times in routings, enter the total workload required, not just the elapsed time. In other words, if an operation needs multiple resources working simultaneously, multiply the time by the number of resources. For example, if 2 operators for 3 hours are required, set the run time as 6 hours (with 2 resources). Sage X3 will then schedule it to about 3 hours of actual elapsed time on 2 resources, but the cost and load calculations will correctly reflect 6 hours of work in total. If instead you only entered 3 hours with 2 resources, X3 would schedule 1.5 hours per resource (3 hours ÷ 2) and also only calculate cost for 3 hours, underestimating the true effort. In summary, always express operation times in man-hours so that both scheduling and costing are accurate.

• Descheduling if Needed: If you ever need to undo a schedule (make a work order “unscheduled”), Sage X3 provides a separate function Descheduling (FUNMAUTD). This will reset the scheduling status and dates on selected work orders. Descheduling can be useful if you want to completely clear a schedule and start over, or remove orders from the plan without deleting them. Typically, running Recalculate Loads (FUNMIWL) with a reference date will also deschedule and reschedule orders (see Section 3), so you don’t often use FUNMAUTD alone – but it’s good to be aware of it for troubleshooting purposes.

2. Load Inquiry – Viewing Work Centre Loads (CONSMWK)

After scheduling work orders, you’ll want to analyse work centre loads to see if any resources are over or under-loaded. The Loads Inquiry (CONSMWK) function provides a period-by-period view of each work centre’s capacity versus the load placed on it. This is essentially the capacity planning view of your schedule.

What does the Loads Inquiry show? It displays the workload (hours required) and capacity (hours available) for each period in your chosen horizon, broken down by site and work centre (or work centre group). In Sage X3 V12, the results are grouped by the MRP/Scheduling periods defined in your scheduling parameters (daily, weekly, monthly) over the specified horizon. You can filter the inquiry to a specific site, a work centre group, or a single work centre.

For each period (e.g. Week 1, Week 2, … or specific date ranges), it shows:

• Total capacity (hours available in that period) of the work centre – this accounts for the number of resources and working hours per the calendar.
• Load (MRP) – hours of load from MRP planned suggestions.
• Load (MPS) – hours from Master Production Schedule (if used).
• Load (Planned WOs) – hours from work orders in Planned status.
• Load (Firm WOs) – hours from firm (released) work orders.
• Load % – the utilisation percentage = (total load / capacity) × 100, with a colour indicator bar.

The colour coding helps quickly spot load issues as defined in Sage X3: a green bar means the work centre is busy but within capacity, whereas red indicates an overload in that period (more work scheduled than available hours). An entirely blank or white bar means that work centre has no load in that period (idle capacity).

You can click on a specific period/cell and often drill down to see which operations or work orders contribute to that load:

• Using the Action icon on a period or on a work centre line, you may find options like Operation loads or Load in progress. This will show the list of individual operations (with their work order numbers, products, quantities, times) that make up the load. Essentially, this is where you see all relevant operations, including those from suggested or unscheduled orders, as a detailed list.

• There’s also a related Graphical loads inquiry (Manufacturing > Inquiries > Loads > Graphical Loads) that presents the same information in a bar chart format. In the graphical view, you can zoom in to see details for a given period. 

2.1 The OPERATIONS vs WORKLOAD Tables (Understanding the Data Model)

To clarify the behind-the-scenes data:

• WORKLOAD table – Stores an aggregated record for each Work Centre per period. This includes fields for capacity hours and load hours (likely split by source type) for that period. This table is refreshed when you run Recalculate loads (FUNMIWL). Notably, it only includes load from scheduled operations (i.e. firm/planned work orders that have been scheduled with dates). This is why the Loads inquiry focuses on confirmed load; it’s giving you load vs capacity comparisons that are meaningful (you generally compare committed work to capacity).

• OPERATIONS table – Contains an entry for every operation within the load horizon, regardless of status (firm, planned, or even suggested). It is used for comprehensive load listings. For example, a work order suggestion from MRP (which is not firm and not scheduled) would not appear in WORKLOAD, but an entry for its operations would appear in OPERATIONS so that total pending work can be analysed. The trade-off is those unscheduled operations don’t have a defined slot in time, so they can’t be summed into a capacity bucket reliably. Therefore, OPERATIONS is used for detailed inquiries (without capacity comparison) whereas WORKLOAD is used for the aggregated view with capacity.

In practice, after you run scheduling and then run load recalculation, the WORKLOAD table is populated with the hours each work centre will spend on work orders in each period. The Loads screen pulls from that. If you have some planned orders not yet scheduled, you might see the “Planned WO load” column empty because until they’re scheduled (given dates), they don’t contribute to the buckets. However, if MRP was run with load calculation turned on, it might have tentatively distributed suggested order load into periods in the WORKLOAD table as well. (In some configurations, MRP can populate projected load for suggestions, but generally suggestions are handled by scheduling or by FUNMIWL when you include them.)

Bottom line: Use the Loads inquiry to identify overloads: any red bar means that in that period, the work centre is over capacity (the sum of hours required by scheduled work exceeds available hours). Grey or green bars mean there’s some headroom, whereas white means idle time. This helps production planners decide where to adjust: e.g., if a particular week shows red for the Milling Centre, you may need to defer some work orders to later weeks, add an extra shift or overtime (increase capacity), or allocate some operations to an alternate work centre (if available).

2.2 Best Practices for Load Analysis

• Recalculate Loads Regularly: Always ensure you run the Recalculate loads process (FUNMIWL) whenever there have been significant changes (new orders, orders completed or rescheduled, calendar changes, etc.). The inquiry will only be as accurate as the last load calculation. A good practice is to schedule FUNMIWL to run nightly or weekly so that the load data is up-to-date each morning.

• Focus on Overloads: Use the visual cues to quickly scan for red overload indicators. Those periods denote bottlenecks or over-utilisation that need addressing. Drill down into those periods to see which orders/operations are causing the overload. This information can guide you to either expedite some orders earlier (if possible), push some to later periods, or increase capacity. Keep in mind that since the scheduling was infinite, overlapping operations from different orders all piled into the same day will show as overload – which is expected and highlights where manual intervention is needed.

• Check Underutilised Capacity: Likewise, if you see a lot of green or especially white (0% load) periods, that indicates under-utilised capacity. There may be an opportunity to pull in some production earlier to level the load, if material availability and priorities allow. The goal is to smooth the production load where feasible, avoiding peaks and valleys.

• Use Work Centre Group View: If you have multiple work centres in the same group (i.e., capable of similar work), you can define a Work Centre Group and view load by group. This gives an aggregate picture (e.g. total capacity vs load for all paint booths together). An overload at group level means all similar resources combined are overloaded – often you must still drill down to individual centres to see which specific one is over capacity.

• Consider Alternate Work Centres: If your routing allows certain operations to run at alternate work centres, consider moving operations from an overloaded centre to one with available capacity. Sage X3 supports specifying alternate work centres in the routing; however, the automatic scheduling won’t swap them for you (unless using the advanced optimizer in the old scheduler). You’d have to manually adjust the work order routing to use an alternate centre if one is free. The Loads inquiry can help spot if one machine is over and another is underloaded in the same timeframe.

• Real-Time vs Batch Data: Remember that the Loads inquiry is a snapshot based on the last calculation. If you have been making manual changes to the schedule (e.g., unscheduling a WO, or a WO gets completed early), those won’t be reflected until a new load calc is run. For example, completing a work order will reduce load (its remaining operations drop out of the load). As a quick fix, you can run Recalculate loads on-demand after major updates to see immediate effects.

• Graphical View for Communication: The Graphical Loads inquiry can be useful to present the load vs capacity in meetings or reports, as it plots a bar chart of capacity and load by period, using the same colour scheme. While you can’t change anything in that view, it’s great for a visual management report. You might export or screenshot it for communication with stakeholders about upcoming production stress periods.

• Use the Right Inquiry Filters: By default, the Loads inquiry compares capacity against scheduled orders only (the WORKLOAD table). Make sure your inquiry settings include all relevant orders. For example, using the inquiry code “ALL” will include MRP suggestions and all orders regardless of status, giving a full picture of load. Filter settings in the inquiry can cause certain orders to be excluded (e.g. unscheduled suggestions might be hidden by default). If something seems off or an expected load is missing, try the “ALL” inquiry code or adjust filters, and compare the Operations listing against the Workload summary to identify any orders that are not accounted for. This can help catch load that hasn’t been scheduled or calculated yet.

3. Recalculate Loads (FUNMIWL)

The Recalculate loads (FUNMIWL) function (menu Manufacturing > Batch processes > Recalculate the loads) is a critical batch process that synchronises the load data with the current state of work orders and capacity. In essence, this function rebuilds the WORKLOAD table “buckets” from scratch according to your defined periods, by looking at all relevant work orders and their operations. You should run this whenever there are changes that could affect capacity planning . For example, after scheduling new work orders, after changing a work centre’s calendar or capacity, after making manual scheduling adjustments, or simply on a regular schedule (daily/weekly) to keep data fresh.

3.1 What Recalculate Loads Does

When you execute Recalculate loads (FUNMIWL), it will prompt for:

• Production Site (to choose the site to process).

• An optional range of Work Centres (you can limit the recalculation to specific work centres, or leave blank to include all).

• A Reference date (the starting date from which to (re)build the load buckets).

• Options (checkboxes) typically labeled Reschedule orders in the past (or “Rescheduling” in arrears) and Reschedule optimized/forced operations.

On clicking OK, the process goes through the following steps for the selected site:

• Identify relevant work orders – It finds all work orders whose start date is later than or equal to the reference date and that have at least one operation on one of the selected work centres (or any work centre if none specified). In other words, it will ignore any production that is already in progress or started before the reference date. (The reference date effectively declares “I only care about loads from this date forward.”)

• Deschedule the orders – It temporarily unschedules those work orders (clearing their current schedule, freeing up their operations from any existing bucket allocations).

• Reset and rebuild load buckets – It clears out the existing capacity vs load entries and then recalculates them anew:

  • It will create period records from the reference date onward, based on the defined scheduling periods, up to the specified horizon (or default horizon from parameters).
  • It re-fetches each selected work order and reschedules it (essentially applying the same scheduling logic as FUNMAUTJ but now as part of this batch) one by one. This assigns dates/times to operations anew – effectively, Recalculate Loads performs a fresh scheduling of all the included orders relative to the reference date.
  • If the option to reschedule past orders was checked, any work order that had a start date before the reference date will be moved to start exactly on the reference date. In other words, the reference date becomes the new Day 1 for any orders that were “in arrears”. This ensures even overdue work orders are brought into the current plan going forward.
  • If the option to modify operations with forced dates (optimised orders) is checked, then even operations that had fixed/forced dates (perhaps from a prior manual adjustment or an optimisation run) can be moved by this process. If unchecked, those operations remain anchored on their dates and the recalculation works around them.
  • Allocate load into buckets – As it schedules each operation, it allocates that operation’s hours into the corresponding period bucket for its work centre in the WORKLOAD table. At the same time, it calculates each period’s capacity from the work centre’s calendar. The result is a fully refreshed set of load vs capacity figures for each work centre and period from the reference date onwards. Essentially, the WORKLOAD table is rebuilt to match the newly scheduled operations.
  • The work orders themselves also get their dates updated (since it effectively rescheduled them). So MFGHEAD and MFGOPE will reflect the new schedule after this run.

In summary, Recalculate Loads “resynchronises” the load data with the current production plan by re-planning all open work orders starting from a given date. It’s especially useful if:

• You have some work orders in the past that haven’t been completed – by moving them to the reference date, the system includes their remaining load in the future periods.
• You changed bucket sizes or the period definitions, the recalculation will rebuild buckets accordingly.
• You suspect the load table might be out of sync (perhaps due to manual changes or a missed schedule run) , running this will correct it.
• You simply want to batch reschedule everything as of now. (Common use: at the start of a week, reschedule all open orders from today onward to see a fresh plan.)

The function can be run interactively or in batch (there is a batch task for FUNMIWL as well). Many companies schedule FUNMIWL nightly so that each day’s load report is current.

3.2 Key Options and Their Effects

Clarifying the two key checkboxes in FUNMIWL:

• “Reschedule orders which are in arrears” - If checked, any work order that started before the reference date will be treated as needing rescheduling. The reference date essentially becomes its new start date. For example, if reference date is 01/09/2025 and there was an open WO that was supposed to start 25/08/2025 (last week) and finish by 30/08, this process will reschedule that WO to start on 01/09/2025 instead. All its remaining operations shift accordingly. If this option is not checked, then that WO from 25/08 would simply not be included in the load recalculation (since its start < reference, it fails the selection criteria). That would effectively drop its load from the forward-looking buckets, which might be unrealistic since in reality that work still needs to be done. Therefore, in most cases you do want to tick the reschedule-arrears option to ensure no pending work is left out. Only leave it unticked if you deliberately want to exclude past-due orders (e.g. maybe they were handled manually or cancelled outside the system).

• “Reschedule optimized/forced operations” - If checked, the recalculation will ignore any fixed dates on operations and freely reschedule them. (In previous usage, “optimized orders” refers to those already sequenced by the old Production Scheduler or manually forced to dates.) If unticked, the process will keep any operation with a fixed/forced start date at that date and schedule other operations around it. For example, if an operation had a fixed start on 10/09, the recalculation would leave it on 10/09 (even if it was technically “in arrears” relative to a 01/09 reference). Generally, if you are not using any separate detailed scheduling tool, you might not encounter forced operations often. It’s typically safe to allow rescheduling of all operations (check this box) so that the tool can fully recompute the schedule. If you know certain operations/dates must remain as-is, leave it unchecked to respect those constraints.

3.3 Outcome of Recalculate Loads

After running FUNMIWL:

• The WORKLOAD table is fully rebuilt for all selected work centres from the reference date forward. All capacity and load figures are up-to-date as of that moment.

• The Work Orders (MFGHEAD) have new start/end dates if they were moved. The SCDFLG (scheduling status) on each will be “Scheduled” (not “Not scheduled” or “To be rescheduled” anymore, since we just scheduled them). Essentially, every included work order is now considered scheduled as of the reference date or later.

• The MFGOPE (operations) records have updated dates too, and any “frozen” status they had might be cleared if we allowed forced ops to move.

(Note: This function does not modify closed or completed work orders as those are outside its scope.)

Be cautious if you run Recalculate Loads for only a subset of work centres: other work orders using different work centres won’t be touched. You could end up with some WOs partially rescheduled (those ops on included WCs move, others remain). It’s usually better to run it for all work centres unless you have a specific reason to isolate it (like focusing on one department’s resources). The selection by work centre is there for convenience or performance if needed.

3.4 Best Practices & Tips for Recalculation

• Use a Two-Pass Recalculation: To ensure the Loads Inquiry data is fully accurate, it’s recommended to run the Recalculate loads process twice in succession: first with the rescheduling option checked, then a second time with it unchecked (i.e. one run with “Reschedule orders in arrears” = Yes, then run again with it = No). This two-pass approach is advised because the first run brings any past-due orders forward and reschedules them, while the second run (without rescheduling) then updates the load distribution with those orders now in the current timeline. In effect, the first pass handles repositioning of late work orders, and the immediate second pass finalises the load calculations for all orders. Following this sequence helps avoid any gaps or omissions in the workload data.

• Regular Schedule (Automate It): Consider automating FUNMIWL on a regular basis. For example, schedule it to run every night or every Sunday evening. Regular recalculation ensures your load inquiry (Section 2) is always working with current data. Sage explicitly notes you should run it especially after any modification to a work centre (capacity or calendar). This prevents stale or inconsistent data in the WORKLOAD table. 

• After Capacity Changes: If you update a work centre’s capacity or calendar, remember that existing load buckets won’t automatically adjust. The recommended steps are: (1) Reschedule the affected work orders (via FUNMAUTJ or FUNMIWL) so their operation timings align with the new capacity (for instance, if new working days have been added, operations might now be allowed to move into those days). (2) Run Recalculate loads to rebuild the capacity and load table with the new values. Until you do this, the Loads inquiry may still show capacity or load based on the old settings.

• When Load Data Seems Off: If you ever notice that the load inquiry isn’t matching reality (e.g., the sum of loads of individual operations doesn’t equal the bucket load shown, or an overload is indicated where your calculations say there shouldn’t be one), it’s likely the data is out of sync. The first remedy is to run FUNMIWL to regenerate the workload table from scratch. This often resolves discrepancies. If issues persist, dig into your calendar definitions: ensure time table schema assignments are complete for all working days (no blanks that rely implicitly on DEFDIH). If a day in a calendar had no schema and DEFDIH was not set, the load calc might have treated that day as zero capacity but scheduling might have still placed work there (or vice versa), causing mismatches. So always define a default day schema via DEFDIH as mentioned earlier. Also verify that an operation’s required number of resources does not exceed the work centre’s capacity. If, for example, an operation needs 4 operators but the work centre is defined with capacity of 2, the scheduling might still schedule it (because infinite scheduler doesn’t mind), but the load calculation logic will show that as 200% load for one operation. The solution is to align these: either split the operation or update the work centre’s defined capacity. In short, clean master data combined with a fresh FUNMIWL run should keep load figures sensible.

• “No work order processed” Issue: If the FUNMIWL log reports “No work order processed”, it means none met the criteria. Possibly your reference date is too far in the future (no orders start after it), or you filtered to a work centre with no pending orders. Another possibility: if you left “reschedule past” unchecked and all open orders actually start before your reference, it would skip all of them. The solution is to adjust your parameters: use an earlier reference date or enable the reschedule checkbox to include past orders. In general, you want to include all relevant WOs; otherwise, a “nothing processed” message simply indicates there was nothing to do in that range.

• Locking and Performance: Recalculate Loads will lock the work orders it’s processing (to update them). If it’s a large run (many WOs), run it during off-hours to avoid conflicts. If it encounters a lock (someone editing a work order at the same time), that order will be skipped and a message will be noted in the log (e.g., “Modification in process on another workstation”). Make sure no one is modifying WOs when you run these batch jobs, or simply rerun for any that were missed. Also note that the process can be resource-intensive if you have a lot of orders; monitor its performance and consider limiting the range (by work centre or date) if needed to complete within a suitable time window. 

• After Running FUNMIWL – Next Steps: Once you run FUNMIWL ( using the two-pass sequence), immediately check the Loads inquiry to see the effect. You should see load redistributed starting exactly at the reference date. For instance, if many orders were past-due and you used today as the reference date, expect the load on today and this week to spike (since those all got moved to start now). That tells you how much catch-up work is now planned. You might then decide to manually stagger some of these orders, adjust priorities, or call a meeting to address the overload. After making any manual adjustments, run FUNMIWL again to refresh the picture. Essentially, FUNMIWL gives you a new baseline plan, you then refine the plan as needed.

• Keep an Eye on “Last Calculation Date”: In the Scheduling Parameters (GESPTA) screen, Sage X3 records the date of the last load calculation. Ensure this date is recent. If it’s old, your load data is stale. Always update it by running FUNMIWL when needed. Regular scheduling of FUNMIWL, as noted, will prevent this from ever drifting too far out of date.

4. Summary of Best Practices and Troubleshooting

To wrap up, here are key best practices and common issues related to scheduling and load functions, and how to address them:

Double-Run Load Recalculation

For accurate load data, run the Recalculate Loads (FUNMIWL) process twice back-to-back: first with rescheduling checked, then again without. The first pass reschedules overdue orders, the second updates the loads.

'ALL' Filter in Load Inquiry

Remember that Load Inquiry (CONSMWK) by default shows only scheduled orders. Use the inquiry code "ALL" or adjust filters to include planned/suggested orders if needed. This helps ensure you're seeing the full workload vs capacity.

Routing Times = Total Man-Hours

Enter routing operation times as total effort. For example, 2 people working 3 hours should be entered as 6 hours. Sage X3 will split it across resources for scheduling, and cost/load calculations will reflect all 6 hours of work.

Common Issues & Solutions: The table below summarises some common scheduling/load issues and how to resolve them:

Finally, always cross-check the system’s plan with shop floor reality. Sage X3’s scheduling and load functions provide a structured plan, but human judgment is needed to resolve conflicts, since the base scheduler assumes infinite capacity. Use the tools to identify where the problems are (overloads, late orders, idle gaps), then apply operational decisions.