INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
Issue:
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
Ref: <Reference>
1.0
<Project code>
Date:
03/04/2012
<Application Code>
<AIRSUPPLY DEPLOYMENT>
Supplier M2M project recommendation guide
Responsibilities
Name - Function
Written by
Florent Coletta
Department Company
On behalf of Airbus
Date
Authorized by
Cécile Bernard
Airbus - ILNC
03/04/2012
Document owner Mark Dempsey
Airbus - ILNC
03/05/2012
03/04/2012
Signature
 Airbus SAS 2016.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
1/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
TABLE OF CONTENT
<AIRSUPPLY DEPLOYMENT>
1
SUPPLIER M2M PROJECT RECOMMENDATION GUIDE
1
TABLE OF CONTENT
2
1.
3
INTRODUCTION
1.1.
PURPOSE OF THE DOCUMENT
3
1.2.
TERMINOLOGY
3
2.
MAIN RECOMMANDATIONS
4
2.1.
FILE SIZE LIMITATIONS ON SUPPLIER SIDE
4
2.2.
FORECAST DOWNLOAD
4
2.3.
PURCHASE ORDER DOWNLOAD
4
2.4.
THE PURCHASE ORDER RESPONSE
5
2.5.
IMPLEMENTATION OF VMI FLOW
6
3.
MAIN CHANGES BETWEEN ESUPPLYCHAIN AND AIRSUPPLY
7
3.1.
GENERAL CHANGES
7
3.2.
MAIN CHANGES WITH PO IN AIRSUPPLY
7
3.3.
MAIN CHANGES WITH FORECAST IN AIRSUPPLY
9
3.4.
MAIN CHANGES WITH VMI IN AIRSUPPLY
9
3.5.
MAIN CHANGES WITH DESPATCH ADVICE IN AIRSUPPLY
10
4.
MIGRATION HIGHLIGHTS & KEY ELEMENTS
11
5.
APPENDIX
12
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
2/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
1.
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
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
ARP Id
AS2
ASN
BIC
BIS
BIS TPM
CP
CRLF
CSV
EAI
EDI
EDIINT AS2
IMO
M2M
MDN
SB
SCM
SO
VMI
XML
File Name: Document1
Description
Abbreviation
Supplier’s Airbus Resource Planning identifier
Applicability Statement 2 (= specification for data
exchange)
Advance Shipping Notification
Business Integration Conversion (the conversion module
of the BIS executing the message conversion/translation
into another format)
SEEBURGER Business Information Server (SupplyOn’s
EDI messaging system software)
BIS Trading Partner Management (e.g. SupplyOn’s
configuration of all AS2 communication partners within the
BIS)
Control Point
Carriage Return Line Feed
Comma or (Semi) Colon Separated Values (Message
Format)
Enterprise Application Integration (system)
Electronic Data Interchange
Electronic Data Interchange Internet Integration –
Applicability Statement 2
Inventory Monitor
Machine-to-Machine connection
Message Disposition Notification
Self Billing
Supply Chain Management
SupplyOn
Vendor Managed Inventory
Extended Markup Language
Template Ref: IS-TEM-TRM-0010/Issue EE
3/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
2.
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
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 the approach (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.
How to evaluate file and transmission sizes
See with EDI SupplyOn support.
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
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
4/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
2. The supplier must decide how he will deal with the PO changes:
a. Integrate the changes without question in his system
b. Separate the flow of PO between new and PO that have changed. Treat with a specific
workflow the modified POs
c. Set-up automatic email alert in the AirSupply hub to be alerted by these cases and
manually propagate the change
d. 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 steps directly in the application, especially if he wants to
use all the possibilities of the collaboration (request for change), and not only accept.
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 response the 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.
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
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
5/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
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
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 (valerie.truc@airbus.com) -> VMI Finance TransNatCos
If the supplier wants to manage his own invoice, he has to identify the withdrawal movements.
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:
StkMvt to be
invoiced_V2.xlsx
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.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
6/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
3.
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
MAIN CHANGES BETWEEN ESUPPLYCHAIN AND AIRSUPPLY
3.1. General changes
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.
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
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.
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.
Buyer notion replaced by Ordering Officer
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
7/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
In Airsupply we do not use the buyer notion. It is named Ordering Officer.
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).
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
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.
PO_PositionNumber
In AirSupply, the PO position number (i.e. PO line) is always recorded on 5 digits (ex: 00010).
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.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
8/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
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
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.
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 PUBDMD by SUPCOM before uploading file.
3.4. Main changes with VMI in AirSupply
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
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.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
9/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
3.5. Main changes with Despatch Advice in AirSupply
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.
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.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
10/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
AIRSUPPLY DEPLOYMENT
AirSupply
4.
SP1
<Project code>
Ref: <Reference>
Issue:
1.0
Date:
03/04/2012
<Application Code>
MIGRATION HIGHLIGHTS & KEY ELEMENTS
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.
Material number prefix added
Material number contains now a prefix.
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.
File Name: Document1
Template Ref: IS-TEM-TRM-0010/Issue EE
11/12
INFORMATION
SYSTEMS
Supplier M2M project recommandation guide
5.
Issue:
AIRSUPPLY DEPLOYMENT
AirSupply
Ref: <Reference>
1.0
<Project code>
SP1
Date:
03/04/2012
<Application Code>
APPENDIX
REFERENCE DOCUMENTS
Index
Title
Reference
Issue
Date
APPROVAL
Name - Function
Department Company
Date
Signature
TABLE OF REVISIONS
Issue
1.0
Date
03/04/2012
File Name: Document1
Modified by
Modified
sections
Observations
Document creation
Template Ref: IS-TEM-TRM-0010/Issue EE
12/12