MTO - Configuring Custom Metadata for Scheduling & Capacity

Navigate to Custom Metadata via Setup > Custom Metadata Types, select 24Flow Schedule4MTO Settings, and then click the button Manage 24Flow Schedule4MTO Settings. Then select the specific setting, 24Flow allows you to work with multiple of these settings.

These settings comprise:

• General scheduling settings.

• Settings specific to capacity calculations both for teams and for equipment

The leading factor for determining capacity can be defined in multiple ways. The way the capacity calculation is determined is based on the values of the Schedule Leading field in the Teams and Equipment object.

• Settings specific to automated scheduling at the operation level.

These settings are explained in more detail below.

Production Order Scheduling

• Schedule Offset (min): Can be considered as a safety margin or buffer, i.e. it is an additional time taken into account when scheduling, beyond the touch time and non touch time for the operations.

• Batch Size Schedule Production Orders: This parameters avoids hitting some Salesforce platform limitations when scheduling a large number of orders. If in doubt, set this parameter to 200 as a starting point.

• Workhours Base Timezone Id: This parameter is required only in case the automated process user is in a different time zone than the time zone your plant is located in.

• Schedule Sequence Logic: There are three sequence logic options the scheduler can take in to consideration.

  • Sequence: scheduling according to the sequence numbers given on the operation in ascending order.

  • Sequence grouping: same as sequence but if sequence numbers are equal they are considered a grouping. Behaviour for forward scheduling, the start of the next operation is the latest end of the previous sequence group. Behaviour for backward scheduling, the calculation for the previous operation starts from the earliest startdate of the next grouping.

  • Predecessor: scheduling according to the predecessor lookup in operation.
    When nothing is set, sequence is taken.

• Schedule Rebounce: If the scheduling type is backwards, the calculation can suggest a planned start date that lies in the past, which is impossible. In this case, the calculation of the production order happens with scheduling type forward.

• Schedule Begin Of Day Forward: When Scheduling with type forward, it will set the startdate to the beginning of the workday.

• Schedule Begin Of Day Backward: When Scheduling with type backward, it will set the startdate to the beginning of the workday.

• Operation - Touch Time Field (min.): defines the field to use as touch time for an operation. 24Flow is by default using the field sfy24__TouchTimeQrmMinutes__c. Note that the touch time should be expressed in minutes.

• Operation - NonTouch Time Field(min.): defines the field to use as non-touch time for an operation. 24Flow is by default using the field sfy24__NonTouchTimeQrmMinutes__c. Non-touch time is the buffer time between operations. Note that the non-touch time should be expressed in minutes.

• Prod. Ord. - NonTouch Time Field (min.): In the case you work with main- and sub-production orders, there can be buffer time between a sub order and its parent. The Prod. Ord. NonTouch Time Field contains API name of the field on the Production Order that contains this buffer value (expressed in minutes).

• Schedule - Run Equipment Capacity: After Scheduling the production orders, the capacities will be calculated on equipment level.

• Schedule - Run Team Capacity: After Scheduling the production orders the capacities will be calculated on team level.

• Schedule - Publ. 24Planner Event: Launch a Salesforce Platform Event to 24Planning when the production order scheduling is finished.

Workday

The first section of parameters define the start- and end-time of a workday as well as the pause. Hoover over the help icon if in doubt on how to complete these fields.

The second section of parameters define on which weekdays the company is opened. This is a first selection done on a high level. So if the checkbox is not set, the day will not be evaluated by the scheduling logic. If more granularity is needed, you can specify it clearly on the Employee, Team or Equipment records.

Capacity General Setting

The datetime fields used in this setting will determine the required capacity of the operation.

• Capacity Reference Start Field: The date-time field api-name set here will be used to determine the required capacity of the operation. If no value is given, the 24Flow standard field ‘Planned Start Date - sfy24__Start_Date__c’ is used.

• Capacity Reference End Field: The date-time field api-name set here will be used to determine the required capacity of the operation. If no value is given, the 24Flow standard field ‘Planned End Date - sfy24__End_Date__c’ is used.

Capacity Settings Team

These settings are used when calculating the capacity at the team level. When multiple (hierarchical) teams are defined, the capacity will be computed at each of these team levels.

• Capacity Primary Team: The field that contains the primary team. If schedule leading is Team, the capacity is calculated as the minutes filled in on the field Capacity Renewable Daily or on the Workschedule fields. If Schedule leading is Employee, the capacity is calculated as the sum of the capacities of the employees that belong to that team.

• Capacity Secondary Team: If you have multiple forms of teams, e.g. a subteam, you can define a second team lookup field on the operation object. If filled in, the capacity calculator will also calculate the capacity on the secondary team.

• Capacity Tertiary Team: Third team lookup field on operation.

• Batch Size Team Daily Capacity: This parameters avoids hitting some Salesforce platform limitations.

• Batch Team Capacity Start Relative: The number of calendar days from current date the start date of the operations must be taken to take into account for the team capacity calculation. E.g. today is 04/06/<yyyy>, if this value is -3, then all operations from start date 01/06/<yyyy> are taken into account.

• Batch Team Capacity End Relative: The number of calendar days from current date the end date of the operations must be taken to take into account for the team capacity calculation. E.g. today is 03/06/<yyyy>, if this value is 3, then all operations less then or equal to end date 06/06/<yyyy> are taken into account.

• Capacity Subtract Unavailable Time: Subtract unavailable time from the team capacity.

• Capacity Team Weekly After Daily: Compute the weekly team capacity after an update of the daily capacity.

• Capacity Team run Equi Daily After: When set to true, it will launch a calculation of the equipment capacities after the team capacities have been calculated.

• Capacity Team Publish 24Planner Eve: Launch a Salesforce Platform Event to 24Planning when new team capacities are stored.

Capacity Settings Equipment

• Equipment Field on operation: Lookup field from the operation to the equipment.

• Team Equipment on Employee Planning: Used to compute equipment capacity when the leading schedule is set to Employee. This is the lookup field to team equipment set on the object Employee Planning.

• Batch Size Equipment Daily Capacity: This parameters avoids hitting Salesforce platform limitations.

• Batch Size Equipment Weekly Capacity: This parameters avoids hitting Salesforce platform limitations.

• Batch Equi. Req. Capacity Field (min.): This field is used for determining the capacity required by a specific operation. By default, 24Flow uses the touch time of the operation for this: sfy24__TouchTimeQrmMinutes__c.

• Batch Equipment Capacity Start Relative: The number of calendar days from current date the start date of the operations must be taken to take into account for the equipment capacity calcuation. E.g. today is 04/06/<yyyy>, if this value is -3, then all operations from start date 01/06/<yyyy> are taken into account.

• Batch Equipment Capacity End Relative: The number of calendar days from current date the end date of the operations must be taken to take into account for the equipment capacity calculation. E.g. today is 04/06/<yyyy>, if this value is 3, then all operations less then or equal to end date 07/06/<yyyy> are taken into account.

• Capacity Equi Subtract Unavailable Time: When checked, the unavailable time is subtracted for equipment capacity calculations.

• Capacity Equi Weekly After Daily: Calculate the weekly load on equipment after the daily load has been computed.

• Capacity Equipment Publish 24Planner Eve: Launch a Salesforce Platform Event to 24Planning when new equipment capacities are stored.

Capacity Filters

The capacity filter selects the subset of operations for which the capacity is computed. This applies to capacity calculations for teams and equipment.

Operation Grouping

The parameters described here govern the way 24Flow will automatically schedule operations. Before getting into the details, we first explain general concepts.

The planning horizon is the window within which unplanned orders will be planned. The selection starts on the current day and extends for a predefined number of calendar days (the planning horizon), taking the weekend into account.

Because you may not want to replan already planned orders for the near term, 24Flow introduced the concept of a freeze horizon and a fixed horizon.

The fixed horizon means that 24Flow’s automatic scheduling will not alter anything during this time window, even when there is still capacity available.

The freeze horizon means that 24Flow’s automatic scheduling will leave all already scheduled operations untouched but may add additional operations when capacity is available.

This implies that when 24Flow starts a re-planning exercise, all orders that are in the planning window, but outside the freeze and fixed window will momentarily become unplanned and will be replanned for optimum efficiency. The minimum freeze and fixed window is zero days, which means that every planning run, all orders will be replanned. The maximum freeze window equals the planning window which means that 24Flow only optimizes new orders but does not touch orders that have previously been planned.

Regardless of the definition of fixed, freeze and planning horizon, the Operation Grouping logic will NEVER replan operations for which the corresponding order has been released.

• Production Order Date Field: This is the date field that will determine whether or not the operation will fall into the planning horizon. This could e.g. be the delivery date that is retrieved from the ERP system.

• Group Op. Selection Horizon: Planning horizon as explained above.

• Group Op. Fixed Horizon: Fixed horizon as explained above.

• Group Op. Freeze Horizon: Freeze horizon as explained above.

• Group Op. Free Horizon: Horizon where orders can get rescheduled and added according to the grouping scheduler.

• Group Op. Capacity Threshold: 24Flow allows you to specify a correction factor, i.e. you do not plan at 100% capacity but for a reduced capacity. Currently, this parameter is set at 90%.

The automated scheduling for operations can group operations based on multiple fields. Currently four levels are supported, and for each of the levels you can select an ascending or descending order. To make it practical, let’s consider a concrete example to see how this works:

Assume you have defined two fields: priority and product type, both ascending. 24Flow will then first schedule operations from low to high priority. When each level of priority, it will consider the product type and schedule the operations of orders of the same product type before moving on to the next product type.

• Group Op. Possible Equipments: This is the field that determines the list of preferred equipment the operation should be assigned to. E.g. first check whether capacity is available on machine X, if not, check for machine Y etc.

• Group Operation Equipment Assignment: Lookup field on the operation object that will be used by the grouping algorithm to assign a specific operation to a particular equipment.

• Operation Grouping Offset (min.): Offset in minutes between the grouped/ chained operations. Can be useful to use in conjunction with the 24Planning settings - View Preset - Time Resolution Increment

• Group Op. Last Operation per Prod.Ord: Only use the last operation in the selection in case it contains multiple operations for the same production order. This avoids getting into a loop and replanning operations multiple times.

• Group Op. Run Equipment Capacity: After running the grouping logic, the equipment capacities are calculated.

• Group Op. Run Team Capacity: After running the grouping logic, the team capacities are calculated.

• Group Op. Publ. 24Planner Event: 24Planner is updated when operation grouping is done.

Operation Grouping Filters

• Group Op. Filter Field: Add an additional SOQL WHERE filter to select operations. E.g. If you only want to select operations that are not finished for the plant 9000 a possible statement could be Group Op. Filter Field: Plant__c = '9000' AND sfy24__Is_Finished__c = FALSE

Don’t use enters in the WHERE filter

Operation Grouping - Dynamic Duration

Advanced configuration when the touch time of the operation depends on several parameters. This settings allows for the operation grouping logic to calculate the touch time dynamically depending on these parameters.

This functionality is best explained via an example. We will use the object Equipment Product, but the principles are applicable to any Salesforce object.

Firm X has 2 machines and 2 products:

• Equipment 1 has a speed/product of 2 minutes for Product A and 1 minutes for Product B.

• Equipment 2 has a speed/product of 3 minutes for Product A and 1 minute for Product B.

These speeds are defined on the Equipment Product object. This object will hold a record for each combination, e.g. a record with a lookup to Equipment 1 and a lookup to Product A and a value of 2 in a duration field.

In this scenario, if an operation with required quantity 50 of Product A is made on Equipment 1. The duration will be 100 minutes (50x2).

Now we just have to set the fields for MTO so it can dynamically calculate the duration.

For the operation to know the speed of product A on Equipment 1, it needs to look up the speed on the Equipment Product record.

• So, on the operation record the following fields have to be filled in (see also the section on extending the data model):

  • Dynamic Duration Object Name: API name of the object that contains the dynamic duration. For our example above, this would be Equipment_Product__c. This way the Dynamic grouping knows where to look for the correct record.

  • Dynamic Duration Record Id: This is the record where the dynamic duration of the operation can be found. In our scenario the record for product A and Equipment 1 had the id ‘a1bd1000000fZoEAAU’.

• In the custom metadata settings, the following has to be filled in:

  • Group Op. Dynamic Duration: JSON structure with all the fields for the dynamic duration. The following field names are required:

    • touchTimeFieldMin: The API name of the field that contains the touch time in minutes in the duration object.

    • operationQuantityField: The API name of the field in the Operation object that contains the quantity that has to be multiplied with the touch time. If blank/null it is just the given touch time. In our scenario this quantity is 50.

    • operationDynamicDurationRecordField: The API name of the lookup field in the operation for the dynamic duration record. For instance in the scenario of the equipment product, this field is populated with Equipment_Product__c.

    • filter: Define a filter for the selection of the operations. the “value” in the filter refers to the API lookup on the operation and the fieldname to lookup in the dynamic duration object. In the example below, only operations that have a value in ‘ProductId__c’ which is defined as ‘Product__c’ on Equipment_Product__c or operations with a value for ‘sfy24__SchedMtoEquipment__c’ which is called ‘Equipment__c’ on the Equipment_Product__c object are selected.

    • durationObjectName: Object name where the dynamic duration is found. Put the api name of the object that contains the durations here.

• Scenario JSON example in the case that touch time is dependent on Equipment and Product: [{"touchTimeFieldMin":"Duration_In_Minutes__c","operationQuantityField":"sfy24__Quantity_Required__c","operationDynamicDurationRecordField":"Equipment_Product__c","filter":{"rows":[{"value":"ProductId__c","rows":[],"operator":"Equals","nextRowOperator":"AND","isString":null,"isPicklist":null,"isNumeric":null,"isGroup":false,"isCheckbox":null,"fields":[],"fieldName":"Product__c"},{"value":"sfy24__SchedMtoEquipment__c","rows":[],"operator":"Equals","nextRowOperator":null,"isString":null,"isPicklist":null,"isNumeric":null,"isGroup":false,"isCheckbox":null,"fields":[],"fieldName":"Equipment__c"}]},"durationObjectName":"Equipment_Product__c"}]