Skip to Content
Technical Articles
Author's profile photo Knut Heusermann

How does SAP ByDesign map IDoc Party IDs

SAP Business ByDesign (ByD) can be used as cloud ERP solution for subsidiaries in large enterprise networks. For this purpose SAP Business ByDesign offers a predefined subsidiary integration scenario with SAP S/4 HANA or SAP ECC.

As part of the overall subsidiary integration scenario, ByD supports the business-to-business (B2B) message exchange of Purchase Orders, Purchase Order Confirmations, Advanced Shipping Notifications (ASN) and Invoices using intermediate documents (IDocs).

This blog posts explains how ByD maps party IDs when receiving Purchase Order Confirmations, Advanced Shipping Notifications (ASN) and Invoices IDoc xml messages from SAP ECC or SAP S/4 HANA.

Beyond the scope of this blog post you find general information about the ByD integration with SAP S/4 HANA on SAP Help >> Integration Scenarios >> Subsidiaries.

 

Mapping of IDoc Party IDs

In general ByD B2B message types support 3 kind of identifiers to identify a target record:

  • The internal ID of the document sender
  • The internal ID of the document receiver
  • Standard IDs that are known by both communication parties

This concept applies to all kind of ID types incl. document IDs (e.g. order IDs) and master data ID (e.g. business partner IDs and product IDs).

Example:

A supplier in ByD may have the following identifier:

  • Internal ID
  • Customer ID at Supplier
  • Global Location Number (GLN) as standard ID
  • Tax number

In an invoice document send from S/4 to ByD this supplier might be referred to as “seller party” and can be identified by

  1. Standard ID => Global Location Number
  2. Bill-to ID => Internal ID of the ByD supplier = “Supplier ID at Customer” of the S/4 vendor
  3. Bill-from ID => Internal ID of the S/4 vendor = “Customer ID at Supplier” of the ByD supplier
  4. Tax ID => Tax number

As precondition for a smooth message inbound processing, the master data in S/4 and ByD should be maintained properly according the above described concept. You find more information about the required master data settings in the Integration Guide for Purchasing (ByD Wiki, login required).

 

Advanced Shipping Notifications

Communication: S/4 HANA Delivery Dispatch Advice >> ByD Advanced Shipping Notification

  • ByD interface: InboundDeliveryProcessingDeliveryNotificationIn_IDOC
  • IDoc type: DESADV.DELVRY05

The ByD message inbound processing checks IDoc segment e1edl20-e1adrm1 for an instance with the corresponding party type:

  • Vendor party: e1edl20-e1adrm1 with partner_q = OSO
  • Product recipient party: e1edl20-e1adrm1 with partner_q = AG
  • Buyer party: e1edl20-e1adrm1 with partner_q = AG
  • Seller party: e1edl20-e1adrm1 with partner_q = OSO
  • Carrier party: e1edl20-e1adrm1 with partner_q = SP

For each party type the system checks sub-segment e1adre1 for available ID types:

  1. Customer ID at Customer (S/4 knows the ByD party internal ID): e1adre1-extend_q = 302
  2. Supplier ID at Customer (vendor party and seller party only): Check if ByD knows the S/4 party internal ID using the party roles AG and WE:
    ByD checks segment e1adrm1 with partner_q = AG and partner_q = WE and then sub-segment e1adre1 with extend_q = 300.
  3. Standard ID (S/4 and ByD know both the same standard Global Location Number): e1adre1-extend_q = 100.

 

Invoices

Communication: S/4 HANA Customer Invoice >> ByD Supplier Invoice

  • ByD interface: SupplierInvoiceProcessingInvoicingIn_IDOC
  • IDoc type: INVOIC.INVOIC02

Bill-to party:

The ByD message inbound processing checks if IDoc segment e1edka1 contains an entry with parvw = RE and then checks available party ID types:

  1. Standard ID (S/4 and ByD both know the same standard Global Location Number, GLN): Element e1edka1-ilnnr
  2. Bill-to ID (S/4 knows the party ID used in ByD): Element e1edka1-lifnr
  3. Bill-from ID (ByD knows the party ID used in S/4): Element e1edka1-partn
  4. Tax ID (S/4 and ByD both know the same business partner tax number): e1edk01-kundeuinr

Buyer party:

ByD derives the buyer party from the bill-to party. However, if the S/4 does not transfer a bill-to party, then ByD searches for the buyer party:

The ByD message inbound processing checks if IDoc segment e1edka1 contains an entry with parvw = AG and then checks available party ID types:

  1. Standard ID (S/4 and ByD both know the same standard Global Location Number, GLN): Element e1edka1-ilnnr
  2. Bill-to ID (S/4 knows the party ID used in ByD): Element e1edka1-lifnr
  3. Bill-from ID (ByD knows the party ID used in S/4): Element e1edka1-partn
  4. Tax ID (S/4 and ByD both know the same business partner tax number): e1edk01-kundeuinr

Bill-from party:

The ByD message inbound processing checks if IDoc segment e1edka1 contains an entry with parvw = RS and then checks available party ID types:

  1. Standard ID (S/4 and ByD both know the same standard Global Location Number, GLN): Element e1edka1-ilnnr
  2. Bill-to ID (S/4 knows the party ID used in ByD): Element e1edka1-partn
    Note: In case of party type RS (bill-from-party), S/4 sends the bill-from party in the field partn.
  3. Tax ID (S/4 and ByD both know the same business partner tax number): e1edk01-eigenuinr

Seller party:

The ByD message inbound processing checks if IDoc segment e1edka1 contains an entry with parvw = LF and then checks available party ID types:

  1. Standard ID (S/4 and ByD both know the same standard Global Location Number, GLN): Element e1edka1-ilnnr
  2. Bill-to ID (S/4 knows the party ID used in ByD): Element e1edka1-lifnr
  3. Bill-from ID (ByD knows the party ID used in S/4): Element e1edka1-partn
  4. Tax ID (S/4 and ByD both know the same business partner tax number): e1edk01-eigenuinr

If no seller party ID could be found, ByD uses the Bill-from party as seller party:

  1. … (see above)

If still no seller party ID could be found, ByD use the vendor view party (e1edka1-parvw = LFL) as seller party:

  1. Standard ID (S/4 and ByD both know the same standard Global Location Number, GLN): Element e1edka1-ilnnr
  2. Bill-to ID (S/4 knows the party ID used in ByD): Element e1edka1-lifnr
  3. Bill-from ID (ByD knows the party ID used in S/4): Element e1edka1-partn

If no seller party ID could be identified, ByD raises an error message.

 

Purchase Order Confirmations

Communication: S/4 HANA Sales Order Confirmation >> ByD Purchase Order Acknowledgment

  • ByD interface: PurchaseOrderProcessingOrderingIn_IDOC
  • IDoc type: ORDRSP

ByD does not map party IDs because all parties are already given by the reference to the purchase order.

 

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jacques-Antoine Ollier
      Jacques-Antoine Ollier

      Hello Knut Heusermann ,

      thank you very much for this piece of information!

      We are currently implementing some EDI transactions with an EDI partner for a customer and we are using the GLN for the parties.

      One thing we did notice, and we are not sure we are right, is:

      • The standard ID = GLN, is only sent for the billing parties node, not for the shipping parties of Invoices, am I right?
        • In the QueryCustomerInvoice endpoint,
          • we can see the StandardID at Buyer, Seller and BillTo in the header/root level
        • however, the Ship-to party/ProductRecipient at Item level do not come with the corresponding StandardID of the Account

      Am I missing something or is it how SAP BYD is supposed to work to get the Standard ID on billing parties and not on the product recipient party of billing documents ?

      Thank you for your attention

      Best
      Jacques-Antoine Ollier