27
To Be Process Purchasing process – Inter & Intra company flows - Avenir V2 document.doc Table of content 1 DOCUMENT UPDATES....................................................3 2 SCOPE............................................................... 4 2.1 PROCESS SCOPE DESCRIPTION............................................ 4 2.2 APPLICATION ARCHITECTURE (GLOBAL).....................................5 2.2.1 Customer download to the receiving/shipping plant ..........................................................5 2.2.2 Material download to the receiving / shipping plant ..........................................................5 2.2.3 Vendor download to the receiving plant...............................................................................5 2.2.4 Purchase order download to the receiving plant................................................................6 2.2.5 Purchasing scheduling agreement download to the receiving plant ...............................6 2.2.6 Purchasing scheduling agreement download to the shipping plant (only for PUSH) ....6 2.2.7 Delivery download to the shipping plant..............................................................................6 2.2.8 Delivery upload from the shipping plant.............................................................................. 6 2.2.9 Reception upload from the receiving plant..........................................................................6 2.3 CROSS REFERENCES................................................... 7 3 BUSINESS RULES...................................................... 8 3.1 CORE MODEL – BUSINESS RULES.......................................... 8 3.2 COUNTRY OR CUSTOMER SPECIFIC – BUSINESS RULES...........................9 4 PROCESS............................................................ 10 4.1 PROCESS OBJECTIVES................................................. 10 4.2 PROCESS PRE-REQUISITES............................................. 10 4.3 PROCESS FLOW..................................................... 12 4.3.1 SAP shipping (PULL mode)....................................................................................................12 4.3.2 FLEXNET shipping (PUSH mode)...........................................................................................15 4.3.3 A posteriori shipping............................................................................................................. 16 5 KEY ELEMENTS OF SYSTEM IMPLEMENTATION ..............................17 5.1 MASTER DATA...................................................... 17 5.1.1 Material................................................................................................................................... 17 5.1.2 Vendor..................................................................................................................................... 17 5.1.3 Info-record.............................................................................................................................. 17 5.1.4 Customer................................................................................................................................. 17 5.1.5 Source-list................................................................................................................................ 17 5.1.6 Quota arrangement............................................................................................................... 17 5.2 CUSTOMIZING...................................................... 19 5.2.1 Intra-company SAP shipping................................................................................................ 19 5.2.2 Inter-company SAP shipping................................................................................................19 5.2.3 Intra-company FLEXNET shipping / Shipping a posteriori ...............................................19 5.2.4 Inter-company FLEXNET shipping / Shipping a posteriori ................................................20 5.2.5 Intra-company Prototype...................................................................................................... 20 1/27 26/04/22 - 01:19

ACO_MM_TBP_17bis_Purchasing Process - Inter & Intra Company Flows - Avenir V2

Embed Size (px)

DESCRIPTION

SAP PURCHASING

Citation preview

ACO_MM_TBP_17_Purchasing Process - Inter & Intra company flows-

To Be Process

Purchasing process Inter & Intra company flows - Avenir V2

ACO_MM_TBP_17bis_Purchasing Process - Inter & Intra company flows - Avenir V2

Table of content

31Document updates

42Scope

42.1Process scope description

52.2Application architecture (global)

52.2.1Customer download to the receiving/shipping plant

52.2.2Material download to the receiving / shipping plant

52.2.3Vendor download to the receiving plant

62.2.4Purchase order download to the receiving plant

62.2.5Purchasing scheduling agreement download to the receiving plant

62.2.6Purchasing scheduling agreement download to the shipping plant (only for PUSH)

62.2.7Delivery download to the shipping plant

62.2.8Delivery upload from the shipping plant

62.2.9Reception upload from the receiving plant

72.3Cross references

83Business Rules

83.1Core model Business rules

93.2Country or customer specific Business Rules

104Process

104.1Process objectives

104.2Process pre-requisites

124.3Process flow

124.3.1SAP shipping (PULL mode)

154.3.2FLEXNET shipping (PUSH mode)

164.3.3A posteriori shipping

175Key elements of system implementation

175.1Master data

175.1.1Material

175.1.2Vendor

175.1.3Info-record

175.1.4Customer

175.1.5Source-list

175.1.6Quota arrangement

195.2Customizing

195.2.1Intra-company SAP shipping

195.2.2Inter-company SAP shipping

195.2.3Intra-company FLEXNET shipping / Shipping a posteriori

205.2.4Inter-company FLEXNET shipping / Shipping a posteriori

205.2.5Intra-company Prototype

205.3Summary

216Organizational roles and impacts

227Application specific development requirements

228Key volume & performance indicators

229Added value for the Business and economical considerations

Document updates

The table below lists all modifications and updates done on the considered document. Fill in Date, Author and a summary of the documents update content, reason and/or objectives.

Updates

Date

Version

Author

Comment

19/08/05

V0

C. Choubard

document creation

1 Scope

1.1 Process scope description

This document describes inter and intra-company flows applied within Sekurit Avenir V2 solution

They consist in stock transfers between Sekurit sites glass plants / extrusion / encapsulation / service centers:

Inside the same Sekurit company (without transfer of property) ( INTRA-COMPANY

Between two Sekurit companies (with transfer of property) ( INTER-COMPANY

It concerns Logistics tradable products, i.e. prototypes, tradable semi-finished products and finished products.

Definitions:

Shipping plant: the Sekurit site from which goods are sent.

Receiving plant: the Sekurit site for which goods are intended.

Site typology:

C. Site in sales organization V2 with FLEXNET

D. Site in sales organization V2 without FLEXNET

E. Site in sales organization V2 not yet deployed (in case of transitory period)

Out of scope

( This process concerns all types of Sekurit sites as long as they work with Sekurit Avenir solution systems. If a Sekurit site does not work with Sekurit Avenir solution systems (for Instance SGS Thaland), it is considered as an external vendor or customer: standard purchasing / sales flows are applied.

This document doesnt contains the flows that occurred from the Spain go-live (09.2003) to the Italy-Belgium-Portugal go-live (10.2005), it means that there is no Avenir V1 situation.

Cf. TBMM17 Inter &Intra company flows

( This document does not deal with inter-company direct delivery, when the vendor delivers the final customer but sends the invoice to its inter-company customer.

Cf. TBSD21 Inter-company Billing

( This document does not deal with inter-company returns to vendor / from customer.

Cf. V2-TBIN07 - Returns

( This document does not deal with transfers for components that are handled another way in the system.

Cf. TBIN03 Process internal movements

1.2 Application architecture (global)

This paragraph describes the different Idoc exchanges taking place between SAP and WMS.

SAP

Purchase order

download

Delivery

Order

WHSCON

Scheduling

agreement

Buyer

Receiving plant

WMS

Shipping plant

WMS

Requirement

planning

Scheduling

agreement

-

Schedule

lines

Purchase

Requisitions

Or

Requirement

planning

Requirement

planning

Scheduling

agreement

-

Schedule

lines

Purchase

Requisitions

Or

Inter

-

company

Sales Bill

Inter

-

company

Vendor invoice

Purchase

Order

Purchase scheduling

agreement download

Purchase scheduling

agreement download

Delivery

download

Reception

upload

Purchase order

download

Delivery

upload

Vendor

Download

Vendor

Vendor

Download

Material

download

Material

Material

download

Customer

Download

Customer

Customer

Download

1.2.1 Customer download to the receiving/shipping plant

For all customer creation, modification and deletion, the following Idoc is downloaded from SAP.

If the receiving/ shipping plant has:

FLEXNET (Type C)

( Idoc DEBMAS03/ ZDEBMAS2

No FLEXNET (Type D, E)

( No Idoc

1.2.2 Material download to the receiving / shipping plant

For all material creation, modification and deletion, the following Idoc is downloaded from SAP.

If the receiving / shipping plant has:

FLEXNET (Type C)

( Idoc MATMAS03 / ZMATMAS

No WMS (Type D, E)

( No Idoc

1.2.3 Vendor download to the receiving plant

For all vendor creation, modification and deletion, the following Idoc is downloaded from SAP.

If the receiving / shipping plant has:

FLEXNET (Type C)

( Idoc CREMAS01 / ZCREMAS

No WMS (Type D, E)

( No Idoc

1.2.4 Purchase order download to the receiving plant

For all purchase order creation, modification and un-activation, the following Idoc is downloaded from SAP.

If the receiving plant has:

FLEXNET (Type C)

( Idoc ORDERS01 / ZORDERS_RCV

No WMS (Type D, E)

( No Idoc

1.2.5 Purchasing scheduling agreement download to the receiving plant

For all purchasing scheduling agreement creation, modification and un-activation, the following Idoc is downloaded from SAP.

If the receiving plant has:

FLEXNET (Type C)

( Idoc BLAORD02 / ZBLAORD_RCV

No WMS (Type D, E)

( No Idoc

1.2.6 Purchasing scheduling agreement download to the shipping plant (only for PUSH)

For all PUSH scheduling agreement creation, modification and un-activation, the following Idoc is downloaded from SAP to FLEXNET

( Idoc BLAORD02 / ZBLAORD_SH

1.2.7 Delivery download to the shipping plant

For all delivery creation, modification or deletion, the following Idoc is downloaded from SAP.

If the shipping plant has:

FLEXNET (Type C)

( Idoc DELVRY01/ WHSORD

No WMS (Type D, E)

( No Idoc

1.2.8 Delivery upload from the shipping plant

For all truck closing in FLEXNET of a delivery created in SAP, the following Idoc is uploaded to SAP.

( Idoc DELVRY01 / WHSCON

For all truck closing of a delivery created in FLEXNET, the following Idoc is uploaded to SAP.

If the turnaround procedure has been used

( Idoc DELVRY01 / WHSCON that falls in error in SAP

If the intraco transitory process has been used (flow from a site type C or D to a site type E inside the same company)

( Idoc WMMBID01 / WMMBXY triggering a 993 goods movement

If the inter-co transitory process has been used (flow from a site type C or D to a site type E between two different companies in the same country)

( Idoc ORDERS03/ DELORD triggering a TAM (sales Order) creation

1.2.9 Reception upload from the receiving plant

For all reception in FLEXNET, the following Idoc is uploaded to SAP.

If the receiving plant has:

FLEXNET (Type C)

( Idoc WMMBID01 / WMMBXY

No WMS (Type D, E)

( No Idoc

For all return receptions in WMS, the following Idoc is uploaded to SAP.

If the shipping plant has:

FLEXNET (Type C)

( Idoc WHSCON / DELVRY01

No WMS (Type D, E)

( No Idoc

1.3 Cross references

TBPP13Supply / Delivery requests

V2-TBMM08Supply Manage deliveries requests

V2-TBMM13Purchasing process Scheduling agreement

V2-TBMM14Purchasing process Purchase orders

TBMM17 Purchasing process Inter & intra company flows (V1 and V2 cases)

TBMM22Document Outputs

TBMM23Document Forms

TBIN08Process Shipments

TBIN02Process Receiving

TBSD18Standard delivery with DCS - internal clients

TBSD21Inter-company billing

TBMM32Invoice verification

TBFI16AP Vendor Master Data

Business Rules

1.4 Core model Business rules

( Languages: whatever is the communication language with the vendor, purchasing documents are printed in the language of the purchasing company. ????????????????

( Inter-company flows are an agreement between two companies. The purchasing company is responsible for maintaining its requirements in the purchasing document, because delivery requirements treated by the shipping company are totally dependant on these purchasing requirements.

( For intra-company flows, no invoicing is managed. For inter-company flows, invoicing must be managed (standard invoice verification is mainly used compared to logistic invoice verification).

( Following rules apply:

In a delivery, only one customer (corresponding to the receiving plant) should be concerned,

In a delivery, only one shipping plant should be concerned,

In the delivery, the reference of the purchasing document should be declared.

( Returns flows:

The returns flows are managed in different way if there are Inter or intracompany flows. They are managed as SD flows.

Intercompany physical return:

The plant that return the goods creates a ZZRL delivery; the expedition in Flexnet (mvt 161) generates then a MM return order on this plant, and a SD return order (type ZPRE) on the plant that will receive back the good.

Intercompany non-physical return:

The plant makes a logistics scrap (mvt 961), that generates then a MM return order on this plant, and a SD return order (type ZNRE) on the other plant.

Intracompany physical return:

The plant that return the goods creates a ZZRL delivery; the expedition in Flexnet (mvt 995) generates then a SD return order (type ZPRI) on the plant that will receive back the good.

Intracompany non-physical return:

The plant makes a Logistics scrap (mvt 551)

( When the shipping plant is in the V2 sales organization and has FLEXNET in the shipping area (type C), two shipping processes are available:

- The SAP shipping process (flow initiated in SAP, PULL mode)

The receiving plant needs must be generated by the MRP or registered manually in SAP

The delivery must be created first in SAP according to these needs. This is done:

In the shipping area if SAP is available

Centralized and perform elsewhere if SAP is not available in the shipping area

The delivery is then processed in FLEXNET

- The FLEXNET shipping process (flow initiated in FLEXNET, PUSH mode)

This FLEXNET shipping flow is mainly useful in France and Spain, where production is pushed to the service centers. This is due to the fact that service centers are closer to the customer and stock capacity is reduced in factories. This

The flow initiation in FLEXNET enables service centers in Spain to be autonomous without need of SAP, but is not convenient for France, as deliveries management are centralized in Chantereine. (Service centers are not authorized to create deliveries in FLEXNET)

=> THIS MODE CAN BE USED ONLY FOR FLOWS INSIDE A COUNTRY

- For each flow (shipping plant _=> receiving plant), only one of these two processes is available

Therefore, it is a choice that should be made according to:

The MRP planning capabilities in the receiving plant

The Storage areas available in the shipping and receiving plant

The workers and information systems in the shipping plant

In Spain, the following choices have been made:

All flows to Service centers will use the FLEXNET-shipping process

All flows to Glass plants will use the SAP-shipping process

In France, PUSH mode is used for the flows between Chantereine and the Service centers.

In Germany, only PULL mode is used.

In Italy, PUSH mode is used for the flows Savigliano => Pozzilli, and PULL mode is used for the flows Pozzilli => Savigliano

1.5 Country or customer specific Business Rules

( Spain - Invoice verification: as for purchases in General Warehouse, ERS (Executive Receipt Settlement) could be used for national vendors. For instance, for flows between companies SG Cristaleria and Saint-Gobain Devisa (intercompany flows).

Use of standard/ logistics or ERS invoice verification mode is determined through vendor master data.

2 Process

2.1 Process objectives

Manage deliveries between the shipping site (inter-company vendor) and the receiving site (inter-company customer)

Update stocks

Emit an invoice sent to the inter-company customer (Only inter-company flow)

Perform the invoice verification at the inter-company vendors (Only inter-company flow)

2.2 Process pre-requisites

Pre-requisites to this flow are presented below and detailed in part 5.1.1 Pre-requisites (Master data and Customizing).

Master data manager

Material, on receiving

plant

Master data manager

Vendor, on Purchasing

Organization

Master data manager

Purchase info

-

record,

on receiving plant

(ONLY INTER

-

CO)

Master data manager

Order / Scheduling

agreement

Master data manager

Material, on shipping

plant

Master data manager

Customer, on Sales

Organization

Master data manager

Source

-

list, on

receiving plant

Master data manager

Quota arrangement,

on receiving plant

Receiving plant

Shipping plant

Inter-company flows

For prototypes: a ZPRO purchase order is created on the receiving plant, for each shipping, with an NLAG item used for invoicing

For classical flows, the following table gives the SAP orders to use:

Receiving Shipping

C

(V2 FLEX)

D

(V2 noFLEX)

E

(V2 not depl.)

C (V2 FLEX.)

LPA / ZLP

LPA / ZLP

LZM-TAM

D (V2 no FLEX)

LPA

LPA

LZM-TAM

E (V2 not depl.)

LPA

LPA

N.A.

NB1: if the shipping plant is in V2 but does not have any Sekurit IT system (Type D: Vigo, Valdemoro): LPA purchase scheduling agreement or NB purchase order can be used

NB2: if the shipping plant is in V2 and has Flexnet (type C) and the receiving plant is in V2, the type of order to be used depends on the choice made between SAP and FLEXNET-shipping process:

If FLEXNET-shipping process has been chosen for the flow: ZLP scheduling agreement

If SAP-shipping process has been chosen for the flow: LPA scheduling agreement

In Spain:

FLEXNET shipping (ZLP) will be used for the flows DEVISA( service centers

SAP shipping (LPA) will be used for the flows CRISTALLERIA( DEVISA.

In France: PULL only

NB3: if the receiving plant is in transitory period (is part of SAP V2 system but as not been yet deployed), a sales process will be used:

For shipping from V2 site: LZM scheduling agreement + TAM sales order.

Intra-company flows

For prototypes: a ZUB Purchase order is created for each shipping (without any NLAG item)

For classical flows, the following table gives the SAP orders to use:

Receiving Shipping

C

(V2 FLEX)

D

(V2 noFLEX)

E

(V2 not depl.)

C (V2 FLEX.)

LU / ZLU

LU / ZLU

LK

D (V2 no FLEX)

LU

LU

LK

E (V2 not depl.)

LU

LU

N.A.

NB1: if the shipping plant is in V2 but does not have any Sekurit IT system (Type D: Vigo, Valdemoro), only LU purchase scheduling agreement will be used

NB2: if the shipping plant is in V2 and has Flexnet (type C) and the receiving plant is in V2, the type of order to be used depends on the choice made between SAP and FLEXNET-shipping process (PULL or PUSH):

If FLEXNET-shipping process has been chosen for the flow: ZLU scheduling agreement

If SAP-shipping process has been chosen for the flow: LU scheduling agreement

In Spain:

FLEXNET shipping (ZLU) will be used for the flows to the service centers

SAP shipping (LU) will be used for the flows to the glass plants.

In France: FLEXNET shipping (ZLU) will be used for the flows from the plants to the service centers

In Germany: SAP shipping (LU) will be used for all the flows

NB3: if the shipping plant is in V2 and the receiving plant is in transitory period (is part of SAP V2 system but as not been yet deployed), a modified sales process will be used (LK scheduling agreement triggering WMMBXY Idoc with 993 goods movement).

Process flow

2.2.1 SAP shipping (PULL mode)

Hereunder is the SAP shipping process

Automatic / Demand Forecaster

Customer Requirements :

Sales order or Purchase order

Automatic / Demand Forecaster

Customer Requirements :

Sales order or Purchase order

Shipping Plant

Automatic

Material Requirement

Planning

Automatic

Material Requirement

Planning

MRP / Demand Forecaster

Scheduling Agreement

schedule lines creation /

modification

MRP / Demand Forecaster

Scheduling Agreement

schedule lines creation /

modification

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Demand Forecaster

Process delivery due list :

create delivery

Demand Forecaster

Process delivery due list :

create delivery

Shipment supervisor

Process SAP delivery

Shipment supervisor

Process SAP delivery

Receiving Plant

Receiving Operator

Process Goods Receipt

Receiving Operator

Process Goods Receipt

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

1

3

2

4

5

7

9

8

Physical

goods

transfer

6

Receiving plant

Shipping plant

SAP shipping

Step 1: represents the customer need. Requirements can be stored in a sales order for an external vendor, or in a purchase order for an internal customer (inter-company or intra-company).

Responsible: Requirements are keyed in either manually by the demand forecaster or automatically through EDI messages.

Step 2: MRP calculations

A job is planned to run every day. It compares the needs, the stocks and the outstanding purchases or planned orders to the requirements, to trigger if required a planned order or a purchase.

To determine whether the product is produced and / or purchased, master data are used (material, source-list, quota arrangement).

If the product is purchased through a scheduling agreement (document type LU, LPA):

MRP creates or changes automatically delivery schedules.

Responsible: automatic from MRP calculations

Remark: MRP results are analyzed and modified if needed by the demand forecasters.

Step 3: Purchase validation/ Transfer order validation

The product is purchased /required through scheduling agreements, delivery schedules can be checked and if required, changed manually.

Output :

( Printout: the delivery schedule can be printed and sent to the inter-company vendor (ME84)

( IDoc: Delivery schedules are not sent to the receiving plant FLEXNET system.

Transactions ME38 or ME39.

Apart from MRP result checks, it is possible to change quantities in schedule lines so as to create the requirement for a pre-determined value, for example quantities of a production campaign.

Purchasing documents created for the receiving plant are seen on the shipping plant as requirements. They contain the information of the market for which the product is required.

Responsible: demand forecaster

Step 4: Process the delivery due list to create the needed delivery orders, for the shipping plant.

Deliveries are created using transaction YVL04 for the past up to date required quantities. The delivery is created referring to only one purchasing document.

The delivery contains the information of the market of the required product, which should not be changed.

Output:

( Idoc: each time a delivery is created or modified, it is automatically sent to the WMS of the shipping plant

Responsible: demand forecaster

Step 5: Process shipment

The delivery is treated for picking, goods issue and labels printout.

If the shipping plant uses FLEXNET, the delivery is treated in FLEXNET, Cf. TBIN08 Process shipment. The market required in the delivery cannot be changed manually in FLEXNET.

A control is performed on the required market in the delivery and the picked products market.

Output: once treated in FLEXNET, an idoc is sent to SAP to close the delivery order and update SAP stocks. Idoc type DELVRY01 (message WHSCON).

If the shipping plant uses SAP, the delivery is treated in SAP: picking and good issue. (Transaction VL02).

Responsible: warehouse manager, deliveries manager

Step 6: Physical transfer of goods between the two sites.

Users can display the stocks in transit between the two companies with transactions MB53 or MB5T (or the specific report ZM83), in SAP.

The previous delivery goods issue

Decremented stock quantities on the shipping plant

Incremented stocks in transit on the receiving plant

For Inter-company flow, the stock is not valorized in any plant while in transit. For Intra-company flow, the stock is immediately valorized in the receiving plant after the post goods issue in the shipping plant..

Step 7: Goods receipt on the receiving plant, referring to the scheduling agreement.

The delivery note number should imperatively be filled in.

If the receiving plant uses FLEXNET, the goods receipt is declared in FLEXNET, Cf. TBIN02 Process Goods Receipt.

If both shipping and receiving plants work with FLEXNET, the goods receipt is eased by an ASN,

If one plant works with FLEXNET and the other with SAP, there will be no ASN. (This is also the case for plants in V2 not yet deployed -transitory phase-)

A consistency check is performed between the purchasing document, the supplier delivery note and the received products. (Market consistency is especially verified)

Output: an idoc is posted to SAP idoc type WMMBID01 (message WMMBXY) to update stocks.

If the receiving plant uses SAP, the goods receipt is declared directly in SAP using transaction ZB01,

Responsible: warehouse manager.

Step 8: Inter-company billing

The inter-company due list is processed (transaction VF04) to create the invoice, based on the delivered products / quantities.

Cf. TBSD21 Inter-company billing.

Responsible: inter-company vendor accounting department.

Step 9: Invoice verification

It is performed in reference to the purchase document but based on goods receipts transactions MRHR or MR1M, or MRRL if Executive Receipt Settlement can be used.

Responsible: inter-company customer accounting department.

FLEXNET shipping (PUSH mode)

Shipping Plant

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Automatic

Create delivery

Automatic

Create delivery

Shipment supervisor

Process CIM delivery

Shipment supervisor

Process CIM delivery

Receiving Plant

Receiving Operator

Process Goods Receipt

Receiving Operator

Process Goods Receipt

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

5

4

7

9

8

Physical

goods

transfer

6

Receiving plant

Shipping plant

FLEXNET shipping

The FLEXNET-shipping process is similar to the SAP-shipping process apart from the following difference:

The steps 1, 2 and 3 are not relevant anymore.

The steps 4 and 5 are inverted. The delivery is first created in FLEXNET according to the order that has been downloaded. It is then uploaded to SAP and thus automatically created. If needed, schedule lines might be automatically updated as well.

Step 4: Delivery creation and treating.

The delivery creation transaction will be done directly in FLEXNET with the reference of the scheduling agreement downloaded in FLEXNET (in the same time in the supplying and in the receiving plant) from SAP. This is the major difference with the previous flow.

Delivery treating: the required products are picked and sent from the shipping plant to the receiving plant. It posts a goods issue on the shipping plant.

Step 5: It posts an idoc type DELVRY01 (message type ZWHSCON) to SAP to create schedule lines, create the delivery order, post the picking and the goods issue and update stocks.

A posteriori shipping

Reconciliation responsible

Scheduling Agreement

schedule lines creation /

modification

Reconciliation responsible

Scheduling Agreement

schedule lines creation /

modification

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Accounting Department

Invoice verification

(ONLY INTER

-

CO)

Reconciliation responsible

Process delivery due list :

create delivery

Reconciliation responsible

Process delivery due list :

create delivery

Reconciliation responsible

Post SAP delivery

Reconciliation responsible

Post SAP delivery

Receiving Plant

Receiving Operator

Process Goods Receipt

Receiving Operator

Process Goods Receipt

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

Accounting Department

Process Inter

-

company Billing

due list : invoice creation

(ONLY INTER

-

CO)

3

4

5

7

9

8

Receiving plant

Shipping plant

A posteriori Shipping

Physical

goods

transfer

1

The a posteriori shipping process is used for flows from a site in V2 without any Sekurit IT system (type D) to another site V2. It has the following characteristics:

The physical goods transfer is done first

The schedule lines are added manually to the scheduling agreement according to the goods transfer done

The delivery is created a posteriori in SAP on these schedule lines

It is processed in SAP (picking + post goods issue)

As in the FLEXNET shipping process, the scheduling agreement used triggers no delivery download to any WMS.

( All these tasks are done by 1 reconciliation-responsible. In Spain DEVISA is responsible for the reconciliation of VIGO and VALDEMORO shipping

The reception is done as usual but the receiving operator may have to ask the reconciliation-responsible for the creation of the delivery if it has not yet been done.

For Inter-company, the invoicing process is done as usual.

3 Key elements of system implementation

It was decided to use standard SAP function: purchase document and SD functionality for delivery.

This will be applied to logistics materials, type FER1 (and possibly ZPRO for prototypes).

3.1 Master data

3.1.1 Material

Material should be created in the Sales Organization concerned, on Distribution Channel GR

Material description should also be maintained in the vendor language

On the receiving plant, MRP2 view,

Set the Procurement type to F for External procurement or E (not X) if the product is possibly produced and supplied at the same time. This is necessary for the MRP, to create a purchase requisition or a schedule line

If the Procurement type is set to F, anf for a flow inside a country (whatever intra or intercompany), set the Special Procurement type 40.

Set the Quota Arrangement to 3 so that the quota arrangement is taken into account for MRP.

3.1.2 Vendor

Check in the Communication data that the language key is the good one

The shipping plant is defined as a plant in the system, but also as a vendor Account group GRP-. The account number plant should be assigned to the plant in the Purchasing data view of the vendor, Extras ( Add. purchasing data (excepted for prototype orders, where its necessary to use the vendor not linked to the plant)

Reconciliation account : rules defined in TBFI16

3.1.3 Info-record

For inter-company: it is created in the standard info-record category.

For intra-company, as the shipping and the receiving plant belong to the same company, the flow will consist in a stock transfer, there is no purchasing. So, there is no info-record to manage.

3.1.4 Customer

A customer must be created for the receiving plant Account group GRP in the sales area of the shipping plant, in the distribution channel GR.

3.1.5 Source-list

The validity period should be correct, not to block MRP calculations,

For inter-company, filling in the vendor number enables to get the Plant from which material is procured automatically. For Intra-company, the vendor number would not be filled in but the Plant from which material is procured should be set with the shipping plant reference,

If working with a scheduling agreement, fill in the agreement and agreement item numbers,

Flag the Fix source of supply indicator so that the MRP can trigger the purchase automatically,

Fill the MRP column with 1 if working with purchase requisitions and purchase orders, with 2 if working with a scheduling agreement.

Remark: The source lists are not fixed with 2 in all cases, there is some exceptions, according the logistics situation (exemple: no source list for the flows between Stolberg and Wurselen in Germany)

3.1.6 Quota arrangement

The validity period should be correct, not to block MRP calculations,

If the product is possibly produced and supplied at the same time or it is purchased to 2 vendors at the same time, quota arrangement items should be maintained.

Rem: quota arrangement can only be maintained once the source-list has been maintained.

Customizing

Customizing is performed to:

Assign to each plant its customer number

Assign the delivery type, per plant, depending on the purchasing document type (it also concerns intra-company flows)

Define all the possible flows, supplying plant / receiving plant / purchasing document type combination.

Decision was taken to customize:

All possible intra-company flows in the system

All existing inter-company flows before implementation. (New inter-company flows after go-live will be customized and tested by the CDC when required.)

Each flow depends on the scheduling agreement used. Several scheduling agreement are therefore customized.

The scheduling agreement is created in SAP using transaction ME31L / ME37 (for intracompany). For one shipping plant and one receiving plant, there can be one scheduling agreement with all the products concerned or many scheduling agreements (one by market for example)

When creating or updating the scheduling agreement, a message type ZNEU is triggered for printout, and an other message type XNRC so that items are sent to the receiving plant FLEXNET system via an idoc type BLAORD02 (message type ZBLAORD_).

To make the message types be triggered, master data should be maintained by the CDC with menu path:

Logistics ( Materials Management ( Purchasing

Master data ( Messages ( Purchase order OR Outline Agreement

Access sequence:Condition: Doc type + Purchasing group

Condition: Doc type + Purchasing Organization

Condition: Doc type

3.1.7 Intra-company SAP shipping

Customizing of LU as default SA type for the flow

Manual creation of a LU scheduling agreement

Schedule lines filled in by the MRP and modified manually

Manual creation in SAP of a ZZNL delivery

Automatic ZORD output generation at each delivery change or delete

ZORD output converted into WHSORD Idoc sent to FLEXNET of shipping plant

3.1.8 Inter-company SAP shipping

Customizing of LPA as default SA type for the flow

Manual creation of a LPA scheduling agreement

Schedule lines filled in by the MRP and modified manually

Manual creation in SAP of a NLCC delivery

Automatic ZORD output generation at each delivery change or delete

ZORD output converted into WHSORD Idoc sent to FLEXNET of shipping plant

3.1.9 Intra-company FLEXNET shipping / Shipping a posteriori

Customizing of ZLU as default SA type for the flow

Manual creation of a ZLU scheduling agreement

Automatic creation/ modification of schedule lines at ZWHSCON Idoc integration

Automatic creation & post goods issue of ZNL delivery at ZWHSCON Idoc integration

Manual creation/ modification of schedule lines

Manual creation in SAP of a ZNL delivery

No ZORD output generated at delivery change or delete

3.1.10 Inter-company FLEXNET shipping / Shipping a posteriori

Customizing of ZLP as default SA type for the flow

Manual creation of a ZLP scheduling agreement

Automatic creation/ modification of schedule lines at ZWHSCON Idoc integration

Automatic creation & post goods issue of ZNLC delivery at ZWHSCON Idoc integration

Manual creation/ modification of schedule lines

Manual creation in SAP of a ZNLC delivery

No ZORD output generated at delivery change or delete

3.1.11 Intra-company Prototype

Customizing of ZUB as default PO type for the flow

Manual creation of a ZUB purchase order

Manual creation/ modification of schedule lines

Manual creation in SAP of a ZZPI delivery

Automatic ZORD output generation at each delivery change or delete

ZORD output converted into WHSORD Idoc sent to FLEXNET of shipping plant

3.2 Summary

IMMM007-Stock transport order (intra & inter company)

IMMM008-Partner determination

IMMM016-Stock transport scheduling agreement

IMMM025-Message types

IMMM026-Layout sets per message type

IMMM027-Message determination schemas

IMMM028-Partner roles per message type

4 Organizational roles and impacts

( Master data management

As detailed in pre-requisites, master data are very important for inter-company flows in the system. Master data maintenance procedures should be synchronized with flows data management procedures.

Master data management procedure scope is :

Material types FER1, ZPRO, HLB1

BOMs and routings,

Purchasing master data : info-records, source-lists, quota arrangements

Customer-material informations

Flows data management also require :

Vendors,

Customers,

Sales scheduling agreement for external customer requirements integration through EDI,

Purchasing scheduling agreement if chosen.

( For flows between glass plants, encapsulation / extrusion plants, service centers, the tasks distribution should be previewed:

Who is responsible for purchasing documents creations or changes ?

Who is responsible fore deliveries creation in SAP ?

Demand forecasters should be responsible for these tasks but this function might be centralized in glass plants or de-centralized. It depends on each country organization :

In France, purchasing documents creations and changes and deliveries creation are centralized in Chantereines glass plant,

In Germany, purchasing documents creations and changes are centralized in Aachen but deliveries are created by each plant,

In Spain, purchasing documents are centrally reviewed in Madrid but deliveries are created by each plant.

5 Application specific development requirements

Necessary AIG: message to be triggered when modifying a purchasing document, for a deleted / blocked / finally delivered items.

A development July 2001 (Specifications under S:\Core Solution\Service Center DCS\30_Integration\SAP DCS interface\Customizing\INSC002) was performed in order to fill in, in case of intra-company orders, the idoc field with the corresponding vendor account number.

In the procedure with the creation of the delivery in the service center the creation of a function module in SAP is necessary in order to create automatically the delivery in SAP and to adjust the stock in the supplying plant.

6 Key volume & performance indicators

7 Added value for the Business and economical considerations

11/2222/08/05 - 16:08