Sequencing processes

In the Administrative Functions area, you can manage some code lists that are used to configure and to control the sequencing processes in Release Management:

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 Release Management: 5 days with 500 pending vehicles each day.

For each incoming BOD, Release Management creates a new plan revision and publishes PlanningSchedule and SequenceSchedule BODs.

To improve the overall performance of customer JIT or JIS installations, these features can be used in Release Management:

  • Release Management publishes all BODs according to the BOD separation rule after importing a new schedule. This is usually a PlanningSchedule and a SequenceSchedule for the sequencing. In case of importing a PlanningSchedule, it is not required to publish a SequenceSchedule. To suppress the publishing of a SequenceSchedule BOD, after a PlanningSchedule BOD has been imported, configure the code list SequencePlanningScheduleFastProcess in the Administrations Functions area. By default, the suppression is deactivated and the SequenceSchedule is published. The publishing of the SequenceSchedule 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.
  • Release Management 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 by the PlanValidateFetcher process for a defined time and processed together. The merged plans are then processed by the PlanValidator process like before. The merge is always active for sequential impulse messages. To make this processing logic work, you can change the Cron expression of the PlanValidateFetcher to some minutes, for example, 10 minutes: 0 0/10 * * * ?. If one sequential impulse message is received every 2 minutes, 5 fitting messages can then be merged and processed together.

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 Release Management 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 Release Management 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 status Failed on the Manage Unprocessed Plans page.

To process a sequential impulse message without a corresponding sequential forecast message, you can configure the code list SequenceAcceptImpulseWithoutForecast in the Administrative Functions area.

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 Manage Unprocessed Plans page. If the parameter is activated, the sequential impulse message is processed without errors.