Functions

Item/Delivery Points Regeneration Flag Update

For all company/warehouses that have their regeneration flags set to "yes":

1. Search for all endorsements that have this company/warehouse as sourcing company warehouse.

2. For each endorsement, search all the item/delivery points attached to the endorsement. Set their regeneration flag to "yes".

For all changed delivery conditions that have their regeneration flag set to "yes":

1. Search for all the item/delivery points attached to the changed delivery condition and set their regeneration flag to "yes". Set the delivery condition regeneration flag to "no".

Reopening of Delivery Requests Attached to Flagged Item/Delivery Points

Reset to "open", all delivery requests with a split status and attached to item/delivery points that are flagged to "yes". The system splits the reset delivery requests again during the offset release generation and sets their delivery point regeneration flags to "no".

VDA Delivery Request Validation and Input

The VDA Delivery Request Validation and Input program (GA209E) handles all VDA type delivery requests sent by customers, validating the requests according to syntax and functional criteria. The requests are written to the VDA Delivery Request Batch Input file (GA210AP4). The VDA Delivery Request Validation and Input program (GA209E) passes the messages stored in GA210AP4 to the GA210HP2 and GA210HP3 workfiles for processing. Two types of delivery request segments are processed during this time: segments numbered 51X (ex: 511, 512, 513, etc.) correspond to VDA4905 (LAB) delivery request messages whereas segments numbered 55X (ex: 551, 552, 553, etc.) correspond to VDA4915 (FAB) delivery request messages.

During this processing, data is passed from GA210HP2 to GA210HP3 and is then written to either delivery request files or erroneous message files. Specifically, correct VDA requests are written to the MAC-PAC delivery request files (GA210M1, GA210M2, GA210M3) according to the VDA replacement rules. Erroneous VDA requests are written to the VDA Delivery Request Error Message file (GA210HP). These error messages may be updated manually in the VDA Messages Update conversation (GA217E) and processed during the following Synchro batch job. This processing loop continues until the workfiles (GA210HP2 and GA210HP3) have been emptied or an error occurs. The workfiles are then cleared and the next VDA message is checked (the program checks the VDA counter). After several levels of validation, the new VDA message is written to the delivery request files.

Automatic Entry of Delivery Requests

This process updates the delivery requests files from the electronically-transmitted DELINS messages, according to the SY-GALIA translator version for the ODETTE protocol. The Delivery Request header, releases, comments and Item Delivery Point relationship files are updated.

The messages received are validated. Messages in error are either rejected or an error message is displayed.

DELINS are transmitted by the buyer to the supplier and state the shipping schedule to be followed for more items. Each message includes one or more releases per item. The releases are expressed in quantity by period or quantity by date.

Translation software is used to receive DELINS messages. It generates internal files at the rate of one record by segment of message received. The generated files are read sequentially by the automatic entry program of the delivery requests. Each segment generates a record organized within a specific data structure depending on the segment type, according to the SY-GALIA translator version for the ODETTE protocol. The record type is specified in each record at the same place, regardless of the record type.

For each item/delivery point of a blanket order referenced in a delivery request, the process considers the releases which already exist in the system in order to take into account the new releases in mode 'cancel and replace', or in mode 'current actualization' depending on the delivery request type. The validation rules are different depending on the delivery request type.

An endorsement is associated to each of the acquired releases. The selected endorsement must be valid at the period start date of the release.

See the Electronic Transmission of Messages Key Concept in this overview for information specific to the segments of messages interpreted.

A Delivery Request Variance Analysis can provide you with the variances that occur between the previous delivery requests quantities and the one in process. This analysis is printed on a report sorted by sender company/warehouse, buyer/analyst code, and ship-to customer.

Automatic Reconciliation of Synchronization Data

The synchronization data is simultaneously maintained by you and your customers. It allows you to be aware of the delivery advance/backorder status of the shipments for each item/delivery point relationship in your system. This information is regularly supplied by the customer to the vendor on the delivery requests, whether they are automatically acquired or entered manually through the Delivery Request Maintenance conversation.

The reconciliation process compares the data provided by the customer with the ones defined in Synchro. It allows you to detect possible errors that are then notified to the user on the final error report.

Synchro manages different data for each item/delivery point relationship:

· The cumulative quantity shipped, updated as the shipments are sent.

· Cumulative quantity due shipped at end of day, updated by the batch process of shipping proposal generation (GA230E).

The synchronization data transmitted by the customer through the DELINS or VDA messages is:

· Synchronization date

· Last dispatch advice message number

· At least two of the following: cumulative quantity expected, cumulative quantity received, and the delivery advance/backorder corresponding to the difference of the last two.

The purpose of the reconciliation process is to verify that the following are equal:

· Cumulative quantity received declared by the customer.

· Cumulative quantity shipped and calculated by the system at the same level of the shipment sequence (Synchro accumulation).

To calculate the second cumulative quantity, the system goes back to the level of the last shipment taken into account by the customer. It assumes that all the shipments preceding the last shipping list declared by the customer have been received and accepted.

A warning is displayed when the two quantities, expressed in ordering unit, are not equal.

Splitting/Offsetting of Delivery Requests

The delivery requests splitting/offsetting process allows you to obtain, from the releases, offset delivery request releases for the generation of shipping proposals and taken into account in the MAC-PAC planning functions.

The splitting/offsetting process considers the customer delivery conditions as well as the data associated to the endorsements. in Particular, the transportation lead time (endorsement) and the preparation lead time (endorsement) define the shipping date and the preparation date for each planned shipment, depending on the customer given delivery date.

See the Splitting and Offsetting of Delivery Requests Key Concept in this overview for more information about splitting/offsetting of releases.

Lock/Forward Shipments for Parts Managed by Synchro

The purpose of this process is to permanently lock shipments for which the shipping date is passed and to forward, through fictitious releases, the existing delivery advance/backorder for each item/delivery point relationship.

The fictitious releases are then used in the shipping proposals generation process.

Lock: The shipping proposals locked by the process are the ones for which the shipping date is passed. No new shipment can be executed for a locked shipping proposal. More importantly, prepared or frozen shipping lists associated to the shipping proposal can no longer be shipped.

Forward: The forward process analyzes, for each item/delivery point relationship of a blanket order, the completed shipments versus the shipments planned by the system.

It defines for each item/delivery point relationship:

The difference between the quantities associated to the shipping proposals and the cumulative quantities shipped. The result of this data (positive for a backorder and negative for a delivery advance), when not zero creates a fictitious release associated to the item/delivery point relationship.

Backorder Processing for Company/Warehouse for Parts Managed by Synchro

Backorder processing is indicated by a nature type of 0. The system uses the following rules to determine the company/warehouse that will handle a backorder:

1. The system checks the endorsement valid at the time of the daily batch date.

2. Based on the company/warehouse manufacturing calendar, the system finds the earliest preparation date.

3. The system checks the closest endorsement in other company/warehouses.

4. If the preparation date determined in step 2, is greater than the validity date of the endorsement in step 3, the company/warehouse found in step 3 will be responsible for the shipment of the backorder. If the preparation date determined in step 2 is less than the validity date of the endorsement in step 3, the company/warehouse found in the endorsement in step 1 will be responsible for the shipment of the order.

Note: In case of backorder, there is no preparation lead time. The preparation date is equal to the shipping date.

Advance Netting for Parts Managed by Synchro

For each item/delivery point with an advance (where the difference between the total shipped and the total due is positive), the advance is netted against the open offset releases until it is totally cleared out.

The offset release keeps the original quantity in the ROQSKU field. However, a specific field (Net Quantity ROQNSK), reflects the net quantity (original quantity - advance).

In VDA mode, this processing works the same way. However, when a completely new VDA delivery request is processed, every release in the past is generated which could include blocked releases having non-zero net quantities, indicating a demand to the system. For VDA mode, blocked releases should be taken into account.

Note: The IC, MS, and RP modules take the net quantity into account when calculating the Synchro demand.

Lock Shipments for Parts Managed by Customer KANBAN

The purpose of this process is to permanently lock shipments for which the shipping date is passed. No new shipments can be executed for a locked shipping proposal.

The quantity to be shipped is:

1. Added to the quantity due at the end of the day for the part/delivery point on the shipment

2. Subtracted from the advance/backorder quantity for the part/delivery point on the shipment

The GABATCH process flag for the order is then set to yes.

Recycle Picked or Booked Orders

For each Customer KANBAN order that has been picked or booked but not shipped, the shipped order status is reset to no, the picker number is set to blanks, and the number of picker lines is set to zero.

Generation of Shipping Proposals for Parts Managed by Synchro

This process generates the shipping proposals for which the preparation must begin to meet the customer requirements.

The generated shipping proposals specify the quantities by item to be shipped, taking in consideration the following:

· Offset releases for which the preparation start date is reached in the processed horizon.

· Fictitious releases generated by the lock/forward process representing the delivery advance/backorder for each item/delivery point relationship of the blanket order.

· Packaging rounding rules defined for the item in the valid endorsement.

The endorsement taken into account to define the data associated to a shipping proposal is:

The endorsement associated to each offset release, for the releases for which the preparation date has been reached.

For fictitious releases representing a backorder, two instances are possible:

1. An offset release exists and its preparation date corresponds to the one of fictitious release. The advance/backorder for the fictitious release is then added to the same shipping proposal.

2. None of the offset releases have a preparation date corresponding to the one associated to the fictitious release. The system generates a specific shipping proposal for the fictitious release.

Shipping proposals are grouped by:

· Shipping company/warehouse

· Preparation date (fictitious or offset release)

· Synchro blanket order (blanket order)

· Delivery point (item/delivery point relationship)

· Consolidation point (endorsement)

· Ship via (endorsement)

· Shipping date (fictitious or offset release)

· Delivery date (fictitious or offset release)

All the offset or fictitious releases that have this identical data will be grouped on the same shipping proposal. The quantity associated to each item corresponds to the offset releases due for the day and the delivery advance/backorder. When an offset release is taken into account in a shipping proposal, its status, as well as the status of the corresponding delivery request release, becomes locked , and can no longer be modified.

Offset releases of a planned nature (2, 3, 4) are taken into account in a shipping proposal if the associated endorsement specifies the authorization to ship on planned shipment. If the endorsement does not specify this authorization, these releases are closed. Packaging rounding rules are taken into account, if the endorsement associated to the shipped item authorizes it. In this case, the quantities to be shipped proposed by the system are rounded to the nearest higher packaging unit.

VDA processing requires that an immediate release must be delivered as soon as possible. When an immediate release is proposed, two things can happen:

1. The immediate release has the same start delivery date as the first firm demand (only these two releases can have the same date). The system proposes the accumulated quantity due for the two releases on the same line and sets the immediate release flag to indicate that the line is proposed with an immediate release.

2. The immediate release does not have the same start delivery date as the first normal demand. The system proposes only the quantity due for this immediate release and sets the immediate release flag to indicate that the line is proposed with an immediate release.

If the system sets the immediate release flag, it prints an asterisk on the shipping proposal report.

Printing of Shipping Proposals

Shipping proposals are sorted by shipping warehouse and by number.

The shipping proposal report displays, for each shipping proposal, the ordered quantities, the advance/backorder and the quantity to be shipped by item. The units of measure, as well as the conversion factors, are also displayed on the report. In addition, a ship reason code description corresponding to a ship reason code entered on the Picker Header File may be printed on the shipping proposal. The reason code and description are defined on Reference File category M11.

Each shipping proposal is printed once when it is generated. You can also request to reprint it., however the reprinted report will not include the completed shipments nor the frozen or open shipping lists.

The location of the print outs are set up by warehouse/report on Reference File category G25 (Synchro Spool File Routing).

Inventory Allocation Calculation

The system skips the inventory allocation calculation if the allocated quantity update flag on category G26 (Synchro batch parameters) is set to no.

The Synchro allocation quantity is made of backorder quantities from the item/delivery points and net quantities of the open offset releases (firm, immediate, and planned with a Planned Schedule flag of Y). The system updates the allocation quantity on the Warehouse Balance File (WBSIAQ Synchro Inventory allocated quantity).

Shipping Schedule Work File Generation

This process prepares the data on which the Shipping Schedule Inquiry program is based. This inquiry displays the shipments to be made for each shipping warehouse by date, delivery point, and ship-via.

The information retrieved for this inquiry from the Shipping Proposal File is:

· Shipping proposals that have not undergone the lock/forward process

· Shipping proposal number

· Shipping date

· Shipping company/warehouse

· Delivery point

· Ship-via

· Weight and volume

The following information is retrieved from the Offset Releases File:

· Open status offset releases, meaning the offset releases valid at the processing date and not yet taken into account in a shipping proposal.

· Regrouping of offset releases per the following criteria:

- Shipping date

- Delivery date

- Delivery point

- Consolidation point

- Ship via

- Shipping company/warehouse

Printing of Error and Warning Messages

This report displays all of the errors noted in the delivery requests, whether during the automatic acquisition of DELINS and/or VDA or during the daily batch process.

The report is printed daily after the batch process.

Printing Errors from the Batch Process

All the errors noted during the batch process are recorded in an error message file The errors are sorted into three categories:

WARNING errors: do not hold the process, but are for the user's information

CRITICAL errors: interrupt the batch process

ABORT errors: stop the entire process and indicates an incoherence in the data base.

Determination of the Next Batch Processing Date

The next batch processing date is automatically set by the application. It indicates the next working date in the production calendar, after the previous processing date. It is reset after each daily batch session.

Menu