This tab affects the behaviour concerning integration to ERP systems using any of the modules: XML integration

During import of operations ROB-EX will automatically create a template operation for each new operation name imported.

If this option is enabled the resource assigned to an imported operation is automatically added as an alternative or possible resource for that operation. Example: An operation with name “welding” is imported with “Peter” as the selected resource. In case “Peter” is not already an alternative for the template operation “welding” he will automatically be added if this flag is selected.
If an operation no longer exists in imported route give user a warning.
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:
Settings
Over all settings – will rarely need to be overwritten
Settings.ProdOrderSettings
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.

autoCompleteOperations
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).
deleteOldOperationAccess
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”.
deleteAllNonImportedProdOrders
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
deliveryTimeOfDay
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”.
forceStatusNew
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
ignoreProgress
Ignore the <Progress> tag on import
keepExistingOperationDescription
By default operation descriptions are overwritten on import for existing operations. Specify “true” if a change made in ROB-EX should win
keepExistingOrderDescription
By default production order descriptions are overwritten on import for existing operations. Specify “true” if a change made in ROB-EX should win
keepExistingResourceSpecificCalendar
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
materialCalUseTimeNowIfNull
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
noCalculatedEfficiencyBelow100Percent
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.
oprStatusMaster
What side of the integration wins concerning status updates. The default value is source (the ERP system).
oprTimeMaster
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.
opSeqStructureMaster
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.
parallelUsingLabels
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.
progressOnly
For existing operations only the progress is imported. All other things are ignored.
recalcPlannedStartEndOnFirstStart
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.
replanWhenDeliveryIsChanged
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.
resourceMaster
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.
reverseSubOrderRef
The relation ship between sub-order and main order is reversed.
splitProgress
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)
 
auto
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.
none
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.
even
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)
forward
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.
weighted
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.
chronologic
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).
 
timesMaster
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”)
updateExistingProdOrders
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.CalendarSettings
Settings related to how ROB-EX will treat resource calendars on import. Will rarely need to be overwritten.
Settings.PlanningSettings
Settings related to how production orders in general will be planned on import. Will rarely need to be overwritten.
Click for detail about the automation server.
Put a check mark in “Auto start Automation Server” to have ROB-EX automatically start up the automation service when ROB-EX start up.
The default port number to listen on is 14324. If you experience conflicts with other applications using the same port change to a different port number. Also note that on a Windows/Citrix Terminal Server you may have multiple ROB-EX clients started each trying to start up the Automation Server interface. In that case it will be necessary to select a different port number for each of the clients.
By default the automation service is disabled. Press the “Start now” button to start the automation service now and put a check mark in “Auto start Automation Server” to have ROB-EX automatically start up the automation service when ROB-EX start up.
Use the Interface history manager on an integration client to inform other users about the status on the integration to an external ERP system. Click for details on how to use the interface history manager. Note: only available when running with Multiuser server.
Enable the Integration status bar to see the status of an integration clent running the interface history manager. Click for details on how to use the integration status bar and interface history manager. Note: only available when running with Multiuser server.
Various database connection profiles can be created and edited. The profiles can be selected on the Database plugin and Project Database Plugin. Shortcuts exists on the two plugins so the connection easily can be changed.

Press “Edit” to see the available data source profiles. Double click on a profile opr press the “Edit” button in order to edit an existing profile.

Press “Add” to create a new profile. The window below will open.

The Id is auto generated, but can be changed. However this must be unique, so if the id already exists an error message is shown. When the pofile has been created the Id can not be changed.

Also the name must be unique.
The rest covers the usual settings needed to setup a database connection.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment