EDI Interfaces: IDoc messages [REV]

-
  • Invoicing
    • IDOC_INPUT_GSVERF
    • IDOC_INPUT_SBINV
  • Delivery/shipment processing
    • Message types 
      • Shipping notification
      • Informing the forwarding agent
      • Shipping order 
      • Warehouse order
      • Proof of delivery
    • Basic types
      • Structure of GSVERF02 (IS-A, delivery confirmation)
      • Structure of basic type DELVRY07
  • Additional information 
    • 1594584 - Actual goods issue date field in IDOC
       

Invoicing

IDOC_INPUT_GSVERF Incoming EDI: Standard Self-Billing Procedure

In the standard self-billing procedure, the customer prices deliveries from you based on:
  • Prices from the customer's Purchasing department
  • Differences between the delivery note and goods receipt
  • Differences due to the quality of the material, for example
  • Retroactive price adjustments
The customer uses these prices to prepare credit advice that they send to you. The system converts this advice into an intermediate document (IDoc) GSVERF.

The system then determines the corresponding internal delivery, and from it the internal invoice, based on:
  • The internal delivery number sent in the credit advice (table LIKP)
  • The internal delivery number determined from external agent deliveries (consignment issues) using the customer purchase order number
  • The external delivery number sent in the credit advice
The system compares the following condition values for each item:
  • Net value
  • Cash discount
  • Surcharges/Discounts
  • Value-added tax (VAT)
If the values in the credit advice match the values in your invoice, the system assigns the credit advice number as a reference to the open items in the journal entry.

If the system finds any differences in the values, it terminates processing of the IDoc and sends a mail to the employee responsible. The employee can then correct the problem manually, or inform the customer to send one of the following correction or retro-billing documents:
  • Credit memo requests for quantity corrections
  • Credit and debit memo requests for retroactive billing

Credit or debit memo requests based on return deliveries are treated just as credit memo requests for quantity corrections, except that the system carries out pricing only for those materials that are returned. Also, instead of comparing each condition value, the system determines an overall difference per item and compares it to the overall correction value.

In the case of retro-billing, the system reprices all documents in the transaction before comparing the condition values of the items. It calculates the difference between the old and new prices in the delivery, invoice, and existing credit or debit memos, and compares it to the difference calculated by the customer in the credit or debit memo request. The difference calculated by the customer is copied to condition type EDI2, and the one that you calculate to condition type PDIF. If these values match, the system automatically creates a credit or debit memo request, then a credit or debit memo.

If these values do not match, the system sends a mail to the employee responsible but creates the document anyway. If you do not want this, make the appropriate settings in Customizing for the sales document type.

The customer sends a payment advice note based on their credit advice. The credit advice number that they include with the payment advice note indicates whether there are several deliveries per credit advice number or only one:
  • The customer sends payment for a number of deliveries. These deliveries are covered by one credit advice, the number of which is sent with the payment.
  • The customer sends payment for a number of deliveries. There is, however, only one delivery per credit advice. In this case, the customer groups the advice numbers and assigns a collective number, such as the EDI sequential number or vendor posting number. Payment, then, is for the total of the credit advices represented by this collective number. To compare open items, you must refer to the individual credit advice numbers.
When converting external documents, note that you must create an IDoc for each delivery (for example, VDA4908: an IDoc must be created for each record type 823).

IDOC_INPUT_SBINV

In the self-billing procedure with invoice creation, the customer prices deliveries from you based on:
  • Prices from the customer's Purchasing department
  • Differences between the delivery note and goods receipt
  • Differences due to the quality of the material, for example
  • Retroactive price adjustments
The customer uses these prices to prepare an invoice on your behalf that they send to you by Electronic Data Interchange (EDI). The system receives and converts this invoice into intermediate document (IDoc) GSVERF. It then forwards it to this function module, which determines the reference delivery and items based on the internal delivery number, or external delivery number, sent in the external invoice.

In this procedure, you cannot create an invoice for the delivery: no original invoice exists. However, the system simulates invoice creation to determine internal prices and their conditions.

Once the system has determined the reference delivery and simulated an invoice, it compares condition values in these documents to those in the external invoice, in IDoc form. The system compares only those conditions specified in the IDoc and entered in Customizing.

If the values in the external invoice match the values in the simulated invoice, and the delivery, the system creates an invoice in the R/3 System exactly as the customer has prepared it. Note that the system does not use the standard billing transaction here, but rather a special billing interface (GN_INVOICE_CREATE).

If the system finds any differences in the values, it updates the IDoc status records, and sends a mail to the employee responsible. It creates the document anyway.

Self-Billing Document Types

The customer can send in the following documents for the self-billing procedure with invoice creation:
  • Invoice: The customer must submit invoices with reference to one or more internal or external deliveries. Several invoices can be sent for one delivery item. The system will continue to create invoices as the customer sends them until the delivery has been fully billed.
  • Credit memos for quantity corrections: The customer sends in a credit memo when they have billed a larger quantity of material in the invoice than what was actually delivered. The customer must submit credit memos of this type with reference to the invoice.
  • Credit and debit memos for retroactive billing: The customer sends in a credit or debit memo to balance out retroactive price adjustments. The customer must submit credit and debit memos of this type with reference to one or more invoices. In the case of credit memos, the system calculates the difference between the old and new prices in the invoice and delivery, and enters it into condition PDIF to use in the pricing procedure.
  • Cancellation documents: The customer sends in a cancellation document to cancel existing invoices, credit memos, or debit memos. The customer must submit documents of this type with reference to the document they wish to cancel. When the invoice needs to be adjusted, the employee informs the customer to send one of the above correction or retro-billing documents: The system determines the invoices for these documents, along with the related deliveries, credit and debit memos, and cancellation documents.

Credit or debit memo requests based on return deliveries, are treated just as credit memo requests for quantity corrections, except that the system carries out pricing only for those materials that are returned. Also, instead of comparing each condition value, the system determines an overall difference per item and compares it to the overall correction value.

In the case of retro-billing, the system reprices all documents in the transaction before comparing the condition values of the items. It calculates the difference between the old and new prices in the invoice and delivery, and enters it into condition PDIF to use in the pricing procedure. The difference calculated by the customer in the credit or debit memo is entered in the internal condition that you have assigned in Customizing. If these values match, the system automatically creates the credit or debit memo.

...
  • You have not made the appropriate Customizing settings for self-billing, or the necessary general Customizing settings.
  • There are different values for the internal and external conditions that you have assigned in Customizing (V4 177).
  • There are different value-added tax indicators (V4 180).
  • The order referred to in the external invoice is different from the order determined by the system from the delivery.
  • There are different sales units (V4 174).
  • The customer did not specify a material (V4 173).
  • There are different sales organizations (V4 165).
  • There are different currencies (V4 185).
  • The invoice referred to in the correction document does not exist or has been cancelled (V4 181).
  • The simulated invoice has no value (V4 191).
  • The external invoice contains items that the system normally would not copy to a billing document in the R/3 System (V4 198).
  • The external invoice requires an invoice split.
  • General errors in billing document creation have occurred.


Delivery/shipment processing

This Delivery interface groups together all messages that have a reference to the delivery.

Message types 

  • Shipping notification
    • Outbound EDI: Sending a shipping notification (DESADV)
      • EDIFACT:  DESADV
    • Inbound EDI: Shipping confirmation from service agent (SHPCON)
      • EDIFACT:  RECADV
  • Informing the forwarding agent (CARNOT, )
    • Outbound EDI: With the notification of the forwarding agent, the delivery data is transferred so that the forwarding agent carries out the pickup and inbound delivery of the goods according to the customer's request
  • Shipping order ( the shipping order and the shipping confirmation serve to communicate with a warehousing contractor/service agent) 
    • Outbound EDI: Shipping order to warehousing contractor (SHPORD)
      • EDIFACT: INSDES (Instruction to Despatch)
    • Shipping confirmation from service agent (SHPCON)

    • Functions: SHPORD/ SHPCON is functionally identical to WHSORD/ WHSCON.
  • Warehouse order ( the warehouse order and the warehouse verification both serve to connect a company's own external system with Warehouse Management)
    • Outbound ALE: Warehouse order to internal warehouse (WHSORD, )
    • Inbound ALE: Warehouse verification from internal warehouse (WHSCON)
    • Functions: 
      • Picking verification without flow records ( Non-picked, The picked quantities are reported by the subsystem to the central system )
        • E1EDL24-POSNR, E1EDL24-LFIMG, E1EDL19-QUALF = 'QUA'
      • Picking verification with flow records ( the picked quantities can be reported to the central system, only the complete, picked quantity of an item can be taken )
        • E1EDL20-VBELN, E1EDL18-QUALF = 'PIC'
      • Change delivery 
        • E1EDL20-VBELN, E1EDL18-QUALF = 'CHG'
      • Verification of batch split items from the subsystem ( If batch split items occur in the central system, the original item must not be reported. Instead, the new items are transferred as follows)
        • E1EDL20-VBELN, E1EDL24-POSNR = Item number of batch split item (90000*), E1EDL24-HIPOS = Item number of main item, E1EDL19-QUALF = 'BAS'
          • Different batches are confirmed or
          • The subsegment does not confirm the complete quantity
      • Weight and volume verification
        • E1EDL18/9-QUALF = 'GWT',E1EDL18/9-QUALF = 'NWT', E1EDL18/9-QUALF = 'VOL'
      • Post-delivery goods issue
        • E1EDL20-VBELN, E1EDL18-QUALF = 'PGI'
      • Delete delivery
        • E1EDL20-VBELN, E1EDL18-QUALF = 'DEL'
      • Packing verification (only for creating handling units)
        • E1EDL37-EXIDV, E1EDL37-VHILM, E1EDL44-POSNR, E1EDL44-VEMNG
      • If a non-assigned handling unit is to be created, no contents data (items) must be transmitted
  • Proof of delivery
    • EDI: EDI 861, RECADV.
    • Outbound, EDI: Proof of delivery (STPPOD)
    • Inbound EDI: Proof of delivery (STPPOD)
    • Content:
      • E1EDL53 Proof of delivery
        • GRUND Reason for deviation for the POD
        • PODMG Quantity (in sales units) actually received for each delivery item
        • LFIMG_DIFF Deviation from the quantity actually delivered (in sales units)
        • VRKME Sales unit
        • LGMNG_DIFF Deviation from actual delivery quantity (in stock-keeping units)
        • MEINS Base unit of measure

Basic types

Structure of GSVERF02 (IS-A, delivery confirmation)

  • E1EDK01 : IDoc: Document header general data
  • E1EDK14 : IDoc: Document Header Organizational Data
  • E1EDKA1 : IDoc: Document Header Partner Information     
  • E1EDK02 : IDoc: Document header reference data    
  • E1EDK05 : IDoc: Document header conditions             
  • E1EDK23 : IDoc: Document Header Currency Segment                   
  • E1EDK03 : IDoc: Document header date segment
  • E1EDK28 : IDoc: Document Header Bank Data 
  • E1EDK29 : IDoc: Document Header General Foreign Trade Data 
  • E1EDK17 : IDoc: Document Header Terms of Delivery 
  • E1EDK18 : IDoc: Document Header Terms of Payment 
  • E1EDL51 : Delivery Header External Release Number     
  • E1EDKT1 : IDoc: Document Header Text Identification            
  • E1EDP01 : IDoc: Document Item General Data
    • E1EDP02 : IDoc: Document Item Reference Data 
    • E1EDP03 : IDoc: Document Item Date Segment
    • E1EDP04 : IDoc: Document Item Taxes 
    • E1EDP05 : IDoc: Document Item Conditions
    • E1EDPA1 : IDoc: Doc.item partner information
    • E1EDP19 : IDoc: Document Item Object Identification
    • E1EDP17 : IDoc: Document item terms of delivery
    • E1EDP18 : IDoc: Document Item Terms of Payment
    • E1EDP26 : IDoc: Document Item Amount Segment
    • E1EDP28 : IDoc: Document Item - General Foreign Trade Data
    • E1EDP08 : IDoc: Package data individual
    • E1EDL52 : Delivery Item External Release Number
      • Qualifier
        • 'DON' DON number 
        • 'PRN' External release number 
  • E1EDS01 : IDoc: Summary segment general                                                                                                                                                                                                                       
All messages are based on IDoc type DELVRY*.
  • E1EDL20 : Delivery header 
  • E1EDL22 : Delivery Header Descriptions 
  • E1EDL21 : Delivery Header Additional Data 
  • E1EDL55 : IDOC Reference Number 
  • E1EDT13 : IDoc: Deadline (delivery) 
  • E1EDL40 : Points (delivery deadlines) 
  • E1TXTH8 : General Text Header 
  • E1EDL33 : Export Data Delivery Header 
  • E1EDL28 : Routes 
  • E1EDL29 : Routes Descriptions 
  • E1EDL30 : Route Stages
  • E1EDL31 : Route Stage Descriptions 
  • E1EDL32 : Route Stage Point 
  • E1EDL45 : Points descriptions  
  • E1EDL47 : Express Delivery Company's Tracking Connection Data 
  • E1EDL24 : Delivery Item 
    • E1EDL41 Reference data ordering party (SD)
      • Customer Reference
      • Customer Reference Date
      • Customer Purchase Order Type
      • Your Reference
  • E1EDL56 : List of allowed carriers 
  • E1EDL25 : Delivery Item Descriptions 
  • E1EDL53 : Delivery Item POD 
  • E1EDL11 : IDOC: Serial Number 
  • E1EDL15 : IDOC: Batch Characteristic 
  • E1EDL35 : Export Data Delivery Item 
  • E1TXTH9 : General Text Header 
  • E1EDL58 : Subcontracting Component
  • E1EDL37 : Handling unit header  
  • E1EDL39 : Control Segment for Handling Units 
  • E1EDL38 : Handling Unit Header Descriptions 
  • E1EDD50 : Dangerous Goods Data (Handling Unit Header) 
  • E1EDD52 : Assignment of Dangerous Goods-Based Exception (HU Header)
  • E1EDL44 : IDoc: Handling Unit Item (Delivery)  
  • E1EDL54 : Repack Handling Units 


Additional information 

1594584 - Actual goods issue date field in IDOC

Launch transaction WE19 with IDoc number which has segment E1EDT13 filled and qualifier ‘006’;
Process the IDOC;
Check the the actual goods date value in segment E1EDT13;
he IDoc message type DESADV with the function module IDOC_INPUT_DESADV1 does not fill WADAT_IST field via standard since it is only updated during actual goods movement posting (timestamp).

       WHEN 'E1EDT13'.
        s_dt13 = idoc_data-sdata.
        CASE s_dt13-qualf.
          WHEN '006'.
            IF NOT s_dt13-ntanf IS INITIAL.
              mv s_dt13-ntanf s_koko-wadat.
              mv s_dt13-ntanz s_koko-wauhr.
              s_koko-kzwad = true.
            ENDIF.
            mv s_dt13-isdd s_koko-wadat_ist.
          WHEN '007'.
            mv s_dt13-ntanf s_koko-lfdat.
            mv s_dt13-ntanz s_koko-lfuhr.
            s_koko-kzlfd = true.
          WHEN '010'.
            mv s_dt13-ntanf s_koko-kodat.
            mv s_dt13-ntanz s_koko-kouhr.
            s_koko-kzkodat = true.
          WHEN OTHERS.
        ENDCASE.

Comments

Post a Comment