Supplier M2M project recommendation guide€¦ · Web viewThis document functions as an...

EADSINFORMATION SYSTEMS

AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS

Supplier M2M project recommandation guide Ref: <Reference><Reference>

AIRSUPPLY DEPLOYMENT Issue:

1.0Date:

03/04/2012AirSupply SP1

<Project code>

<Application Code>

<AIRSUPPLY DEPLOYMENT>Supplier M2M project recommendation guide

Responsibilities Name - Function Department - Company

Date Signature

Written by Florent Coletta 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

File Name: document.docx Template Ref: IS-TEM-TRM-0010/Issue E 1/12

Ó EADS 2023. All rights reserved. Confidential and proprietary document.Ó Airbus SAS 2023.


AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

TABLE OF CONTENT

<AIRSUPPLY DEPLOYMENT> 1 SUPPLIER M2M PROJECT RECOMMENDATION GUIDE 1 TABLE OF CONTENT 2 1. INTRODUCTION 3

1.1. PURPOSE OF THE DOCUMENT 31.2. TERMINOLOGY 3

2. MAIN RECOMMANDATIONS 4

2.1. FILE SIZE LIMITATIONS ON SUPPLIER SIDE 42.2. FORECAST DOWNLOAD 42.3. PURCHASE ORDER DOWNLOAD 42.4. THE PURCHASE ORDER RESPONSE 52.5. IMPLEMENTATION OF VMI FLOW 6

3. MAIN CHANGES BETWEEN ESUPPLYCHAIN AND AIRSUPPLY 7

3.1. GENERAL CHANGES 73.2. MAIN CHANGES WITH PO IN AIRSUPPLY 73.3. MAIN CHANGES WITH FORECAST IN AIRSUPPLY 93.4. MAIN CHANGES WITH VMI IN AIRSUPPLY 93.5. MAIN CHANGES WITH DESPATCH ADVICE IN AIRSUPPLY 10

4. MIGRATION HIGHLIGHTS & KEY ELEMENTS 11 5. APPENDIX 12



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

1. INTRODUCTION

1.1. Purpose of the documentThis 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 AbbreviationARP Id Supplier’s Airbus Resource Planning identifier

AS2 Applicability Statement 2 (= specification for data exchange)

ASN Advance Shipping Notification

BICBusiness 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 TPMBIS Trading Partner Management (e.g. SupplyOn’s configuration of all AS2 communication partners within the BIS)

CP Control PointCRLF 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 MonitorM2M Machine-to-Machine connectionMDN Message Disposition NotificationSB Self Billing

SCM Supply Chain ManagementSO SupplyOnVMI Vendor Managed InventoryXML Extended Markup Language



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

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 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.

2.1.1. How to evaluate file and transmission sizes

See with EDI SupplyOn support.

2.1.2. Multi attachment or mono attachmentImportant 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 downloadPO 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



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

2. The supplier must decide how he will deal with the PO changes:a. Integrate the changes without question in his systemb. Separate the flow of PO between new and PO that have changed. Treat with a specific

workflow the modified POsc. Set-up automatic email alert in the AirSupply hub to be alerted by these cases and

manually propagate the changed. 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 responseAs 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.

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 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.

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 changeThe 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 changeNon-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



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<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 flow2.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 ([email protected]) -> 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.



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

3. MAIN CHANGES BETWEEN ESUPPLYCHAIN AND AIRSUPPLY

3.1. General changes3.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 AirSupply3.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 backlogIn 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 replaced by Ordering Officer



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

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.



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

3.2.9. Changes impacting PO Response3.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 PUBDMD by SUPCOM before uploading file.

3.4. Main changes with VMI in AirSupply3.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



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

3.4.2. Identification of the withdrawal valueAs 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.



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

4. MIGRATION HIGHLIGHTS & KEY ELEMENTS

4.1.1. PO prefix removedThis 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 addedMaterial number contains now a prefix.

4.1.3. Vendor Material Number / VMN DescriptionThere 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.



AIRBUSINFORMATION

SYSTEMS

INFORMATION SYSTEMS



1.0Date:


<Project code>

<Application Code>

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


Supplier M2M project recommendation guide€¦ · Web viewThis document functions as an...

Documents

Transcript of Supplier M2M project recommendation guide€¦ · Web viewThis document functions as an...