SAP for Automotive

-
  • JIT Processing
  • SAP for Automotive: Business processes 
  • Outbound Scheduling Agreement Processing
    • Automatic Supply-to-Production 
  • ERS (  pay-on-receipt )
  • Delivery confirmation processing 
  • Multi-Level Goods Receipt
    • Proof of Delivery at Goods Receipt for Inbound Deliveries
    • Profiles in Goods Receipt for Automotive
    • Automatic Determination of Purchasing Document
    • Determination of the Unloading Point and the Unloading Zone
  • Planning, Tracking, and Executing Inbound Deliveries
    • Regular Route
    • Tracking: Monitoring of Inbound Shipments & Monitoring Inbound Deliveries
  • Self-Billing
    • Processing External Service Providers
    • Cross-System Transit between Two Plants
  • Extensions
    • Scheduling Agreement (SD-SA)
    • Extension of the Inbound Interface for Deliveries and Shipments
  • Parts Interchangeabilities
    • Supersession
    • Inventory-Managed Manufacturer Part Number
    • Material exchange
  • Supplier extension
    • Kanban: Enhancements for Automotive
    • Tolerance Check
    • Supplementary Fields in the Scheduling Agreement
    • Outbound Delivery Group
    • Stop Flag
  • References
    • 591388 - JIT: JIT and HUM processes

#1 Just-in-Time and Just-in-Sequence Processing with SAP

Just in time is the management approach, where the main concern is, if the production schedule is set, it is possible to organize the movement of material flows in such a way that all materials, components, and semi-finished products will arrive in the right quantity, in the right place and exactly by the appointed time for production, assembly or sale of finished products. At the same time, safety stocks freezing the company's cash are not needed. 

What is JIT (Just-in-Time)? The delivery of the material in the right quantity, at the right time, to the right place in production is defined as a just-in-time (JIT) delivery.

What is JIS (Just-in-Sequence)? JIS delivery is an extension of the JIT process. The material is also delivered to the customer in the correct order.  + JIS call production number and therefore always has a vehicle reference.  The production number is stored in the KANNR  (Seq. no) field (table LIPS), when a delivery document item has been created with the reference to the SD document item.

  • JIT inbound receives a call for and processes it
  • JIT outbound generates JIT calls from a JIT inbound process . The combination of JIT inbound and JIT outbound is only possible for production-synchronous releases.

Outbound Scheduling Agreement Processing

Automatic Supply-to-Production 

ERS (  pay-on-receipt )

ERS is a process that eliminates the supplier by sending an invoice to the customer.

Delivery confirmation processing 

Receive delivery confirmations per EDI, in which a JIT customer confirms the call components delivered. The system automatically creates a billing document on the basis of the delivery confirmation.

Prerequisites

  • Set up the EDI Interface for the IDoc GSVERF02 ( VDA4913 and ANSI 861 )
  • To be able to receive the delivery confirmation, either manual or automatic matching must be set in Customizing for the delivery creation profile. JIT scheduling agreements with the sales document type LZJQ
The system carries out this function ( billing generation ) automatically when you receive a delivery confirmation from your JIT customer on the basis of the quantity confirmed in the delivery confirmation without carrying out a logistics match without the quantities in your system beforehand.

It copies the number of the delivery confirmation, the call components and their quantities as well as the sales area to the billing document.

If an error occurs when creating the billing document, the system terminates the operation and creates an express mail that contains the status records of the IDoc. The person responsible can determine why the error has occurred, using this mail.

You cannot cancel the delivery confirmation and thus you cannot create the billing document.

If you do not want to check the delivery confirmations your JIT customer sends to you, you do not have to use the logistic quantity match. This then ensures better system performance.
  • MTCH Delivery confirmation: set to Matched (only status change)
  • UDMT Reset delivery confirmation match (only status change)
You have set whether and how you want to carry out the match in the control profile for the delivery in Customizing for JIT Inbound. You have assigned the control profile to the corresponding JIT customer in the JIT basic data.

The JIT customer transmits the call components and their confirmed delivery quantities in a delivery confirmation. In addition, at header or item level, the customer transmits the external call numbers of the JIT calls in which the call components were assembled. However, the customer does not transmit any information on which quantity is assembled in which call. Therefore, in the match, the system calculates the quantities of all transmitted external call numbers and then matches the components groups with the quantities of the delivery confirmation. The system displays the differences under the materials that cannot be used for the match. As the JIT customer does not transmit the necessary information the system does not know in which JIT calls the differences occur.

If differences occur, you can set the delivery confirmation manually to status Matched , to conclude the delivery confirmation. You can also reset the match (status change) and carry it out again later.

SAP Easy Access screen, choose Logistics Logistics Execution JIT Inbound Control Data Matching Delivery Confirmations.

Process

  1. Customer sends the JIT call;
  2. The supplier delivers component groups;
  3. The JIT customer sends a delivery confirmation in regular intervals ( content:  the call components and their aggregated quantity, external call numbers of the JIT calls ).
    • when executing action OGRE Post Goods Receipt for JIT Outbound, the system automatically creates a delivery confirmation
  4. The system  creates the billing document on the basis of the delivery confirmation.
    • Logistic quantity match ( quantities confirmed in the delivery confirmation <>quantities of the JIT calls ). 
    • If differences occur, process them manually. 

DELCON processing 

IDOC_INPUT_DELCON

1. It creates a billing document for all the items in the transmitted message.
2. It matches the production numbers from the header or items in the message with the data that already exists in the receiving system from specific applications, such as SeqJC data.

BADI: JIT_DELCON

    CALL METHOD delcon_badi->mapping
      EXPORTING
        idoc_data_it            = idoc_data_lt
        docnum_iv               = idoc_contrl-docnum
      CHANGING
        delcondia_header_cs     = delcondia_ls
        delcondia_ct            = delcondia_lt
        jit_matnr_prodn_ct      = jit_matnr_prodn_lt

*--> check material: - finding own material from customer material or
*                    - finding customer material from own material
*                    - finding delivery scheduling agreement
*                    - finding sales area data from scheduling agreement
*                      (Sales Org., Distribtn Channel, Product Divis.)

* This method can be used to trigger follow-on actions

CALL METHOD delcon_badi->action

Multi-Level Goods Receipt

Proof of Delivery at Goods Receipt for Inbound Deliveries

Goods receipt in the automotive industry can be split into two main processes:
  • Goods receipt for parts that are procured just-in-time is posted when the parts are built into a vehicle.
  • Goods receipt for all other parts is usually a multi-level process.
    • The first step for goods receipt involves registering trucks at the goods receipt office and comparing the shipping documents with the data received by EDI. 
    • Goods receipt is posted when the quantity and content of the packages has been compared with the unloading list at the unloading point.

Profiles in Goods Receipt for Automotive

In goods receipt for Automotive, use profiles to adjust the dialog to the roles of the individual user groups. The typical roles in goods receipt for Automotive are 
  • V: preliminary entry (technical name: SAP_ISA_MM_GR_PRE_ENTRY), 
    • The goods receipt office compares the system data relevant for posting goods receipt with the delivery papers that accompany the inbound delivery. 
      1. Compare the data received by EDI for the inbound deliveries with the delivery papers.
      2. Assign the inbound deliveries to the correct inbound shipments.
        • The shipment type is relevant for the multi-level goods receipt process, which you define in the GR-RelevanceInd field in Customizing for Logistics Execution
      3. Enter any missing data and correct the data transmitted by EDI.
      4. Register the inbound delivery. 
        • The system assigns the In plant status to the inbound deliveries that you register.
        • This status shows that the material has arrived at the goods receipt office and is available in principle. 
        • The unloading list is printed automatically
      5. The shipment status is automatically set to Registered when all the inbound deliveries assigned to the shipment are In plant.
  • B: posting (technical name: SAP_ISA_MM_GR_GOODS_RECEIPT) and 
    • When you want all HUs at an unloading point (or material staging area) to be visually inspected, you should check the HU Ind box (for HU visual inspection indicator) for the material staging area in Customizing for Logistics Execution
      • It is not possible to post partial goods receipt for materials with serial numbers.
  • C: clearing (technical name: SAP_ISA_MM_GR_CLEARING).
    • You can use the clearing function to process all objects which could not be processed in preliminary posting or posting.
Automatic Determination of Purchasing Document
  • The purchasing document number and the item are transferred to the inbound delivery item when  when the data is in an IDoc.
  • The system checks in the IDoc for a reference to summarized JIT call items.
  • The system uses the source list records, the outline agreements (contracts or scheduling agreements), purchasing documents for a material to determine the preferred purchasing document at a particular time. The vendor must be known.
Determination of the Unloading Point and the Unloading Zone
  1. The unloading point is determined by using the control cycle when the inbound delivery items refer to a summarized JIT call.
  2. The data from the referenced scheduling agreement is used when none of the inbound delivery items refers to a summarized JIT call or the unloading point cannot be determined from the summarized JIT call.
  3. The field remains blank when the system cannot determine the unloading point.

Planning, Tracking and Executing Inbound Deliveries

Regular Route

Prerequisites
  • Define the goods receiving point at the OEM, which serves as the last point of the route.
  • Define a receiving zone (or departure zone) for your receiving point.
  • Assign your receiving point to a plant and storage location.Assign the shipping point, or receiving point, to a plant.
  • Create the transportation connection points for your route individually for a supplier.
  • Define your route, that is, all the suppliers and the goods receiving point
  • Define the route determination in the shipping notification (or delivery) ~ Define Allowed Actual Route By Proposed Route
  • Create a transportation planning point
  • Create a Route schedule
Process flow
  • You create an initial shipment for a pending inbound delivery from the schedule.
    • With the help of a periodical report, the system selects all relevant schedules for a certain delivery date and generates shipments for them, the headers of which contain the schedule.
  • The supplier sends an EDI shipping notification announcing the inbound delivery.
    • The supplier has defined Message code AR1 for message category DESADV in the EDI Partner Profiles: Outbound Parameters.
  • The system searches for the appropriate schedule (route schedule determination).
  • The system updates the schedule and route which it determined in the header of the inbound delivery.
  • The system assigns the inbound delivery to the shipment when the route schedule for the shipment is identical to the route schedule in the inbound delivery.
  • Post goods receipt for the shipment as soon as you receive the goods from the supplier.

Tracking: Monitoring of Inbound Shipments & Monitoring Inbound Deliveries

With EDI, tracking information can be processed automatically. The logical message TRXSTA with the accompanying IDoc type TRXSTA01 is used for this.
We can use the confirmation control key to specify whether a new arrival date for individual inbound deliveries is to be determined based on the dates received.

Self-Billing

The SD self-billing procedure allows the customer to send self-billing documents to the vendor, stating the deliveries and amounts that are settled and paid. Process Flow
  1. The vendor creates a delivery with reference to the SD scheduling agreement/order in his system.
  2. The vendor posts goods issue of the delivery.
  3. The vendor creates an initial billing document, which he does not send to the customer.
  4. The customer receives the materials and creates a goods receipt with reference to the delivery note number in the MM module.
  5. The customer creates a self-billing document for the goods received, using the MM ERS functions. 
  6. The customer transmits the self-billing document to the vendor "per EDI".
  7. The document must include a number that the system can use to directly or indirectly determine an SD document number.
  8. The vendor system reads and checks the transmission, which can contain several IDocs and therefore several deliveries.
  9. The vendor initiates the processing of the transmission, in which the open value from the internal invoice is compared with the value in the self-billing document.
    • If the values match, an external reference number is updated in the billing (FI) document.
    • If the values do not match, the system automatically posts all differences, debit or credit, depending on the +/- sign. It assigns a reference number to all documents that are assigned to the delivery. The reference number is used later to post receipt of payment. 
      • If we have set a tolerance check, the system creates no open items unless the tolerance levels are exceeded. 
      • If the tolerance levels are exceeded, the system creates new open items. 
Consider EDI Settings for the SD Self-Billing Procedure: Logical message SBWAP.

Processing External Service Providers

Cross-System Transit between Two Plants

Use this process to map material stock transfers between two plants that use different SAP systems. The process uses Valuated stock functionality (STO) which is changed with a new message type GOODSMVT_SAPCREATE.

Process flow
  • Strightforward
    • Sender: recieve DELINS message ( a release from the scheduling agreement ) and create a DESADV message based on an outbound delivery, after GI send a new message GOODSMVT_SAPCREATE
    • Reciever: The receiving system increases the recipient’s transit stock after
    • Reciever: With the goods receipt posting from the receiving plant, the system books the goods quantity out of the transit stock.
  • Corrections
    • Goods Issue Cancellation
      • Cancel it with VL09 (  movement type 6A2 )
      • Sending system creates a GOODSMVT_SAPCREATE ( movement type 6B2)
    • Posting a Return Delivery in the Receiving System
      • Create a returns order 
      • Create a returns delivery 
      • Sending system creates a GOODSMVT_SAPCREATE
  • Check Report for Scheduling Agreements and Sales Orders (Sender)
Prerequisites 
  • Use SD and MM scheduling agreements or sales orders and purchase orders on sender and receiver side.
  • Each sales order or SD scheduling agreement on sender side corresponds to exactly one purchase order or MM scheduling agreement on receiver side.
  • Maintain settings
    • New customizing to map SD and MM document's settings
    • Settings for Application Link Enabling (ALE) in the sending and receiving systems.
      • Creating Customers and Goods Recipients (Sending System)
        • Assign Customer Number to an External Plant
      • Creating Vendors (Receiving System)
        • Assign the plant that the vendor represents under Additional Purchasing Data
    • Maintaining Message Determination
      • PO NEU,  MM-SA LPH1.
    • Setting Up Stock Transport Orders and Stock Transport Scheduling Agreements (Receiving System)

Extensions

Scheduling Agreement (SD-SA)

#1 New sales document types
  • LZ:Scheduling agreement with delivery schedules
  • LK: ESA scheduling agreements
  • LZM: Scheduling agreement with delivery orders
  • LZJQ / LZJ: JIT scheduling agreement with self-billing / invoice
#2 Relevance of schedules for delivery and MRP
Очень важно учитывать JDS горизонт и тип для MRP планирования.
New delivery schedule replaces current schedule (FDS/FDSand JDS/JDS)
  1. MRP indicator 'E': is used if the goods recipient works without JIT delivery schedules. The FDS is then relevant for both MRP and delivery. 
  2. MRP indicator 'C': FDS for MRP and JIT for delivery.
  3. MRP indicator 'B': FDS is relevant for MRP and delivery; JIT is relevant for MRP inside and for delivery outside the horizon.
#3 Cumulative quantity
To monitor sales/procurement operations.
Cumulative quantities generally reset at the end of a fiscal year.
Reconciliation process targets to clean differences between you and vendor using the date and quantity.
  • Cumulative release quantity (CRelQ) is transmitted by the customer in the delivery schedule.
  • Cumulative received quantity (CRecQ): Delivered quantity received in the customer fiscal year.
  • Cumulative scheduled quantity (CSQ): received + open.
  • Cumulative delivered quantity (CDQ): Updated when delivery is posted.
Material/Production/Delivery Go ahead ( Current and Maximum Qty. )

#3.1 Correction delivery note
Correction of cumulative delivered qty at any point of time if the differences with the customer arise. It is created in SD-SA document.

#3.2 Automatic year 
Cumulative quantities are usually reset to zero at the end of the fiscal year. A fiscal year might be not  the calendar year and can be managed specifically for a customer. The fiscal year ends automatically on dispatching per

#4 Sales agreement determination 
  • From the IDoc
  • Determination of sold-to party for EDI FDS/JDS in accordance with Customizing

Extension of the Inbound Interface for Deliveries and Shipments

Create a shipment using the shipment message SPHADV . The assignment of the shipment to existing inbound deliveries uses the supplier and the supplier’s delivery number. Use this process for grouped load transport.
Shipment message SHPADV contains all data from shipping notification DESADV. In this way, you can create several inbound deliveries and the appropriate shipment in one operation. Use this process for direct transports and when freight forwarders create shipping notifications.
The system periodically creates shipments from the master data for transportation processing by using regular routes. The system determines the regular route when a DESADV shipping notification arrives and the value in the Qualifier field in segment E1EDL18 is INC . When the regular route is determined, the system can determine the appropriate shipment and assign the shipping notification to that shipment. 
Shipment message SHPADV allows you to change a shipment. The system determines the shipment using the supplier number and the freight forwarder's shipment number.  

Parts Interchangeabilities

Replace parts with other parts, because the manufacturer has carried out a part exchange.

Supersession

Changes to the design, form and function of parts require vendors and manufacturers to replace obsolete parts with new versions of the same parts. 
If a new version of a part can replace the old version, the system issues a new part number. The new number requires changes to be made in stock, in procurement, in production, in material requirements planning and in sales; that means in all core processes in the supply chain. We must also determine replacement rules and validity dates for the new part.

Inventory-Managed Manufacturer Part Number

Inventory-managed manufacturer parts are materials that can be found, identified and mapped by the system using the combination of a manufacturer part number (MPN) and external manufacturer .
Some parts from different manufacturers are interchangeable in the purchasing, MRP and availability check functions due to having the same technical characteristics. The system recognizes these as interchangeable and manages them with their own individual stocks .

Material exchange

  • Purchasing: The system supports you in changing and allocating the relevant order items so that the follow-on steps refer to the part that was actually delivered.
  • Inventory Management: We can use transaction MIGO to carry out material exchange for goods issues and receipts.
  • Sales Order Product Selection: if a part is not available, you can use the sales order product selection to exchange the interchangeable materials.
  • PM Orders, PP Orders, and Networks: If a component is not available, the system proposes interchangeable materials.
  • Replenishment Deliveries
  • Stock transport orders

Supplier extension

Kanban: Enhancements for Automotive

A control cycle defines the relationship between the demand source (such as a production line in production) and the supply source (such as an external supplier or warehouse).

Tolerance Check

The delivery schedules that are provided by EDI are normally posted automatically as a forecast delivery schedule or JIT delivery schedule.  The new schedule lines can differ from the last delivery schedule posted.
The schedule lines are compared using a tolerance profile. The tolerance check starts with the date plus one day. If a backlog is found, it is added to the IDoc as status information.

Supplementary Fields in the Scheduling Agreement

  • The forecast delivery schedule header (  Sales and Distribution    Sales    Create /Change / Display Scheduling Agreement  ; Forecast Delivery Schedule ; Header ) contains the Additional data tab which permits us to store this supplementary customer information.
  • These fields are defined by segments E1EDK09-USR0X (1-5) and must be filled appropriately in the EDI subsystem.
  • In incoming JIT and forecast delivery schedules, certain field changes are not automatically copied to the corresponding scheduling agreement. For certain fields such as the unloading point or purchase order number we can set automatic updating in Customizing.

Outbound Delivery Group

We use outbound deliveries to group together several deliveries that we are going to deliver to the within the same shipment. An outbound delivery group consists or one or more items, which represent outbound deliveries.
We can change outbound delivery groups by moving individual outbound deliveries to other outbound delivery groups.
The system transfers outbound delivery groups in the following IDocs: DELVRY03,SHPMNT05.

Stop Flag

When delivery schedules are passed by EDI, there are various reasons why a delivery schedule should not be imported automatically. The flag is set in the SD-SA document. Then messages can be seen in the monitor.

References

591388 - JIT: JIT and HUM processes

Note 1: A JIT call is either a sequenced JIT call or a summarized JIT call.
Note 2: Consider the Customizing of the JIT concerning the control of internal releases, the delivery or the SumJC in all cases. These contain fields which are relevant for the generation of an HU. Detailed help exists at for these. Assign the profiles to the respective JIT customers.
Note 3: You always check as to whether there are any alternative process modelings. If, for example, you only need a packing label, then you could also use the grouping information. You do not need to pack discreet materials before a stock transfer.
Note 4: In addition to the options listed here, which were developed specifically for the JIT, there are also other functions which can be used in a scenario with JIT. Generally, for example, there is the option to add an HU to a delivery.


I would like to transfer a components group into, for example, the Warehouse Management, and I have to group the materials of the release together. How does that work?
This function exists since Release 4.6B. Create an HU. You can then place or remove this HU from storage in the Warehouse Management. CRHU or DEHU is provided for the purpose of generating a HU. Note that an HU that is generated by CRHU cannot be delivered. You find a description of the function in the Knowledge Warehouse.
Can I pack a JIT call right away during the delivery creation?
This function exists since Release 4.6B. Maintain either a packing proposal or a packing instruction. As an alternative, you can also use a user exit. If you are dealing with a sequenced delivery schedule, you use DELI to create the delivery. If you are dealing with summarized JIT call, you use Transaction JITK. The HU is, in this case, automatically generated.
Can an HU be created for a scheduling agreement first and then assigned to summarized JIT call after that?
This function exists since Release 4.6C2. You make the assignment using Transaction VL10HU. For this, maintain a suitable user role so that you can display the summarized JIT call.
Can an HU be created for a JIT call before the delivery, yet then also be delivered?
This function exists since Release 4.6C2. Use HUPP for this. An HU that is generated as such can be deleted using DEHU. Consider the prerequisites for the HU management. You particularly need an HU required storage location which is assigned to a non-HU required storage location. Make a corresponding packing instruction available. Also maintain corresponding material masters for the HUs in the respective storage locations.

Comments

Post a Comment