|| The “XML Import settings” allows a user to overwrite control settings either already specified or missing in imported data. To add or overwrite a setting select the relevant group and the desired “Option” and press the arrow down button and specify the desired value in the table.
If the override column is checked the setting added in the table will replace a possible value supplied as part of the import data. If override column is not checked the setting specified will only have any effect if the same setting is not already part of the imported data.
Currently import settings flags can be specified on 4 different groups:
Over all settings – will rarely need to be overwritten
Settings related to how ROB-EX will treat production orders and operations on import. Settings in this category are the most common to overwrite. The following table describes the different options, the most common options to overwrite have been underlined.
- when importing
<Progress> automatically change operation status to complete if there is no outstanding work left on the operation (i.e. when all planned quantity/hours have been reported).
- let the user define if ROB-EX should delete RawMaterialAccess attached to an operation in the plan, but not present in the import. RawMaterialAccess attached to Operations not present in the import will be preserved no matter how this setting is set. The default value for this attribute is “true”.
- defines if after import, and before the imported production orders are scheduled, all the production orders that wasn’t in the XML file have to be deleted silently from ROB-EX. Important: In order to get this function activated, the XML file has to contain at least one production order. The default value is false
- defines the time of the day ROB-EX should use for delivery dates (most of ERP system just have a date without specification of the time). As default this time is set to “23:59”.
- By default ROB-EX will not switch the status backward to NEW for a production order with higher status. To enable this set this attribute to ”true”. This attribute can also be defined per production order in the tag
- Ignore the
<Progress> tag on import
- By default operation descriptions are overwritten on import for existing operations. Specify “true” if a change made in ROB-EX should win
- By default production order descriptions are overwritten on import for existing operations. Specify “true” if a change made in ROB-EX should win
- When defined as “true” then ignore any specific calendar exceptions for resources on import. With this option “true” the planner can manually maintain the resource specific calendar in ROB-EX while still importing the general calendar from the ERP system
- If the ERP system does not supply any material date it will by default be set to the time NOW first time an order is imported
- This setting is used when the the attribute is set to -1 – indicating that ROB-EX during import should automatically recalculate the operation efficiency to respect the supplied operation start and end dates from the ERP system. If this setting is set to “true” check if the newly calculated efficiency is below 100% and then set it to 100 if that the case. If rule is applied the end date/time of the operation will however no longer match the end date received from the ERP system.
- What side of the integration wins concerning status updates. The default value is source (the ERP system).
- defines which side of the integration controls operation start and end times, i.e. Opr.startCal and Opr.endCal. As default it is the ERP system that is time master (oprTimeMaster=”source”). This means that during the import process the data in ROB-EX will be overwritten by the start and end times coming from the ERP system for every operation. In the contrary, if ROB-EX is defined as time master (oprTimeMaster=”destination”), imported operation start and end times will be ignored in case values already exist inside ROB-EX. Note that this attribute can be defined generally in this tag or per production order in the tag.
- defines which side of the integration decides how modifications in the operation sequence should be managed. As default the ERP system is the master (opSeqStructureMaster=”source”), it means that ROB-EX in the event of a difference, will overwrite the operation sequence definition as specified in the imported XML document. On the other hand, if ROB‑EX Gantt is structure master (opSeqStructureMaster=”destination”) any differences in the structure between ROB‑EX Gantt and the XML file, will be ignored. This attribute can also be defined per production order in the tag.
- states if parallel operations (i.e. an overlap of 0) should be detected using the method described in section the chapter “7.7.2 Definition of parallel operations” of the XML Import specification document . If false is specified overlap is only determined based on the attributes Opr.overlapCount and Opr.overlapHours. The default value is true.
- For existing operations only the progress is imported. All other things are ignored.
- If recalcPlannedStartEndOnFirstStart is set “true”, do the following the first time an operation is started – i.e.
<Progress> is reported on it:
a. If realStartCal is specified, plannedStart is updated to this value and plannedEnd is calculated from plannedStart
b. If realStartCal is NOT specified, but lastStartCal IS, plannedEnd is set to the calculated actualEnd and plannedStart is calculated backwards from plannedEnd.
c. In all other situations this setting is ignored.
This setting will impact the result of calculating lag/lead.
- Defines if an existing order is automatically re-planned when a new delivery time is imported on the order (new meaning “not the same date”). The rule is only applied for orders where oprTimeMaster=“destination”!
The default value is “off” causing this setting not to have any effect. When the setting is not “off”, it will have the name of the planning strategy to use, i.e. “forward”, “backward,deliverycalendar,unlimited” etc.
When a delivery time on an order during import has been detected as changed, then ProdOrder.oprTimeMaster for the order is overwritten to “source” and ProdOrder.planStrat is overwritten with the value supplied (i.e. “forward”, “none” etc.). The effect is that the order, even though oprTimeMaster by default is “destination”, is re-planned according to the specified rule when the delivery date is changed in the ERP system. Note that the rule “none” has the effect that the supplied operation start/end times from the ERP system will be used.
This setting is useful in situations where ROB-EX is master for operation start/end times (oprTimeMaster=“destination”), ensuring that an order is still respecting a change to the delivery date made in the ERP system.
- defines which side of the integration decides how differences between current resource selection for an operation should be managed. As default the ERP system is the master (resourceMaster=”source”), it means that ROB-EX in the event of a difference, will choose the resource selection from the XML import file. On the other hand, if ROB‑EX Gantt is resource master (resourceMaster=”destination”) any differences in currently selected resource between ROB‑EX Gantt and the XML file, will be ignored.
- The relation ship between sub-order and main order is reversed.
- This setting specifies how
<Progress> should be allocated to operations having been split in ROB-EX. As an example Operation A in ROB-EX has been split into A-1 and A-2. This rule will decide how progress imported from the ERP system on operation A is divided between the two new operations A-1 and A-2.
Important: These rules will only be applied when the original operation A is imported. The rules are not applied in case the XML already specifies A-1 and A-2 in the XML (which is the case when importing progress using the Time and Attendance plugin)
- selects either “even” or “forward”, depending on overlap. If the operation is running in parallel (offset is 0), the “even” import progress rule is used, else “forward” is used. This is the default rule used.
- assumes the Operation is not split, and applies the data directly to the original operation, ignoring any potential split children. This is the default rule used for non-split operations.
- splits the progress data evenly across all split children, not taking any planned workload into consideration. This rule works best for an operation split over multiple Resources, where all split children are synchronized (have same start, end and length)
- splits the data across the split children, filling the split children in chronological order (by start time). If any progress data is left, when all Operations have been filled, the last operation will receive the extra progress data. This rule works best for an operation split into multiple operations all on the same Resource.
- splits the data across all split children weighted, taking the planned workload of each operation into consideration to determine the weight. The split children will be filled at the same percentile rate, causing them to finish at the same time. This rule works best for an Operation split over multiple Resources, where all split children have the same start time, but not necessarily the same length.
- splits the data across the split children in a chronologic fashion, taking the start time, resource calendar etc into consideration, trying to have the split children start when progress from the chronological previous children have passed the start time of the child. This rule works best for an Operation split over multiple Resources, but where the split children not necessarily have the same start time or the same length. If the split children are all on the same Resource, this rule works like the “forward” rule (but “forward” would be preferable in that case, as it would be faster). If the split children are synchronized across different Resources (same start, end and length), this rule works the same as “even” (but “even” would be preferred in that case).
- defines which side of the integration decides how differences between operation times (workload, capacity, setup/switchover, queue/transport, workload factor, workload type and operation efficiency) for an operation should be managed. As default the ERP system is the master (timesMaster=”source”)
- defines if already existing production orders have to be updated with new data from XML file or not at all.
Important: If this flag is set to false and a production order is already existing, nothing will be updated for THIS production order, its product, operation sequence and operations included. The only exception is import of orders with status=90 (deleted), which will still result in the specified order being deleted.
The default value is true
Settings related to how ROB-EX will treat resource calendars on import. Will rarely need to be overwritten.
Settings related to how production orders in general will be planned on import. Will rarely need to be overwritten.