Interfacing with Operation split and join

This chapter describes how to handle interfacing when performing split and join in ROB-EX at operation level (split at order level is another subject). The challenge is how interface wise, to handle the additional Operation objects created after a split.

To further elaborate by an example.

1. ROB-EX is importing production order PO1 with operation O1 from an external ERP system.
2. The ROB-EX planner would like to produce the operation in two steps and performs an operation split of O1 into O1-1 and O1-2
   

At this point in time, the object model between ERP and ROB-EX is no longer in sync. The order has one operation in ERP – but two in ROB-EX. This will provide a challenge in the following situations.
is

• Situation S1: The plan is re-imported ERP -> ROB-EX. The ERP will only export O1. Even though two operations O1-1 and O1-2 now exists in ROB-EX?
• Situation S2: The plan is exported ROB-EX -> ERP. The ERP system will not know operation O1-1 and O1-2, so where should the ERP map this information to?

The brief conclusion of the details described below is, that it is OK to split and join operations in ROB-EX, even when you run integrated to external systems. As long as you

1. use XML import/export, SQL (GanttERP2) or DirectSQL. These technologies will handle the challenge like described below
2. once you start splitting in ROB-EX, then be aware that from that point on, ROB-EX will no longer update the route with new or deleted operations. So a change to the route in ERP will no longer be reflected in ROB-EX

XML, SQL and DirectSQL

As of ROB-EX 6.2.0.165 this is the how ROB-EX will default handle this situation

Import ERP -> ROB-EX

For situation S1, then ROB-EX will on import, by default investigate if an imported operation has been split inside ROB-EX – and map accordingly. In the above example O1 is imported and the following will take place

1. O1 start time is ignored
2. O1 end time is ignored
3. O1 status is set on all split members, if O1 status is higher than current status of the split member. One exception is status “Started”, which is not immediately forwarded, since we want the progress reports to start the individual split members (based on the “ProdOrderSettings.splitProgress” setting)
4. O1 setup time is ignored
5. O1 workload time is ignored
6. O1 switch over time is ignored
7. O1 progress is distributed across the operations according to the ProdOrderSettings.splitProgress setting

Effectively this means, that as soon as you start splitting operations in ROB-EX, then new or deleted operations from the ERP side will be ignored. I.e. ROB-EX is now master of what operations exists in the route.

Requirement for versions prior to 6.4.0.140: ProdOrderSetting.opSeqStructureMaster=destination
Handled automatically from 6.4.0.140 and later

Export ROB-EX -> ERP

For situation S2, then ROB-EX will on export, by default aggregate information of O1-1 and O1-2 and export the information as only O1. The aggregation will happen like this

1. O1 start time is the earliest start of either O1-1 or O1-2
2. O1 end time is the latest end of either O1-1 or O1-2
3. O1 status is the highest status of O1-1 and O1-2. Except for status Complete, in which case second highest state is exported. O1 will get status “Complete” only when both O1-1 and O1-2 is “Complete”
4. O1 setup time is the setup time of the earliest of the operations
5. O1 workload time is the workload time of the original operation before the split
6. O1 switch over time is the switchover time of the latest of the operations
7. O1 progress: the quantityFinished field is the quantity sum completed among all split members (only DirectSQL and DB – not pure XML export which does not export progress)

Joining operations

When joining operations back to the starting point, then the original operation is re-created in ROB-EX. I.e. ROB-EX will now be in sync again with the ERP object model. So no special handling is needed for joining.