Define Partner Settings

… the direction of the message.

The valid alternatives are:

I = Input

O = Output.

… the message type, which should contain the name of the standard message to be processed.

Examples:

EDIFACT messages:

ORDERS ORDRSP, etc.

ODETTE messages:

DELINS AVIEXP, etc.

… the application reference, which can be used as reference information concerning the entire transmission. In other words, the information applies to all messages in the transmission and is determined by the sender.

The field is only used for outgoing messages.

… the access reference, which is used to relate all message transfers to a common business deal or the like.

The field is only used for outgoing messages.

… how to perform reconciliation.

The valid reconciliation methods are:

0 = No reconciliation

1 = Delivery note

2 = Cumulative

3 = Proactive—In-sequence requirements are time triggered and override related delivery schedules within the specified date range. These in-sequence requirements are received within a planning horizon.

4 = Reactive—In-sequence requirements are instantly triggered and consume related delivery schedules based on FIFO.

5 = Discrete (for future use).

Method 0: The delivery schedule updates order stock without taking completed deliveries into account.

Method 1: Delivery note information must exist in the delivery schedule. Delivery notes specified in the delivery schedule are matched against corresponding delivery notes in M3.

Method 2: Cumulative information must exist in the delivery schedule and for items in (MMS072). Parameter 12 in (CRS716) must be set to 1.

Method 3: Sequence delivery schedule information must exist. Normally, the sequence of deliveries is obtained in a chain of sequential schedules. The delivery is physically executed from the sequence delivery schedule itself and overrides the related (fixed or forecast) delivery schedule. Normally, the current date triggers a delivery from the stored chain of sequence delivery schedules.

Method 4: Sequence delivery schedule information must exist. The difference from method 3 is that a received sequence delivery schedule instantly triggers an outgoing delivery. The sequence delivery schedule does not override the (firm or forecast) delivery schedule. The quantity specified in the sequence delivery schedule reduces the earliest quantity in the delivery schedule.

Method 5: This method is not currently used.

… how the delivery schedule is reconciled against on-hand orders and delivery transactions. The values indicate how far the reconciliation process will be allowed to continue before it is interrupted.

The valid alternatives are:

For delivery note reconciliation (method 1):

Generally, when the delivery note quantities are allowed to differ, the customer’s quantities are used.

0 = All delivery notes in the delivery schedule and in M3 delivery history transactions must be matchable, or the run is interrupted. The delivery note quantities must be the same.

1 = Same as 0, except the delivery note quantities can differ.

2 = At least one delivery note must be matchable for the reconciliation to continue. The delivery note quantities must be the same.

3 = Same as 2, except the delivery note quantities can differ.

4 = If no delivery note can be matched, the first release order date from the previous delivery schedule is used as the reconciliation basis.

5 = If no delivery note can be matched and there is no previous delivery schedule, the value in the ‘Delivery schedule interval’ field in (RSS015), parameter 230, is used to calculate a reconciliation point in past time.

6 = If none of the values above can be used, the item is allowed to be placed in the run without reconciliation.

For cumulative reconciliation (method 2):

0 = If the quantities for an individual record in the delivery schedule are different from those in the customer order system, the run is stopped.

1 = If the quantities for an individual record in the delivery schedule are different from those in the customer order system, the discrepancy is adjusted in the customer order system according to the delivery schedule.

… whether the field heading and field contents should be displayed, and whether the contents are changeable.

The valid alternatives are:

0 = Do not display field heading and contents.

1 = Display field heading and contents. Contents may not be changed.

2 = Display field heading and contents. Contents may be changed.

… whether the delivery schedule should be reconciled against M3 customer orders and delivery history transactions.

The valid alternatives are:

0 = No

1 = Yes.

Reconciliation means that a new delivery plan for an item is checked against current order situations and the latest deliveries.

… the cumulative type.

The valid alternatives are:

1 = Quantity actually received

2 = Quantity scheduled received

3 = Commitment for production

4 = Highest production

5 = Lowest production

6 = Commitment for fabrication

7 = Highest fabrication

8 = Lowest fabrication

9 = Commitment for raw material

10 = Highest material

11 = Lowest material

12 = Forecast

13 = Highest forecast

14 = Lowest forecast

15 = Agreement

16 = Highest agreement

17 = Lowest agreement

18 = Released for payment

19 = Highest released

20 = Lowest released.

… the identity used to identify how the quantity is accumulated. This is specified for each alias number and customer.

The valid alternatives are:

1 = By customer only

2 = Warehouse

3 = Warehouse and address

4 = Warehouse, address and delivery specification

5 = Warehouse and model year

6 = Warehouse, model year and address

7 = Warehouse and agreement

8 = Warehouse, agreement and address

9 = Warehouse, model year and agreement

10 = Warehouse, model year, agreement and address

11 = Address

12 = Address and delivery specification

13 = Model year

14 = Model year and address

15 = Agreement

16 = Agreement and address

17 = Model year and agreement

18 = Model year, agreement and address.

… the delivery schedule group, and is used to internally group or categorize different delivery schedule types that have a hierarchical relationship to each other. The levels in the hierarchy can be entered in (RSS015), (parameter 045). This field is optional.

Example: If a delivery schedule and a sequence delivery schedule are used, the relationship between these two must be described. The delivery schedules must belong to the same group.

The highest-level delivery schedule always overrides the lower levels. In other words, the delivery schedule is assigned level 1 and the sequence delivery schedule is assigned level 2.

The field is used to internally group or categorize different delivery schedule types that have a hierarchical relationship to each other. The field is only valid if a delivery schedule group is defined in (RSS015/E).

Up to 99 levels can be entered, where 01 has the lowest priority. A delivery schedule with a higher level overrides customer orders that are created with the same delivery date but on a lower level.

Refer to the example in the help text for the ‘Delivery schedule group’ field in (RSS015/E).

… an application version, which is usually defined within each definition of partner, message type and application reference.

The field is optional.

… a deviation model.

A defined deviation model can be connected to a delivery schedule via a combination of IDs such as message direction, partner, message type and application reference.

A deviation model affects how the delivery schedule will be transferred to the customer order system. A deviation model works with the ‘Next manual function’ field (parameter 055) in (RSS010).

Deviation models are created in (RSS020).

… whether the information for splitting specified in (RSS056) should be used to split quantity buckets, such as weekly requirements to daily requirements.

The valid alternatives are:

0 = No

1 = Yes

If activated, splitting will be performed automatically after validation.

… the split model.

This field is used to connect a defined split model to a delivery schedule that belongs to a defined combination of direction, partner, message and application reference.

The split functionality splits a quantity into several deliveries and is defined in (RSS055) and (RSS056).

… the controlling information in sequence delivery schedules.

The field indicates the type of search criteria to be used to follow the sequence order in a sequence delivery schedule. The search field is built up and placed in the RCSRCH field in the ORSINS file (delivery schedule instructions).

The information is used when activating the delivery schedule to find the previous delivery schedule on the same level.

Changing the search field value during delivery schedule production is not recommended.

The valid alternatives are:

0 = Alias number/date/time

1 = Alias number/chassis

2 = Alias number/kanban number

3 = Alias number/production sequence.

For normal delivery schedules, this value should be set to 0.

… whether to hold the new delivery schedule if the ID of the previous delivery schedule specified in the new schedule was not found in the search.

The valid alternatives are:

0 = No. If a previous delivery schedule is not found, the last schedule used is searched, if one exists.

1 = Yes. If a previous delivery schedule is not found, the new schedule is not activated. The delivery schedule for the current item remains at status 15. After that, it must be activated manually.

… how the From/To date for the demand period is calculated. The To date is calculated according to the demand bucket.

The valid alternatives are:

0 = From date equals requested date, and To date is set according to the length of the period.

1 = From date is set to the period’s first date, and To date is set to the period’s last date.

Example:

Required date is Wednesday the 17th.

Demand bucket is 2 (weekly demands).

Calculation method 0:

Required date (From date) is Wednesday the 17th.

To date is set to Tuesday the 23rd.

Calculation method 1:

Required date (From date) is Monday the 15th.

To date is set to Sunday the 21st.

… where the start and end dates for a delivery schedule are retrieved. The dates are retrieved during the validation step.

A delivery schedule contains information about the delivery instruction’s start and end dates, both on the header and item level. This information is normally provided in the batch entry (EDI information), but is also calculated automatically in the RS system. The days calculated indicate the first and last valid delivery date for any item in the current delivery schedule.

The valid alternatives are:

0 = Dates used are those received from the delivery schedule batch entry.

1 = Dates used are the calculated dates from the header level.

2 = Dates used are each item’s individually calculated start and end dates.

… whether there should be a check of whether the item exists for new demands, and whether the demands should be added to that item if it exists.

The valid alternatives are:

0 = The received schedule will be received "as is" without any check of the item’s existence.

1 = For every new demand in the received schedule, the item will be checked for whether it has already been received and, if so, the demands will be added as instructions on the item.

This indicator will be used if the received schedule is structured in a way other than the M3 database structure; that is, not with item as the controlling entity.

For example, the received schedule is structured like:

Date item/quantity item/quantity date item/quantity item/quantity. If this indicator is set to 1, the structure will be converted to:

Item date/quantity date/quantity item date/quantity date/quantity.

… whether the proposal for the supplying warehouse should follow a separate table.

The valid alternatives are:

0 = No

1 = Yes

If this also should be valid for kit items, then alternative 1 has to be placed after alternative 3 in the search sequence used when entering new CO lines.

Table values are defined in (MMS058). If the table value is missing, the main warehouse is used according to the current combination of item and facility.

… whether to carry out a search via an item’s standard facility (RSS010).

The valid alternatives are:

0 = No

1 = Yes. The search is carried out during the validation step.

… whether to retrieve package information from (MMS053) before transfer to the customer order system. The retrieval is done during the validation step.

The valid alternatives are:

0 = No

1 = Yes

… the type of date received in the delivery schedules. If a value other than 0 is used, any date type received in the EDI transmission is overridden.

Also, any value entered manually will be the default date type.

The valid alternatives are:

0 = Date type from the EDI file

1 = Delivery date

2 = Ship-via date

3 = Goods receiving date.

… whether package leveling is performed. This means that the quantities in the delivery schedule are leveled so that they correspond to the defined quantity per package.

The valid alternatives are:

0 = No

1 = Yes. All quantities per day will be leveled.

2 = Yes. All quantities per day will be leveled except the last package.

Leveling is performed as part of the reconciliation (transfer to the customer order system). The quantity per package is defined in (MMS053).

Example: The order quantity is 125, and the standard quantity in one package is defined as 50. If alternative 1 is specified, the proposed quantity in the order will be leveled at 150 (three packages multiplied by 50).

… the sequence used for delivery schedules and whether fields from the schedule hierarchy above will update the hierarchy below.

For example, fields from a forecast plan update fields to a sequence delivery schedule.

The fields to be updated are retrieved from the predefined table in (RSS016).

… the combination of demand commitment codes that are to be created in the net schedule. If left blank, all codes will be included in the net schedule.

The valid alternatives are:

1 = Firm

2 = Manufacturing

3 = Raw material only

4 = Forecast

9 = Reference to agreement between partners.

… how to process a blanket agreement for customer delivery schedules.

The valid alternatives are:

0 = According to the agreement check fields in (CRS610).

1 = The customer’s order number in the item’s delivery schedule is used to retrieve the blanket agreement.

2 = The contract number in the item’s delivery schedule is used to retrieve the blanket agreement.

3 = The model/year value in the item’s delivery schedule is used to retrieve the blanket agreement.

Alternative 0 will retrieve a blanket agreement when the net schedule is processed in the batch order entry according to the customer’s agreement check fields. Currency will not be retrieved from the blanket agreement.

Alternatives 1, 2 and 3 will use the retrieved agreement in the batch order entry. If defined in (OIS060), the agreement currency will override the customer currency when the delivery schedule item is validated. When using these alternatives, the agreement check fields in (CRS610) should be set to 0.

In order to use alternatives 1, 2 and 3, either the customer’s order number, the contract number or the model/year must be specified in (OIS060/E) as the customer’s order number.

… whether demand commitment definitions entered in (RSS018) will override the values retrieved from the registered delivery schedule.

The valid alternatives are:

0 = No

1 = Yes

The demand commitment definition is checked during the validation phase.

… the customer’s order number.

The entered value will override the value received from delivery schedules transmitted via electronic data interchange (EDI).

… the priority of customer orders. The specified priority applies to all the lines in a customer order. This information is shown in the material plan and can be used in case of shortage.

Priority is set on a scale from 0 to 9, with 0 being the highest priority.

The priority is used as selection criteria when shortages occur. The priority is also used during release for automatic allocation and release of picking lists in (MWS410).

A normal priority is entered per customer in (CRS610/F). When entering customer orders, a priority is suggested depending on the customer order type.

… whether transport lead times should be taken into consideration when calculating dates for customer delivery schedule demands.

The valid alternatives are:

0 = Transport lead times are not taken into consideration.

1 = Transport lead times are taken into consideration based on transport on delivery days according to (CRS900).

2 = Transport lead times taken into consideration, but (CRS900) is disregarded. This option is useful when transport is performed during weekends.

The date calculation is performed during validation.

… the delivery schedule interval. This field is used only in combination with the ‘020 Reconciliation level’ field in (RSS015), value 5.

The field is used during reconciliation, and the values are entered in days. The value of the delivery schedule interval should reflect how often a delivery schedule is received. The reconciliation run uses the interval to produce the correct reconciliation data when no delivery notes can be matched and there is no previous delivery schedule.

When the interval is set to 0, no reconciliation is done if neither a previous delivery schedule nor a matching delivery exists.

… the delivery schedule interval hours. This field is used only in combination with the ‘020 Reconciliation level’ field in (RSS015), value 5.

The interval is expressed in hours and is related to the ‘230 Delivery schedule interval days’ field.

… the number of days before the delivery schedule is physically moved to the historical delivery schedule files.

To deactivate this function, enter 0 in the field. To activate it, enter the number of days greater than zero.

The deletion date is calculated by the delivery schedule’s start date.

… a unique user ID.

The ID can be used for selection and sorting.

… whether overriding of a mail recipient entered is allowed.

The valid alternatives are:

0 = No, mail recipient will not be overridden.

1 = Yes, mail recipient will be overridden using a value in (RSS015/310).

… the view for (RSS100).

Views are user defined and determine what fields are to be displayed, as well as how the data is to be calculated.

… the view for (RSS101).

Views are user defined and determine what fields are to be displayed, as well as how the data is to be calculated.

… the view for (RSS102).

Views are user defined and determine what fields are to be displayed, as well as how the data is to be calculated.

… the consolidated forecast demand. The field can only be used in relation to another defined partner parameter definition.

The field is normally used to manage aggregated forecast delivery schedules. This means that requirements for two or more actual customers are consolidated into one requirement for forecasting purposes.

If this field is defined, fields 405–420 in (RSS015) might need to be defined depending on whether the current record defined is a forecast or an actual partner definition.

The material delivery is normally performed from the customer orders created from the partner’s delivery schedule.

The valid alternatives are:

0 = No partner relation definition

1 = Forecast partner definition

2 = Actual partner definition.

… the unique identification of a customer. It can contain up to ten positions and is alphanumeric.

For temporary customers (customer type 9), the customer number must be within a defined range where only customers with customer type 9 can be entered.

… an ID for a delivery specification. This ID can be connected to customer order lines when entering them.

A delivery specification is a detailed description of where a customer order line is delivered. This can be a workplace, building, house, entrance or floor.

Each specification is saved in a separate file and can then be used for several customer order lines.

… whether to use issue multiples. This field is used as an alternative to the ‘Package level’ field.

The valid alternatives are:

0 = No

1 = Yes. All quantities per day will be delivered according to the issue multiple.

If 1 is entered, the delivery schedule’s quantities are calculated from the specified multiple during reconciliation (that is, transfer to the customer order system). The issue multiple is entered in (MMS002).

… whether to use issue multiples on back order instructions.

The field performs the same leveling according to issue multiples as the ‘Adjust to issue multiple from item/whs’ parameter. This parameter only affects delivery instructions with instruction reason 3=Back order.

The valid alternatives are:

0 = No leveling of back orders

1 = Back orders will be leveled.

If 1 is entered, the delivery schedule’s quantities are calculated from the specified multiple during reconciliation (that is, transfer to the customer order system). The issue multiple is entered in (MMS002).

… whether to use the delivery pattern for the delivery schedule.

The valid alternatives are:

0 = No

1 = Yes, adjust delivery days according to delivery pattern.

Delivery patterns are entered in (RSS025).

… whether or not hours and minutes are used in the delivery schedule.

The valid alternatives are:

0 = No

1 = Yes

When 0 is specified, the required delivery time will be set to 00:00 indicating a requirement for a whole day.

… the date the delivery note information on an incoming delivery schedule refers to. Delivery note dates are important to the reconciliation process.

The valid alternatives are:

0 = Date when goods were dispatched.

1 = Date when goods were received.

If you specify 1, the delivery note date is calculated based on the transportation lead time.

… the terms that apply when goods are packaged.

The terms entered in (RSS015) will override the terms of (RSS050) and (CRS610).

… an international time zone such as Central European Time (CET) or CET+1.

Time zone &SYS must be entered in (DRS045). &SYS is the time zone used internally in M3.

When no time zone is entered for a location, local time is used. This means that no conversion of time is done.

… whether MRP should be run on the changed items when the requirements have been transferred to a customer order. Only items that do not use continuous net change are affected.

Note that explosion is not supported in this release.

These fields indicate whether checks should be done against the delivery schedule on the level above. The check is performed during activation and when the net schedule is created.

The valid alternatives are:

0 = No replacement check

1 = Replacement check.

Checking against the delivery schedule on the level above means that the demands on the schedule a level above are replaced by the demands in the current level schedule IF the customer’s order number is identical in the two schedules. If it is not identical, the replacement does not occur and new demands are created for the current level schedule in parallel with the demands in the schedule on the level above.

In a common scenario, the current level is a call-off delivery schedule and the above level is a forecast delivery schedule.

The parameter is only valid if more than one level is used inside the same delivery schedule group.

These fields indicate whether a check should be done against the previous schedule for the current level. The check is performed during activation and when the net schedule is created.

The valid alternatives are:

0 = No replacement check

1 = Replacement check.

Checking against the previous schedule for the current level means that the demands in the previous delivery schedule on the current level are replaced by the demands in the new delivery schedule IF the customer’s order number is identical in the two schedules. If it is not identical, the replacement does not occur and new demands are created for the new schedule parallel with the demands in the previous schedule.

In a common scenario, the previous delivery schedule is a call-off (n) and the new delivery schedule is a call-off (n+1).