Supplier M2M Project Recommendation Guide

Supplier M2M Project Recommendation Guide

/ / Supplier M2M projectrecommandation guide / Ref: <Reference>
AirSupply Deployment / Issue:
1.0 / Date:
03/04/2012
AirSupply / SP1 / <Project code>
<Application Code>

<AirSupply Deployment

Supplier M2M project recommendation guide

Responsibilities / Name - Function / Department - Company / Date / Signature
Written by / FlorentColetta / On behalf of Airbus / 03/04/2012
Authorized by / Cécile Bernard / Airbus - ILNC / 03/04/2012
Document owner / Mark Dempsey / Airbus - ILNC / 03/05/2012

TABLE OF CONTENT

<AirSupply Deployment>

Supplier M2M project recommendation guide

TABLE OF CONTENT

1.Introduction

1.1.Purpose of the document

1.2.Terminology

2.Main recommandations

2.1.File size limitations on supplier side

2.2.Forecast download

2.3.Purchase Order download

2.4.The Purchase Order response

2.5.Implementation of VMI flow

3.Main changes between esupplychain and airsupply

3.1.General changes

3.2.Main changes with PO in AirSupply

3.3.Main changes with Forecast in AirSupply

3.4.Main changes with VMI in AirSupply

3.5.Main changes with Despatch Advice in AirSupply

4.migration highlights & key elements

5.appendix

1.Introduction

1.1.Purpose of the document

This document functions as an implementation guideline for suppliers to connect to the new shared European aerospace Supply Chain Management (SCM) platform via a Machine-to-Machine (M2M).

This Implementation Guideline includes both technical details and general information in order to provide suppliers some highlights on main changes on M2M connections between eSupplyChain and AirSupply.

This document has not the objective to be exhaustive but to ensure that main aspect of Airsupply M2M integration will not be missed by the supplier.

1.2.Terminology

Term / Description / Abbreviation
ARP Id / Supplier’s Airbus Resource Planning identifier
AS2 / Applicability Statement 2 (= specification for data exchange)
ASN / Advance Shipping Notification
BIC / Business Integration Conversion (the conversion module of the BIS executing the message conversion/translation into another format)
BIS / SEEBURGER Business Information Server (SupplyOn’s EDI messaging system software)
BIS TPM / BIS Trading Partner Management (e.g. SupplyOn’s configuration of all AS2 communication partners within the BIS)
CP / Control Point
CRLF / Carriage Return Line Feed
CSV / Comma or (Semi) Colon Separated Values (Message Format)
EAI / Enterprise Application Integration (system)
EDI / Electronic Data Interchange
EDIINT AS2 / Electronic Data Interchange Internet Integration – Applicability Statement 2
IMO / Inventory Monitor
M2M / Machine-to-Machine connection
MDN / Message Disposition Notification
SB / Self Billing
SCM / Supply Chain Management
SO / SupplyOn
VMI / Vendor Managed Inventory
XML / Extended Markup Language

2.Main recommandations

2.1.File size limitations on supplier side

Designing and implementing M2M connection, it is important for the supplier to take in consideration the size of the transmissions and the size of the files exchanged. It really depends on the flow (PO, Forecast etc.), on the format (Boostaero XML or CSV) and on theapproach (frequency of downloads).

We distinguish 2 constraints:

-The network constraint that is related to the size of the transmission and the file transferred. For example files can be zipped to reduce their impact on the network.

-The system constraint that is related to the message content and size. The ability of the system to treat a file (archiving for example) determine this constraint.

For Forecast for instance, all Forecast messages are downloaded on Tuesday morning while PO are downloaded along the flow: risk of overload on Forecast message!!!

In case of important volumes identified, it is important to perform the analysis in term of volume and performance and to plan load test.

2.1.1.How to evaluate file and transmission sizes

See with EDI SupplyOn support.

2.1.2.Multi attachment or mono attachment

Important element is to understand that SupplyOn provides multi-attachment AS2 transmission. Choosing between Boostaero XML and CSV messages impact are different. Supplier has to make the analysis.

Indeed CSV messages will be transmitted in only one CSV file, 1 line per data.

Boostaero XML transmission contains several messages in the same transmission.

2.2.Forecast download

Using the scheduler in AirSupply the supplier is able to select the data measure he needs. Indeed the on every date within a Foreacst 4 types of information is available. Depending on whether the supplier is collaborating on Forecast or not, type of data he needs will be different.

2.3.Purchase Order download

PO integration is made along the flow downloading with high frequency the POs using delta option (“Only new data…”). The important thing to understand is that if a change happen in the PO, would it be collaborative change (change in status, date or quantity) or non-collaborative (for example delivery address) the PO will be downloaded again with the delta option. Indeed the supplier must be aware of this change and must be sent the PO to take the changes in consideration.

So 2 impacts:

  1. Before recording a downloaded PO the supplier has to check if he has not already record it
  2. The supplier must decide how he will deal with the PO changes:
  3. Integrate the changes without question in his system
  4. Separate the flow of PO between new and PO that have changed. Treat with a specific workflow the modified POs
  5. Set-up automatic email alert in the AirSupply hub to be alerted by these cases and manually propagate the change
  6. Other

He may also decide to put in place more than one of these solutions if he needs to (a + c for example to make sure no loss of information).

2.4.The Purchase Order response

As explained upper, the supplier has to take in consideration the possible changes in a PO he has recorded on his side. It is all the more true when he decides to do PO response by M2M. Indeed the supplier has to answer or collaborate on the last “version” (last status, last quantity last date) of the PO published on the hub.

The PO response is not easy to manage by M2M. The supplier should consider the option to perform download by M2M but make the collaboration stepsdirectly in the application, especially if he wants to use all the possibilities of the collaboration (request for change), and not only accept.

2.4.1.The PO version

This new element (not present in eSC) aims to guarantee that PO response from a supplier is made on a PO that has not changed in between.

This data is a number (version number) managed at PO line level which is raised/increased when the Customer (Airbus) makes a collaborative change (change of date, quantity or status). The supplier has to send in his PO responsethe same version, the same figure.

Please note that this version is also increased with the 1st response of a supplier.

The recommendation is to download frequently the PO with “new data” via M2M, check if the PO has already been recorded on his side, and in case of PO has been recorded take in consideration the change in the PO and record the current version.

2.4.2.Collaborative and non-collaborative change

A PO will be downloaded again if a change occurs on the PO. 2 types of changes are distinguished.

The PO response is not easy to manage by M2M. The supplier should consider the option to perform download by M2M but make the collaboration steps directly in the application, especially if he wants to use all the possibilities of the collaboration (request for change), and not only accept.

2.4.2.1.Collaborative change

The collaborative change of a PO is a change on the status, date or quantity. A collaborative change from the customer (Airbus) will increase the version. In case of consecutive changes only the 1st collaborative change on a PO from the supplier will increase the version.

2.4.2.2.Non- collaborative change

Non-collaborative change of a PO is a change in some other data in a PO like delivery address, price or ordering officer. It will make the PO to be downloaded again but version will not be increase. If with the delta option in download (“only new data”) a PO that has already been downloaded is downloaded again, and version is the same: it is non-collaborative change.

2.5.Implementation of VMI flow

2.5.1.VMI invoicing: do self-billing

The Airbus recommendation regarding invoicing management of VMI flow is to implement self-billing.

Fully automated self-billing is implemented via EDI connection with Airbus and not with Airsupply M2M connection.

To go for Self-billing contacts are:

Valérie Truc () -> VMI Finance TransNatCos

If the supplier wants to manage his own invoice, he has to identify the withdrawal movements.

2.5.2.The withdrawal movements

VMI movements corresponding to real consumption (to invoice) are known as withdrawal values. In Airsupply all the VMI movements are published. The difficulty is to identify among them which one are the withdrawal values. In the VMI movement is provided the Airbus movement code. Depending on the Airbus Natco (country of origin) the rule to identify these values is different. So the idea is for each movement get the Natco information and the movement code and check with the criteria table below if it is a withdrawal value:

M2M supplier has to implement this rule on his side.

The complexity and the fact that this table of criteria is maintained on supplier side are an additional reason to recommend self-billing.

3.Main changes between esupplychain and airsupply

3.1.General changes

3.1.1.Date format

The date format in SupplyOn contains now the hour. It is important to integrate this change at download and especially when performing PO response: indeed not returning the same hour in the date (“delivery date” for example) would be considered as a Supplier Order Change.

3.1.2.Material number

Natco prefix is still available in front on the material number however we recommend you to not integrate this Natco identifier in your ERP system.

3.2.Main changes with PO in AirSupply

3.2.1.No more Natco prefix in PO number

There is no more PO Natco identifier with AirSupply.

If you used it to identify the Natco of your purchase order, we recommend you to use the value in the ‘PARTNER_RELATION_CUSTOMER_ORGCODE’ field (field # 118 of PO CSV mapping).

3.2.1.1.Impact on backlog

In the PO sent from eSC there was a prefix. After migration on the new application, the prefix is removed but the number does not change. The supplier has to take it in consideration just after migration to be able to make the match and to send the response and dispatch advice with the good PO number.

Remove the 3 first characters.

3.2.2.Order type/Order sub-type

In eSupplyChain, only field ‘Order Sub-Type’(field # 39 of Spoke PO mapping) was used to store order type and order sub-type. The possible values were "CALLUP", "OTHER" and "SPARES".

With AirSupply, spares purchase orders are identified thanks to “SPARES” values available in field ‘PO_OrderSubType’(field # 5 of PO CSV mapping). Field ‘PO_OrderType’ will always be set to “OTHER” for spares.

3.2.3.Buyer notion replacedby Ordering Officer

In Airsupply we do not use the buyer notion. It is named Ordering Officer.

3.2.4.PO versioning

Field ‘PO_UpdateVersion’ (field # 130 of PO CSV mapping)

It represents the update version of the PO schedule line within the AirSupply system.

On each collaboration change on the PO schedule line (either from ERP system or by AirSupply due to collaboration), the PO schedule line receives an increment of value on the update version (to indicate the count of changes performed on the PO schedule line).

The PO version is used for consistency check on down/upload by supplier (and M2M).

3.2.5.Country code format

For all county code, AirSupply is now using the ISO 3166-3 country code norm. The field that follows this format is the following:

-‘PO_InvoiceCountryCode’: field # 5 of PO CSV mapping

3.2.6.Terms of payment

The field ‘Terms’ in the Spoke PO mapping has been splitted in AirSupply in two fields.

-‘PO_PayTerms’ (field # 96 of PO CSV mapping)

-‘PO_PayTermsCode’ (field # 97 of PO CSV mapping)

In eSupplyChain, the field ‘Terms’ contained the code of payment Term followed by the description of the payment terms.

3.2.7.PO_PositionNumber

In AirSupply, the PO position number (i.e. PO line) is always recorded on 5 digits (ex: 00010).

3.2.8.Changes impacting PO Download

Regarding the PO download itself the only impacts may be a slight increase of the scope of PO received. That will be directly managed by deployment team in time.

3.2.9.Changes impacting PO Response

3.2.9.1. PO versioning

Field ‘PO_UpdateVersion’ (field # 130 of PO CSV mapping)

It represents the update version of the PO schedule line within the AirSupply system.

On each collaboration change on the PO schedule line (either from ERP system or by AirSupply due to collaboration), the PO schedule line receives an increment of value on the update version (to indicate the count of changes performed on the PO schedule line).

The PO version is used for consistency check on down/upload by supplier (and M2M).

3.3.Main changes with Forecast in AirSupply

3.3.1.Logistic family code

In eSupplyChain, the logistic family code was provided in the last characters of eSC mapping's column 7.

With AirSupply, a new field ‘LogisticFamilyName’ (field # 26 of Forecast CSV mapping) contains the logistic family of the material.

3.3.2.Changes impacting Forecast Response

3.3.2.1.Best practices for forecast response

If you want to commit to Airbus forecast published demand, you need only to keep lines with value PUBDEM on field ‘DataMeasure’ (field # 53 of Forecast CSV mapping) on your downloaded file then to replace the value PUBDMDby SUPCOM before uploading file.

3.4.Main changes with VMI in AirSupply

3.4.1.3 message types

In Airsupply, to manage VMI data, the supplier will receive 3 different types of message:

-The stock movement, containing information of stock movement for a material

-The stock level, containing the information of the quantity in Airbus stock

-The VMI demand corresponding to gross need

In eSupplyChain there was only 1 type of message and the supplier would select between the different data measure to get the information needed

3.4.2.Identification of the withdrawal value

As explained before, now to get the withdrawal values the supplier has to use the stock movement and the criteria table given before to have the withdrawal value. There is no easy criterion.

3.5.Main changes with Despatch Advice in AirSupply

3.5.1.Despatch advice codification rule

The rule to create the dispatch advice ID or code is not the same than in eSC. It is now compliant with SSCC18 international norm. Please refer to documentation provided on SupplyOn portal (where are published M2M guidelines) to find the complete description of the new rule.

3.5.1.Control on departure date VS estimated delivery date

With eSupplyChain, a control was done when uploading an ASN to ensure that the estimated delivery date was greater than the departure date.

4.migration highlights & key elements

4.1.1.PO prefix removed

This point has been mentioned before but just after migration the impact of change in PO numbering may have impact on PO download when trying to match PO before migration and the same PO downloaded after and which PO number have changed (prefix removed). The number remains the same!

Same for PO response and Despatch Advice on a PO that has been downloaded before.

4.1.2.Material number prefix added

Material number contains now a prefix.

4.1.3.Vendor Material Number / VMN Description

There is no automatic migration of the supplier cross-references made in ESL for eSupplyChain. There is a way for the supplier to perform this migration with mass upload function. It is important to note that Airbus cannot perform the migration as this is supplier data ownership. When migration comes, supplier will be communicated how to perform this mass upload.

5.appendix

REFERENCE DOCUMENTS
Index / Title / Reference / Issue / Date
APPROVAL
Name - Function / Department -
Company / Date / Signature
TABLE OF REVISIONS
Issue / Date / Modified by
/ Modified sections / Observations
1.0 / 03/04/2012 / Document creation
File Name: IS-TEM-TRM-0010_E.doc / Template Ref: IS-TEM-TRM-0010/Issue E / 1/12