DEF STAN 00-60 (PART 24)/3

Section Two. Order Administration (OA) Procedures

4 OA General

4.1The OA process is as detailed in S2000M Chapter 3, subject to variations as detailed in this Part of this Defence Standard.

4.2OA enables orders to be placed and progressed, for both Initial Provisioning (IP) and follow-on support.

4.3OA is the term used to embrace all activities undertaken in connection with an order, from the time it is placed by the Customer with a Contractor, through all associated amendment, diversion, inquiry, progression and advice phases to confirmation of delivery of the articles. Repair OA will be covered in Part 26 of this Defence Standard.

4.4OA defines procedures, within a pre-negotiated contractual framework, by which the Customer may place and progress orders with the Contractor. These procedures provide the ability to use standardized messages, known as transactions, for the exchange of data between computer systems.

4.5The principles of OA require that:

(a)Every order will carry a unique Order Number (Text Element Identifier (TEI): IPO).

(b)Each order will be placed for only one Part Number (TEI: PNR), in conjunction with the NATO Supply Code for Manufacturer/User Nation Code (TEI: MFU), and/or NATO Stock Number (TEI: NSN).

(c)Each order will apply to only one prime contract.

(d)The total quantity ordered (TEI: QTY) will be stated; it may be split into partial order quantities against different delivery and/or packaging requirements.

4.6 There shall be no automatic acceptance of any OA transaction unless detailed in the contract.

5 OA Transactions

5.1 The administration of orders requires the frequent exchange of business transactions between the Customer and the Contractor. Def Stan 00-60, transactions have been tailored from those in S2000M. These are reproduced at annex A.

5.1.1 Deviations from S2000M. Deviations from S2000M are highlighted by an asterisk (*) in annex A, with the exception of the general changes detailed below:

4

DEF STAN 00-60 (PART 24)/3

(a)All S2000 Conditional ‘Project Specific’ Data Elements are now Optional unless otherwise stated in annex A.

(b)The Data Element User Nation Code (TEI: USR) shall be Mandatory in all cases, as detailed at annex A.

(c)Standard Remarks have been annotated against the following Data Elements/TEI:

(d)All S2000M Conditionalities have been amplified eg ‘Else not present’ or ‘Else O’.

(e)ST1 notification for collection. This transaction is not used in Def Stan 00-60.

5.2 The OA transaction types profiled for use in this part of this Defence Standard are detailed in clauses 5.2.1 to 5.2.5.

5.2.1Order Placement (Customer to Contractor) (SA1). The SA1 enables the Customer to place an order, in a standard format.

5.2.2The order detail at Level 1 of the transaction will be augmented by individual Segments at Level 2. he total order QTY can be split into partial quantities, eg varying Required Delivery Dates (TEI: RDD), Priorities (TEI: PTY) and Ultimate Destinations (TEI: UDU). A minimum of one Level 2 Segment will always be present.

5.2.3Order Acceptance (Contractor to Customer) (SA2). The Contractor shall use the SA2 to indicate acceptance of the SA1.

5.2.3.1 The SA2 shall include Forecast Delivery Dates (TEI: FDD), but if the FDD cannot be provided, a SA2, with a SAC ‘KB’ shall be transmitted, indicating that an SA4 shall follow. If, prior to the expiry of timescales for the SA4 transmission as detailed in annex B, the Contractor provides an order amendment transaction (SE1/SF1/SG1). The FDD may be included in the amendment transaction. If this amendment is accepted by the Customer, a SA4 is not required.

5.2.4 Order Rejection (Contractor to Customer) (SA3). Where the Contractor wishes to reject the SA1, the SA3 shall be used.

5

DEF STAN 00-60 (PART 24)/3

5.2.5 Advice of Order Change (Contractor to Customer) (SA4). The Contractor shall use the SA4 to inform the Customer of executive changes to the order details. An executive change is a change to order details that is deemed to be within the remit of the Contractor to implement without prior acceptance by the Customer.

6 Amendment Request/Acceptance Procedures

6.1The Customer and the Contractor may propose an amendment to an existing order at any time until acceptance of the final invoice against that order, with the exception of the SB1 which, when required, must be raised within one month of the automatic acknowledgement of the order. Such amendments will not come into effect unless and until accepted by the other party to the order.

6.2Input of Concurrent Amendment Messages. The Contractor shall not and the Customer will not transmit second or subsequent amendments to an order until the preceding amendment has been cleared by either, an acceptance, or a rejection message. Until the preceding amendment has been cleared by either, an acceptance, or a rejection message, any further amendment will be rejected by an Error Notification Message (ERRNLT) for reassessment. For details of ERRNLT messages, refer to S2000M Volume 4 Appendix 2 annex E.

6.2.1 Priority Transaction Override Procedures. When an amendment request has been transmitted and a reply cannot be provided immediately, under the rules detailed at Clause 6.2 above, the relevant part of the order is blocked from further amendment, as detailed below, until an acceptance or rejection is transmitted.

6.2.1.1If Level 0 information is being amended, the whole order is blocked.

6.2.1.2If Level 1 information is being amended, associated Level 1 segments and their dependant Level 2 segments are blocked.

6.2.1.3If Level 2 information is being amended, associated Level 2 segments are blocked.

6.2.2 Where an urgent amendment is required against the ‘blocked’ order/segments, one of the following override options shall be applied:

(a)Option 1: The receiver is not yet ready to reply to the initial message but wishes to input a separate urgent amendment to the order. In this circumstance the receiver will reject the initial amendment and include the SAC ‘AJ’ within the rejection message. This SAC indicates that the amendment request has been rejected because of the urgent, follow-on requirement. If additional explanation for the rejection is required, this should be contained within REM. The urgent amendment message will then be transmitted. Once the urgent requirement has been accepted or rejected the initial amendment should be reassessed and actioned accordingly.

(b)Option 2: The receiver has not yet replied to the initial message but the sender wishes to input a separate urgent amendment to the order. In this circumstance the sender will transmit a SH6/7 hastening message (refer to Clauses 6.14 and 6.15), utilising SAC ‘AK’, advising the

6

DEF STAN 00-60 (PART 24)/3

receiver of the situation. This message requests the receiver to reject or accept the initial amendment transaction immediately. If the receiver rejects the initial amendment transaction to allow the priority action to take place, the rejection message must include the SAC ‘AJ’. Once the urgent requirement has been accepted or rejected the initial amendment should be reassessed and actioned accordingly.

6.3Override for Crossing Transactions. It may be possible to send amendment messages concerning the same order which cross in the transmission system. If there is a conflict within either receiving system, it will reject, utilising an ERRNLT message, the incoming message back to its originating system. Any such conflict will be resolved off-line.

6.4Procedures for Customer Order Amendments that Incur Contractor Price Amendments. When the Customer initiates an Order Amendment Request that incurs Contractor price amendment implications the procedures illustrated in the process flow diagram at annex C, will be adopted.

6.5Order Amendment (Customer to Contractor) SB1/SC1/SD1. These transactions are used by the Customer to request the amendment of order data. In all cases, the transactions will not amend the order data until an acceptance message is received. The procedures to be adopted for the implementation of the Customer order amendments that incur Contractor price amendments are detailed in annex C.

6.5.1SB1 - This transaction will be used by the Customer to request an increase in the overall (Level 1) QTY required in the order to which reference is made. The amendment may also include changes to other Data Elements related to the change in QTY.

6.5.2SC1 - This transaction will be used by the Customer to request a reduction in the overall (Level 1) QTY, or total cancellation of an order. The amendment may also include changes to other Data Elements related to the change in QTY. In the case of a cancellation of an order, the QTY fields will be filled with 0 (zero).

6.5.3SD1 - This transaction will be used by the Customer to request amendments to order data, where the overall (Level 1) QTY is not amended. The SD1 is also the transaction for submitting Diversion Order (DO) Requests.

6.5.3.1 DO Requests will be submitted by the Customer to accelerate an order already placed and accepted. The DO may include a split and/or diversion of delivery destination against that order. The DO will normally involve the introduction or increase of PTY and an amendment to the RDD. In submitting such requests, the Customer will create a unique Diversion Number (TEI: DNO) for each diversion raised, as well as indicating required changes in PTY, RDD, delivery addresses and shipment requirements. Each diversion will have one DNO unique within the IPO which will not be amended, except cancellation of the diversion and rescheduling the diversion into a number of deliveries, during the life of the diversion. To cancel a diversion requirement the DNO and PTY values should be deleted and any other changes to the order definition should be reviewed eg RDD and UDU.

7

DEF STAN 00-60 (PART 24)/3

6.6 Order Amendment Acceptance (Contractor to Customer) (SB2/SC2/SD2). The Contractor shall use these transactions to accept the corresponding SB1/SC1/SD1. The Contractor shall not transmit pricing amendments via the SB2/SC2/SD2. The procedures to be adopted for the implementation of the Customer order amendments that incur Contractor price amendments are detailed in annex C.

6.6.1 SB2/SD2 - If the FDD for an increased QTY differs from the original order, the new FDD shall be provided by the SB2/SD2. If the FDD cannot be provided, a SB2/SD2 with a SAC ‘KB’ shall be transmitted, indicating that an SA4 shall follow. If, prior to the expiry of timescales for the SA4 transmission, as detailed in annex B, the Contractor provides an order amendment transaction (SE1/SF1/SG1). The FDD may be included in the amendment transaction. If this amendment is accepted by the Customer, the requirement for an SA4 is not required.

6.7 SB3/SC3/SD3 Order Amendment Rejection (Contractor to Customer). The Contractor shall use these transactions to reject the corresponding SB1/SC1/SD1. The procedures to be adopted for the implementation of Customer order amendments that incur Contractor price amendments are detailed in annex C.

6.7.1 If the Contractor rejects the Customer’s SC1 because the order QTY decrease/cancellation will incur financial liability, in addition to the procedures detailed in annex C, the Contractor shall transmit a SC3 with a SAC ‘KA’. If the Customer wishes to accept this liability, a new SC1 will be submitted with a SAC ‘KC’.

6.8Order Amendment (Contractor to Customer) (SE1/SF1/SG1). The Contractor shall use these transactions to request the amendment of order data. The amendment may also include changes to other Data Elements related to the change in QTY (including pricing). In the case of a SF1 cancellation of an order, the QTY fields shall be 0 (zero) filled. The procedures to be adopted for the implementation of the Customer order amendments that incur Contractor price amendments are detailed in annex C.

6.9Order Amendment Acceptance (Customer to Contractor) (SE2/SF2/SG2). The Customer will use these transactions to accept corresponding SE1/SF1/SG1.

6.10Order Amendment Rejection (Customer to Contractor) (SE3/SF3/SG3). The Customer will use these transactions to reject the corresponding SE1/SF1/SG1.

6.11Status Enquiry (Customer to Contractor) (SH1). The Customer will use the SH1 transaction to seek status information concerning either a specific item, which may be the subject of several orders. In the case of the latter, the Customer will be able to obtain information for the whole order, or a nominated part thereof.

6.12Status Advice (by Order) (Contractor to Customer) (SH4). The Contractor shall use the SH4 to respond with the specific information, by order, requested by the Customer via a SH1.

8