Sequencing processes
Under
, you can manage some code lists that are used to configure and to control the sequencing processes in :Just-In-Time (JIT) and Just-In-Sequence (JIS) performance optimizations
In sequencing processes like JIT or JIS, a large data volume must often be processed in a short time. This situation leads to specific performance requirements. Because JIT or JIS processes differ from the standard processes that use planning schedules and shipment schedules, specific performance optimizations are required. The actual requirements are specific for each JIT or JIS process. These are factors that influence a JIT or JIS process:
- The trading partner
- The number and kind of items per vehicle
- The number of produced vehicles
- The distance to the supplier, for example, on site versus long-range JIS
Especially important is to process the sequential impulse messages in time. The lead time for these messages depends on the specific production and shift model and can be lower than 1 hour.
This example situation demonstrates some factors of influence:
- 500 produced vehicles per day
- 100 items per vehicle (from 200 items in total)
- Daily forecast sequence schedule with a horizon of 1 day, received 5 days in advance containing 500 vehicles
- One sequential impulse message per vehicle: 500 EDI messages per day, received about 4 hours in advance, in average one sequential impulse message every 2 minutes
The key figures of the example result in about 2500 order lines per combined plan in
: 5 days with 500 pending vehicles each day.For each incoming BOD, PlanningSchedule
and SequenceSchedule BODs
.
To improve the overall performance of customer JIT or JIS installations, these features can be used in
:PlanningSchedule
and aSequenceSchedule
for the sequencing. In case of importing aPlanningSchedule
, it is not required to publish aSequenceSchedule
. To suppress the publishing of aSequenceSchedule BOD
, after aPlanningSchedule BOD
has been imported, configure the code listSequencePlanningScheduleFastProcess
under . By default, the suppression is deactivated and theSequenceSchedule
is published. The publishing of theSequenceSchedule
is only suppressed for customers that are specified in the code list. The BOD type is copied into the Last Processed Schedule field of the new combined plan.
publishes all BODs
according to the BOD separation rule after importing a new schedule. This is
usually a - merges sequential impulse messages before the validation. Normally, each sequential impulse message causes the creation of a single plan for each item representing one order line per vehicle. These new plans are processed. All affected plans are published containing all current order lines per vehicle. To reduce the publishing of all items of each vehicle, the plans are collected for a defined time and processed together. The merged plans are then processed like before. The merge is always active for sequential impulse messages.
Publishing net changes when processing sequential impulse messages
A Sequential Impulse message normally contains information about one
vehicle. When Release Management publishes the SequenceSchedule BOD
, all sequenced requirements are published
independent of whether they are changed or not. To reduce the number of lines in the
SequenceSchedule BOD
to be published, you can
configure in a way that only changed requirements are published.
In the code list SequenceNetChange
, you
can specify the customers per accounting entity for which the net changes are
published.
During plan adjustment, the field Purpose Code is set on requirement level.
Supported values are Insert, Update,
and Delete. If the "Net Change" functionality is activated,
the Purpose Code is
published for requirements of type "Sequential Impulse" per reference RequirementPurposeCode
.
In addition, the entire sequence schedule is marked as being a NetChange
schedule.
If the "Net Change" functionality is not activated, all requirements are published.
Sequential impulse messages without sequential forecast in the sequencing process
Standard behavior of Failed on the Unprocessed Plans page.
is to stop the processing of a sequential impulse message without a corresponding sequential forecast message. These schedules are shown as unprocessed plans with the exception statusTo process a sequential impulse message without a corresponding
sequential forecast message, you can configure the code list SequenceAcceptImpulseWithoutForecast
under .
By default, the parameter of the code list is deactivated. The sequential impulse message is shown as unprocessed plan with the exception status Failed on the Unprocessed Plans page. If the parameter is activated, the sequential impulse message is processed without errors.