EP1875428A2 - Consistent set of interfaces derived from a business object model - Google Patents

Consistent set of interfaces derived from a business object model

Info

Publication number
EP1875428A2
EP1875428A2 EP06765436A EP06765436A EP1875428A2 EP 1875428 A2 EP1875428 A2 EP 1875428A2 EP 06765436 A EP06765436 A EP 06765436A EP 06765436 A EP06765436 A EP 06765436A EP 1875428 A2 EP1875428 A2 EP 1875428A2
Authority
EP
European Patent Office
Prior art keywords
characterizing
party
package containing
information
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06765436A
Other languages
German (de)
English (en)
French (fr)
Other versions
EP1875428A4 (en
Inventor
Michael Seubert
Jochen Rasch
Axel Kuehl
Dirk Becker
Markus Biehler
Daniel Bock
Andreas Brossler
Renzo Colle
Giovani Deledda
Ralf Dielschneider
Robert Doerner
Phillippe Drouin
Karsten Egetoft
Stefan Franke
Wernere Gnan
Daniel Goldmann
Antonia Gross
Patrick Gross
Nils Hartmann
Stephan Hetzer
Christine Hofmann
Johann Kemmer
Joachim Kenntner
Adam Kiwon
Arndt Koester
Thilo Kraehmer
Andreas Krompholz
Corinne Kuster
Marcus Lotz
Otto Makris
Ramesh Nn
Dietmar Nowotny
Till Oppert
Markus Peter
Georg Podhajsky
Ruediger Radcke
Michael Redmann
Frank Reinemuth
Paola Sala
Arnulf Schueler
Dagmar Schulze
Ralf Sievers
Jan Stephan
Sergej Stotz
Frank Thome
Andre Wagner
Burkhard Weiss
Rudolf Winkel
Renato Zadro
Brit Ziemendorf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/145,464 external-priority patent/US8655756B2/en
Priority claimed from PCT/US2005/021481 external-priority patent/WO2006038924A2/en
Priority claimed from PCT/US2005/022137 external-priority patent/WO2006012160A2/en
Priority claimed from US11/166,065 external-priority patent/US8606723B2/en
Application filed by SAP SE filed Critical SAP SE
Priority claimed from US11/364,538 external-priority patent/US8744937B2/en
Priority claimed from PCT/IB2006/001401 external-priority patent/WO2006117680A2/en
Publication of EP1875428A2 publication Critical patent/EP1875428A2/en
Publication of EP1875428A4 publication Critical patent/EP1875428A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • PCT Patent Application No. PCT/US05/19961 entitled “Consistent Set Of Interfaces Derived From A Business Object Model,” filed on June 3, 2005.
  • PCT Patent Application No. PCT/US05/021481 entitled “Consistent Set Of Interfaces Derived From A Business Object Model,” filed on June 17, 2005.
  • the subject matter described herein relates generally to the generation and use of consistent interfaces derived from a business object model. More particularly, the subject matter described herein relates to the generation and use of consistent interfaces that are suitable for use across industries, across businesses, and across different departments ⁇ vithin a business.
  • Transactions are common among businesses and between business departments within a particular business. During any given transaction, these business entities exchange information. For example, during a sales transaction, numerous business entities may be involved, such as a sales entity that sells merchandise to a customer, a financial institution that handles the financial transaction, and a warehouse that sends the merchandise to the customer.
  • the end-to-end business transaction may require a significant amount of information to be exchanged between the various business entities involved. For example, the customer may send a request for the merchandise as well as some form of payment authorization for the merchandise to the sales entity, and the sales entity may send the financial institution a request for a transfer of funds from the customer's account to the sales ⁇ entity's account.
  • Exchanging information between different business entities is not a simple task. This is particularly true because the information used by different business entities is usually tightly tied to the business entity itself.
  • Each business entity may have Us own program for handling its part of the transaction. These programs differ from each other because they typically are created for different purposes and because each business entity may use semantics that differ from the other business entities. For example, one program may relate to accounting, another program may relate to manufacturing, and a third program may relate to inventory control. Similarly, one program may identify merchandise using the name of the product while another program may identify the same merchandise using its model number. Further, one business entity may use U.S. dollars to represent its currency while another business entity may use Japanese Yen.
  • UN/CEFACT Centre for Trade Facilitation and Electronic Business
  • UN/CEFACT is still in its early stages of developing such a harmonized system. Additional info ⁇ nation regarding UN/CEFACT can be found at www.unece.org/cefact/.
  • Such business entities may include different companies within different industries. For example, one company may be in the chemical industry, while another company may be in the automotive industry.
  • the business entities also may include different businesses within a given industry, or they may include different departments within a given company.
  • the interfaces are consistent across different industries and across different business units because they are generated using a single business object model.
  • the business object model defines the business-related concepts at a central location for a number of business transactions. In other words, the business object model reflects the decisions made about modeling the business entities of the real world acting in business transactions across industries and business areas.
  • the business object model is defined by the business objects and their relationships to each other (overall net structure).
  • a business object is a capsule with an internal hierarchical structure, behavior offered by its operations, and integrity constraints.
  • Business objects are semantically disjoint, i.e., the same business information is represented once.
  • the business object model contains all of the elements in the messages, user interfaces and engines for these business transactions.
  • Each message represents a business document with structured information.
  • the user interfaces represent the information that the users deal with, such as analytics, reporting, maintaining or controlling.
  • the engines provide services concerning a specific topic, such as pricing or tax.
  • Methods and systems consistent with the subject matter described herein generate interfaces from the business object model by assembling the elements that are required for a given transaction in a corresponding hierarchical manner. Because each interface is derived from the business object model, the interface is consistent with the business object model and with the other interfaces that are derived from the business object model. Moreover, the consistency of the interfaces is also maintained at all hierarchical levels. By using consistent interfaces, each business entity can easily exchange information with another business entity without the need for human interaction, thus facilitating business transactions.
  • Methods and systems consistent with the subject matter described herein provide an object model and, from this object model, derive two or more interfaces that are consistent.
  • Methods and systems consistent with the subject matter described herein provide a consistent set of interfaces suitable for use with a business scenario that spans across the components within a company. These components, or business entities, may be heterogeneous.
  • An electronic message to request cancellation of an accounting can be generated by a first application that executes in a landscape of computer systems providing message- based services. Transmission of the message to a second application can be initialed in order to request cancellation of the accounting. Responding to a request to cancel an accounting can include receiving a message including an accounting cancellation package and initiating cancellation of an accounting of posting info ⁇ nation.
  • An accounting cancellation package can contain an accounting cancellation entity and a business transaction document reference package, where the accounting cancellation entity identifies a first document that characterizes cancellation of an accounting and identifies a type of a second document characterizing posting information previously sent and to be canceled, and the business transaction document reference package contains a reference entity identifying the second document.
  • the posting information can include posting information previously sent for an invoice or credit memo
  • the request for cancellation of an accounting can include a request for cancellation of an accounting of an invoice.
  • the posting info ⁇ nation can include posting information previously sent with respect to a movement of goods
  • the request for cancellation of an accounting can include a request for cancellation of an accounting of a movement of goods.
  • the accounting cancellation package can further contain a note entity characterizing a reason for the cancellation, and a date entity characterizing a date on which the cancellation is to be entered.
  • An electronic message to request a bank account statement can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to request the bank account statement.
  • the generated message can include a bank account statement package containing a bank account statement entity characterizing a statement of a bank regarding turnovers on a customer bank accouni.
  • the bank account statement package can also contains a bank account package containing info ⁇ nation characterizing a bank account.
  • the bank account statement package further contains a bank account statement item package containing an item entity characterizing a single turnover on a bank account.
  • the bank account statement item package also contains a payment explanation package containing information characterizing payments in a bank account statement.
  • the payment explanation package contains a payment difference explanation package containing information characterizing documents relating to payments in a bank account statement.
  • the bank account statement package can further contain a party package containing a payment transaction initiator party entity characterizing a part ⁇ ' that initiated a payment.
  • the party package can also contain a payment transaction destination party entity characterizing a party that receives payment in case of a bank transfer or whose account is debited in case of a direct debit.
  • the party package can also contain an original payment transaction initiator party entity characterizing a party executing a payment transaction.
  • the party package can also contain a final payment transaction destination party entity characterizing a party to receive a payment or to be debited.
  • the bank account statement package can also include a bank account statement bank account package containing a payment transaction initiator bank account entity characterizing a bank account of a party initiating a payment transaction.
  • the bank account statement bank account package can also contain a payment transaction destination bank account characterizing a bank account of a party receiving a payment or to be debited.
  • the bank account statement package can also include a business transaction document reference package containing a payment reference entity characterizing a document from a payment transaction initiator.
  • the business transaction document reference package can also include a payment order reference entity characterizing a payment order by a payment transaction initiator.
  • the business transaction document reference package can also include a business transaction document reference package.
  • the business transaction document reference package can further contain a bill of exchange reference entity characterizing a bill of exchange number.
  • the payment explanation package can further contain a payment explanation item characterizing a payment amount.
  • the payment explanation package can also contain a payment explanation party package containing an original payment transaction initiator party entity characterizing an original party on behalf of which a payment transaction is executed.
  • the payment explanation party package can also contain a final payment transaction destination party characterizing a party on behalf of which a payment is received or debited.
  • the payment explanation package can also contain a business document object reference package containing a payment explanation payment transaction initiator invoice reference entity characterizing an invoice of a transaction initiator.
  • the business document object reference package can also contain a payment explanation payment transaction destination invoice reference entity characterizing an invoice of a party receiving a payment or being debited.
  • the business document object reference package can also contain a payment explanation payment transaction initiator contract reference entity characterizing a contract of a transaction initiator.
  • the business document object reference package can also contain a payment explanation payment transaction destination contract reference entity characterizing a contract of a party receiving a payment or being debited.
  • the business document object reference package can also contain a payment explanation payment transaction initiator purchase order reference entity characterizing a purchase order of a transaction initiator.
  • the business document object reference package can also contain a payment explanation payment transaction destination purchase order reference entity characterizing a reference to a purchase order of a party receiving a payment or being debited.
  • the payment difference explanation package can contain a payment difference explanation item entity characterizing differences between expected and actual payment amounts.
  • the payment difference explanation package can also contain a business document object reference package containing a payment difference explanation payment transaction initiator invoice reference entity characterizing an invoice of a transaction initiator.
  • the business document object reference package can also contain a payment difference explanation payment transaction destination invoice reference entity characterizing an invoice of a party receiving a payment or being debited.
  • the business document object reference package can also contain a payment difference explanation payment transaction initiator contract reference entity characterizing a contract of a transaction initiator.
  • the business document object reference package can also contain a payment difference explanation payment transaction destination contract reference entity characterizing a contract of a party receiving a payment or being debited.
  • the business document object reference package can also contain a payment difference explanation payment transaction initiator purchase order reference entity characterizing a purchase order of a transaction initiator.
  • the business document object reference package can further contain a payment difference explanation payment transaction destination purchase order reference entity characterizing a reference to a purchase order of a party receiving a payment or being debited.
  • Generating a request for a bank account statement can be accomplished by receiving an electronic message in a landscape of computer systems providing message-based services and initiating generation of a request for a bank account statement.
  • the received message includes a bank account statement package containing a bank account statement entity characterizing a statement of a bank regarding turnovers on a customer bank account.
  • the bank account statement package also includes a bank account package containing information characterizing a bank account.
  • the bank account statement package further contains a bank account statement item package containing an item entity characterizing a single turnover on a bank account.
  • the bank account statement item package also contains a payment explanation package containing information characterizing payments in a bank account statement.
  • the payment explanation package also contains a payment difference explanation package containing information characterizing documents relating to payments in a bank account statement.
  • An electronic message to request bank account balances for a time period for a group of bank accounts can be generated by a first application that executes in a landscape of computer systems. Transmission of the message to a second application can be initiated in order to request account balances for a time period for a group of bank accounts. Responding to a request for account balances for a time period for a group of bank accounts can include receiving a message including a bank account balance report query package and initiating a request for bank account balances for a time period for a group of bank accounts.
  • the bank account balance report query package can contain a bank account balance report query entity, a bank account package, and item package.
  • the bank account balance report query entity characterizes a request for balance information for a bank account.
  • the bank account package characterizes the bank account for which requests are to be made.
  • the item package characterizes criteria that are relevant for determining bank account balances.
  • the bank account package can contain a bank account entity identifying the bank account for which balance information is to be ascertained.
  • the item package can contain a bank account balance report query item entity characterizing criteria for determining bank account balances.
  • the bank account balance report query item entity can contain a bank account balance type code characterizing a type of a bank account balance and a date period entity identifying a period for which the bank account balances are to be taken into consideration.
  • the bank account package can further contain a bank account differentiator entity characterizing the difference between accounts that are managed under one account number.
  • the bank account differentiator entity can contain a bank account differentiator ID characterizing a unique identifier to differentiate between bank accounts.
  • An electronic message to respond to a request for bank account balances for a time period for a group of bank accounts can be generated by a first application that executes in a landscape of computer systems. Transmission of the message to a second application can be initiated in order to receive account balances for a time period for a group of bank accounts. Responding to a request for account balances for a time period for a group of bank accounts can include receiving a message including a bank account balance report package and initiating a request for bank account balances for a time period for a group of bank accounts.
  • the bank account balance report package can contain a bank account balance report entity containing information about balances of a bank account.
  • the bank account balance report package can contain a log package, a bank account package and a bank account balance package.
  • the log package characterizes log messages that are issued when bank account balances are determined and can contain a log entity characterizing a sequence of log messages issued by an application while executing a task.
  • the bank account package characterizes information about the bank account for which requests are made and can contain a bank account entity characterizing the bank account to which balance information belongs, and a bank account differentiator entity characterizing the difference between accounts that are managed under one account number.
  • the bank account differentiator entity can contain a bank account differentiator ID characterizing a unique identifier to differentiate between bank accounts.
  • the bank account balance package characterizes bank account balances, and can contain a bank account balance entity containing bank account balances.
  • An electronic message to record business document data from a digitized image of the data can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to record the digitized business document data either manually or automatically. Responding to a request to record business document data from a digitized image of the data can include receiving a message including a business transaction document image recognition package and initiating recording of the digitized business document data either manually or automatically.
  • a business transaction document image recognition package can contain a business transaction document image recognition request entity characterizing a request for a digitized business document to be recognized and an attachment package containing an attachment entity identifying the digitized business document.
  • the digitized business document to be recognized can include an invoice, and the request to record business document data from an image can include a request for the manual entry of the invoice data.
  • the digitized business document to be recognized can include an invoice, and the request to record business document data from an image can include a request for automatic entry of the invoice data with the use of Optical Character Recognition (OCR) software.
  • OCR Optical Character Recognition
  • An electronic message requesting to change, create, or delete items in a catalogue can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to request to change, create, or delete items in a catalogue.
  • a catalogue publication transmission package can contain a catalogue entity that characterizes a structured directory of catalogue items.
  • the catalogue publication transmission package can further contain a content package.
  • the content package can contain a content entity, catalogue item package, a catalogue view package, and a transmission information package.
  • the content entity can characterize a list of items to be changed, created, or read.
  • the catalogue item package can contain a catalogue item entity, a catalogue item description entity, a catalogue classification entity, a property valuation entity and a catalogue item relationship entity.
  • the catalogue item entity can characterize information about a catalogue item required to change, create, or delete it.
  • the catalogue item description entity can characterize an item in various locales.
  • the catalogue classification entity can characterize a classification of a catalogue item.
  • the property valuation entity can characterize a value of a property associated with a catalogue item.
  • the catalogue item relationship entity can characterize a relationship between two catalogue items.
  • the catalogue view package can contain a catalogue view entity and a catalogue view item entity.
  • the catalogue view entity can characterize a restricted subset of a catalogue.
  • the catalogue view item entity can chaiacterize a catalogue item to be included in a catalogue view.
  • the transmission information package containing information characterizing a transmission of an object contained in the message.
  • An electronic message confirming receipt of a request to change, create, or delete items in a catalogue can be generated by a first application that executes in a landscape of computer systems providing message-based sendees. Transmission of the message to a second application can be initiated in order to confirm receipt of the request to change, create, or delete items in a catalogue. Responding to the confirmation request can include receiving a message including a catalogue publication transmission package and initiating generation of a confirmation that the request to change, create, or delete items in a catalog can be performed.
  • the catalogue publication transmission package can contain a catalogue publication transmission entity characterizing information required to confirm whether items in a catalogue request can be changed, created, or deleted.
  • the catalogue publication transmission package can also contain a catalog package.
  • the catalog package can contain a catalogue entity that can characterize a catalogue of items which can be changed, created, or deleted.
  • An electronic message to request institutions to carry out one or more payment transactions can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to request institutions to carry out on payment transactions. Responding to a request for instructions to carry out one or more payment transactions can include receiving a message including the instructions to carry out one or more payment transactions, and initiating an instruction to a payer's account to record the results of payment transactions.
  • the message can comprise a collective payment order package which in turn can include a collective payment order entity and a payment order package.
  • the collective payment order entity characterizes an instruction to a credit institution to carry out one or more payment transactions.
  • the payment order package contains a payment order entity characterizing one or more instructions to a credit institution to carry out a payment transaction, and a net amount entity identifying a payment amount associated with the payment order entity.
  • the instruction to a credit institution can comprises a payment form code identifying a form of payment
  • the instruction to the payment transaction initiator's account to record the result of the payment transaction can comprises the result of the payment transaction based on a form of payment.
  • the instruction to a credit institution can also comprise an account debit indicator identifying whether or not the payment transaction initiator's account is to be debited, and the instruction to the payment transaction initiator's account to recoid the result of the payment transaction can comprises an indication as to whether or not the payment transaction initiator's account was debited.
  • the instruction to a credit institution can comprise a payment procedure code identifying one or more technical characteristics of the payment transaction, and the instruction to the payment transaction initiator's account to record the iesult of the payment transaction can comprises the result of the payment tiansaction based on a payment procedure code.
  • the instruction to a credit institution can comprise a payment execution date identifying an execution date for the payment transaction, and the instruction to the payment transaction initiator's account to record the result of the payment transaction can comprises a date of execution of the payment transaction.
  • the collective payment order package can include a party package containing information characterizing information concerning parties involved in the payment transaction, and a bank account package containing information characterizing information concerning banking details of a payment transaction initiator and a bank account to be used by a bank for bank charges.
  • the party package can include a payment transaction initiator party entity characterizing the party that initiated a payment.
  • the bank account package can include a payment transaction initiator bank account entity characterizing a bank account of the payment transaction initiator, and a bank charges bank account entity characterizing a bank account to be debited with bank charges for a collective payment order.
  • the payment order package can include a party package containing information characterizing the party that placed the order and a bank account package containing information characterizing banking details for the destination party of the payment transaction. It can also include a payment instruction package containing information characterizing information for participating banks concerning a payment transaction execution, and a state central bank report package containing information characterizing legal reporting information to a central bank. 7Tie payment order package further can include information to satisfy a legal reporting requirement for payments to foreign payees, and a business transaction document reference package containing information characterizing references to different documents involved in the payment transaction, such as checks. It can also include a payment explanation package containing information , ⁇ characterizing an explanation for a purpose, and an amount of a payment, which can include references to individual invoices or credit memos.
  • the parry package can include a payment transaction destination party entity characterizing the party that receives a payment or whose account is debited, and an original payment transaction initiator party entity characterizing the party on whose behalf a payment order can be executed by the payment transaction initiator parly entity. It can also include a final payment transaction destination party entity characterizing the party that can optionally receive a payment or be debited.
  • the bank account package can include a payment transaction destination bank account entity characterizing a bank account of the party that the payment transaction is destined.
  • the payment instruction package can include a payment instruction entity characterizing an instruction to an executing bank related to the payment order, such as to send a bank advice to the payee, and a correspondence bank details entity characterizing details from a bank of a correspondence bank that should be used for forwarding the payment order.
  • the correspondence bank details entity further can include a correspondence bank type code characterizing a type of a correspondence bank, a bank code characterizing an address or identifier for the correspondence bank, and a bank account code characterizing a correspondence bank account.
  • the state central bank report package can include a central bank report item entity characterizing information to satisfy legal reporting to a central bank and a requirement for payments to foreign payees.
  • the business transaction document reference package can include a payment reference entity characterizing a reference to a payer's payment document representing an actual payment that includes at least the payment procedure, the payment currency, the payment amount, the payment date and the payment receiver.
  • the payment reference entity can also identify parties involved and banking details associated with a payment.
  • the business transaction document reference package can also include a check reference entity characterizing a reference to a check (i.e., checknumber) that was used for the payment, and a bill of exchange reference entity characterizing a reference to a bill of exchange (i.e., a bill of exchange number) that was used for the payment.
  • the payment explanation package can include a payment explanation item entity characterizing a payment amount for the payee. It can refer to one or more invoices or other business documents relevant for the payment amount such as potential adjustments applied by the payer.
  • An electronic message to provide notification of ihe payment behavior of the business partner can be generated by a first application that executes in a landscape of computer systems providing message-based services. Tiansmission of the message to a second application can be initiated in order to provide notification of the payment behavior of the business partner. Responding to the message to provide notification of the payment behavior of the business partner can include receiving a message including a credit payment behavior summary package and initiating the notification of the payment behavior of Ihe business partner.
  • a credit payment behavior summary package can contain a credit payment behavior summary message entity and a party package.
  • the credit payment behavior summaiy message entity can characterize key figures regarding the payment behavior of a business partner.
  • the party package can contain information that characterizes the parties relevant to the payment behavior of the business party.
  • the party package can contain a debtor party entity, a creditor party entity, and a seller paity entity.
  • the debtor party entity can characterize a debtor party having a payment obligation.
  • the creditor party entity can characterize a party that owns a receivable due from the debtor party.
  • the seller party entity can characterize a party that has sold a product to the debtor party.
  • the message to provide notification of the payment behavior of the business partner can further contain a product information package.
  • the product information package can contain information that characterizes the product sold to the debtor party.
  • the product information package can further contain a payment information package.
  • the payment information package can contain information that characterizes the payment behavior of the debtor party.
  • the payment information package can contain a last payment entity, an oldest open item entity and a maximum level dunned open item entity.
  • the last payment entity can characterize a last payment received from the debtor party.
  • the oldest open item entity can characterize an oldest open item of the debtor party.
  • the maximum level dunned open item entity can characterize an open item of the debtor party having a highest dunning level.
  • Responding to a message requesting to generate a query regarding creditworthiness of a party can include receiving a message including a credit worthiness query package and initiating a query regarding creditworlhiness of a party.
  • the credit worthiness query package can contain a credii worthiness entity and a party package.
  • the credit worthiness entity can characterize a query regarding creditworthiness of a party.
  • the party package can contain a debtor party entity that can characterize a party for whom creditworlhiness information is to be provided.
  • the party package can further contain a creditor party entity and a seller party entity.
  • the creditor party entity can characterize a party that owns a receivable due from a debtor.
  • the seller party entity can characterize a party that sells or plans to sell a product to a debtor.
  • the credit worthiness query package can further contain a product information package.
  • the product information package can contain information that can characterize a product category of a product sold cr to be sold to a debtor.
  • An electronic message requesting to generate a response to a query regarding the creditworthiness of a party can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate a response to a query regarding the creditworthiness of a party.
  • Responding to a message requesting to generate a response to a query regarding creditworthiness of a party can include receiving a message including a credit worthiness query package and initiating a response to a query regarding creditworthiness of a party.
  • the credit worthiness query package can contain a credit worthiness entity, a party package and an information package.
  • the credit worthiness entity can characterize a query regarding creditworthiness of a party.
  • the party package can contain a debtor party entity that can characterize a party for whom creditworthiness information is to be provided.
  • the information package can contain a credit rating entity that can characterize a credit rating for a debtor party.
  • the party package can further contain a creditor party entity and a seller party entity.
  • the creditor party entity can characterize a party that owns a receivable due from a debtor.
  • the seller party entity can characterize a party that sells or plans to sell a product to a debtor.
  • the credit worthiness queiy package can further contain a product information package.
  • the product information package can contain information that can characterize a product category of a product sold or to be sold to a debtor.
  • the information package can further contain a credit risk class entity, a credit limit entity and a credit exposure entity.
  • the credit risk class entity can characterize a risk of non-payment by a debtor party.
  • the credit limit entity can characterize a credit limit for a debtor party.
  • the credit exposure entity can characterize a level of a credit limit that has been consumed.
  • An electronic message to request generation of delivery quantity and scheduling ii) formation can be generated by a lirsc application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to request generation of delivery quantity and scheduling information. Responding to the request for generation of delivery quantity and scheduling information can include receiving a message including a purchase request package and initiating a generation of delivery quantity and scheduling information.
  • a purchase request package can contain a purchase request entity and a purchase request item package.
  • the purchase request entity can characterize requisition requirements.
  • the purchase request item package can contain a schedule line package that can characterize quantity and date information associated with a requisition.
  • the party package can further contain a buyer party entity and a bill to party entity.
  • the buyer party entity can characterize a party that buys goods or services.
  • the bill to party entity can characterize a party that is billed for goods or services.
  • the item package can further contain a delivery information package, a delivery schedule item party package, a location package and a schedule line package.
  • the delivery information package can contain a previous delivery entity and a cumulative delivery entity.
  • the previous delivery entity can characterize identification and validity of a last release instance previously transferred in a delivery schedule.
  • the cumulative delivery entity can characterize identification and validity of instances previously transferred in a delivery schedule.
  • the delivery schedule item party package can contain a buyer party entity and a product recipient party entity.
  • the buyer party entity can characterize a party that buys the goods to be delivered.
  • the product recipient part ⁇ ' entity can characterize a party that receives a goods delivery.
  • the location package can contain a ship from location entity, a trans-shipment location entity and a ship to location entity.
  • the ship from location entity can characterize a place from which ordered goods are delivered.
  • the trans-shipment location entity can characterize a location to which ordered products are trans-shipped en route to a recipient.
  • the ship to location entity can characterize a place to which ordered goods are delivered.
  • the schedule line package can contain a schedule line entity and a confirmed schedule line entity.
  • the schedule line entity can characterize a statement about goods to be deliveied.
  • the confirmed schedule line ei ⁇ ity can characterize a confirmation from a vendor party as terms of a delivery of goods from a scheduling agreement
  • An electronic message to request generation of delivery quantity and scheduling information can be generated by a first application tliat executes in a landscape of computer systems providing message-based sei vices. Transmission of the message to a sscoml application can be initiated in order to request generation of deiivc'ty quantity and scheduling information. Responding to the lequest for generation of delivery quantity and scheduling information can include receiving a message including a purchase request package and initiating a generation of deliveiy quantity and scheduling information.
  • ⁇ purchase lequest package can contain a purchase request entity and a purchase request item package. The purchase request entity can characterize requisition requirements. The purchase request item package can coniain r» schedule line package that can characterize quantity and date information associated with a requisition.
  • the party package can further contain a buyer party entity and a bill to patty entity.
  • the buyer party entity can characterize a party that buys goods or services.
  • the bill to party entity can characterize a party that is billed for goods or services.
  • the item package can further contain a delivery information package, a delivery schedule item party package, a location package and a schedule line package.
  • the delivery information package can contain a previous delivery entity and a cumulative delivery entity.
  • the previous delivery entity' can characterize identification and validity of a last release instance previously transferred in a delivery schedule.
  • the cumulative delivery entity can characterize identification and validity of instances previously Transferred in a delivery schedule.
  • the delivery schedule item party package can contain a buyer party entity and a product recipient party entity.
  • the buyer party entity can characterize a party that buys the goods to be delivered.
  • the product recipient party entity can characterize a party that receives a goods delivery.
  • the location package can contain a ship from location entity, a trans-shipment location entity and a ship to location entity.
  • the ship from location entity can characterize a place from which ordered goods are delivered.
  • the trans-shipment location entity can characterize a location to which ordered products are trans-shipped en route to a recipient.
  • the ship to location entity can characterize a place to which ordered goods are delivered.
  • the schedule line package can contain a schedule line entity and a confirmed schedule line entity.
  • the schedule line entity can characterize a statement about goods to be delivered.
  • the confirmed schedule line entity can characterize a confirmation from a vendor party as terms of a delivery of goods from a scheduling agreement.
  • Generating a notification regarding a shipment event associated with a delivery of goods can be accomplished by using a first application executing in a landscape of computer systems providing message-based services to generate an electronic message and initiating transmission of the message Io a second application to generate a shipment notification regarding an event associated with a delivery of goods.
  • the generated message includes a delivery package containing a delivery entity characterizing goods or a combination of goods to be made available for transportation.
  • the delivery package also contains a location package containing a ship to location entity characterizing a place to - which goods are shipped.
  • the delivery package also contains an item package containing an item entity characterizing a quantity of goods in a delivery.
  • the item package further ' contains a product information package containing information characterizing a product in a delivery item.
  • the delivery package can further contain a handling unit containing information characterizing units of packaging materials and packaged products.
  • the delivery package can also contain a delivery party package containing a buyer party entity characterizing a party that purchased goods specified in a delivery.
  • the delivery party package can also contain a vendor party entity characterizing is a party that delivers goods.
  • the delivery party package can also contain a product recipient party characterizing is party to whom goods are delivered.
  • the delivery party package can also contain a carrier party entity characterizing a party that transports goods.
  • the delivery party package can also contain a bill to party entity characterizing a party to whom an invoice for delivered goods is sent.
  • the delivery package can also contain a transport information package containing a transport means entity characterizing a transport mechanism for a delivery.
  • the transport information package can also contain a transport tracking entity characterizing information tracking a status of a transport of a delivery.
  • the delivery package can also contain a delivery information package containing information characterizing delivery conditions related to a shipping notification.
  • the location package can further contain a ship from location entity characterizing a place from which goods are shipped.
  • the location package can also contain a transshipment location entity characterizing a location at which goods are to be trans-shipped on their way to a recipient.
  • the item package can further contain a business transaction document reference package containing a purchase order reference entity characterizing a reference to a purchase order or an item in a purchase order.
  • the business transaction document reference package can also contain an origin purchase order reference entity characterizing a reference to an original purchase order or an item within an original purchase order.
  • the business transaction document reference package can also contain a scheduling agreement reference entity characterizing an outline agreement item.
  • the business transaction document reference package can further contain a sales order reference entity characterizing a reference to an item in ?. sales order.
  • the location package can further contain a batch package containing info ⁇ nation characterizing a batch in a delivery item.
  • Generating a notification regarding a shipment event associated with a delivery of goods can be accomplished by receiving an electronic message in a landscape of computer systems providing message-based services and initiating a notification regarding a shipment event associated with a delivery of goods.
  • the received message includes a delivery package containing a delivery entity characterizing goods or a combination of goods to be made available for transportation.
  • the delivery package also contains a location package containing a ship to location entity characterizing a place to which goods are shipped.
  • the delivery package further contains an item package containing an item entity characterizing a quantity of goods in a delivery.
  • the item package also contains a product information package containing information characterizing a product in a delivery item.
  • Generating a notification regarding a receipt of a delivery of goods can be accomplished by using a first application executing in a landscape of computer systems providing message-based services to generate an electronic message and initiating transmission of the message to a second application to generate a notification regarding a receipt of a delivery of goods.
  • the generated message includes a delivery package
  • I S containing a delivery entity characterizing a confirmation of a receipt of a delivery of goods.
  • the delivery package also contains a party package containing a vendor party entity characterizing party that delivered goods or on whose behalf goods were delivered.
  • the delivery package also contains a location package containing information characterizing a 5 place to which goods were delivered.
  • the delivery package further contains an item package containing an item entity characterizing a quantity of goods that were delivered.
  • the item package also contains a product info ⁇ nation package containing information characterizing a delivered.
  • the item package can further contain a delivery information package containing information characterizing a delivery information for a delivery of goods.
  • Generating a notification regarding a receipt of a delivery of goods can be accomplished by receiving an electronic message in a landscape of computer systems
  • the received message includes a deliver ⁇ ' package containing ⁇ delivery entity characterizing goods or a combination of goods to be made available for transpoitation.
  • the delivery package also contains a location package containing a ship to location entity characterizing a place to which goods are shipped.
  • Z ⁇ ' r'elivery package further contains an item package containing an item entity characterizing a quantity of goods in a delivery.
  • the item package also contains a product information package containing information characterizing a product in a delivery item.
  • Tiansmission of the message to a second application can be initiated in order to generate invoicing information associated with a business transaction .
  • Responding to the request to generate invoicing information associated with a business transaction can include receiving a message including invoice package and initiating the generation of invoicing information associated with a business
  • the invoice package can contain an invoice entity and an invoice party package.
  • the invoice entity can characterize payables and receivables for delivered goods and rendered services.
  • the invoice party package can contain a bill to party entity and a bill from party entity.
  • the bill to party entity can characterize a parry to which an invoice for deliveries received or services rendered is sent.
  • the bill from party entity can characterize a party initiating an execution of an invoice.
  • the invoice party package can further contain an invoice buyer party entity, an invoice seller party entity, an invoice product recipient party entity, an invoice vendor party entity, an invoice manufacturer party entity, an invoice payer parly- entity, an invoice payee party entity and an invoice earner party entity.
  • the invoice buyer party entity can characterize a party authorizing deliveries or services.
  • the invoice seller party entity can characterize a party that sells goods or services.
  • the invoice product recipient party entity can characterize a party to whom goods are delivered or services are provided.
  • the invoice vendor party entity can characterize a party that delivers goods or provides services.
  • the invoice manufacturer party entity can characterize a party that produces goods being invoiced.
  • the invoice payer party entity can characterize a party that pays for goods or sendees.
  • the invoice payee party entity can characterize a party that receives payment for goods or services.
  • the invoice carrier party entity can characterize a party that transports goods to be invoiced.
  • the invoice due package can further contain a location package, an invoice dciivrry information package, an invoice payment information package, an invoice price information package, an invoice tax package, an invoice attachment package, an invoice description package, an invoice item package, an item hierarchy relationship entiiy, an item product information package, an item price information package, an item tax package, an item > package, a business transaction document reference package, an item attachment package, an item description package and an item delivery information package.
  • the location package can contain a ship to location entity and a ship from location entity.
  • the ship to location entity can characterize a place to which goods are shipped or where services are provided.
  • the ship from location entiiy can characterize a place from which goods aie shipped.
  • the invoice delivery information package can contain information that can characterize delivery information for goods being invoiced.
  • the invoice payment info ⁇ nation package can contain a cash discount terms entity and a payment form entity.
  • the cash discount terms entity can characterize terms of payment.
  • the payment form entity can characterize a payment form and required data for the payment form.
  • the invoice price info ⁇ nation package can contain information that can characterize a total price to be settled for goods or services to be invoiced.
  • the invoice tax package can contain information that can characterize tax price components in an invoice.
  • the invoice attachment package can contain information that can characterize attachment information associated with an invoice.
  • the invoice description package can contain information that can characterize texts associated with an invoice.
  • the invoice item package can contain an item entity.
  • the item entity can characterize pricing information and taxes for a quantity of product that has been delivered or for a service that has been rendered.
  • the item hierarchy relationship entity can characterize hierarchical relationships between items.
  • the item product information package can contain a product entity and a product category entity.
  • the product entity can characterize a product in an invoice item.
  • the product category entity can characterize a category of a good or service that is being invoiced.
  • the item price information package • can contain information that can characterize an amount invoiced for goods delivered or services rendered.
  • the item tax package can contain information that can characterize tax components in a total amount invoiced for goods delivered or services rendered.
  • the item package can contain an item buyer party entity, an item seller party entity, an item product recipient party entity, an item vendor party entity, an item manufacturer party and a carrier party entity.
  • the item buyer party entity can characterize a party authorizing deliveries or services.
  • the item seller party entity can characterize a parry that sells goods or services.
  • the item product recipient party entity can characterize a party to whom goods are delivered or services are provided.
  • the item vendor patty entity can characterize a party that delivers goods or provides services.
  • the item manufacturer party can characterize a party that produces goods being invoiced.
  • the carrier party entity can characterize a party that transports goods to be invoiced.
  • the business transaction document reference package can contain a purchase order reference entity, a sales order reference entity, a delivery reference entity, a service acknowledgement reference entity, an origin invoice reference entity, a purchase contract reference entity, a sales contract reference entity, a buyer product catalogue reference entity and a seller product catalogue reference entity.
  • the purchase order reference entity can characterize a purchase order or an item within a purchase order.
  • the sales order reference entity can characterize a sales order or an item within a sales order.
  • the delivery reference entity can characterize a delivery or an item within a delivery.
  • the service acknowledgement reference entity can characterize a confirmation by a seller that a service has been provided.
  • the origin invoice reference entity can characterize a reference to an invoice previously sent.
  • the purchase contract reference entity can characterize a purchase contract or an item within a purchase contract.
  • the sales contract reference entity can characterize a sales contract or an item within a sales contract.
  • the buyer product catalogue reference entity can characterize a product catalogue of a buyer or an item within the catalogue.
  • the seller product catalogue reference entity can characterize a product catalogue of a seller or an item within the catalogue.
  • the item attachment package can contain information that can characterize attachment information associated with an invoice.
  • the item description package can contain information that can characterize texts associated with an invoice.
  • the item delivery information package can characterize delivery information associated with an invoice.
  • the item package can further contain an accounting package.
  • the accounting package can contain information that can characterize an assignment of an invoice item net amount or partial amount to a set of account assignment objects.
  • An electronic message requesting to generate business transaction information can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate business transaction information . Responding to the request to generate business transaction information can include receiving a message including invoice due package and initiating the generation of business transaction information.
  • An invoice due package can contain an invoice due entity, an invoice due party package, an invoice due location package, an invoice due delivery information package, an invoice due payment information package, an invoice due price information package, an invoice due account assignment package, an invoice due attachment package. an invoice due description package and an invoice due item package.
  • the invoice due entity can characterize details of a business transaction relevant for settling the business transaction.
  • the invoice due party package can contain information that can characterize parties to a business transaction.
  • the invoice due location package can contain information that can characterize locales associated with a business transaction.
  • the invoice due deliver ⁇ ' information package can contain information that can characterize a delivery of goods associated with a business transaction.
  • the invoice due payment information package can contain information that can characterize payment terms for a business transaction.
  • the invoice due price information package can contain information that can characterize a total price to be settled for goods or services provided under a business transaction.
  • the invoice due account assignment package can contain information that can characterize account assignment information associated with a business transaction.
  • the invoice due attachment package can contain information that can characterize attachment information associated with a settlement of a business transaction.
  • the invoice due description package can contain information that can characterize texts associated with a settlement of a business transaction.
  • the invoice due item package can contain information that can characterize item information for a settlement of a business transaction.
  • the invoice due party package can further contain a buyer party entity, a seller party entity, a product recipient party entity, a vendor party entity, a bill to party entity, a bill from party entity, a payer party entity and a payee party entity.
  • the buyer party entity can characterize a party that purchases goods or services.
  • the seller party entity can characterize a party that sells goods or services.
  • the product recipient party entity can characterize a party to whom goods are delivered or services are provided.
  • the vendor party entity can characterize a party that delivers goods or provides services.
  • the bill to party entity can characterize a party to which an invoice for goods or services is sent.
  • the bill from party entity can characterize a party that draws up an invoice for goods or services.
  • the payer party entity can characterize a party that pays for goods or services.
  • the payee party entity can characterize a party that receives payment for goods or services.
  • the invoice due location package can further contain a ship to location entity and a ship from location.
  • the ship to location entity can characterize a place to which goods are shipped or where services are provided.
  • the ship from location can characterize a place from which goods are shipped.
  • the invoice due payment information package can further contain a cash discount terms entity and a payment form entity.
  • the cash discount terms entity can characterize terms of payment.
  • the payment form entity can characterize a payment form and required data for the payment form.
  • the item package can further contain an item entity, an item hierarchy relationship entity, an item product information package, an item price information package, a business transaction document reference package, an item attachment package, an item due- description package and a delivery information package.
  • the item entity can characterize information from a business document item that is to be taken into account for a settlement of a business transadion.
  • the item hierarchy relationship entity can characterize hierarchical relationships between items.
  • the item product information package can contain a product entity and a product category entity.
  • the product entity can characterize a product for which an invoice is due.
  • the product category entity can characterize a category of a product or service that is being invoiced.
  • the item price information package can contain a price entity and a procurement cost upper limit entity.
  • the price entity can characterize an amount to be settled for a product or service.
  • the procurement cost upper limit entity can characterize a quantity or value-based restriction placed on a product or sendee to be settled.
  • the business transaction document reference package can contain a purchase order reference entity, a sales order reference entity, a delivery reference entity, a purchase contract reference entity, a sales contract reference entity, a buyer product catalogue reference entity and a vendor product catalogue reference entity.
  • the purchase order reference entity can characterize a purchase order or an item within a purchase order.
  • the sales order reference entity can characterize a sales order or an item within a sales order.
  • the delivery reference entity can characterize a delivery or an item within a delivery.
  • the purchase contract reference entity can characterize a purchase contract or an item within a purchase contract.
  • the sales contract reference entity can characterize a sales contract or an item within a sales contract.
  • the buyer product catalogue reference entiry can characterize a product catalogue of a buyer or an item within the catalogue.
  • the vendor product catalogue reference entity can characterize a product catalogue of a vendor or an item,i within the catalogue.
  • the item attachment package can contain information that can/ characterize attachment information associated with a settlement of a business transaction.
  • the item due description package can contain information that can characterize texts associated with a settlement of a business transaction.
  • the delivery information package can chaiacterize deliver ⁇ ' information associated with a business transaction.
  • Requesting a generation of a loan contract can be implemented by using a first application executing in a landscape of computer systems providing message-based services to generate un electronic message and initiate transmission of the message to a second application to generate a loan contract or a request associated therewith.
  • the generated message includes a loan contract package.
  • the loan contract package contains a loan contract entity characterizing information required to generate a loan contract, llie-loan ( contract package also includes a party package containing information characterizing parties to a loan contract.
  • the loan contract package also contains a product information package containing information characterizing a product upon which a loan contract is based.
  • the loan contract package also contains a payment information package containing information characterizing information associated with payment processing.
  • the loan contract package further contains an item package containing information characterizing conditions of a loan contract.
  • the party package can contain a lender party entity characterizing a party that grants a loan.
  • the party package can also contain a borrower party entity characterizing a party that is issued a loan.
  • the party package can also contain a payer party entity characterizing a party responsible for repayment of a loan.
  • the party package can also contain a broker party entity characterizing an agent for issuance of a loan.
  • the party package can further contain a bailsman party entity characterizing a party responsible for guaranteeing a loan.
  • the product information package can further contain a product category entity characterizing a product category of a loan.
  • the product information package can further contain a product entity.
  • the payment information package can further contain a payment form entity characterizing a form of payment.
  • the product information package can further contain a bank account entity characterizing a bank account.
  • the loan contract package can further contain a loan contract attachment package containing information characterizing documents relevant for a loan.
  • the loan contract package can also contain a loan contract item package.
  • the loan contract item package can contain a loan condition information entity characterizing terms and conditions of a loan.
  • the loan can contain a loan interest condition entity characterizing an interest condition for a loan.
  • the loan can also contain a loan amortizement condition entity characterizing a repayment condition for a loan.
  • the loan can further contain a loan fee condition entity characterizing a fee condition for a loan.
  • the a loan contract item package can further contain a loan contract item party package containing information characterizing all parties to a loan contract.
  • Requesting a generation of a loan contract can be accomplished by receiving an electronic message and initiating generation of a loan contract in a landscape of computer ' systems providing message-based services.
  • the received message includes a loan contract package.
  • the loan contract package contains a loan contract entity characterizing information required to generate a loan contract.
  • the loan contract package can also contain a party package containing information characterizing parties to a loan contracl.
  • the loan contract package can also contain a product information package containing information characterizing a product upon which a loan contract is based.
  • the loan contract package can also contain a payment information package containing information characterizing information associated with payment processing.
  • the loan contract package can further contain an item package containing information characterizing conditions of a loan contract.
  • Generating a confirmation of a creation of a loan contract can be accomplished by using a first application executing in a landscape of computer systems providing message- based services to generate an electronic message and initiating transmission of the message to a second application to generate a confirmation of a creation of a loan contract.
  • the generated message includes a loan contract package.
  • the loan contract package contains a loan contract entity characterizing information regarding a creation of a loan contract.
  • the loan contract package also contains a log package containing information characterizing log messages associated with a creation of al loan contract.
  • the loan contract package further contains a payment information package, and the payment info ⁇ nation package contains a bank account entity characterizing information about a bank account to be used to repay a loan.
  • Generating a confirmation of a creation of a loan contract can be accomplished by receiving an electronic message in a landscape of computer systems providing message- based services and initiating a generation of a confirmation of a creation of a loan contract.
  • the received message includes a loan contract package.
  • the loan contract package includes a loan contract entity characterizing information regarding a creation of a loan contract.
  • the loan contract package can also include a log package containing information characterizing log messages associated with a creation of al loan contract.
  • the loan contract package can further include a payment info ⁇ nation package, and the payment info ⁇ nation package contains a bank account entity characterizing information about a bank account to be used to repay a loan.
  • a notice ⁇ elating to product activities for a vendor can be created by generating an electronic message characterizing activities associated with goods of a buyer and initiating transmission of the message to an application to generate a notice to a vendor relating to ' product activities.
  • generating a notice from a buyer to a , vendor relating to product activities can include receiving an electronic message characterizing activities associated with goods of a buyer and initiating a generation of a notice to a vendor relating to product activities.
  • An electronic message can characterize product activities by including a package that characterizes activities associated with goods of a buyer at a ship to location and a package containing an entity package characterizing activities associated with goods of a buyer at a ship to location.
  • Those packages can be a product activity package and item package, respectively, and the entity can be an item entity.
  • the location package can contain a ship to location entity characterizing a location to which goods are to be delivered and the item package can include a product information package characterizing goods to be delivered.
  • the product activity message can further contain a party package that contains a buyer party entity characterizing a party that purchases goods, a vendor party entity characterizing a party that delivers goods, and a product recipient party entity characterizing a party that receives a delivery of goods.
  • the party package can further contain a business transaction document reference package containing information characterizing references to business documents associated with a product activity notice, and the location package can further contain a ship from location entity characterizing a location from which goods are to be shipped for delivery.
  • the item package can further contain an inventory package containing an inventory entity characterizing stock of a good at a buyer and a consignment inventory entity characterizing goods in possession of a buyer that are owned by a vendor until purchased.
  • An electronic message requesting to generate a notice of an event affecting product demand can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate a notice of an event affecting product demand. Responding to the request to generate a notice of an event affecting product demand can include receiving a message including product demand influencing event package and initiating a generation of a notice of an event affecting product demand.
  • a product demand influencing event package can contain a product demand influencing event entity, a party package and an item package. The product demand influencing event entity can characterize a product demand influencing event.
  • the party package can contain d buyer party entity and a vendor party entity. The buyer party entity can characterize a party that purchases goods.
  • the vendor party eniity can characterize a party that delis ⁇ ers goods.
  • the item package can contain an item entity, a location package and a product information package.
  • the item entity can characterize activities associated with goods of a buyer at a ship to location.
  • the location package can contain a ship to location entity.
  • the ship io location entity can characterize a location to which goods are to be delivered.
  • the product information package can contain information that can characterize goods to be delivered.
  • the product demand influencing event package can further contain a scheduling package.
  • the scheduling package can contain information that can characterize time orders utilized to define a schedule for logistics associated with goods affected by a product demand influencing event.
  • the location package can further contain a ship from location entity.
  • the ship from location entity can characterize a location from which goods are to be shipped for delivery.
  • the item package can further contain a product information package.
  • the product information package can contain information that can characterize goods affected by a product demand influencing event.
  • An electronic message requesting to generate information associated with a purchase order can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate information associated with a purchase order. Responding to the request to generate information associated with a purchase order can include receiving a message including purchase order package and initiating generation of information associated with a purchase order.
  • the purchase order package can contain a purchase order entity, a purchase order party package, a purchase order location package, a purchase order delivery information package, a purchase order payment information package, a price order price information package, a purchase order attachment package, a purchase order description package, a purchase order follow up message package and a purchase order item package.
  • the purchase order entity can characterize a request by a buyer to a seller to provide certain quantities of products or services.
  • the purchase order party package can contain information characterizing parties to a purchase order.
  • the purchase older location package can contain information characterizing locations associated with n purchase oider.
  • the purchase order delivery information package can contain information characterizing a delivery of goods associated with a purchase order.
  • the purchase order payment informaiion package can contain information characterizing payment terms associated with a purchase order.
  • the price order price information package can contain pricing information associated with a purchase order.
  • the purchase order attachment package can contain information characterizing attachments relevant to a purchase order.
  • the purchase order description package can contain information characterizing texts associated with a purchase order.
  • the purchase order follow up message package can contain information characterizing messages associated with a purchase order and occurring subsequent to an issuance of such purchase order.
  • the purchase order item package can contain information characterizing an item associated with a purchase otder.
  • the purchase order party package can further contain a buyer party entity, a seller party entity, a product recipient party entity, a vendor party entity, a manufacturer party entity, a bill to party entity, a payer party entity find a carrier party entity.
  • the buyer party entity can characterize a party that buys goods or services.
  • the seller party entity can characterize a party that sells goods or services.
  • the product recipient party entity can characterize a party to which goods are to be delivered or to whom services are to be provided.
  • the vendor party entity can characterize a party that delivers
  • the manufacturer party entity can characterize a party that manufactures goods.
  • the bill to party entity can characterize a party to which an invoice for goods or sendees is sent.
  • the payer party entity can characterize a party that pays for goods or services.
  • the carrier party entity can characterize a party that transports goods.
  • the purchase order location package can further contain a ship to location entity and a ship from location entity.
  • the ship to location entity can characterize a location to which goods are to be delivered or where services are to be provided.
  • the ship from location entity can characterize a location from where goods are to be shipped.
  • the purchase order payment information package can further contain a cash discount terms entity, a payment form entity and a payment card entity.
  • the cash discount terms entity can characterize te ⁇ ns of payment in an ordering process.
  • the payment form entity can characterize a payment form and associated payment information.
  • the payment card entity can characterize a credit card or a customer payment card.
  • the purchase order description package can further contain a description entity and a confirmation description entity.
  • the description entity can characterize text associated with a purchase order.
  • the confirmation description entity can characterize text associated with an order confirmation.
  • the follow up message package can further contain a follow up purchase confirmation entity, a follow up dispatched delivery notification entity and a follow up service acknowledgement request entity.
  • the follow up purchase confirmation entity can characterize information associated with a confirmation to be received by a buyer from a seller in connection with a purchase order.
  • the follow up dispatched delivery notification entity can characterize notification preferences of a buyer relating to outbound deliveries by a seller.
  • the follow up service acknowledgement request entity can characterize notification preferences of a buyer relating to services provided by a seller.
  • the purchase order item package can further contain a purchase order item entity, a hierarchy relationship entity, a product information package, a price information package, a purchase order item party package, a purchase order location package, a purchase order item delivery information package, a purchase order item business transaction document reference package, a purchase order item attachment package, a purchase order item description package and a schedule line package.
  • the purchase order item entity can characterize a product ordered in a purchase order.
  • the hierarchy relationship entity can characterize a hierarchical relationship between items.
  • the product information package can contain a product entity and a product category entity.
  • the product entity can characterize a commercial description of a product.
  • the product category entity can characterize a commercial categorization of a product.
  • the price information package can contain a price entity, a confirmed price entity, an item buyer party entity, an item seller party entity, an item product recipient party entity, an item vendor party entity, an item manufacturer party entity, an item bill to party entity, an item payer party entity, an item carrier party entity, a ship to location entity and a ship from location entity.
  • the price entity can characterize a purchase order price specified by a buyer.
  • the confirmed price entity can characterize a purchase order price specified by a seller.
  • the purchase order item party package can contain an item buyer party entity can characterize a party that buys goods or services.
  • the item seller party entity can characterize a party that sells goods or services.
  • the item product recipient party entity can characterize a party to which goods are to be delivered or to whom services are to be provided.
  • the item vendor party entity can characterize a party that delivers goods or services.
  • the item manufacturer party entity can characterize a paity that manufactures goods.
  • the item bill to party entity can characterize a party to which an invoice for goods or pervices is sent.
  • the item payer party entity can characterize a party that pays for goods or services.
  • the item carrier party entity can chaiacterize a party that transports goods
  • the purchase order location package can contain a ship to location entity and a ship from location entity.
  • the ship to location entity can characterize a location to which goods are to be deliveied or where services are to be provided.
  • the ship from location entity can characterize a location from where goods are to be shipped.
  • the promischase ordei item delivery information package can contain information characterizing a delivery of goods associated with a purchase order.
  • the purchase order item business transaction document reference package can contain a quote reference entity, a purchase contract reference entity, a sales contract reference entity, an origin purchase order reference entity, a buyer product catalogue reference entity and a seller product catalogue reference entity.
  • the quote reference entity can characterize a reference to a quotation or an item within a quotation.
  • the purchase contract reference entity can chaiacterize a purchase contract or an item in a purchase contract.
  • the sales contract reference entity can characterize a sales contract or an item in a sales contract.
  • the origin purchase order reference entity can characterize an origin purchase order to an item within an origin purchase order.
  • the buyer product catalogue reference entity can characterize a product catalogue of a buyer or an item within such catalogue.
  • the seller product catalogue reference entity can characterize a product catalogue of a seller or an item within such catalogue.
  • the purchase order item attachment package can contain information characterizing attachments relevant to a purchase order.
  • the purchase order item description package can contain a description entity and a confirmation description entity.
  • the description entity can characterize texts associated with a purchase order item.
  • the confirmation description entity can characterize texts regarding a purchase order item confirmation.
  • the schedule line package can contain a schedule line entity and a confirmed schedule line entity.
  • the schedule line entity can characterize a line containing a quantity and date of a performance schedule required by a buyer for a purchase order.
  • the confirmed schedule line entity can characterize a quantity and date of a confirmed by a seller
  • An electronic message can be generated that characterizes a status of a purchase order and transmission of this message can be initiated so that such status information can be created.
  • an electronic message can be received that can be used to subsequently create status information for a purchase order.
  • the message can include a purchase order package that contains one or more of a purchase order information package containing one or more of a purchase order information entity characterizing a request by a buyer to a seller to provide certain quantities of products or services, a purchase order information party package containing information characterizing parties to a purchase order, a purchase order information location package containing infb ⁇ nation characterizing locations associated with a purchase order, a purchase order information payment information package containing information characterizing payment information associated with a purchase order, a price order price information package containing pricing information associated with a purchase order, a purchase order information attachment package containing information characterizing attachments relevant to a purchase order, a purchase order infonnation description package containing information characterizing texts associated with a purchase order, a purchase order infonnation follow up message package containing information characterizing, and a purchase order information item package containing information characterizing an item.
  • the purchase oider information party package can further contain one or more of a buyer party entity characterizing a party that buys goods or services, a seller party entity characterizing a party that sells goods or services, a product recipient party entity characterizing a party to which goods are to be delivered or to whom services are to be provided, a vendor party entity characterizing a party that delivers goods or services, a manufacturer party entity characterizing a party that manufactures goods, a bill to party entity characterizing a party to which an invoice for goods or services is sent, a payer party entity characterizing a party that pays for goods or services, and a carrier party entity characterizing a party that transports goods.
  • a buyer party entity characterizing a party that buys goods or services
  • a seller party entity characterizing a party that sells goods or services
  • a product recipient party entity characterizing a party to which goods are to be delivered or to whom services are to be provided
  • a vendor party entity characterizing a party that delivers goods or services
  • a manufacturer party entity characterizing
  • the purchase order information location package further can also contain one or both of a ship to location entity characterizing a location to which goods are to be delivered or where services are to be provided and a ship from location entity characterizing a location from where goods are to be shipped.
  • the 5 purchase order information payment information package can additionally contain one or more of a cash discount terms entity characterizing terms of payment in an ordering process, a payment form entity characterizing a payment form and associated payment information, and a payment card entity characterizing a credit card or a customer payment card.
  • the purchase order information description package can further contain one or both of a
  • the follow up message package can include one or more of a follow up purchase confirmation entity characterizing information associated with a confirmation to be received by a buyer from a seller in connection with a purchase order, a follow up dispatched deliver ⁇ ' notification t : " entity characterizing notification preferences of a buyer relating to outbound deliveries by a s ⁇ ller, a follow up service acknowledgement request entity characterizing notification preferences of a buyer relating to services provided by a seller, and a follow up invoice request entity characterizing whether a buyer expects to receive an invoice from a seller.
  • the purchase order information item package can include one or more of a purchase 0 order information item entity characterizing a product ordered in a purchase order, a hierarchy relationship entity characterizing a hierarchical relationship between items, a product info ⁇ nation package, a price information package, a purchase order information item party package, a purchase order information location package, a purchase order information item delivery info ⁇ nation package containing information characterizing a 5 deliver)' of goods associated with a purchase order, a promis chase order information item business transaction document reference package, a purchase order info ⁇ nation item attachment package containing information characterizing attachments relevant to a purchase order, a purchase order information item description package containing a description entity characterizing texts associated with a purchase order item, and a 0 confirmation description entity characterizing texts regarding a purchase order item confirmation.
  • a purchase 0 order information item entity characterizing a product ordered in a purchase order
  • a hierarchy relationship entity characterizing a hierarchical relationship between items
  • a product info ⁇ nation package a price information package
  • the product information package can contain one or both of a product entity characterizing a commercial description of a product, and a product category characterizing a commercial categorization of a product.
  • the price information package can contain one or more of a price entity characterizing a purchase order price specified by a buyer, a confirmed price entity characterizing a purchase order price specified by a seller, and a procurement cost upper limit entity characterizing a cost upper limit for one or more types of procurement costs.
  • the purchase order information item party package can contain one or more of an item buyer party entity characterizing a party that buys goods or services, an item seller party entity characterizing a party that sells goods or services, an item product recipient party entity characterizing a party to which goods are to be delivered or to whom services are to be provided, an item vendor party entity characterizing a party that delivers goods or services, an item manufacturer party entity characterizing a party that manufactures goods, an item bill to party entity characterizing a party to which an invoice for goods or services is sent, an item payer party entity characterizing a party that pays for goods or services, and an item carrier party entity characterizing a party that transports goods.
  • the purchase order information location package can contain one or both of a ship to location entity characterizing a location to which goods are to be delivered or where services are to be provided, and a ship from location entity characterizing a location from where goods are to be shipped.
  • the purchase order information item business n-ansaction document reference package can contain one or more of a quote reference entity characterizing a reference to a quotation or an item within a quotation, a purchase contract reference entity characterizing a purchase contract or an item in a purchase contract, a sales contract reference entity characterizing a sales contract or an item in a sales contract, an origin purchase order reference entity characterizing an origin purchase order to an item within an origin purchase order, a buyer product catalogue reference entity characterizing a product catalogue of a buyer or an item within such catalogue, and a seller product catalogue reference entity characterizing a product catalogue of a seller or an item within such catalogue.
  • Generating a request querying a buyer to procure products or services can be accomplished by using a first application executing in a landscape of computer systems providing message-based services to generate an electronic message and initiate transmission of the message to a second application.
  • the generated message includes a purchase request package.
  • the purchase request package contains a purchase request entity characterizing requisition requirements.
  • the purchase request package further contains a purchase request item package, and the purchase request item package contains a schedule line package containing information characterizing quantity and date information associated with a requisition.
  • the purchase request party package can further contain a buyer party entity characterizing a party that buys goods or services.
  • the purchase request party package can also contain a seller party entity characterizing a party that sells goods or services,
  • the purchase request party package can also contain a proposed seller party entity characterizing a preferred party for selling goods or services.
  • the purchase request party package can also contain a requestor party entity characterizing a party that requests procurement of goods or services.
  • the purchase request party package can also contain a product recipient party entity characterizing a part ⁇ ' to which goods are to be delivered or to whom services are to be provided.
  • the purchase request party package can further contain a manufacturer party entity characterizing a party that manufactures goods.
  • the generated message can further contain a purchase request location package grouping information associated with locations relevant for a requisition.
  • the purchase request location package includes a ship to location entity characterizing a location to which goods are to be delivered or where sendees are to be provided.
  • the purchase request location package al?o includes a ship from location entity characterizing a location, from where goods are to be shipped.
  • the purchase request item package can further contain a purchase request entity characterizing a requested product.
  • the purchase request item package can also contain a hierarchy relationship entity characterizing relationship between items in an item hierarchy.
  • the purchase request item package can also contain a product information package containing a product entity characterizing a product and a product category entity characterizing a product category.
  • the purchase request item package can also contain a price information package containing a price entity characterizing a specified purchase order price, and a procurement cost upper limit entity characterizing upper procurement limits.
  • the purchase request item package can also contain an item party package containing information characterizing parties to a requisition.
  • the purchase request item package can also contain a location package containing information characterizing location information associated with a requisition.
  • the purchase request item package can also contain an object reference package containing information characterizing business documents relevant for a requisition.
  • the object reference package contains a purchase contract reference entity characterizing a purchase contract or an item in a purchase contract.
  • the object reference package also contains a purchase order reference entity characterizing a purchase order or an item in a purchase order.
  • the object reference package also contains a project reference entity characterizing a project or an element within a project associated with a requisition.
  • the object reference package further contains a project element assignment entity characterizing an assignment between two elements of a project associated with a requisition.
  • the purchase request item package can also contain an accounting object set assignment package containing information characterizing accounting information associated with a requisition.
  • the purchase request item package can also contain an attachment package containing information characterizing attachments relevant to a requisition.
  • the purchase request item package can further contain a description package containing information characterizing texts relating to a requisition.
  • the schedule line package can further contain a schedule line entity characterizing quantity and dates of a performance period associated with a requisition.
  • the schedule line package can also contain a deliver ⁇ ' period entity characterizing a delivery period for a requisition.
  • the schedule line package can further contain a quantity entity characterizing a quantity specified by a requisition.
  • Generating a request querying a buyer to procure products or services can be accomplished by receiving an electronic message in a landscape of computer systems providing message-based services and initiating a generation of a request querying a buyer to procure products or services.
  • the received message includes a purchase request package.
  • the purchase request package contains a purchase request entity characterizing requisition requirements.
  • the purchase request package also contains a purchase request item package containing a schedule line package containing information characterizing quantity and date information associated with a requisition.
  • Generating a confirmation of a fulfillment of a requisition can be accomplished by using a first application executing in a landscape of computer systems providing message- based services to generate an electronic message and initiate transmission of the message to a second application.
  • the generated message includes a purchase request package containing a purchase request entity characterizing a confirmation of requirements associated ⁇ vith a procurement of products or services.
  • the purchase request package also contains an item package containing an item entity characterizing a product and a purchase order package containing information characterizing a level of fulfillment of a requirement by a purchase order.
  • Generating a confirmation of a fulfillment of a requisition can be accomplished by receiving an electronic message in a landscape of computer systems providing message- based services and initiating a generation of a confirmation of a fulfillment of a requisition.
  • the received message includes a purchase request package containing a purchase request entity characterizes a confirmation of requirements associated with a procurement of products or services.
  • the purchase request further includes an item package containing an item entity characterizing a product, and a purchase order package containing information characterizing a level of fulfillment of a requirement by a purchase order.
  • An electronic message to generate purchasing contract information can be generated by a first application that executes in a landscape of computer systems providing message- based services. Transmission of the message to a second application can be initiated in order to generate purchasing contract information.
  • the message can include a purchasing contract package.
  • the purchasing contract package can contain one or more of a purchasing contract entity characterizing an agreement to order products or provide services within a certain period of time, a purchasing contract party package containing information characterizing parties to a purchasing contract parties to a purchasing contract, a purchasing contract location package containing information characterizing locations associated with a purchasing contract, a purchasing contract delivery information package containing information characterizing a.
  • a purchasing cort payment information package containing information chaiacterizing payment terms for a purchasing contract
  • a purchasing contract price information package containing information characterizing pricing of goods or services identified in a purchasing contract
  • a purchasing contract attachment package containing info ⁇ nation characterizing documents referring to a purchasing contract
  • a purchasing contract description package containing information characterizing texts associated with a purchasing contract
  • a purchasing contract item package containing information characterizing a product or service in a purchasing contract.
  • the purchasing contract part ⁇ ' package can include one or more of a buyer party entity characterizing a party that buys goods or services, a seller party entity characterizing a party that sells goods or services, a product recipient party entity characterizing a party to which goods are to be delivered or to whom services are to be provided, and a contract release authorized party entity characterizing a party that is authorized to effect releases from a purchasing contract.
  • the purchasing contract attachment package can also contain one or more of an attachment web address entity characterizing a location of documents referring to a purchasing contract, an internal attachment web address entity characterizing a location of internal documents referring to a purchasing contract, and a legal document attachment entity characterizing legal text of a purchasing contract.
  • the purchasing contract description package can include one or more of a description entity characterizing text associated with a purchasing contract, and an internal description entity characterizing internal text associated with a purchasing contract.
  • the purchasing contract item package can contain one or more of a purchasing contract item entity characterizing a product or service in a purchasing contract, a purchasing contract item product information package, a purchasing contract item price information package containing information characterizing pricing of goods or services identified in a purchasing contract, a purchasing contract item location package containing information characterizing locations associated with a purchasing contract, a purchasing contract item party package containing information characterizing parties to a purchasing contract parties to a purchasing contract, a purchasing contract item delivery information package containing information characterizing a delivery requested in a purchasing contract, a purchasing contract business document object reference package, a purchasing contract item attachment package containing information characterizing documents referring to a purchasing contract, and a purchasing contract item description package containing information characterizing texts associated with a purchasing contract.
  • the purchasing contract item product information package can contain one or both of a product entity characterizing a product or service, and a product category entity characterizing a category foi a product or service.
  • the purchasing contract business document object reference package can contain one or more of a quote reference entity characterizing a bid of a purchaser or a bid to an item withm a bid of a purchaser, an operational purchasing contract reference entity characterizing an operational purchasing contract or an item in an operational purchasing contract, and a buyer product catalogue reference entity characterizing a product catalogue of a purchaser or to an item within such a catalogue.
  • An electronic message to generate a notification of a purchasing contract release can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate a notification of a purchasing contract release.
  • the message can contain a purchasing contract release package can contain one or more of a purchasing contract release entity characterizing a notification regarding a performed release with reference to a purchasing contract, a purchasing contract release party package containing information characterizing a release of a purchasing contract, a purchasing contract release location package containing information characterizing locations associated with a release of a purchasing contract, and a purchasing contract release item package.
  • the purchasing contract release item can include one or more of a purchasing contract release item entity characterizing an item in a purchasing contract release, a purchasing contract release item location package containing information characterizing locations associated with a contract release item, and a purchasing contract release item business document object package containing information characterizing references to business documents relevant to an item in a purchasing contract release.
  • An electronic message to generate replenishment order information can be generated by a first application that executes in a landscape of computer systems providing message- based services. Transmission of the message to a second application can be initiated in order to generate replenishment order information.
  • the electronic message can include a replenishment order package containing a replenishment order entity characterizing a replenishment order executed by a vendor for a customer, and a replenishment order item package.
  • the replenishment order item package can contain a replenishment order item entity characterizing an item in a replenishment order, a replenishment order item location package that contains a ship from location entity characterizing a location from which products listed in a replenishment order are to.be, delivered and a ship to location entity characterizing a location from which products listed in a replenishment order are to be delivered.
  • the replenishment order item package can also include a replenislunent order item product information package containing information characterizing a product associated with a replenishment order.
  • the replenishment order package can contain one or more of a replenishment order party package, a replenishment order delivery information package containing information characterizing a requested delivery for a replenishment order, a replenishment order payment information package containing information characterizing payment information for a replenishment order, and a replenishment order handling unit package containing information characterizing packing requirements for product associated with a replenishment order.
  • the replenishment order party package can include one or more of a buyer party entity characterizing a party that purchases goods associated with a replenishment order, a seller party entity characterizing a party that sells goods associated with a replenishment oider, and a vendor party entity characterizing a part ⁇ ' to provide a replenishment delivery.
  • the replenishment order location package can further contain a trans-shipment location entity characterizing a location at product in a replenishment order is transferred from a first transportation mechanism to a second transportation mechanism.
  • the replenishment order item package can contain one or more of a business transaction documents reference package, a replenishment order item party package, a replenishment order item product information package containing information characterizing a product listed in a replenishment order, a replenishment order item batch package containing information characterizing a batch to be delivered, a replenishment order item promotion package containing information characterizing marketing promotions associated with a replenishment order, a replenishment order item price information package containing pricing information of an item in a replenishment order, and a replenishment order item schedule line package.
  • the business transaction documents reference package can contain on or more of o purchase contract reference entity characterizing a purchase contract or an item in a purchase contract, a scheduling agreement reference entity characterizing a scheduling agreement or an item in a scheduling agreement, a purchase order reference entity characterizing a purchase order of a buyer or a purchase order item created by a vendor, an origin purchase order reference entity characterizing an original purchase order or to an item within an original purchase order, a sales order reference entity characterizing a sales order or an item in a sales order, and an origin sales order reference entity chaiacterizing an original sales order or an item within an original sales order.
  • the replenishment order item party package can contain one or more of a replenishment order item buyer party entity characterizing a panty that purchases goods associated with a replenishment oidei, a replenishment order item product recipient party entity characterizing a party to receive goods associated with a replenishment order, and a replenishment order item bill to party entity characterizing a party to receive an invoice associated with a replenishment order.
  • the replenishment order item schedule line package can contain one or both of a schedule line entity characterizing quantity and scheduling associated with a replenishment order, and a confirmed schedule line entity characterizing a confirmation of quantity and scheduling associated with a replenishment order.
  • An electronic message to generate replenishment order proposal information can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate replenishment order proposal information.
  • the message can include a replenishment order proposal package can contain a replenishment order proposal entity characterizing a proposal for an order to replenish product supply and a replenishment order proposal item package.
  • the replenishment order proposal item package can contain a replenishment order proposal item entity characterizing an item in a replenishment order proposal, a replenishment order proposal item location package, and a replenishment order proposal item product information package containing information characterizing a product associated with a replenishment order proposal.
  • the replenishment order proposal location package can contain a ship from location entity characterizing a location from which products listed in a replenishment order proposal are to be delivered and a ship to location entity characterizing a location from which products listed in a replenishment order proposal are to be delivered.
  • the replenishment order proposal package can contain one or both of a replenishment order proposal party package and a replenishment order proposal business document object reference package containing information characterizing business documents relating to a replenishment order.
  • the replenishment order proposal party package can contain one or more of a buyer party entity characterizing a party that buys • goods associated with a replenishment order, a vendor party entity characterizing a party that delivers goods associated with a replenishment order, and a product recipient party ' entity characterising a party to which goods associated with a replenishment order*are • delivered.
  • the product information package can contain out or both of a product category entity characterizing a category of a product associated with a replenishment order proposal, and a vendor product category en ⁇ ty characterizing a vendor categoiy of a product associated with a replenishment order proposal.
  • the replenishment order proposal item package can contain one or more of a replenishment order proposal item price informaiion package containing information characterizing pricing of a product associated with a proposed replenishment order, a replenishment order proposal item party package containing info ⁇ nation characterizing parties associated with a proposed replenishment order a replenishment order proposal item location package, a replenishment order proposal item business document object reference package containing information characterizing business documents relating to a replenishment order, and a schedule line package.
  • the replenishment order proposal item location package can contain one or both of a ship from location entity characterizing a location from which products listed in a replenishment order proposal are to be delivered, and a ship to location entity characterizing a location from which products listed in a replenishment order proposal are to be delivered.
  • the schedule line package can contain one or both of a schedule line entity characterizing quantity and scheduling associated with a replenishment order proposal, and a confirmed schedule line entity characterizing a confirmation of quantity and scheduling associated with a replenishment order proposal.
  • Generating a notification associated with a return delivery is accomplished by using a first application executing in a landscape of computer systems providing message-based services to generate an electronic message and initiating transmission of the message to a second application to generate a notification associated with a return delivery.
  • the 5 generated message includes a return delivery instruction package.
  • the included return delivery instruction package further contains a return delivery instruction entity characterizing logistical instructions to a vendor for a future return delivery and a return delivery instruction item package containing a product information package containing information character
  • the return delivery instruction package can further include a party package and a location package.
  • a party package can contain a buyer party entity characterizing a party that has purchased goods being returned or has reordered a repurchase of goods.
  • a party package can also contain a vendor entity characterizing a party that sends backs goods to be returned.
  • a party package can further contain a product recipient entity characterizing a
  • a location package can contains a ship to entity characterizing a location from which goods for return are sent back and ; ⁇ ship to location characterizing a location to which goods for return are sent back.
  • the return delivery instruction package can further include a return delivery item package and a delivery handling unit package.
  • a return delivery item package can contain a 0 return delivery instruction item entity characterizing a quantity of product to be returned and an associated delivery period.
  • a return delivery item package can also contain a deliveiy item business transaction document reference package characterizing business document references relevant to a product to be returned
  • a return delivery item package can also contain a party package containing information characterizing business partners relevant to 5 a product to be returned.
  • a return deliver)' item package can further contain a batch package containing information characterizing a batch of product to be returned. Tn addition, a delivery handling unit package containing information characterizing handling requirements for a product to be returned.
  • Generating a notification associated with a return delivery can be accomplished by 0 receiving an electronic message in a landscape of computer systems providing message- based services and initiating a generation of a notification associated with a return delivery.
  • the message includes a return delivery instruction package.
  • the return delivery instruction package further includes a return deliver ⁇ 1 instruction entity characterizing logistical instructions to a vendor for a future return delivery, and a return delivery instruction item package containing a product information package containing information characterizing.
  • Exchanging information associated with a request for quotation is accomplished by using a first application executing in a landscape of computer systems providing message- 5 based services to generate an electronic message and initiate transmission of the message to a second application.
  • Exchanging information associated with a request for quotation is accomplished by receiving an electronic message in a landscape of computer systems providing message- based services and initiating an exchange of information associated with a request for 10 quotation.
  • the generated and received message includes a package that contains various other packages that contain information associated with a request for quotation.
  • the package contains a party package, a location package, a delivery information package, a payment information package, a product information package, a business transaction document . i :> reference package, a follow up business transaction document reference package, an attachment package, a description package, and an item package.
  • Each of the information containing packages contain different information associated with a request for quotation.
  • a party package contains information characterizing parlies associated with a request for quotation.
  • a location package contains 0 information characterizing locations associated with a request foi quotation.
  • a delivery information package contains information characterizing a required delivery associated with a request for quotation.
  • a payment information package contains information characterizing payment information associated with a request for quotation.
  • a product information package contains information characterizing a product category associated with 5 a request for quotation.
  • a business transaction document reference package contains information characterizing business document references associated with a request for quotation.
  • a follow up business transaction document reference package contains information characterizing business transaction documents expected by a buying party associated with a request for quotation.
  • An attachment package contains information 0 characterizing documents refeiring to a request for quotation.
  • a description package contains information characterizing text visible to parties to a request for quotation.
  • An item package also contains various information containing packages including a product info ⁇ nation package, a party package, a delivery information package, a business transaction document reference package, an attachment package, a description package, and a schedule line package.
  • a product information package contains information characterizing a product tendered by a request for quotation.
  • a party package contains information characterizing parties associated with a request for quotation.
  • a delivery info ⁇ nation package contains information characterizing delivery of a product.
  • a business transaction document reference package contains information characterizing a required delivery associated with a request for quotation.
  • An attachment package contains information characterizing documents referring to a request for quotation.
  • a description package contains info ⁇ nation characterizing text visible to parties to a request for quotation.
  • a schedule line package contains information characterizing quantity and date info ⁇ nation associated with a request for quotation.
  • the info ⁇ nation contained in the various packages is selected from a group including a request from a buyer to a bidder to start a request for quotation process, a request from a buyer to a bidder to modify a request for quotation during a request for quotation process, a cancellation of a request for quotation, a notification from a bidder to a buyer containing a response by the bidder to an invitation to respond to a request for quotation, a notification of an acceptance of a bid in response to a request for quotation, a
  • Exchanging information associated with seivices that have been entered can be accomplished by using a first application executing in a landscape of computer systems providing message-based services i.o generate an electronic message and initiate transmission of the message to a second application.
  • the generated message includes a ⁇ service acknowledgement package.
  • the service acknowledgement package contains a service acknowledgement entity characterizing information about a confirmation by a purchase of an entered service and a party package.
  • the party package further contains a buyer party entity characterizing a party that purchases goods or services.
  • the party package can further contain a seller party entity characterizing a party selling goods or services.
  • the party package can also contain a product recipient party entity characterizing a party to which goods are delivered or for whom services are provided.
  • the party package can also contain vendor party entity characterizing a party that delivers goods or provides services.
  • the party package can further contain a manufacturer party entity characterizing a party that manufactures goods.
  • the service acknowledgement package can further contain a location package containing information characterizing a location at which products have been delivered or a service provided.
  • the service acknowledgement package can also contain an attachment package containing information characterizing a document referring to a service acknowledgement.
  • the service acknowledgement package can also contain a description package containing information characterizing text regarding a service acknowledgement.
  • the service acknowledgement package can further contain an item package.
  • the item package can contain an item entity characterizing an entered service or service product.
  • the item package can also contain a hierarchy relationship entity characterizing a relationship between items in a hierarchy and a product information package.
  • the product information package can contain a product entity characterizing a product, and a product category entity characterizing a category for a product.
  • the service acknowledgement package can also contain a price information package containing information characterizing price information for a service acknowledgement item.
  • the service acknowledgement package can also > contain a party package containing information characterizing parties associated with a service acknowledgement.
  • the service acknowledgement package can also contain a location package containing information characterizing a location at which a products have been delivered or services provided.
  • the service acknowledgement package can also contain a business document object reference package.
  • the business document object reference package can contain a purchase order reference entity characterizing a purchase order or an item within a purchase ⁇ order.
  • the business document object reference package can also contain a service acknowledgement reference entity characterizing a previously sent service acknowledgement.
  • the business document object reference package can also contain a purchase contract reference entity characterizing a reference to a purchase contract or an item within a purchase contract.
  • the business document object reference package can also contain a sales contract reference entity characterizing a reference to a sales contract or an item within a sales contract.
  • the business document object reference package can also contain a buyer product catalogue reference entity characterizing a reference to a product catalogue of a buyer or an item within a product catalogue of a buyer.
  • the business document object reference package can further contain a seller product catalogue reference entity characterizing a reference to a product catalogue of a seller or an item within a product catalogue of a seller.
  • the service acknowledgement package can also contain an attachment package containing information characterizing a document referring to a service acknowledgement.
  • the service acknowledgement package can further contain a description package containing information characterizing text regarding a service acknowledgement.
  • the business document object reference package can further contain a project reference entity characterizing a reference to a project or an element within a project.
  • the business document object reference package can further contain a project element assignment entity characterizing an assignment of two elements within a project that is referenced by an item of a service acknowledgment.
  • the item package can further contain an accounting package containing information characterizing account assignment information.
  • Exchanging information associated with services that have been entered can be accomplished by receiving an electronic message in a landscape of computer systems providing message-based services and initiating an exchange of information associated with services that have been entered.
  • the received message includes a service acknowledgement package.
  • the service acknowledgement package includes a service acknowledgement entity characterizing information about a confirmation by a purchase of an entered seivice.
  • the service acknowledgement package further includes a party package, which contains a buyer party entity characterizing a party that purchases goods or services.
  • An electronic message to tequest generation of a supply chain exception notification can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate a supply chain exception notification.
  • the supply chain exception package can contain a supply chain exception report entity, a business transaction document reference package, a location package and a product information package.
  • the supply chain exception report entity can characterize an exception that occurred in a supply chain.
  • the business transaction document reference package can contain a purchaser order entity that can characterize a reference to a purchase order or an item within a purchase order for which an exception in a supply chain has occurred.
  • the location package can contain a ship from location that can characterize a location from which ordered products are delivered.
  • a product information package can characterize a product associated with a supply chain exception.
  • the message requesting generation of a supply chain exception notification can further include a party package containing a buyer party entity, a vendor party entity and a product recipient entity.
  • the buyer party entity can characterize a buyer of goods or services.
  • the vendor party entity can characterize a vendor of goods or 5 services.
  • the product recipient entity can characterize a recipient of goods or services.
  • the business transaction document reference package can further contain a scheduling agreement reference entity, a sales order reference entity, an inbound delivery reference entity and a batch package.
  • the scheduling agreement reference entity can characterize a reference to an item in a scheduling agreement.
  • the sales order reference entity can be
  • the inbound delivery reference entity can characterize an inbound delivery or an item of an inbound delivery.
  • the supply chain exception package can further contain a batch package.
  • the batch package can contain a batch entity, a property valuation package and a log package.
  • the batch entity can characterize a batch of products.
  • the property valuation package can
  • the log package can contain a validation log entity that can characterize a logistic ⁇ planning or logistics execution check log.
  • the log package can also contain an item entity.
  • the location package can further contain a ship to location entity that can characterize a location where ordered products are deliveied.
  • An electronic message to generate a tax declaiation can be generated by ⁇ first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to provide tax declaration information to generate a tax declaration based on a purchase. Responding to a request to generate a tax declaration can include receiving a message
  • a tax declaration package can contain a log package and a party package, where the log package can contain a validation log entity characterizing log messages from a tax authority associated with a receipt and validation of a tax return based on a purchase, and the party package can contain a tax payer party entity that characterizes a party liable for tax on a 0 purchase.
  • the party package can also contain a tax authority party entity that characterizes a tax authority that receives a tax declaration.
  • a log package can also contain an item entity.
  • the item entity can characterize a log of a receipt and validation of a tax refund based on a purchase.
  • the party package can also contain a tax operator entity that characterizes a party that creates and sends a tax return for tax on purchases.
  • a declaration package can also contain an item package that characterizes reported taxes on purchases.
  • An electronic message to create information associated with a vendor initiated purchase order can be generated by a first application that executes in a landscape of computer systems providing message-based services. Transmission of the message to a second application can be initiated in order to generate information associated with a vendor initiated purchase order.
  • the message can include a vendor generated order package containing a vendor generated order entity characterizing a purchaser order that is initiated by a vendor for a customer, a part ⁇ ' package, a location package, and a vendor generated order item package.
  • the party package can contain a buyer party entity characterizing a party to receive a goods replenishment delivery, and a vendor party entity characterizing a party to provide a goods replenishment delivery.
  • the location package can contain a ship from location entity characterizing a location from which goods associated with a purchase order is to be delivered, and a ship to location entity characterizing a location at which goods as ⁇ ociated • with a purchase order is to be delivered.
  • the vendor generated order item package can contain a vendor generated order item entity characterizing quantities of goods and associated delivery and location conditions for goods in a purchase order, and a produce information package containing information characterizing goods associated with a purchase order.
  • the location package can further contain a trans-shipment location entity characterizing a location at which delivery of products using a first transport mechanism changes to second transport mechanism.
  • the vendor generated order package can also 'contain a handling unit containing information characterizing packing requirements for goods associated with a replenishment order.
  • the vendor generated order item package can further contain one or mive of a business transaction document reference package, a promotion package containing information characterizing marketing promotions relevant to goods associated with a purchase order, and a schedule line package.
  • the business transaction document reference package can contain one or both of a purchasing contract reference entity characterizing a purchase contract or an item in a purchase contract and a sales order reference entity characterizing a sales order or an item in a sales order.
  • the schedule line package can contain one or more of a schedule line entity characterizing quantity and scheduling dates for replenishment deliveries of goods associated with a purchase order, and a confirmed schedule line entity characterizing confirmed quantity and scheduling dates for replenishment deliveries of goods associated with a purchase order.
  • Adapters and other proxies can be utilized such that messages or other data structures that are not in a format compatible with the generated and received messages can be utilized in connection with the subject matter described herein.
  • generating the message can include converting or mapping a non-compatible message format or other data structure into a compatible message type prior to its transmission.
  • a received message can be subsequently converted or mapped into a non-compatible message format or other data structure to effect the actions specified by the received message.
  • FIGS. 1A-1F depict problems that may arise without the use of consistent interfaces
  • FIG. 1 depicts a flow diagram of the overall steps performed by methods and systems consistent with the subject matter described herein;
  • FIG. 2 depicts a scenario variant model in accordance with methods and systems consistent with the subject matter described herein
  • FIG. 3 depicts a process interaction model for invoice processing in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 4 depicts a business document flow for an invoice request in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 5 depicts data processing systems suitable for practicing methods and systems consistent with the subject matter described herein;
  • FIG. 6 depicts message categories in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 7 depicts a message choreography for a purchase order scenario in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 8 depicts a message choreography of a Master Data Management in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 9 depicts a message choreography of a Source of Supply, Purchase Requirement, and Purchase Order in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 10 depicts a message choreography of a Product Demand, Product Forecast and Product Activity in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 11 depicts a message choreography of a RFQ and Quote in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 12 depicts a message choreography of Purchasing in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 13 depicts a message choreography of Sales in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 14 depicts a message choreography of a Vendor Managed Inventory /
  • FIG. 15 depicts a message choreography of an Advanced Shipment Notification and Proof of Delivery in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 16 depicts a message choreography of a Service Acknowledgement in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 17 depicts a message choreography of an Inventory Change in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 18 depicts a message choreography of Billing Due in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 19 depicts a message choreography of Invoicing Due in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 20 depicts a message choreography of an Invoice in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 21 depicts a message choreography of Invoice Accounting and Payment Due in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 22 depicts a message choreography of Tax Due in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 23 depicts a message choreography of Credit Worthiness, Credit Agency Report, Credit Payment, and Credit Commitment in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 24 depicts a message choreography of a Personnel Time Sheet in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 25-251 depict data type structures in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 252 depicts an example of a package in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 253 depicts another example of a package in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 254 depicts a third example of a package in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 255 depicts a fourth example of a package in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 256 depicts the representation of a package in the XML schema in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 257 depicts a graphical representation of cardinalities between two entities in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 258 depicts an example of a composition in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 259 depicts an example of a hierarchical relationship in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 260 depicts an example of an aggregating relationship in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 261 depicts an example of an association in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 262 depicts an example of a specialization in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 263 depicts the categories of specializations in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 264 depicts an example of a hierarchy in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 265 depicts a graphical representation of a hierarchy in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 266A-B depict a flow diagram of the steps performed to create a business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 267 A-NN depict the business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 268 depicts the message choreography for the Invoice interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 269A-F depict a flow diagram of the steps performed to generate an interface from the business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 270 A-C depict examples of package templates in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 271 depicts the package template of FIG. 270A after the removal of a package in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 272 depicts an entity template for the party package from the business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 273 depicts the entity template for the party package of FIG. 272 after removal of an entity in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 274 depicts the party package of FIG. 272 after removal of the nonessential entities for the Invoice Request in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 275 depicts a portion of the business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 276 depicts a further portion of the business object model in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 277 depicts the package template of FIG. 270A after the removal of the nonessential packages for the Invoice Request in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 278 depicts package template of FIG. 277 after the "business transaction document" is changed in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 279 A-N depict a data model for Invoice interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 280A-K depict an element structure for Invoice interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 281 depicts an example illustrating the transmittal of a business document in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 282 depicts an interface proxy in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 283 depicts an example illustrating the transmittal of a message using proxies in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 284 depicts components of a message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 285 depicts IDs used in a message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 286 depicts a reference to previous messages in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 287 depicts a reference to business documents from previous transactions in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 288 depicts a message choreography for Purchase Requirement interfaces in accordance with methods and systems consistent with the subject matter described herein
  • FIGS. 289A-H depict a data model for Purchase Requirement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 290A-G depict an element structure for Purchase Requirement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 291 depicts message choreography for a Source of Supply interface in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 292A-C depict a data model for the Source of Supply interface in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 293 A-D depict an element structure for the Source of Supply interface in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 294 depicts a message choreography for Purchase Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 295 A-P depict the data model for the Purchase Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 296 depicts a data mode for the Purchase Order Cancellation interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 297 A-ZA depict an element structure for the Purchase Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 298 depicts a message choreography for Service Acknowledgement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 299 A-J depict a data model for the Service Acknowledgement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 300A-L depict an element structure for the Service Acknowledgement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 301 depicts a message choreography for RFQ interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 302 A-K depict a data model for the RFQ interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 303 depicts a data model for RFQ Cancellation interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 304A-J depict a data model for Quote interfaces in accordance with methods and systems consistent with the subject matter described herein
  • FIGS. 305A-D depict a data model for RFQ Result interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 306A-O depict an element structure for RFQ interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 307A-C depict an element structure for RFQ Cancellation interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 308A-M depict an element structure for Quote interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 309 A-D depict an element structure for RFQ Request interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 310 depicts a message choreography for Order to Invoice in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 311 depicts a message choreography for the Order to Invoice provided by RosettaNet
  • FIG. 312 depicts a message choreography for the Order to Invoice provided by
  • FIGS . 313-317 depict a hierarchization process in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 318-358QG depict additional data type structures in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 359 depicts a message choreography for the Catalogue interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 360 A-F depict a data model for Catalogue Update Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 361 A-AA depict an element structure for the Catalogue Update Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 362 A-F depict a data model for Catalogue Publication Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 363 A-Z depict an element structure for Catalogue Publication Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 364 depicts a data model for Catalogue Publication Transmission Package Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 365A-B depict an element structure for the Catalogue Publication Transmission Package Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 366 depicts a data model for Catalogue Publication Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 367 A-B depict an element structure for the Catalogue Publication Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 368 depicts a data model for Catalogue Publication Transmission Cancellation Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 369A-B depict an element structure for Catalogue Publication Transmission Cancellation Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 370 depicts a data model for Catalogue Publication Transmission Cancellation Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 371 A-B depict an element structure for the Catalogue Publication Transmission Cancellation Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 372 depicts a data model for Catalogue Publication Transmission Item Lock
  • FIGS. 373A-C depict an element structure for the Catalogue Publication Transmission Item Lock Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 374 depicts a data model for Catalogue Publication Transmission Item Lock Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 375 A-B depict an element structure for Catalogue Publication Transmission Item Lock Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 375AA-AB depict a data model for Catalogue Publication Transmission Content Change Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 375BA depicts a data model for Catalogue Publication Transmission Content
  • FIG. 375BB depicts an illustration of a Catalog Content Management system in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 376 depicts a message choreography for the Purchase Order Information interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 377 A-N depict a data model for Purchase Order Information Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 378A-ZA depict an element structure for the Purchase Order Information Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 378 AA-S depict an element structure for Purchase Order Information Legal Document Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 379 depicts a message choreography for Tax Due interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 380A-C depict a data model for Tax Due Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 381A-D depict an element structure for the Tax Due Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 382 depicts a message choreography for Delivery Information interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 383 A-H depict a data model for Delivery Information Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 384A-J depict an element structure for the Delivery Information Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 385 depicts a message choreography for Personnel Timesheet Information interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 386 depicts a data model for Personnel Timesheet Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 387A-C depict an element structure for Personnel Timesheet Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 388 depicts a message choreography for Credit Worthiness interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 389 depicts a data model for Credit Worthiness Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 390 depicts a data model for Credit Worthiness Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 39 IA-B depict an element structure for the Credit Worthiness Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 392 A-C depict an element structure for the Credit Worthiness Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 393 depicts a message choreography for Credit Agency Report interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 394 depicts a data model for Credit Agency Report Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 395A-B depict a data model for Credit Agency Report Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 396 A-C depict an element structure for the Credit Agency Report Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 397 A-E depict an element structure for the Credit Agency Report Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 398 depicts a message choreography for Invoicing Accounting interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 399 depicts a data model for Accounting Cancellation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 400 A-B depict an element structure for Accounting Cancellation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 401 depicts a message choreography for Invoice Due interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 402A-M depict a data model for Invoice Due Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 403 depicts a data model for Invoice Due Cancellation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 404 A- J depict an element structure for the Invoice Due Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 405 depicts a message choreography for Inventory Change interfaces in accordance with methods and systems consistent with the subject matter described herein
  • FIGS. 406A-B depict a data model for Inventory Change Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 407 A-D depict an element structure for the Inventory Change Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 408 depicts a message choreography for Sales Order Fulfillment interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 409A-L depict a data model for Sales Order Fulfillment Message in accordance with methods and systems consistent with the subject matter described herein
  • FIGS. 410A-M depict an element structure for Sales Order Fulfillment Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 411 depicts a message choreography for Delivery interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 412A-C depict a data model for Despatched Delivery Notification Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 413 depicts a data model for Received Delivery Notification Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 414A-G depict an element structure for Despatched Delivery Notification Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 415A-C depict an element structure for Received Delivery Notification Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 416 depicts a message choreography for Invoice Accounting interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 417A-C depict a data model for Invoice Accounting Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 418A-E depict an element structure for Invoice Accounting Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 419 depicts a message choreography for Delivery Execution Request interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 420A-L depict a data model for Delivery Execution Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 421 A-K depict an element structure for the Delivery Execution Request
  • FIG. 422 depicts a message choreography for Delivery Schedule interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 423A-C depict a data model for Delivery Schedule Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 424A- V depict an element structure for the Delivery Schedule Message in accordance with methods and systems consistent with the subject matter described herein; 5 FIGS. 424AA-AU depict an element structure for the Delivery Schedule
  • FIGS 424BA-BJ depict an element structure for the Delivery Schedule Confirmation Message in accordance with methods and systems consistent with the subject matter 10 described herein;
  • FIG. 425 depicts a message choreography for Invoice Issued Information interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 426 depicts a data model for Invoice Issued Message in accordance with 15 methods and systems consistent with the subject matter described herein;
  • FIGS. 427A-B depict an element structure for the Im'oice Issued Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 428 depicts a message choreography for Product Activity interfaces in accordance with methods and systems consistent with the subject matter described herein; 20 .
  • FIG. 429 depicts a data model for Product Activity Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 430A-L depict an element structure for the Product Activity Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 431 depicts a messsage choreography for Payment Due invoices in accordance 2.5 with methods and systems consistent with the subject matter described herein;
  • FIGS. 432A-C depict a data model for Payment Due Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 433A-D depict an element structure for Payment Due Message in accordance with methods and systems consistent with the subject matter described herein; 30 FIG. 434 depicts a message choreography for Order ID Assignment interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 435 depicts a data model for Order ID Assignment Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 436A-E depict an element structure for the Order ID Assignment Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 437 depicts a message choreography for Product Demand Influencing Event interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 438 depicts a data model for ProductDemand Influencing Event Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 439A-L depict an element structure for the ProductDemand Influencing Event Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 440 depicts a message choreography for Product Forecast interfaces in accordance with methods and systems consistent with the subject, matter described herein;
  • FIG. 441 depicts a data model for Product Forecast Notification Message in . accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 442A-J depict an element structure for the Product Forecast Notification
  • FIG. 443 depicts a message choreography for Product Forecast Revision interfaces in accordance with methods and systems consistent with the subject matter described
  • FIG. 444 depicts a data model for Product Forecast Revision Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 445A-M depict an element structure for the Product Forecast Revision Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 446 depicts a message choreography for Replenishment Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 447 A-F depict the data model for Replenishment Order Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 448A-W depict an element structure for the Replenishment Order Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 449 depicts a message choreography for Vendor Generated Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 450 A-B depict the data model for the Vendor Generated Order Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 451A-O depict an element structure for the Vendor Generated Order Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 452 depicts a message choreography for Bank Account Balance interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 453 depicts a data model for Bank Account Balance Report Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 454 depicts a data model for Bank Account Balance Report Response Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 455A-B depict an element structure for the Bank Account Balance Report Response Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 456A-B depict an element structure for the Bank Account Balance Report Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 457 depicts a message choreography for Bank Account Statement interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 458A-E depict the data model for Bank Account Statement Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 459A-I depict an element structure for the Bank Account Statement Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 460 depicts a message choreography for Business Transaction Document Image Recognition Request interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 461 depicts a data model for Business Transaction Document Image Recognition Request in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 462 depicts an element structure for the Business Transaction Document Image Recognition Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 463 depicts a message choreography for Collective Payment Order interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 464 A-F depict the data model for Collective Payment Order in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 465 A-F depict an element structure for the Collective Payment Order Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 466 depicts a message choreography for Credit Payment Behavior Summary interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 467 depicts a data model for Credit Payment Behavior Summary Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 468 A-H depict an element structure for the Credit Payment Behaviour Summary Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 469 depicts a message choreography for Customs Vendor Declaration interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 470 depicts a data model for the Customs Vendor Declaration Message in accordance with methods and systems consistent vvith the subject matter described herein;
  • FIGS. 471 A-G depict an element structure for the Customs Vendor Declaration Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 472 depicts a message choreography for Invoice interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 473A-D depict the data model for Supplier Invoice Information Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 474 depicts a data model for Supplier Invoice Settlement Release Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 475 depicts a data model for Supplier Invoice Cancellation Execution Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 476A-D depict the data model for Invoice Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 477A-J depict an element structure for the Invoice Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 47S depicts a message choreography for Loan Contract interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIG.479 depicts a data model for Loan Calculation Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 480 depicts a data model for Loan Calculation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 481 A-C dep'ct the data model for the Loan Contract in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 482 depicts a data model for Loan Contract Create Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 483 A-E depicts an element structure for Loan Contract Create Request
  • FIGS. 484A-B depicts an element structure for the Loan Calculation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 485A depicts an element structure for the Loan Contract Create Confirmation
  • FIGS. 486A-B depict an element structure for the Loan Calculation Query Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 487 depicts a message choreography for Purchase Request interfaces in accordance with methods and systems consistent wth the subject matter described herein;
  • FIGS. 488A-D depict the data model for Purchase Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 489 depicts a data model for Purchase Request Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 490 A-J depict an element structure for the Purchase Request Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 491 A-B depict an element structure for the Purchase Request Confirmation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 492 depicts a message choreography for Purchasing Contract interfaces in 5 accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 493A-D depict the data model for the Purchasing Contract Use Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 494 depicts a data model for the Purchasing Contract Release Message in accordance with methods and systems consistent with the subject matter described herein; 10 FIGS. 495 A-D depict an element structure for the Purchasing Contract Release
  • FIGS. 496A-J depict an element structure for the Purchasing Contract Message in accordance with methods and systems consistent with the subject matter described herein; 15 FIG. 497 depicts a message choreography for Replenishment Order Proposal interfaces in accordance with methods and systems consistent with the subject matter- described herein;
  • FIGS. 498 A-C depict the data model for Replenishment Order Proposal Message in accordance with methods and systems consisteni with the subject matter described herein; ?.O FIGS. 499A-I depict an element structure for the Replenishment Order Proposal
  • FIGS. 499AA-AM depict an element structure for the Replenishment Order Proposal Confirmation Message in accordance with methods and systems consistent with 25 the subject matter described herein;
  • FiG. 500 depicts a message choreography for Return Deliver ⁇ ' instruction interfaces in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 501A-C depict the data model for the Return Delivery Instruction Message in 30 accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 502A-L depict an element structure for the Return Delivery Instruction Notification in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 503 depicts a message choreography for RFQ Legal Document interfaces in accordance with methods and systems consistent wth the subject matter described herein;
  • FIGS. 504 A-L depict the data model for the RFQ Legal Document Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 505A-M depict an element structure for the RFQ Legal Document Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 506 depicts a message choreography for Supply Chain Exception interfaces in accordance with methods and systems consistent wth the subject matter described herein;
  • FIGS. 507 A-C depict the data model for Supply Chain Exception Report Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 508A-P depict an element structure for the Supply Chain Exception Report Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIG. 509 depicts a message choreography for VATDeclaration interfaces in accordance with methods and systems consistent wth the subject matter described herein;
  • F(G. 510 depicts a data model for VATDecla ration Message in accordance with methods and systems consistent with the subject matter described herein;
  • FIGS. 51 IA-F depict an element ultimatelycture for the VATDeclaiation Message in accordance with methods and systems consistent with the subject matter described herein;
  • FtGS. 512A -E depict an element structure for the VATDeclaration Request Message in accordance with methods and systems consistent with the subject matter described herein; and,
  • FIGS. 513A-D depict an eJeme ⁇ t structure for the VATDeclaration Confirmation Message in accordance with methods and systems consistent with the subject matter described herein.
  • Methods and systems consistent with the subject matter described herein facilitate e- commerce by providing consistent interfaces that are suitable for use across industries, across businesses, and across different departments within a business during a business transaction.
  • a business object model which reflects the data that will be used during a given business transaction.
  • An example of a business transaction is the exchange of purchase orders and order confirmations between a buyer and a seller.
  • the business object model is generated in a hierarchical manner to ensure that the same type of data is represented the same way throughout the business object model. This ensures the consistency of the information in the business object model.
  • Consistency is also reflected in the semantic meaning of the various structural elements. That is, each structural element has a consistent business meaning. For example, the location entity, regardless of in which package it is located, refers to a location.
  • Interfaces provide an entry point for components to access the functionality of an application.
  • the interface for a Purchase Order Request provides an entry point for components to access the functionality of a Purchase Order, in particular, to transmit and/or receive a Purchase Order Request.
  • One. skilled in the art ⁇ vilt recognize that eacli of these interfaces may be provided, sold, distributed, utilized, or marketed as a separate product or as a major component of a separate product Alternatively, a group of related interfaces may be provided, sold, distribuled, utilized, or marketed as a product or as a major component of a separate product. Because the interfaces are generated from the business object model, the information in the interfaces is consistent, and the interfaces are consistent among the business entities. Such consistency facilitates heterogeneous business entities in cooperating to accomplish the business transaction.
  • Figs. IA-C depict three different approaches to a transport condition 102a. 102b, 102c, which specifies how products are to be transported.
  • the transport condition 102a, 102b, 102c considers a business partner 104a, 104b, 104c, a product 106a, 106b, 106c, and a combination of the business partner and the product 108a, 108b, 108c.
  • the transport condition 102a may depend on the business partner 104a.
  • the transport condition 102b may depend on the product 106b.
  • the transport condition 102c may depend on the combination of the business partner and the product 108c.
  • Figs. ID-F depict the resulting consistent interfaces from these object models.
  • Fig. ID depicts an interface for quotations 102d, an interface for purchase orders 5 104d and an interface for goods issued 106d derived using the conceptual model depicted in Fig. IA.
  • Fig. IE depicts these same respective interfaces 102e, 104e, 106e derived using the conceptual model depicted in Fig. IB.
  • Fig. IF depicts these same respective interfaces 102f, 104f, 106f derived using the conceptual model depicted in Fig. 1C.
  • inconsistent interfaces 102g, 104g, 106g result without a cross-component
  • Fig. 1 depicts a flow diagram of the overall steps performed by methods and systems consistent with the subject matter described herein. Initially, to generate the business object model, design engineers study the details of a business process, and model the business process using a "business scenario" (step 100). The business scenario identifies the steps
  • the business scenario is a complete representation of a clearly defined business proceSvS.
  • a scenario variant model is used to depict an illustrative business scenario for a Maintenance Repair Operation ("MRO") Procurement 200.
  • MRO Maintenance Repair Operation
  • the developers use these scenario variant models to depict the individual process steps performed by the business 0 entities during the business process.
  • the customer initially processes an internal request (step 202).
  • the internal request corresponds to the customer's internal documentation for the requested maintenance or repair.
  • the customer then processes a purchase request (step 204).
  • the purchase request corresponds to the customer's internal documentation for a 5 specific product or service related to the maintenance or repair.
  • the customer processes a purchase order (step 206), which is sent to the supplier.
  • This prompts the supplier to process a sales order (step 208).
  • the sales order is the supplier's internal documentation regarding the requested product or service.
  • the supplier processes an outbound delivery (step 210). which is the supplier's internal 0 documentation identifying the products or services that will be provided to the customer.
  • the supplier then sends a goods and services confirmation to the customer (step 212).
  • the supplier processes a customer invoice (step 214) and sends the invoice to the customer.
  • the customer processes the supplier invoice (step 216).
  • the customer also processes a due item (step 21S).
  • the due item summarizes the information regarding the product or service ordered by the customer.
  • the customer processes the payment (step 220) by sending the payment information to the business partner and sending the payment info ⁇ nation to the house bank.
  • the business partner processes the payment (step 222), and the bank processes the payment (step 224).
  • the bank also creates a bank statement (step 226) and forwards the bank statement info ⁇ nation to the customer.
  • the customer also processes an accounting document (step 228).
  • the accounting document is the customer's internal documentation regarding the payment to the supplier.
  • the developers add details to each step of the business scenario (step 102).
  • the developers identify the complete process steps performed by each business entity.
  • a discrete portion of the business scenario reflects a "business transaction," and each business entity is referred to as a "component" of the business transaction.
  • the developers also identify the messages that are transmitted between the components.
  • a "'process intei action model" represents the complete process :iteys between two components.
  • Fig. 3 depicts the process interaction model ,for the invoice processing 230 between the supplier 300, which processes the customer invoice, and the customer 302. which processes the supplier invoice.
  • the supplier uses an Invoice Request Out interface 304 to send an Invoice Request message 306 to the customer.
  • the customer uses the Invoice Req ⁇ est In. interface 308 to receive the Invoice Request message (step 310), and to create an internal instantiation of the supplier invoice 312.
  • the customer processes the supplier invoice (step 314), and uses an Invoice Confirmation Out interface 316 to send an Invoice Confirmation 31 S to the supplier.
  • the supplier uses an Invoice Confirmation In interface 320 to receive the Invoice Confirmation 318.
  • the developers create a "message choreography" (step 104), which depicts the messages transmitted between the two components in the process interaction model.
  • the developers then represent the transmission of the messages between the components during a business process in a "business document flow” (step 106).
  • the business document flow illustrates the flow of information between the business entities during a business process.
  • Fig. 4 depicts an exemplary business document flow 400 for the process of purchasing a product or service.
  • the business entities involved ⁇ vith the illustrative purchase process include Accounting 402, Payment 404, Invoicing 406, Supply Chain Execution (“SCE”) 408, Supply Chain Planning (“SCP”) 410, Fulfillment Coordination (“FC”) 412, Supply Relationship Management (“SRM”) 414, Supplier 416, and Bank 418.
  • the business document flow 400 is divided into four different transactions: Preparation of Ordering ("Contract") 420, Ordering 422, Goods Receiving ("Delivery”) 424, and Billing/Payment 426.
  • arrows 428 represent the transmittal of documents. Each document reflects a message transmitted between entities.
  • the messages transferred may be considered to be a communications protocol.
  • the process flow follows the focus of control, which is depicted as a solid vertical line (e.g., 429) when the step is required, and a dotted vertical line (e.g., 430) when the step is optional.
  • the SRM 414 sends a Source of Supply Notification 432 to the SCP 410.
  • This step is optional, as illustrated by the optional control line 430 coupling this step to the remainder of the business document flow 400.
  • the SCP 410 sends a Purchase Requirement Request 434 to the FC 412, which forwards a Purchase Requirement Request 436 to the SRM 414.
  • the SRM 414 then sends a Purchase Requirement Confirmation 438 to the FC -'•12, and the FC 412 sends a Purchase Requirement Confirmation 440 to the SCP 410.
  • the SRM 414 also sends a Puichase Order Request 442 to the Supplier 416, and sends Purchase Order Information 444 to the FC 412.
  • the FC 412 then sends a Purchase Order Planning Notification 446 to the SCP 410.
  • the Supplier 416 after receiving the Purchase Order Request 442, sends a Purchase Order Confirmation 448 to the SRM 414, which sends a ⁇ Purchase Order Information confirmation message 454 to the FC 412, which sends a message 456 confirming the Purchase Order Planning Notification to the SCP 410.
  • the SRM 414 then sends an Invoice Due Notification 458 to Invoicing 406.
  • the FC 412 sends a Delivery Execution
  • the Supplier 416 could optionally 450 send a Despatched Delivery Notification 452 to the SCE 408.
  • the SCE 408 then sends a message 462 to the FC 412 notifying the FC 412 that the request for the Delivery Information ⁇ vas created.
  • the FC 412 then sends a message 464 notifying the SRM 414 that the request for the Delivery Information was created.
  • the FC 412 also sends a message 466 notifying the SCP 410 that the request for the Delivery Information was created.
  • the SCE 4OS sends a message 468 to the FC 412 when the goods have been set aside for delivery.
  • the FC 412 sends a message 470 to the SRM 414 when the goods have been set aside for delivery.
  • the FC 412 also sends a message 472 to the SCP 410 when the goods have been set aside for delivery.
  • the SCE 4OS sends a message 474 to the FC 412 when the goods have been delivered.
  • the FC 412 then sends a message 476 to the SRM 414 indicating that the goods have been delivered, and sends a message 478 to the SCP 410 indicating that the goods have been delivered.
  • the SCE 408 then sends an Inventory Change Accounting Notification 480 to Accounting 402, and an Inventory Change Notification 482 to the SCP 410.
  • the FC 412 sends an Invoice Due Notification 484 to Invoicing 406, and SCE 408 sends a Received Delivery Notification 486 to the Supplier 416.
  • the Supplier 416 sends an Invoice Request 487 to Invoicing 406.
  • Invoicing 406 then sends a Payment Due Notification 488 to Payment 404, a Tax Due Notification 489 to Payment 404, an Invoice Confirmation 490 to the Supplier 416, and an Invoice Accounting Notification 491 to Accounting 402.
  • Payment 404 sends a Payment Request 492 to the Bank 418, and a Payment Requested Accounting Notification 493 to Accounting 402.
  • Bank 418 sends a Bank Statement Information 496 to Payment 404.
  • Payment 404 then sends a Payment Done Information 494 to Invoicing 406 and a Payment Done Accounting Notification 495 to Accounting 402.
  • business documents having the same or similar otn.icp.ires are marked.
  • Purchase Requirement Requests 434, 436 and Purchase Requirement Confirmations 438, 440 have the same structures.
  • each of these business documents is marked with an "06.”
  • Puvchase Order Request 442 and Purchase Order Confirmation 448 have the same structures.
  • both documents are marked with an "01.”
  • Each business document or message is based on a message type.
  • the message type is identified within the rectangle within each of the business documents depicted in the business document flow.
  • Source of Supply Notification 432 is based on message type 77, as reflected by "MT 77.”
  • a list of various message types with their corresponding codes and a description of each message type is provided below.
  • the business object model includes the objects contained within the business documents. These objects are reflected as packages containing related information, and are arranged in a hierarchical structure within the business object model, as discussed below.
  • Methods and systems consistent with the subject matter described herein then 5 generate interfaces from the business object model (step 110).
  • the heterogeneous programs use instantiations of these interfaces (called “business document objects” below) to create messages (step 112), which are sent to complete the business transaction (step 114).
  • Business entities use these messages to exchange information with other business entities during an end-to-end business transaction. Since the business object model is shared by 10 heterogeneous programs, the interfaces are consistent among these programs. The heterogeneous programs use these consistent interfaces to communicate in a consistent manner, thus facilitating the business transactions.
  • Standardized Business-to-Business (“B2B”) messages are compliant with at least one of the e-business standards (i.e., they include the business-relevant fields of the I :) ' standard).
  • the e-business standards include, for example, RosettaNet for the high-tech industry, Chemical Industry DaIa Exchange (“CIDX”), Petroleum Industry Data Exchange (“PIDX”) for the oil industry, UCCnet for trade.
  • PapiNet for the paper industry, Odette for the automotive industry, HR-XML, for human resources, and XML Common Business Library (“xCBL”)-
  • B2B messages enable simple integration of components in 0 heterogeneous system landscapes.
  • Application-to- Application (“A2A) messages exceed the standards, and thus provide the benefit of the full functionality of application components.
  • Fig. 5 depicts two exemplary data processing systems 500, 550 suitable for practicing methods and systems consistent with the subject matter described herein.
  • Data ⁇ processing system 500 includes a main memory 502, a secondary storage device 504, a processor 506, and an input/output (I/O) device 508.
  • data processing system 550 includes a main memory 552, a secondary storage device 554, a processor 556, and an input/output (I/O) device 558.
  • Each data processing system 500, 550 may further comprise standard input devices, such as a keyboard, a mouse or a speech processing means (each not illustrated).
  • the internal components of each data processing system 500, 550 exchange information with one another via system buses 510, 560.
  • Memory 502 includes program 512, which is an application program that facilitates the transfer of information between business entities.
  • Memory 552 similarly includes program 562, which is an application program that facilitates the transfer of information between business entities.
  • program 512 could be an accounting program that transfers information to program 562, which could be a manufacturing program.
  • programs 512, 562 can reside in the same data processing system, ihe Game computer, and even in the same memory.
  • Each program 512, 562 may comprise or may be included in one or more code sections containing instructions for performing their respective operations. While programs 512, 562 are described as being implemented as software, the present implementation may be implemented as a combination of hardware and software or hardware alone.
  • Memory 502 also includes an exchange infrastructure (“XI”) 514, which is an infrastructure that supports the technical interaction of business processes across heterogeneous system environments. XI centralizes the communication between components within a business entity and between different business entities. If necessary, XI carries out the mapping between the messages. XI is a publicly available product sold by SAP AG, Walldorf, Germany. Similarly, memory 552 includes an Xl 564. XI 514, 564 integrates different versions of systems implemented on different platforms (e.g., Java® and ABAP). XI 514, 564 is based on an open architecture, and makes use of open standards, such as XMLTM and Java® environments.
  • XI 514, 564 offers services that are useful in a heterogeneous and complex system landscape.
  • XI 514, 564 offers a runtime infrastructure for message exchange, configuration options for managing business processes and message flow, and options for transforming message contents between sender and receiver systems.
  • XML is a trademark of the Massachusetts Institute of Technology, Tnstitut National de mecanic en Informatique et en Automatique, and Keio University.
  • Java is a registered trademark of Sun Microsystems, Inc. All names used herein may be trademarks or registered trademarks of their respective companies.
  • XI 514, 564 stores data types 516, 566, a business object model 518, 568, and interfaces 520, 570. The details regarding the business object model are described below. Data types 516, 566 are the building blocks for the business object model 518, 568. The business object model 518, 568 is used to derive consistent interfaces 520, 570. XI 514, 564 allows for the exchange of information from a first company having one computer system to a second company having a second computer system over network connection 525 by using the standardized interfaces 520, 570.
  • data processing systems 500, 550 have operating systems that control their operations, including the execution of programs 512, 562 by processors 506, 556.
  • aspects of one implementation consistent with the principles of the subject matter described herein are > described herein with piograms 512, 562 stored in main memories 502, 552, one skilled in uie art will appreciate that all or pait of systems and methods consistent with the subject • matter described heiem may be stored on or read from other eompulet-readable media, such ?s secondary storage devices 504, 554, like hard disks, floppy disks, and CD-ROM; a carrier wave received from a network, such as the Internet; or other forms of ROM or RA M.
  • Interfaces 520, 570 derived from the business object model 518, 568 suitable for use with more than one business area, for example different departments within a company such as finance, or marketing. Also, they are suitable across industries and across businesses. Interfaces 520, 570 are used during an end-to-end business transaction to transfer business process information in an application-independent manner. For example the interfaces can be used for fulfilling a sales order.
  • the communication between a sender 602 and a recipient 604 can be broken down into basic categories that describe the type of the information exchanged and simultaneously suggest the anticipated reaction of the recipient 604.
  • a message category is a general business classification for the messages. Communication is sender-driven. In other words, the meaning of the message categories is established or formulated from the perspective of the sender 602.
  • the message categories include information 606, notification 608, query 610, response 612, request 614, and confirmation 616.
  • Information 606 is a message sent from a sender 602 to a recipient 604 concerning a condition or a statement of affairs. No reply to information is expected. Information 606 is sent to make business partners or business applications aware of a situation. Information • 606 is not compiled to be application-specific. Examples of "information" are an announcement, advertising, a report, planning information, and a message to the business "vareliouse.
  • a notification 608 is a notice or message that is geared to a service.
  • a sender 602 sends the notification 608 to a recipient 604. No reply is expected for a notification.
  • a billing notification relates to the preparation of an invoice while a dispatched delivery notification relates to preparation for receipt of goods.
  • a query 610 is a question from a sender 602 to a recipient 604 to which a response 612 is expected.
  • a query 610 implies no assurance or obligation on the part of the sender 602. Examples of a query 610 are whether space is available on a specific flight or whether a specific product is available. These queries do not express the desire for reserving the flight or purchasing the product.
  • a response 612 is a reply to a query 610.
  • the recipient 604 sends the response 612 to the sender 602.
  • a response 612 generally implies no assurance or obligation on the part cf the recipient 604.
  • the sender 602 is not expected to reply. Instead, the process is concluded with the response 612.
  • a response 612 also may include a commitment, i.e., an assurance or obligation on the part of the recipient 604.
  • Examples of responses 612 are a response stating that space is available on a specific flight or that a specific product is available. With these responses, no reservation was made.
  • a request 614 is a binding requisition or requirement from a sender 602 to a recipient 604.
  • the recipient 604 can respond to a request 614 with a confirmation 616.
  • the request 614 is binding on the sender 602.
  • the sender 602 assumes, for example, an obligation to accept the services rendered in the request 614 under the reported conditions. Examples of a request 614 are a parking ticket, a purchase order, an order for delivery and a job application. (6) Confirmation
  • a confirmation 616 is a binding reply that is generally made to a request 614.
  • the recipient 604 sends the confirmation 616 to the sender 602.
  • the information indicated in a confirmation 616 such as deadlines, products, quantities and prices, can deviate from the information of the preceding request 614.
  • a request 614 and confirmation 616 may be used in negotiating processes.
  • a negotiating process can consist of a series of several request 614 and confirmation 616 messages.
  • the confirmation 616 is binding on the recipient 604. Fw example, 100 units of X may be ordered in a purchase oidev request; however, only the delivery of 80 units is confirmed in the associated purchase older confirmation, b) Message Choreography
  • a message choreography is a template that specifies the sequence of messages between business entities during a given transaction.
  • the sequence with the messages contained in it describes in general the message "lifecycle" as it proceeds between the business entities. If messages from a choreography are used in a business transaction, they appeat in the transaction in the sequence determined by the choreography. This illustrates the template character of a choreography, i.e., during an actual transaction, it is not necessary for all messages of the choreography to appear. Those messages that are contained in the transaction, however, follow the sequence within the choreography. A business transaction is thus a derivation of a message choreography.
  • the choreography makes it possible to determine the structure of the individual message types more precisely and distinguish them from one another.
  • a Purchase Order Request Message 706 is the request from the buyer 702 to the seller 704 to deliver goods or render services.
  • the message type 708 of the Purchase Order Request Message 706 is 0101 , as defined above.
  • the Purchase Order Change Request Message 710 requests a change of a previous purchase order request or purchase order change request message.
  • the message type 712 of the Purchase Order Change Request Message 710 is 0102.
  • the Purchase Order Cancellation Request Message 714 is the cancellation of the request of the buyer 702 to the seller 704 to deliver goods or render services.
  • the message type 716 of the Purchase Order Cancellation Request Message 714 is 0103.
  • the Purchase Order Confirmation Message 718 is a confirmation, a partial confirmation, or a change with respect to the delivery of goods or the rendering of services that were requested or cancelled.
  • the message type 720 of the Purchase Order Confirmation Message 718 is 0104. Illustrative message choreographies that cover a number of transactions are presented below.
  • Fig. 8 depicts the message choreography of a Master Data Management.
  • the Master Data Management choreography involves three components: a Catalogue Provide) 802, a Catalogue Authoring Tool (CAT) 804, and a Catalogue Search Engine (CSE) 806.
  • the Catalogue Provide 802
  • CAT Catalogue Authoring Tool
  • CSE Catalogue Search Engine
  • Catalogue Provider 802 sends a CatalogueUpdat ⁇ Notif ⁇ cation message 808 to the CAT 804.
  • fhe message type 810 of the CatalogueUpdateNotification message 808 is 0080. i.e., n notice from a catalogue provider to an inteiested party about a new catalogue transmitted in the message or about changes to an existing catalogue transmitted in the message.
  • 'Die message type 810 can be divided into multiple messages.
  • the CAT 804 then sends a
  • the message type 814 of the CataloguePublicationRequest message 812 is 0081 , i.e., a request from catalogue authoring to the Catalogue Search Engine (the publishing system) to publish a new or changed catalogue or to delete an already published catalogue (the catalogue is possibly split into several transmission packages).
  • the message type 814 also can be divided into multiple messages.
  • the CSE 806 sends a CataloguePublicationTransmissionPackageNotification message 816 to the CAT S04.
  • the message type 818 of the CataloguePublicationTransmissionPackageNotification message 816 is 00S2, i.e., the notification of the Catalogue Search Engine (the publishing system) to Catalogue Authoring about a package of a catalogue publication transmission and information about the reception of this package and the validity of its content.
  • the message type 818 can be divided into multiple messages.
  • the CSE 806 sends a CataloguePublicationConfirmation message 820 to the CAT 804.
  • the message type 822 of the CataloguePublicationConfirmation message 820 is 0083, i.e., the confirmation of the Catalogue Search Engine (the publishing system) to the Catalogue Authoring whether the publication or deletion of a Catalogue requested by a CataloguePublicationRequest 812 was successful or not.
  • the CAT 804 sends a CataloguePublicationTransmissionCancellationRequest message 824 to the CSE 806.
  • CataloguePublicationTransmissionCancellationRequest message 824 is 0084, i.e., the request of Catalogue Authoring to Catalogue Search Engine (the publishing system) to ⁇ cancel the transmission of a Catalogue and to restore an earlier published state (if such exists) of the Catalogue. Moreover, no more packages are sent for this transmission.
  • the CSE 806 sends a CataloguePublicationTransmissionCancellationConfirmation message 828 to the CAT 804.
  • CataloguePublicationTransmissionCancellationConf ⁇ rmation message 828 is 0085, i.e., the confirmation of Catalogue Search Engine (the publishing system) whether the transmission of a Catalogue has been cancelled successfully and an earlier published state of this • • catalogue (if such exists) has been restored or not.
  • the CAT 804 sends a CataloguePublicationTransmissionlteniLockRequest message 832 to the CSE 806.
  • the message type 834 of the CataloguePublicationTransmissionltemLockRequest message 832 is 0086, i.e., the request of Catalogue Authoring to lock single items of the catalogue contained in the catalogue publication transmission.
  • the CSE 806 sends a CataloguePublicationTransmissionttemLockConfirmation message 836 to the CAT 804.
  • the message type 838 of the CataloguePublicationTransmissionltemLockConfirmation message 836 is 0087, i.e., the confirmation of Catalogue Search Engine (the publishing system) to Catalogue Authoring whether single items of the catalogue contained in the catalogue publication transmission could be locked or not. If an item of the catalogue is locked and the catalogue is not yet published, the items must not be published. If the catalogue is already published, the publication of these items must be revoked. (2) Purchasing and Sales
  • Fig. 9 depicts the message choreography of a Source of Supply, Purchase Requirement, and Purchase Order.
  • the Source of Supply, Purchase Requirement, and Purchase Order choreography involves three components: Supply Chain Planning (SCP) 902, Purchasing (SRM) 904, and a Supplier 906.
  • SCP Supply Chain Planning
  • SRM Purchasing
  • Supplier 906 Supplier 906.
  • the SRM 904 sends a SourceOfSupplyNotification message 908 to the SCP 902.
  • the message type 910 of the SourceOfSupplyNotification message 908 is 0077, i.e., a notice to Supply Chain Planning about available sources of supply.
  • the SCP 902 sends a PurchaseRequirementRequest message 912 to the SRM 904.
  • the message type 914 of the PurchaseRequirementRequest message 912 is 0130, i.e., a request from a requestor to a purchaser to (externally) procure products (materials, services) (external procurement).
  • the SRM 90 ⁇ sends a PurchaseOrderRequest message 916 to the Supplier 906.
  • the message type 918 of the PurchaseOrderRequesl message 916 is 0101 , i.e.. a request from a purchaser to a seller to deliver goods or piovide services.
  • the SRM 904 sends a PurchaseOrderChangeRequest message 920 to the Supplier 906.
  • the message type 922 of the PurchaseOrdeiChangeRequest message 920 is 0102, i.e., ⁇ change to a purchaser's request to the seller to deliver goods or piovide services.
  • the SRM 904 sends a PurchaseOrderCancellationRequest message 924 to the Supplier 906.
  • the message type 926 of the PurchaseOrderCancellationRequest message 924 is 0103, i.e., the cancellation of a purchaser's request to the seller to deliver goods or provide services.
  • the Supplier 906 sends a PurchaseOrderConf ⁇ rmation message 928 to the SRM 904.
  • the message type 930 of the PurchaseOrderConfirmation message 92S is 0104, i.e., a confirmation, partial confirmation, or change from a seller to the purchaser, regarding the requested delivery of goods or provision of services.
  • the SRM 904 sends a PurchaseRequirementConf ⁇ rmation message 932 to the SCP 902.
  • the message type 934 of the PurchaseRequirementConfirmation message 932 is 0131 , i.e., a notice from the purchaser to the requestor about the degree of fulfillment of a requirement.
  • Fig. 10 depicts the message choreography of a Product Demand, Product Forecast and Product Activity.
  • the Product Demand, Product Forecast and Product Activity choreography involves two components: a Buyer (ERP) 1002 and a Vendor (SCM) 1004.
  • ERP Buyer
  • SCM Vendor
  • the Buyer 1002 sends a ProductDemandlnfluencingEventNotification message 1006 to the Vendor 1004.
  • ProductDemandlnfluencingEveiitNotification message 1006 is 0140, i.e., a notification about an event which influences the supply or demand of products.
  • the Buyer 1002 sends a ProductForecastNotification message 1010 to the Vendor
  • the message type 1012 of the ProductForecastNotification message 1010 is 0141, i.e., a notification about future product demands (forecasts).
  • the Buyer 1002 sends a ProductActivityNotification message 1014 to the Vendor i004.
  • the message type 1016 of the ProductActivityNotification message 1014 is 0145, i.e.. a message which coinmum ' cales pioduct-related activities of a b ⁇ yev Io a vendor. Bassd on this, the vendor can perform supply planning for the buyer.
  • the Vendor 1004 sends a PtoductForecasiRevisiovjNoiification message 101 S to ..he IJ'iyer 1002.
  • the message type 1020 of the ProductForecastRevisionNofificntiori message 1018 is 0142, i.e., a notification about the revision of future product demands (forecasts).
  • the Buyer 1002 sends the ProductForecastRevisionNotificati ⁇ n message 1022 to the
  • the message type 1024 of the ProductForecastRevisionNotification message 1022 is 0142.
  • Fig. 1 1 depicts the message choreography of a RFQ and Quote.
  • the RFQ and Oiiote choreography involves two components: Purchasing (SRM) 1102 and a Supplier 1 104.
  • the SRM ] 102 sends a RFQRequest message 1106 to the Supplier 1104.
  • the message type 11OS of the RFQRequest message 1 106 is 0151, i.e., the request from a purchaser to a bidder to participate in a request for quotation for a product.
  • the Supplier 1104 sends a RFQAcceptanceConfi ⁇ nation message 1110 to the SRM
  • the message type of the RFQAccepfanceConfirmation message 11 10 can be any conventional RFQ Acceptance Confirmation 1 112.
  • the SRM 1 102 sends a RFQChangeRequest message 11 14 to the Supplier 1104.
  • the message type 1116 of the RFQChangeRequest message 1114 is 0152, i.e., a change to the purchaser's request for a bidder to participate in the request for quotation for a product.
  • the SRM 1102 sends a RFQCancellationRequest message 1 118 to the Supplier 1104.
  • the message type 1120 of the RFQCancellationRequest message 1118 is 0153, i.e., a cancellation by the purchaser of a request for quotation for a product.
  • the Supplier 1104 sends a QuoteNotification message 1122 to the SRM 1102.
  • the message type 1124 of the QuoteNotification message 1122 is 0155, i.e., the quote of a bidder communicated to a purchaser concerning the request for quotation for a product by the purchaser.
  • the SRM 1 102 sends a RFQResultNotif ⁇ cation message I' 126 to the Supplier 1 104.
  • the message type 1128 of the RFQResultNotification message 1126 is 0154, i.e., a notification by a purchaser to a bidder about the type and extent of the acceptance of a quote or about the rejection of the quote.
  • the Supplier 1 104 sends a RFQResultAcceptanceConfirmation message 1 130 to the
  • the message type of the RFQResultAcceptanceConfirmation message 1 130 ⁇ can be any conventional RFQ Result Acceptance Confirmation 1 132.
  • Fig. 12 depicts the message choreography of Purchasing.
  • the Purchasing choreography involves five components: Sales (CRM.) 1202, Purchasing (SRM) 1204,
  • Line 1212 denotes a company border.
  • one company includes Sales 1202, while another company includes SRM 1204, FC 1206, SCP 1208, and SCE 1210.
  • the SRM 1204 sends a PurchaseOrderRequest message 1214 to the CRM 1202.
  • the message vype 1216 of the PurchaseOrderRequest message 1214 is 0101, i.e., a request from a purchaser to a seller to deliver goods or provide services.
  • the SRM 1204 sends a PurchaseOrderlnformation message 121 S to the FC 1206.
  • the message type 1220 of the PurchaseOrderlnformation message 1218 is 0120, i.e., information from a purchasing system for interested recipients about the current state of a purchase order when creating or changing a purchase order, confirming a purchase order or canceling a purchase order.
  • the FC 1206 sends the PurchaseOrderlnformation message 1222 to the SCP 1208.
  • the message type 1224 of the PurchaseOrderlnformation message 1222 is message type 0120.
  • the CRM 1202 sends a PurchaseOrdeiConf ⁇ rmation message 1226 to the SRM 1204.
  • the message type 1228 of the PurchaseOrderConf ⁇ rmation message 1226 is 0104, i.e., a confirmation, partial confirmation, or change from a seller to the purchaser, regarding the requested delivery of goods or provision of services.
  • the SRM 1204 sends a PurchaseOrderlnformation message 1230 to the FC 1206.
  • the message type 1232 of the PurchaseOrderlnformation message 1230 is 0120, described above.
  • the FC 1206 sends the PurchaseOrderlnformation message 1234 to the SCP 1208.
  • the message type 1236 of the PurchaseOrderlnformation message 1234 is 0120.
  • the FC 1206 sends a DeliveryExecutionRequest message 1238 to the SCE 1210, as depicted by line 1242.
  • the SRM 1204 may send the DeliveryExecutionRequest message 1238 to the SCE 1210, as depicted by broken line 1240.
  • the message type 1244 of the DeliveryKxecufionRequest message 1238 is 0200, i.e.. a request to a warehouse or supply chain execution to prepare and execute the outbound delivery of goods or the acceptance of an expected oi announced inbound delivery.
  • the SCE 1210 sends a Deliver/Information message 1246 to the FC 1206.
  • the message type 1248 of the Delivery Information message 1246 is 0201, i.e., a message about the creation, change, and execution status of a delivery.
  • the FC 1206 sends a Deliverylnformation message 1250 to the SCP 1208.
  • the message type 1252 of the Deliverylnformation message is 0201.
  • the FC 1206 sends a Deliverylnformation message 1254 to the SRM 1204.
  • the message type 1256 of the Deli very Info rmation message 1254 is 0201 .
  • Fig. 13 depicts the message choreography of Sales.
  • the Sales choreography involves five components: Purchasing (SRM) 1302, Sales (CRM) 1304, Fulfillment Coordination (FC) 1306, Supply Chain Planning (SCP) 1308, and Supply Chain Execution (SCE) 1310.
  • Line 1312 denotes a company border.
  • SRM 1302 sends a PurchaseOrderRequest message 1314 to the CRM 1304.
  • the message type 1316 of the PurchaseOrderRequest message 131 ⁇ is 0101, i.e., a request from a purchaser to a seller to deliver goods or provide services.
  • the CRM 1304 sends a SalesOrderFulfillmentRequest message 1318 to the FC 1306.
  • the message type 1320 of the SalesOrderFulfillmentRequest message 1318 is 0160, i.e., a request (or change or cancellation of such a request) from a selling component to a procuring component, to fulfill the logistical requirements (for example, available-to- promise check, scheduling, requirements planning, procurement, and delivery) of a sales order.
  • the FC 1306 sends the SalesOrderFulfillmentRequest message 1322 to the SCP 1308.
  • the message type 1324 of the SalesOrderFulfillmentRequest message 1322 is 0160.
  • the SCP 1308 sends a SalesOrderFulfillmentConfinnation message 1326 to the FC 1306.
  • the message type 1328 of the SalesOrderFulfillmentConfirmation message 1326 is 0161, i.e., a confirmation, partial confirmation or change from the procuring component to the selling component, regarding a sales order with respect to which procurement has been requested. ...
  • the FC 1306 sends the SalesOrderFulfillmentConfirmation message 1330 to the CRM 1304.
  • the message type 1332 of the SalesOrderFulfillmentConfmnation message 1330 is 0161.
  • the CRM ) 304 sends a PuichaseOrderConfirmation message 1334 to the SRM 1302.
  • the message type 1336 of the PiirchaseOrderConfirmation message 1334 is 0104, i.e.) a confirmation, partial confirmation, or change from a seller to the purchaser, regarding the requested delivery of goods or provision of services.
  • the FC 1306 sends a DeliveryExecutionRequest message 1338 to the SCE 1310.
  • the message type 1340 of the DeliveryExecutionRequest message 1338 is 0200, i.e., a request to a warehouse or supply chain execution to prepare and execute the outbound delivery of goods or the acceptance of an expected or announced inbound delivery.
  • the SCE 1310 sends a Deliverylnformation message 1344 to the FC 1306.
  • the message type 1346 of the Deliverylnformation message 1344 is 0201, i.e., a message about the creation, change, and execution status of a delivery.
  • the FC 1306 sends the Deliverylnformation message 1348 to the SCP 1308.
  • the message type 1350 of the Deliverylnfo ⁇ nation message 1348 is 0201, i.e., a message about the creation, change, and execution status of a delivery.
  • the FC 1306 also sends the Deliverylnformation message 1352 to the CRM 1304.
  • the message type 1354 of the Deliverylnfomiation message 1352 is 0201.
  • Fig. 14 depicts the message choreography of a Vendor Managed Inventory / Responsive Replenishment.
  • the Vendor Managed Inventory / Responsive Replenishment choreography involves three components: a Buyer 1402, Supply Chain Planning 1404, and Supply Chain Execution 1406.
  • Line 1408 denotes a company border. Thus, one company includes Buyer 1402, while another company includes Supply Chain Planning 1404 and Supply Chain Execution 1406.
  • the Buyer 1402 sends an OrderlDAssignmentNotif ⁇ cation message 1410 to Supply Chain Planning 1404.
  • the message type 1412 of the OrderIDAssignmentNotification message 1410 is 0185, i.e., a message that allows a buyer to assign a vendor order numbers for identifying ''purchase orders generated by the vendor.'
  • Supply Chain Planning 1404 sends a ReplenishmentOrderNotification message 1414 to Supply Chain Execution 1406.
  • the message type 1416 of the RepisnishmentOrcleiNotification message 1414 is 0216, i.e.. & message that is used by Logistics Planning (SCP, vendor) to lraosfer a replenishment order planned for a cj ⁇ tomer/b ⁇ y p r to Logi ⁇ ics Execulion (SCE. vendor) in ocder k> trigger further processing for the order and prepare the outbound deliver ⁇ '
  • Supply Chain Execution 1406 sends a ReplenishmenLOiderConf ⁇ mtion message 1 ⁇ 18 to Supply Chain Planning M04.
  • ReplenislimentOrderConfirmation message 1418 is 0217, i.e.. a message that is used by Logistics Execution (SCE, vendor) to confirm to Logistics Planning (SCP, vendor) that a replenishment order that is planned for a customer/buyer can be fulfilled.
  • SCE Logistics Execution
  • SCP Logistics Planning
  • Supply Chain Planning 1404 sends a VendorGeneiatedOiderNotif ⁇ cation message 1 ⁇ 22 to the Buyer l ⁇ 402
  • the message type 1424 of the VendorGeneratedOrOeiNotilication message 1422 is 0213, i.e., a message that is used by a vendor/seller to transfer the replenishment order that he has initiated and planned to a customer/buyer so that the latter can create a purchase order.
  • the notification sent by the vendor/seller to the customer/buyer regarding the planned replenishment order can be regarded as a "purchase otder generated by the seller.”
  • VendorGeneratedOrdeiConfirmation message J 426 to Supply Chain Planning 1404.
  • the message type 1428 of the VcndorGeneratedOrderConfirmation message 1426 is 0214, i.e.. VendorGeneratedOrderConfirmation is the confirmation from a customer/buyer that a purchase order has been created for the replenishment order initiated and planned by his vendor/seller. This confirmation from the customer/buyer for a "purchase order generated by the seller" can be regarded as a "purchase order" in the traditional sense, which, in turn, triggers the corresponding fulfillment process at the vendor/seller. (3) Delivery and Goods Movement
  • Fig. 15 depicts the message choreography of an Advanced Shipment Notification and Proof of Delivery.
  • the Advanced Shipment Notification and Proof of Delivery choreography involves two components: a Vendor 1502 and a Product Recipient 1504.
  • the Vendor 1502 sends a DespatchedDeliveryNotification message 1506 to the Product Recipient 1504.
  • the message type 150S of the DespatchedDeliveryNotification message 1506 is 0202, i.e., a notification communicated to a product recipient about the planned arrival, pickup, or issue date of a ready -to-send delivery, including details about the content of the delivery.
  • the Product Recipient 1504 sends a ReceivedDeliveryNotifieation message 1510 fo the Vendor 1502.
  • the message type 1512 of the .ReceivedDeliveryNotifieation message 1510 is 0203, i.e., a notification communicated to a vendor about the arrival of the delivery sent by him to the product recipient, including details about the content of the delivery-.
  • Fig. 16 depicts the message choreography of a Service Acknowledgement.
  • the Service Acknowledgement choreography involves two components: Purchasing (SRM) 1602 and a Supplier 1604.
  • the Supplier 1604 sends a ServiceAcknowledgementRequest message 1606 to the SRM 1602.
  • the message type 1608 of the ServiceAcknowledgementRequest message 1606 is 0240, i.e., a request by a seller to a purchaser to confirm the services recorded.
  • the SRM 1602 sends a ServiceAcknowledgementConfirmation message 1610 to the Supplier 1604.
  • the message type 1612 of the ServiceAcknowledgementConfirmation message 1610 is 0241, i.e., a confirmation (or rejection) of the services recorded.
  • Fig. 17 depicts the message choreography of an Inventory Change.
  • the Inventory Change choreography involves three components: Inventory Management (SCE) 1702, Logistic Planning (SCP) 1704 and Financial Accounting 1706.
  • SCE 1702 sends an InventoryChangeNotification message 1708 to the SCP 1704.
  • the message type 1710 of the InventoryChangeNotification message 1708 is 0250, i.e., a summery of detailed information about inventory changes in inventory management, which is required for logistics planning.
  • the SCE 1702 sends an InventoryChangeAccountingNotification message 1712 to
  • the message type 1714 of the InventoryChangeAccountingNotification message 1712 is 0251, i.e., a summary of aggregated information about inventory changes in inventory management, which is required for financials.
  • the SCE 1702 sends an Inventory ChangeAccountingCancellationRequest message
  • the message type 1718 of the InventoryChangeAccoiintingCancellationRequest message 1716 is 0252, i.e., a request for the full cancellation of posting information previously sent to financials with respect to a goods movement.
  • Fig. 18 depicts the message choreography of Billing Due.
  • the Billing Due choreography involves three components: Sales (CRM) 1802, Supply Chain Execution
  • the CRM 1802 sends a BillingDueNotification message 1808 to Billing 1806.
  • the message type 1810 of the BillingDueNotification message 1808 is 0290. i.e., a notification about billing-relevant data communicated to an application in which the subsequent operative processing of billing takes place.
  • the SCE 1804 sends a BillingDueNotification message 1816 to Billing 1806.
  • the message type 1818 of the BillingDueNotification message 1816 is 0290, i.e., a notification about billing-relevant data communicated to an application in which the subsequent operative processing of billing takes place.
  • Fig. 19 depicts the message choreography of Invoicing Due.
  • the Invoicing Due choreography involves three components: Purchasing (SRM) 1902, Supply Chain Execution (SCE) 1904, and Invoicing 1906.
  • the SRM 1902 sends an InvoicingDueNotification message 1908 to Invoicing 1906.
  • the message type 1910 of the InvoicingDueNotification message 190S is 0291, i.e., a notification about invoicing-relevant data communicated to an application in which the operative verification and creation of invoices takes place, and/or in which "self billing" invoices (evaluated receipt settlement) are created.
  • the SCE 1904 sends an InvoicingDueNotification message 1916 to Invoicing 1906.
  • the message type 1918 of the InvoicingDueNotification message 1916 is 0291, i.e., a 5 notification about invoicing-relevant data communicated to an application in which the operative verification and creation of invoices takes place, and/or in which "self billing" invoices (evaluated receipt settlement) are created.
  • Fig. 20 depicts the message choreography of an Invoice.
  • the Invoice choreography 10 involves four components: Purchasing (SRJVl) 2002, Invoicing 2004, Billing 2006, and Sales (CRM) 2008.
  • Line 2010 denotes a company border.
  • SRM SRM 2002
  • Billing 2006 sends an InvoiceRequest message 2012 to Invoicing 2004.
  • the 15 message type 2014 of the InvoiceRtquest message 2012 is 0401, i.e., a legally binding notice ab ⁇ ut accounts receivable o ⁇ accounts paycible for delivered goods or provided services — tvpioaliy a request that paymeni be made for these goods or services..
  • Im oicing 2004 sends an InvoiceReeei vedlnfomialion message 2016 to the SRM 2002.
  • the message type 2018 of the InvoiceR ⁇ ceivedlnformation message 2016 can be a 20 ccwtntional Invoice Received Information.
  • Billing 2006 sends an Invoicelssuedlnformation message 2020 to Sabs 2008.
  • the message type 2022 of the Invoicelssuedlnformation message 2020 is 0410, i.e., information about provided services, delivered products, or credit or debit memo tequest items that have been billed, the items of an invoice that have been used for this, and the extent to which Z5 they have been billed.
  • Invoicing 2004 sends an InvoiceConf ⁇ rmation message 2024 to Billing 2006.
  • the message type 2026 of the invoiceConfirmation message 2024 is 0402, i.e., the repose of a recipient of an invoice to the bill-from-party by which the invoice as a whole is confirmed, rejected, or classified as 'not yet decided.' 3 U (d) Invoice Accounting and Payment Due
  • Fig. 21 depicts the message choreography of Invoice Accounting and Payment Due.
  • the Invoice Accounting and Payment Due choreography involves three components: Invoicing/Billing 2102, Accounting 2104 and Payment 2106.
  • Invoicing/Billing 2102 sends an InvoiceAccountingNotification message 2108 to Accounting 2104.
  • the message type 2110 of the InvoiceAccountingNotification message 2108 is 0411, i.e., a notification to financials about information on incoming or outgoing invoices from invoice verification or billing.
  • Invoicing/Billing 2102 sends an InvoiceAccountingCancellationRequest message
  • InvoiceAccountingCancellationRequest message 2112 is 0412, i.e., a request for the full cancellation of posting information previously sent to financials, regarding an incoming or outgoing invoice or credit memo.
  • Invoicing/Billing 2102 sends a PaymentDueNotification message 21 16 to Payment
  • the message type 2118 of the PaymentDueNotification message 2116 is 0430, i.e., the PaymentDueNotification notifies an application (Payment), in which subsequent operative processing of payments take place, about due dates (accounts receivable and accounts payable) of business partners.
  • Invoicing/Billing 2102 sends a PaymentDueCaiicellationRequest message : 212 ⁇ " tor ⁇
  • the message type 2122 of the PaymentDueCanceilationRequest message , 2120 can be any conventional Payment Due Cancellation Request.
  • Fig. 22 depicts the message choreography of Tax Due.
  • the Tax Due choreography involves two components: Tax Calculation 2202 and Tax Register 2204.
  • Tax Calculation 2202 sends a TaxDueNotification message 2206 to the Tax Register 2204.
  • the message type 2208 of the TaxDueNotification message 2206 is 0420, i.e., the TaxDueNotification communicates data from tax determination and calculation relevant for tax reports and tax payments to the tax register of a company.
  • Tax Calculation 2202 sends a TaxDueCaticellationRequest message 2210 to the Tax
  • the message type 2212 of the TaxDueCancellationRequest message 2210 can be any conventional Tax Due Cancellation Request.
  • the Credit Worthiness, Credit Agency Report, Credit Payment, and Credit Commitment choreography involves five components: Payment or Accounting 2302, Sales or Financials 2304, a Billing System (e.g., Telco) 2306, Credit Management 2308, and Credit Agency 2310. Sales or Financials 2304 sends a CreditCommitmentRecordNotification message 2312 to Credit Management 2308.
  • the message type 2314 of the CreditCommitmentRecordNotification message 2312 is 0457, i.e., a notice to credit management about existing payment obligations of business partners.
  • Payment or Accounting 2302 sends a CreditPaymeritRecordNotif ⁇ cation message
  • the message type 2318 of the CreditPaymentRecordNotif ⁇ cation message 2316 is 0460, i.e., a notice to credit management about the payment behavior of business partners.
  • Sales or Financials 2304 sends a CreditWorthinessQuery message 2320 to Credit Management 2308.
  • the message type 2322 of the CreditWorthinessQuery message 2320 is 0452, i.e., an inquiry to credit management concerning the credit worthiness of a business partner.
  • Credit Management 2308 sends a CreditAgencyReportQuery message 2324 to Credit Agency 2310.
  • the message type 2326 of the CreditAgencyReportQuery message 2324 is 0450, i.e., an inquiry to a credit agency concerning the credit report for a business partner.
  • Credit Agency 2310 sends a Credit A gene yReportResponse message 2328 to Credit Management 2308.
  • the message type 2330 of the CreditAgencyReportResponse message 2328 is 0451 , i.e., a response from a credit agency concerning the inquiry about the credit repori for a business partner.
  • Credit Management 2308 sends a CreditCommitmentQuery message 2332 to the Billing System 2306.
  • the message type 2334 of the CreditCommitmentQuery message 2332 is 0455, i.e., an inquiry from credit management concerning existing payment obligations of a business partner.
  • the Billing System 2306 sends a CreditCommitmentResponse message 2336 to
  • the message type 2338 of the CreditCommitmentResponse message 2336 is 0456, i.e., a response concerning an inquiry from credit management about existing payment obligations of a business partner.
  • Credit Management 2308 sends a CreditWorthinessResponse message 2340 to Sales or Financials 2304.
  • the message type 2342 of the CreditWorthinessResponse message 2340 is 0453, i.e., a response from credit management concerning the inquiry about the credit worthiness of a business partner.
  • Credit Management 2308 sends a Credit WorthinessChangelnformati ⁇ n message 2344 to Sales or Financials 2304.
  • the message type 2346 of the CreditWorthinessChangelnformation message 2344 is 0454, i.e., information about changes of the credit worthiness of a business partner.
  • Sales or Financials 2304 sends a CreditWorthinessCriticalPartiesQuery message 2348 to Credit Management 2308.
  • 5 CreditWorthinessCriticalPartiesQuery message 234S is 0458, i.e., an inquiry to credit management about business partners, for which the credit worthiness has been rated as critical.
  • Credit Management 2308 sends a CreditWorthinessCriticalPartiesResponse message 2352 to Sales or Financials 2304.
  • 10 CreditWorthinessCriticalPartiesResponse message 2352 is 0459, i.e., a response from credit management concerning an inquiry about business partners, for which the credit worthiness has been rated as critical.
  • FIG. 24 depicts the message choreography of a Personnel Time Sheet.
  • Personnel Time Sheet choreography involves two components: Personnel Time Recording 2402 and Personnel Time Management 2404.
  • Personnel Time Recording 2402 sends a PersonalTimeSheetlnformation message 2406 to Personnel Time Management 2404.
  • the message type 240S of the " IU Pei sonalTimeSheetln formation message 2406 is 0601, i.e., the
  • PersonnelTimeSheetInformalion communicates recorded personnel times and personnel time events from an upstream personnel time recording system to personnel time management.
  • the overall structure of the business object model ensures the consistency of the interfaces that are derived from the business object model.
  • the derivation ensures that the same business-related subject matter or concept is represented and structured in the same way in all interfaces.
  • the business object model defines the business-related concepts at a central location 0 for a number of business transactions. In other words, it reflects the decisions made about modeling the business entities of the real world acting in business transactions across industries and business areas.
  • the business object model is defined by the business objects and their relationship to each other (the overall net structure).
  • a business object is a capsule with an internal hierarchical structure, behavior offered by its operations, and integrity constraints.
  • Business objects are semantically disjoint, i.e., the same business information is represented once.
  • the business objects are arranged in an ordering framework. From left to right, they are arranged according to their existence dependency to each other.
  • the customizing elements may be arranged on the left side of the business object model
  • the strategic elements may be arranged in the center of the business object model
  • the operative elements may be arranged on the right side of the business object model.
  • the business objects are arranged from the top to the bottom based on defined order of the business areas, e.g., finance could be arranged at the top of the business object model with CRM below finance and SRJVl below CRM.
  • the business object model may be built using standardized data types as well as packages to group related elements together, and package templates and entity templates to specify the arrangement of packages and entities -vithin the structure.
  • Data types are used to type object entities and interfaces with a structure. Thif ⁇ typing can include business semantic.
  • the data type BusinessTransactionDocumeiitlD is a unique identifier for a document in a business transaction.
  • Data type BusinessTransactionDooumentParty contains the infonnation that is exchanged in business documents about a party involved in a business transaction, and includes the party's identity, the party's address, the party's contact person and the contact person's address.
  • BusinessTransactionDocumentParty also includes the role of the party, e.g., a buyer, seller, product recipient, or vendor.
  • GDTs Core Component Types
  • CDTs World Wide Web Consortium
  • GDTs context-neutral generic data types
  • CDTs context-based context data types
  • GDTs contain business semantics, but are application-neutral, i.e., without context.
  • CDTs are based on GDTs and form either a use-specific view of the GDTs, or a context-specific assembly of GDTs or CDTs. A message is constructed with reference to a use, and is thus a use-specific assembly of GDTs and CDTs.
  • the data types can be aggregated to complex data types. To achieve a harmonization across business objects and interfaces, the same subject matter is always typed with the same data type. For example, the data type “GeoCoordinates” is built using the data type “Measure” so that the measures in a GeoCoordinate (i.e., the latitude measure and the longitude measure) are represented the same as other "Measures" that appear in the business object model.
  • a CCT Amount 2500 is used to repiesent amounts, costs, remunerations, and fees.
  • a CCT Amount 2500 includes an amount with the corresponding currency unit.
  • CCT Amount 2500 includes the attribute currencyCode 2502.
  • the Category is complexType 2504
  • the Property is Amount 2510
  • the Representation/Association is Content 2514
  • the Type is xsd 251 S
  • the 1 ype Name is decimal 2522
  • the Length can have a maximum 22 predecimal places and 6 decimal places 2626.
  • the Category is Attribute 2506
  • the Object Class is
  • Amount 2508 the Property is Currency 2512, the Representation/Association is Code 2516, the Type is xsd 2520, the Type Name is token 2524, and the Length is three 252S.
  • the Cardinality between CCT Amount 2500 and currencyCode 2502 is one 25J0.
  • CurrencyCode 2502 is mandatory 2532. CurrencyCode 2502 requires the currency to always be specified.
  • a CCT BinaryObject 2600 includes a finite data stream of any number of characters in binary notation (octets).
  • CCT BinaryObject 2600 can be delivered to a partner using two methods: ( I) an implicit representation as an element value, or (2) as a MIME attachment withiii a message, with a unique URt-based reference to the corresponding attachment.
  • T2xkIE 1 hYORvbmFsZCBoYWQgYSBm YXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJffiUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZX JlLAphfflF 1 YWNrIHF 1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHFlYW NrIHF 1 YWNrCkUgSSBFIEkgTwo ⁇ /BinaryObject>.
  • CCT BinaryObject 2600 An example of a reference to CCT BinaryObject 2600 that is delivered as a MIME attachment within a message is:
  • CCT BinaryObject 2600 The element value of CCT BinaryObject 2600 is based on the XML-scheme-specific built-in data type xsd:base64binary. This enables any binaiy data to be represented using base64 encoding. This is done using the base64 Content-Transfer-Encoding procedure.
  • the structure of CCT BinaryObject 2600 is depicted in Figure 26.
  • BinaryObject 2600 includes attributes mimeCode 2602, charSetCode 2604, format 2606, filename 2608, and URI 2610.
  • CCT BinaryObject 2600 the Category is complex-Type _ 2612
  • the Property is Binary-Object 2634
  • the Representation/Association is Content 2646
  • the Type is xsd 265S
  • the Type Name is base64binary 2670.
  • MimeCode 2602 identifies the medium type (image, audio, video, application) ofthe binaiy content according to the MIME type definition in IETF RFC 2046 and the corresponding MIME type recommendations.
  • the Category is Attribute 2614
  • the Object Class is Binary-Object 2625
  • the Property is mime 2636
  • the Representation/Association is Code 2648
  • the Type is xsd 2660
  • the Type Name is token 2672
  • the Cardinality may be 0 or 1 2680.
  • Mimecode 2602 is necessary when CCT BinaryObject 2600 is represented as an element value (see 2688).
  • CharSetCode 2604 identifies the specific character set of text data.
  • CharSetCode 2604 the Category is Attribute 2616, the Object Class is Binary-Object 2626, the Property is Character Set 2638, the Representation/Association is Code 2650, the Type is xsd 2662, the Type Name is token 2674, and the Cardinality may be 0 or 1 2680.
  • CharSetCode 2604 is necessary when CCT BinaryObject 2600 is represented as an element value and comprises text data (see 2690).
  • Format 2606 describes the format ofthe binary content if the format is not clear or unique from the "mimeCode.”
  • the Category is Attribute 2618
  • the Object Class is Binary-Object 2628
  • the Property is Format 2640
  • the Representation/Association is Text 2652
  • the Type is xsd 2664
  • the Type Name is token 2675
  • the Cardinality may be 0 or 1 2684.
  • Fo ⁇ nat 2606 may be optional (see 2692).
  • Filename 260S contains the corresponding name or file name ofthe binary content according to the MEVIE protocol.
  • the Category is Attribute 2620
  • the Object Class is Binary-Object 2630
  • the Property is Filename 2642
  • the Representation/Association is Text 2654
  • the Type is xsd 2666
  • the Type Name is string 2676
  • the Cardinality is may be 0 or 1 2686.
  • Filename 2608 is not defined in ebXML CCTS 1.8, but it is to be submitted. Filename 2608 also conforms with IETF RFC 1341 (see 2694).
  • URI 2610 references the physical location of CCT BinaryObject 2600 if this is represented as a MIME attachment in a SOAP message or in an ebXML-MSG message.
  • the syntax of the URI is defined in the IETF RFC 2396 recommendation and is as follows: ⁇ scheme>. ⁇ scheme-specific part>.
  • the Category is Attribute 2622
  • the Object Class is Binary-Object 2632
  • the Property is Uniform Resource 2644
  • Identifier 2656 the Type is xsd 2668, and the Type Name is anyURI 2678.
  • URI 2610 is necessary when referencing a remote CCT BinaryObject 2600 (see 2696).
  • MIME types are available for mimeCode 2602.
  • one MIME type may be iso-8859-n, where n is a placeholder for the number of the relevant ISO character set from 1 to 9.
  • Another example MIME type is us-ascii.
  • Various URI schemes are also available for the scheme -specific part in the URI, as enumerated by the IANA.
  • one available scheme is ci ⁇ J which is a content identifier.
  • Another available scheme is uuid, which is a Universal Unique Identifier Scheme.
  • CCT BinaryObject 2600 can be used for binary data and all types of binary files. This includes graphics (such as diagrams, mathemadc curves, and the like), pictures (such as photos, passport photos, and the like), sound recordings, video recordings, and documents in binary notation (such as PDF, DOC, and XLS files).
  • graphics such as diagrams, mathemadc curves, and the like
  • pictures such as photos, passport photos, and the like
  • sound recordings such as PDF, DOC, and XLS files.
  • CCT BinaryObject 2600 is BinaryObject. Additional secondary Representation/Associations may be Graphic, Picture, Sound and Video.
  • the useful data in Binary Object 2600 may be delivered either as an element value using base64 octet representation or as a MIME attachment.
  • CCT BinaryObject 2600 is not used to reference a file that is located on a Web server.
  • the global data type "WebAddress" is available for this purpose.
  • the URI 2610 may reference the corresponding "Content ID" of the respecti ⁇ 'e MIME attachment.
  • URI scheme cid may be used, which identifies a freely defined "Content ID”.
  • URI scheme uuid may also be used for this purpose. Uuid identifies a unique identification in accordance with UUED guidelines.
  • a CCT Code 2700 is a character string of letters, numbers, special characters (except escape sequences), and symbols. It represents a definitive value, a method, or a property description in an abbreviated or language-independent form.
  • CCT Code 2700 includes Attributes listID 2702, listVersionlD 2704, listAgencyID 2706, listAgency-SchemeTD 2708 : and listAgency-SchemeAgencylD 2710.
  • the Categoiy is ' complexType 2712
  • the Property is Code 2734
  • the Representation/Association is Content 2746
  • the Type is xsd 2758
  • the Type Name is token 2770.
  • ListID 2702 identifies a list of the codes that belong together. ListID 2702 is unique within the agency that manages this code list. For listID 2702, the Category is Attribute 2714, the Object Class is CodeList 2724, the Property is Identification 2736, the Representation/Association is Ide ⁇ tifier 2748, the Type is xsd 2760, the Type Name is token 2772, and the Cardinality is may be 0 or 1 2782.
  • the attribute ListID may be optional (see 2792).
  • ListVersionlD 2704 identifies the version of a code list. For listVersion ID 2704, the Categoiy is Attribute 2716, the Object Class is CodeList 2726, the Property is Version 2738, the Representation/Association is Identifier 2750, the Type is xsd 2762, the Type Name is token 2774, and the Cardinality may be 0 or 1 2784.
  • the attribute ListVersionlD may be optional (see 2792).
  • ListAgencyID 2706 identifies the agency that manages the code list. The agencies from DE 3055 are used as the default (without roles). For listAgencyID 2706, the Category is Atribute 2718, the Object Class is CodeListAgency 2728, the Property is Identification 2740, the Representation/ Association is Identifier 2752, the Type is xsd 2764, the Type Name is token 2776, and the Cardinality is may be 0 or 1 2786. The attribute ListAgencyID may be optional (see 2796). ListAgencySchemeID 2708 identifies the identification scheme that represents the context that is used to identify the agency.
  • the Categoiy is Attribute 2720
  • the Object Class is CodeListAgency 2730
  • the Property is Scheme 2742
  • the Representation/Association is Identifier 2754
  • the Type is xsd 2766
  • the Type Name is token 2778
  • the Cardinality is may be zero or one 2788.
  • the attribute ListVersionAgencylD may be optional (see 2797).
  • ListAgencySchemeAgencyID identifies the agency that manages the listAgencySchemeID. This attribute can contain values from DE 3055 (excluding roles).
  • listAgencySchemeAgencyID 2710 the Category is Attribute 2722, the Object Class is CodeListAgency 2732, the Property is SchemeAgency 2744, the Representation/Association is Identifier 2756, the Type is xsd 2768, the Type Name- is- token 2780, and the Cardinality may be zero or one 2790.
  • the attribute listAgencySchemeAgtmcyID may be optional (see 2798).
  • the CCT Code 2700 data type is used for elements that are used in the communication between partners or systems to enable a common coded value representation in place of texts, methods, or properties.
  • This code list should be relatively stable, and not subject to frequent or significant changes (for example, CountryCode. LanguageCode, and so on). If the agency that manages the code list is not named explicitly, but is specified by using a role, this is done in the tag name.
  • Standardized codes and proprietaiy codes may be represented by CCT Code 2700.
  • listED 2702 identifies the code list for the standard code.
  • listVersionID 2704 identifies the version of the code list, and listAgencyID 2706 identifies the agency from DE 3055 (excluding roles).
  • listED 2702 For proprietary codes whose code lists are managed by an agency that is identified using a standard, listED 2702 identifies a code list for the proprietary code, listVersionID 2704 identifies a version of the code list, listAgencyID 2706 identifies standardized ID for the agency (such as the company that manages the proprietaiy code list), listAgencySchemeID 2708 identifies the identification scheme for the schemeAgencylD, and listAgencySchemeAgencyID 2710 identifies the agency from DE 2055 that manages the standardized ID 'listAgencyID'.
  • list ID 2702 identifies a code list for the proprietary code
  • HstVersionED 2704 identifies a version of the code list
  • listAgencyID 2706 identifies a proprietary ED for the agency (such as the company that manages the proprietary code list)
  • list AgencySchemeID 2708 identifies the identification scheme for the schemeAgencylD
  • listAgencySchemeAgencyID 2710 identifies 'ZZZ' which is mutually defined from DE 3055.
  • listID 2702 identifies an identification scheme for the proprietary identifier
  • HstVersionlD 2704 identifies a version of the identification scheme.
  • the role is specified as a prefix in the tag name. If there is more than one code list, listID and
  • HstVersionED can be used as attributes. No attributes are required if there is only one code list.
  • the representation term for the CCT Code 2700 is Code.
  • CCT Code 2700 is used as a basis to define a specific code GDT that combines ⁇ aits of standard code lists of different standardization organizations, and the complied lists are not disjunctive, attributes listID 2702, listVersionID 2704, and listAgencyID 2706 may be included in the GDT. Howevet, these attributes may not be required in the GDT if the compiled lists are not disjunctive but, in each interface that uses the GDT, the lists supported by the interface are disjunctive. To be able to represent values, methods, and property descriptions as code, the corresponding code list may be consistent and. unlike identifier lists, subject to very few changes to its content. In certain variations, CCT Code 2700 is not used to uniquely identify any logical or real objects.
  • a passport number is an "Identifier," because a) it identifies a (real) object, namely, a natural person, and b) the list of passport numbers is constantly growing as new passport numbers are issued.
  • a country code (CountryCode or Countryld) may be either an Identifier or a Code. The country code uniquely identifies a real object, namely, the country. However, the country code itself is also a replacement for the respective (unique) country' name Therefore, it is also a Code. Since the code list is relatively consistent, the country name should be represented as a Code. Changes are caused by political events and such changes are few in comparison to those relating to natural persons.
  • a process code (ProcessCode) is a Code, because a) it describes a method type and not an object, and b) the list of process codes seldom changes. (d) DateTime
  • a CCT DateTime 2800 is the time stamp, accurate to the second, of a calendar day.
  • An example for CCT DateTime 2800 is: the following code represents April 19, 2002 at 3:30. m Berlin:
  • CCT DateTime 2800 The structure of CCT DateTime 2800 is depicted in Figure 28.
  • CCT DateTime 2800 is simpleType 2802
  • the Property is DateTime 2804
  • the Representation/ Association is Content 2806
  • the Type is xsd 2808
  • the Type Name is dateTime 2810.
  • the CCT DateTime 2800 core component type uses the W3C built-in data type xs.d:dateThne. This is structured in accordance with the extended repiesentation of ISO S601. However, unlike in xsd:date, in certain variations, negative years or years aie not repiesented with more than 4 numeric values in "Date.” fhe extended representation may be represented as CCYY-MM-DDThh:mm:ss(.sss)Z oc CC YY-MM- DDThh:mm:ss(.sss)(+/-)hh:mm (for example, 2002-04-19T15:30:00Z or 2002-04- 19T10:30:00+05:00, respectively).
  • the extended representation uses CC for century (00 - 99); YY for year (00 - 99); MM for month (01 - 12); DD for day (01 - 28 for month 02; 01 - 29 for month 02 when the year is a leap year; 01 - 30 for months 04, 06, 09, and 11 ; 01 - 31 for months 01, 03, 05, 07, 08, 10, and 12); a hyphen between the year, month, and day; a separator "T" berween the date and time; hh for hours (00 - 23); mm for minutes (00 - 59); ss for seconds (00 - 59); sss for one or more characters after the decimal point to represent fractions of a second; a colon between the hours, minutes, and seconds; Z to specify when the represented time is also the UTC time; +hh:mm to specify when the represented time is a local time that is ahead of UTC time; and -hh:mm to specify when the represented time is a
  • the time stamp may be indicated without additional information (Z, +hh:mm, - hh:mm) relative to the coordinated world time (JJTC time). In certain variations, this time stamp is not then be converted to the respective local time and is therefore for information purposes. Ranges Day, Time, Minutes, Seconds, and Time Zone are defined for DateTime. Day represents all dates from the Gregorian calendar. Time represents exactly 24 hours (0 - 23). Minutes represents exactly 60 minutes (0 -59). Seconds represents exactly 60 seconds (0 -59). Time zone may be expressed in UTC (Coordinated Universal Time). If DateTime represents a local time, the time difference with respect to UTC time may also be specified.
  • CCT DateTime 2800 is used for exact time stamps that may contain the day and time. It may be, the creation date/time, receipt date/time, processing date/time, delivery date/time, expiry date/time, and the like.
  • the primary representation term for the CCT DateTime 2800 is DateTime. Additional secondary representation terms are Date and Time.
  • Date is a calendar representation of a particular day.
  • Time is a time stamp, accurate to the second, of a particular time.
  • the Built-in Data Type for Time is xsd:time.
  • the coordinated world time or coordinated universal time is currently the uniform basis for time specifications that are used internationally. It is based on the route of the sun and is an extremely constant time unit. The mean solar time at the Greenwich meridian can be used as an approximate guide value for UTC.
  • the Gregorian calendar is currently used primarily in the western world and is an ? ⁇ proximation of the complicated calculation of a "tropical year.”
  • the mean of the "tropical year” is 365.2422 days.
  • a CCT ElectronicAddress 2900 is a unique digital address that is represented by the Unified Resource Identifier (URI).
  • URI Unified Resource Identifier
  • An example for CCT ElectronicAddress 2900 in http format is: ⁇ Address> www.sap.com/InterfaceRepository/ElectronicAddresses/ description.htm ⁇ /Address>
  • CCT ElectronicAddress 2900 includes attributes protocolDD 2902 and languageCode 2904.
  • the Category for CCT ElectronicAddress 2900 is complexType 2906, the Property is Electronic Address 2916, the Representation/Association is Content 2922, the Type is'xsd 2928 and the Type Name is anyURI 2934.
  • protocolID 2902 For protocolID 2902, the Category is Attribute 2908, the Object Class is ElectronicAddress 2912, the Property is Protocol 2918, the Representation/Association is Identifier 2924, the Type is xsd 2930, the Type Name is token 2936, and the Cardinality between the CCT Electronic Address 2900 and protocolID 2902 is zero or one 2942.
  • the protocoll ⁇ Attribute 2902 may be optional (see 2946).
  • the Category is A.ttribute 2908
  • the Object Class is olectronicAddress 2914
  • the Property is Langauge 2920
  • the Representation/Association is Code 2926
  • the Type is xsd 2932
  • the Type Name is language 2938
  • the Length is from two to nine 2940
  • the Cardinality between CCT Electronic Address 2900 and languageCode 2904 is zero or one 2944.
  • the langaugeCode Attribute.2904 may be optional (see 2948).
  • CCT Electronic Address 2900 is specified in the IETF RFC 2396.
  • a UJRJ consists of the scheme (in other words, how to access a resource), followed by-a-col ⁇ n and the scheme-specific part.
  • the scheme-specific part is relevant for the service that is connected to the particular scheme.
  • a resource can have multiple IJPJs.
  • One reason may be that a resource exists physically at multiple locations, due to mirroring, or it may be rddressed using different protocols, which are specified by the scheme name. For example, a file can be referenced using http and ftp.
  • a URl is therefore generally constructed as ⁇ scheme>: ⁇ scheme-specific part>
  • Additional URI schemes that are currently not lequired include Gopher, News, nntp, + elne1, wais, prospere, z39.50s, z39.50r, vemmi, service, imap, acap, rtsp, tip, pop, data, dav, opaquelocktoken, sip, tel, fax, modem, Idap, soap.beep, soap.beeps, urn, go, afs, tn3270, and mailserver.
  • URI schemes are not sufficient to determine the address protocol, one can either apply for another URI scheme in accordance with the guidelines of IETF RFC 2717, or define the corresponding protocol type more exactly by specifying the "piOt ⁇ colID" attribute as well.
  • the codes from the UN/EDIFACT DE 3155 "Communication Address Code Qualifier" code list are used. These codes include AB, AF, AN, AO, EM, EI, FT, GM 5 IM, SW, and XF.
  • AB refers to Communications number assigned by Societe Internationale de Telecommunications Aeronautiques (SITA).
  • AD refers to the AT&T mailbox identifier.
  • AF refers to the switched telecommunications network of the United States Department of Defense.
  • AN refers to the ODETTE File Transfer Protocol.
  • AO refers to identification of the Uniform Resource Location (URL) Synonym: World wide web address.
  • EM refers to the Electronic Mail Exchange of mail by electronic means (SMTP).
  • EI refers to the number identifying the service and service user of an EDI transmission.
  • FT refers to the file transfer access method according to ISO.
  • GM refers to the GEIS (General Electric Information Service) mailbox.
  • IM refers to the Internal mail address/number.
  • SW refers to communications address assigned by Society for
  • attribute languageCode 2904 may be used to represent the language of the attachment in accordance with IETF RFC 1766 or IETF RFC 3066.
  • CCT ElectronicAddress 2900 is a core component type that can be used to represent global data types (GDTS) for email addresses, Web sites, and documents or information provided on Web sites.
  • the representation term for the CCT ElectronicAddress 2900 is ElectronicAddress.
  • CCT ElectronicAddress 2900 is not used as a reference component for binary data that is sent as an additional MIME attachment.
  • the CCT BinaryObject 2900 is available for this purpose.
  • a CCT Identifier 3000 is a unique identification of an object within an identification scheme that is managed by an agency. There may be multiple identification schemes for identifying an object.
  • CCT Identifier 3000 includes Attributes schemeID 3002, scheme VersionID 3004, schemeAgencyID 3006, schemeAgency-SchemelD 3008, and scheme Agency-Scheme Agency ID 3010.
  • the Category is complexType 3012
  • the Object Class is Identifier 3024
  • the Property is identifier 3036
  • the Representation/Association is Content 3048
  • the Type is xsd 3060
  • the Datatype is token 3072.
  • SchemeID 3002 identifies an identification scheme.
  • the identification scheme repiesents the context that is used to identify an object.
  • SchemeID is unique within the agency that manages this identification scheme.
  • the Category is Attribute 3014
  • the Object Class is Identifications cheme 3026
  • the Property is Identification 3038
  • the Representation/ Association is Identifier 3050
  • the Type is xsd 3062
  • the Datatype is token 3074
  • Length is from one to sixty 3084.
  • the Cardinality between the CCT Identifier 3000 and schemeID 3002 is zero or one 3090.
  • the schemeID attribute 3002 may b « optional (see 3095).
  • SchemeYfcisionID 3004 identifies the version of an identification scheme.
  • the Category is Attribute 3016
  • the Object Class is IdentiticationScheme 3028
  • the Property is 3040
  • the Representation/ Association is Identifier 3052
  • the Type is xsd 3064
  • the Data-type is token 3076
  • the Length is from one to fifteen 3086.
  • the Cardinality between the CCT Identifier 3000 and SchemeVersion ID is zero or one 3091.
  • the schemeVersionlD attribute 3004 may be optional (see 3096).
  • SchemeAgencyID 3006 identifies the agency that manages an identification scheme.
  • the agencies from DE 3055 are used as the default, but in certain variations the roles defined in DE 3055 aie not used.
  • the Category is Attribute 301 S
  • the Object Class is IdentificationScheme-Agency 3030
  • the Property is Identification 3042
  • the Representation/Association is Identifier 3054
  • the Type is xsd 3066
  • the Datatype is token 3078
  • Length is between one to sixty 3087.
  • the Cardinality between the CCT identifier 3000 and schemeAgencyID 3006 is zero or one 3092.
  • the schemeAgencyID attribute 3006 may be optional (see 3097).
  • SchemeAgencySchemeID 3008 identifies the identification scheme that represents the context that is used to identify the agency.
  • the Category is Attribute 3020
  • the Object Class is IdentificationScheme-Agency 3032
  • the Property is Scheme 3044
  • the Representation/ Association is Identifier 3056
  • the Type is xsd 3068
  • the Datatype is token 3080
  • the Length is from one to sixty 3088.
  • the Cardinality between CCT Identifier 3000 and schemeAgencySchemeID 3008 is zero or one 3093.
  • the SchemeAgencySchemeID attribute 3008 may be optional (see 3098).
  • SchemeAgencySchemeAgencyID 3010 identifies the agency that manages the SchemeAgencySchemeID. This attribute can contain values from DE 3055 (excluding roles).
  • the Category is Attribute 3022
  • the Object Class is IdentificationScheme-Agency 3034
  • the Property is SchemeAgency 3046
  • the • Representation/Association is Identifier 3058
  • the Type is xsd 3070
  • the Data-type is token 3082
  • Length is three 3089.
  • the Cardinality between the CCT Identifier and SchemeAgencySchemeAgencyID 3010 is zero or one 3099.
  • SchemeAgencySchemeAgencyID attribute 3010 may be optional (see 3099).
  • the CCT Identifier 3000 data type is used for elements or attributes that are used in the communication between partners or systems to enable unique identification of logical or real objects.
  • the number of types should not be limited, but continues to grow (e.g., Produ'-Ud, OrderRL, ). New IDs are continually added.
  • Standardized ami proprietary identifiers can be represented. For standardized identifiers whose identification schemes are managed by an agency from the DE 3055 code list.
  • schemeID 3002 identifies an identification scheme for the standard identifier
  • schemeVersion ⁇ D 3004 identifies a version of the identification scheme
  • schemeAgencyID 3006 identifies an agency from DE 3055 (excluding roles).
  • proprietary identifiers whose identification schemes are managed by an agency that is .
  • schemeID 3002 identifies an identification scheme for the proprietary identifier
  • schemeVersionlD 3004 identifies a version of the identification scheme
  • schemeAgencyID 3006 identifies a standardized ID for the agency (normally lhe company that manages the proprietary identifier)
  • schemeAgencySchemeID 3008 identifies an identification scheme for the schemeAgencyID
  • SchemeAgencySchemeAgencyID 3010 identifies an agency from DE 3055 that manages standardized ID 'schemeAgencyID'.
  • schemeID 3002 For proprietary identifiers whose identification schemes are managed by an agency that is identified without the use of a standard, schemeID 3002 identifies an identification scheme for the proprietary identifier, schemeVersionlD 3004 identifies a version of the identification scheme, schemeAgencylD 3006 identifies a proprietary ID for the agency • (normally the company that manages the proprietary identifier), schemeAgencySchemeID 3008 identifies an identification scheme for the schemeAgencylD, and scheme Agency Scheme AgencyID 3010 identifies 'ZZZ' ⁇ vhich is mutually defined from DE
  • schemeID 3002 For proprietary identifiers whose identification schemes are managed by an agency that is specified using a role or not at all, schemeID 3002 identifies an identification scheme for the proprietary identifier and scheme VersionID 3004 identifies a version of the identification scheme.
  • the role is specified as a prefix in the tag name. If there is more than o ⁇ e identification scheme, schemeID 3002 and schemeVersionlD 3004 can be used as ai tributes. No attributes are required if there is one identification scheme.
  • the representation term for the CCT "Identifier" is Identifier.
  • a CCT Indicator 3100 is the binary encoded specification of a fact that has the ' value '0' or '1 ', i.e., 'true' or 'false'.
  • An example for the CCT Indicator 3100 is: ⁇ 3ridicator>true ⁇ /tndicator>.
  • the siructuvft of CCT Indicator 3100 is depicted in Figure 31.
  • CCT Indicator 3100 is simpleType 3 i 02, the Property is Indicator 3104, the Representation/Association is Content 3106, the Type is xsd 3108, and the Type Name is Boolean 3110.
  • CCT Indicator 3100 can have either the value '(rue 1 (T) or 'false 1 (O').
  • CCT Indicator 3 100 is used for binary classifications, indicators, flags, and the like.
  • the representation term for the CCT "Indicator" is Indicator.
  • CCT Measure 3200 is a physical measure value with the corresponding measurement unit.
  • Measure 3200 The structure of Measure 3200 is depicted in Figure 32.
  • the Category for CCT Measure 3200 is complex Type 3204, the Property is Measure 3210, the Representation/Association is Content 3214, the Datatype is xsd:decimal 3218, and the length is 13 predecimal digits and 6 decimal values.
  • Measure 3200 also includes attribute unitCode 3202.
  • Attribute unitCode 3202 the Category is Attribute 3206
  • the Object Class is Quantity 3206
  • the Property is Unit 3212
  • the representation term is Code 3216
  • the Datatype is xsd:token 3220
  • the length is 1 to 3 3224
  • Cardinality is one 3226.
  • Positive and negative quantities can be used by using ihe built-in data type "xsd:decimal.” Negative values may be prefixed with a negative sign ("-"). However, positive values do not require a positive sign "+” prefix. Measurement units are represented in the attribute "unitCode,” in accordance with UN/ECE Recommendation #20.
  • Measure is used for the representation of measure values with physical sizes (meters, centimeters, kilograms).
  • the Representation/Association for the CCT "Measure” is Measure.
  • Quantity is used for the definition of quantity values or units. Quantities can on the one hand be piece sizes, such as packets, containers, and the like, but also physical sizes (meters, centimeters, kilograms).
  • a CCT Numeric 3300 is a decimal value.
  • Au example of the CCT Numeric 3300 is: ⁇ NumeriOl 23.345 ⁇ /Numeric>.
  • CCT Numeric 3300 The structure of CCT Numeric 3300 is depicted in Figure 33.
  • the Category for CCT Numeric 3300 is complexType 3302, the Property is Numeric 3304, the Representation/Association is Content 3306, and the Datatype is xsd:decimal 3308. r
  • Positive and negative numeric values can be used by using the built-in data type ;; xsd:decimal.” Negative values may be prefixed with a negative sign ("-"). However, positive ⁇ 'aiues do not require a positive sign "+” prefix. The decimal sign may be represented as a period (.”").
  • the primary representation term for CCT Numeric 3300 is Numeric. Other secondary representation terms are Value, Rate, and Percent.
  • CCT Numeric 3300 is not used for an indication of quantity, measure or amount.
  • CCT Quantity 3400 is a quantity with the corresponding quantity unit.
  • CCT Quantity 3400 includes attribute unitCode 3402.
  • the Category is Complex Type 3404
  • the Property is Quantity 3410
  • the Representation/Association is Content 3414
  • the Data Type is xsd:decimal 3418
  • the Length is thirteen predecimal and six decimal places 3422.
  • Attribute unitCode 3402. the Category is Attribute 3406, the Object Class is Quantity 3406, the Property is Unit 3412, the Representation/Association is Code 3416. the Datatype is xsd:token 3420, and the Length is from one to three 3424. The Cardinality between the CCT Quantity 3400 and unitCode 3402 is one 3426. The attribute unitCode 3402 is mandatory (see 3428).
  • Positive and negative quantities can be used by using the built-in data type "xsd:decimal.” Negative values may be prefixed with a negative sign ("-"). However, positive values do not require a positive sign "+” prefix. Measurement units are represented in the attribute "unitCode,” in accordance with UN/ECE Recommendation #20 or Xl 2 355.
  • CCT Quantity 3400 is used for the representation of quantity values or units. This can involve physical sizes (meters, centimeters, kilograms) or piece sizes, such as packets, containers, and the like.
  • the representation term for the CCT Quantity 3400 is Quantity.
  • CCT Quantity 3400 should not be confused with Measure.
  • Measure is used for the definition of physical properties, such as sizes (temperature, lengths, and the like.) and weights of a part, product or article.
  • a CCT Text 3500 is a character string with an optional language specification:
  • CCT Text 3500 includes Attribute languageCode 3502.
  • the Category is complexType 3504
  • the Property is Text 3508
  • the Representation/ Association is Content 3512
  • the Type is xsd 3516
  • the Type Name is string 3520
  • the Length is infinity 3524.
  • languageCode 3502 can be used to show the language of the attachment in accordance with IETF RFC 1766 or IETF RFC 3066.
  • the Category is Attribute 3506, the Property is Language 3510, the Type is xsd 3518, the Type Name is language 3522, and the Length is from two to nine 3526.
  • the Cardinality between the CCT Text 3500 and languageCode 3502 is zero or one 3528. Attribute languageCode 3502 may be optional (see 3530).
  • the primary representation term for the CCT Text 3500 include Amount, BinaryObject, Code, DateTime, Identifier, Indicator, Measure, Numeric, Quantity, and Text.
  • Additional secondary representation terms include Graphic, Picture, Sound, Video, Date, Time, Value, Rate, Percent, and Name.
  • the character length for CCT Text 3500 is not defined.
  • the GDT AcceptanceStatusCode 3600 is a coded representation of the status of the acceptance by a communication partner regarding a business transaction that has been transmitted to that partner.
  • An example for GDT AcceptanceStatusCode 3600 is: ⁇ AcceptanceStatusCode>AP ⁇ /AcceptanceStatusCode>.
  • GDT AcceptanceStatusCode 3600 The structure of GDT AcceptanceStatusCode 3600 is depicted in Figure 36.
  • the Property is Acceptance Status Code 3602
  • the Representation/Association is Code 3604.
  • the Type is CCT 3606,
  • the Type Name is Code 3608.
  • the Length is two 3610.
  • AcceptanceStatusCode CCT 3600 may be restricted (see 3612).
  • GDT AcceptanceStatusCode 3600 may be a selection from the UN/EDIFACT code list DE 4343.
  • Three codes that may be used are AP, AJ, and RE.
  • AP means the business transaction transmitted by the communication partner has been accepted
  • AJ means a decision regarding the business transaction transmitted bj' the communication partner has not (yet) been made
  • RE means the business transaction transmitted by the communication partner has been rejected.
  • GDT AcceptanceStatusCode 3600 may be used as a business status instead of as a technical acknowledgment of a message. GDT AcceptanceStatusCode 3600 also may be used as an immediate response to individual messages in bilateral negotiation processes between communication partners.
  • GDT AcceptanceStatusCode 3600 is a proprietary selection from the UN/EDIFACT code list DE 4343. Addition of codes to this selection from the code list may require the approval of the Process Integration Council (PIC).
  • PIC Process Integration Council
  • a GDT AccountingObjectSet 3700 is a set of different account assignment objects.
  • An account assignment object is a business object to which changes in value from business transactions may be assigned in accounting.
  • An example of GDT AccountingObjectSet 3700 is: ⁇ AccountingObjectSet>
  • GDT AccountingObjectSet 3700 includes an element CostCenterID 3702.
  • the Object Class is Accounting Object Set 3706 and the Representation/ Association is Details 3712.
  • CostCenterID 3702 the Category is Element 3704, the Object Class is Cost
  • the Cardinality between the GDT AccountingObjectSet 3700 and CostCenterID 3702 is zero or one 3722.
  • the data type GDT AccountingObjectSet 3700 provides the identifier for multiple types of account assignment objects including cost center (organizational unit for which costs arise), sales order, project, asset, task, funds center, and profit center. Identifiers are optional, but at least one identifier may be specified.
  • the data type GDT AccountingObjectSet 3700 may be used for account assignment, i.e., to assign an amount or quantity to a set of account assignment objects.
  • the amount or quantity is assigned to account assignment objects of the GDT AccountingObjectSet 3700 according to accounting rules. For example, expenses from the purchase of office materials can be transferred to Accounting once the incoming invoice for the materials has been checked and then assigned to a cost center CClOOO and a profit center PC3O5O there.
  • Applications that distribute an amount to several Accou ⁇ tingObjectSets (e.g.. as percentages) may perform this distribution themselves and transfer the partial amounts, each with a separate AccountingObjectSet, to accounting.
  • An example of a percentage distribution to several AccountingObjectSets is 40% to cost center CClOOO and profit center PC3050, 20% to cost center CC2000 and task IO0815, and 40% to cost center CC 3000
  • a GDT ActionCode 3802 is a coded representation of an instruction to the recipient of a message about how to process a transmitted business object.
  • ActionCode 3802 The structure of ActionCode 3802 is depicted in Figure 38.
  • the Property is Action 3804
  • the Representation/Assocation is Code 3806
  • the Type is CCT 3808
  • the Type Name is Code
  • the Length is two 3812.
  • GDT ActionCode 3802 may be a restricted GDT (see 3814).
  • GDT ActionCode 3802 can have a value from 01 to 06.
  • the name for code 01 is Create and means that the element is to be created at the recipient. The element does not exist at the recipient. The element ID and data is transferred.
  • the name for code 02 is Change and means that the element is to be changed at the recipient. The element exists at the recipient. The element ID and data is transferred.
  • the name for the code 03 is Delete and means the element is to be deleted at the recipient. The element exists at the recipient. The element ID is transferred; data is transferred with the exception of elements that are mandatory due to their cardinality.
  • the name for the code 04 is Save and means the element is to be saved at the recipient. The element can exist at the recipient. If the element already exists there, it is changed.
  • the name for code 05 is Pemove and means the element is to be deleted at the recipient. The element can-exis! at the recipient. If it exists, it is deleted. The element ID is transferred; data is not hansferred with the exception of elements that are mandatory due to their cardinality.
  • the name for code 06 is No Action and means that no action is to be carried out for the element at the recipient. The element exists at the recipient. The element ID and data is transferred.
  • ActionCodes may be used under one another in a hierarchy of elements.
  • the following table lists the combinations that may be allowed (X) and not allowed (-).
  • note (1) indicates that the code can have the meaning of the code "01 " (Create).
  • Note (2) in the table indicates that, to ensure compatibility with regard to enhancements, code "04" (Save) is allowed because this code is the default code if no code is transferred.
  • a sender preferably does not set this code.
  • a recipient preferably handles this code as a code "06" (No Action).
  • no further codes occur under code "03" (Delete) or "05” (Remove) because, apart from the element ID, no further data is transferred.
  • a recipient checks the existence of an element using the rules described for the individual codes and generates an error if necessary.
  • a recipient checks the validity of the codes in a hierarchy of elements according to the rules described and generates an error if necessary.
  • a recipient ignores elements and ActionCodes transferred under a code "03" (Delete) or "05 (Remove) and behaves as if these elements and ActionCodes had not been transferred.
  • a syntax check is allowed for these elements.
  • the actions requested at the recipient can have names that are typically used in the business context of a message, as long as this does not change the semantics of the
  • ActionCodes defined above For example, "Annul” or “Cancel” can be used instead of "Delete”.
  • An ActionCode is an attribute of the element to which it refers.
  • the ActionCodes "01" (Create), "02” (Change), "03” (Delete), and "06” (No Action) may model strict semantics that lead to errors at the recipient if the elements corresponding to the actions requested by the sender exist ("Ol") or do not exist ("02", “03", ' 06") ai the recipient. Using strict semantics, therefore, may require that the sender have and use information about the messages it has already sent.
  • the ActionCodes "04" (Save) siid "05” (Remove) model soft semantics that, in a variation, do not lead to errors if the respective elements do not exist at the recipient. These soft semantics, therefore, do not require that the sender have and use information about the messages it has already 'sent.
  • an ActionCode that is not filled in a message instance or does not exist in an interface may be assumed to be "04" (Save). This ensures compatibility when enhancing interfaces to include an ActionCode.
  • the action at the top level may be represented in the name of the message type rather than by an ActionCode.
  • These messages behave semantically as if the ActionCode were at the level of the transferred BusinessTransactionDocument (for example: a message of the message type PurchaseOrderChangeRequest behaves semantically as if an ActionCode "02" (Change) were specified at the PurchaseOrder level).
  • An ActionCode may be used with a CompleteTransmissionlndicator for the parent element.
  • the ActionCode can also be used for an element whose parent element does not have a CompleteTransmissionlndicator. In this case, the child elements of the parent element are transferred, not just the changed child elements.
  • the ActionCode may be used for elements that remain uniquely identifiable across several messages in a business process or that can only occur once in a message (cardinality 0..1 or 1). If an element cannot be clearly identified, it is documented explicitly when the ActionCode is used.
  • the ActionCodes "03" (Delete) and "05" (Remove) do not stipulate that the recipient delete the respective element physically. However, once the element has been deleted, the recipient application handles further transmitted ActionCodes as if the element has been physically deleted. For example, in the case of the ActionCode "01" (Create), it is possible to create a new element with the same identification as the deleted element. Exceptions to this ActionCode behavior are explained and documented in the corresponding description of the interface or message type.
  • a GDT Activelndicator 3902 indicates whether an object is commercially active and whether it can be used in a process or not.
  • An example of GDT Activelndicator 3902 is: ⁇ Acave ⁇ ndicator>true ⁇ / Activelndicator>. i '
  • GDT Activelndicator 3902 The structure of GDT Activelndicator 3902 is depicted in Figure 39.
  • the Property is Active Indicatoi 3904
  • thu Representation/ Association is Indicator 3906
  • Type is CCT:.mdicator 3908.
  • GDT Activelndicator 3902 can . have values 1 (true) or 0 (false). True means the object is active and false means the object is not active.
  • GDT Activelndicator 3902 is used to label objects that can be commercially active or inactive, for example, sources of supply. In the context of an interface, there may be a description of which object the GDT Activelndicator 3902 refers to and what it means in terms of business. (e) Address
  • a GDT Address 4000a contains structured information about types of addresses. This information includes details about addressees, the postal address, and the physical location and communication connections.
  • GDT Address 4000a includes elements OrganisationFormattedName 4002a, PersonName 4003a,
  • FunctionalTitleName 4004a contains the function of a contact person and can be a pai t of the address of the contact person in the organization. For die FunctionalTitleName ⁇ 004a, the Category is Element 4004b, the Object Class is Address 4004c.
  • DepartmentName 4005a contains the department of a contact person and can be a part of the address of the contact person in the organization.
  • the Category is Element 4005b
  • the Object Class is Address 4005c
  • the Property is Department Name 4005d
  • the Representation/ Association is Name 4005e
  • the Type is CCT 4005f
  • the Type Name is text 4005g
  • the Length is from zero to forty 4005h.
  • the Cardinality between the GDT Address 4000a and DepartmentName 4005a is zero or one 4005i. DepartmentName may be restricted (see 4005j).
  • Office 4006a contains information that describes the working environment of a contact person as well as information for addressing or identifying this person within the organization.
  • the Category is Element 4006b.
  • me Object Class is Address 4006c
  • the Property is Office 4006d
  • the Representation/Association is Details 4006e.
  • the Cardinality between the GDT Address 4000a and Office 4006a is zero or one 4006f.
  • Office can also comprise BuildingID 4007a, FloorID 400Sa, RoomID 4009a, InbouseMailID 4010a, and CorrespondenceShortName 401 ] a.
  • BuildingID 4007a is the number or ID of the building in the address of a contact person.
  • the Category is Element 4007b
  • the Object Class is Office 4007c
  • the Property is Building Identification 4007d
  • the Representation/ Association is
  • the Type is CCT 4007f
  • the Type Name is identifier 4007g
  • the Length is from one to ten 4007h.
  • the Cardinality between the GDT Address 4000a and BuildingID 4007a is zero or one 4007i. BuildingID may be restricted (see 4007j).
  • FloorID 4008a refers to the floor of the building in the address of a contact person.
  • the Category is Element 4008b
  • the Object Class is Office 4008c
  • the Property is Floor Identification 4008d
  • the Representation/Association is Identifier 4008e
  • the Type is CCT 4008f
  • the Type Name is Identifier 4008g
  • the Length is from one to ten 4008h.
  • the Cardinality between the GDT Address 4000a and FloorID 4008a is zero or one 4008i.
  • FloorID may be restricted (see 4008j).
  • RoomID 4009a specifies the ioom number in the address of a contact person". For
  • .RoomID 4009a the Category is Element 4009b, the Object Class is Office 4009c, the- Property is Room Identification 4009d, the Representation/Association is Identifier 4009e, the Type is CCT 4009f, the Type Name is Identifier 4009g, and the Length is from one to ten 4009h.
  • the Cardinality between the GDT Address 4000a and RoomID 4009a is zero or one 4009i. RoomID may be restricted (see 4009j).
  • InhouseMaiiID 4010a specifies an internal mail address.
  • the Category is Element 4010b
  • the Object Class is Office 4010c
  • the Property is Inhouse Identification 401Od
  • the Representation/Association is Identifier 401Oe
  • the Type is CCT 401Of
  • the Type Name is Identifier 401Og
  • the Length is from one to ten 401Oh.
  • the Cardinality between the GDT Address 4000a and InhouseMail [D 4010a is zero or one 401 Oi. InHouseMailID may be restricted (see 401 Oj).
  • CorrespondenceShortName 401 Ia is the short name of the contact person for use in correspondence. This short name can be used both internally and externally.
  • the Category is Element 401 Ib
  • the Object Class is Office 401 ]
  • the Property is Correspondence Short Name 401 Id
  • Representation/ Association is Name 401 Ie
  • the Type is CCT 401 If, the Type Name is text 401 Ig, and the Length is from zero to ten 401 Ih.
  • the Cardinality between the GDT Address 4000a and CorrespondenceShortName 401 Ia is zero or one 4011 i. CorrespondenceShortName may be restricted (see 401 Ij).
  • PhysicalAddress 4012a contains the postal address data of a physical location. For the PhysicalAddress 4012a, the Category is Element 4012b, the Object Class is Address 4012c, the Property is Physical Address 4012d, and the Representation/ Association is Details 4012e.
  • the Cardinality between the GDT Address 4000a and PhysicalAddress 4012a is zero or one 4012f.
  • PhysicalAddress 4012a also comprises CountryCode 4013a, RegionCode 4014a, StreetPostalCode 4015a, POBox PostalCode 4016a, CompanyPostaICode 4017a, CityName 4018a, AdditionalCityName 4019a, DistrictName 4020a, POBoxID 4021a, POBoxIndicator 4022a, POBoxCountryCode 4023a, POBoxRegionCode 4034a, POBoxCityName 4035a, StreetName 4036a, StreetPrefixName 4037a, StreetSuffixName 4038a, HouseID 4039a, AdditionalHouseID 4040a, BuildingID 4041a, FloorID 4042a, RoomID 4043a, CareOfName 4044a, and Description 4045a.
  • the category is Element (4013b- 4045b) and the Object Class is Physical Address (4013c-4045c).
  • CountryCode 4013a is the country code of the address in accordance with ISO 3166- 1.
  • the Property is CountryCode 40.13d
  • Representation/Association is Code 4013e
  • the Type is GDT 4013 f
  • the Type Name is ⁇ ' CouitryCode 4013g.
  • the Cardinality between the GDT Address 4000a and CountryCode ' 4013a is zero or one 4013h.
  • RegionCode 4014a is the code for the region of the country in the address. This specification may be part of the address, e.g., in the US. For RegionCode 4014a, the
  • StreetPostalCode 4015a is the zip code in the street address.
  • the rules for zip codes are country-specific.
  • StreetPostalCode 4015a the Property is Street Zip Code 4015d
  • the Representation/Association is Code 4015e
  • the Type is CCT 4015f
  • the Type Name is Code 4015g
  • the Length is from one to ten 4015h.
  • the Cardinality between GDT Address 4000a and StreetPostalCode 4015a is zero or one 4015i. StreetPostalCode 4015a may be restricted (see 4015j).
  • POBoxPostalCode 4016a is the box zip code.
  • the POBoxPostalCode 4016a the
  • CompanyPostalCode 4017a is the zip code of the company when the receiver is an organization with its own zip code.
  • CompanyPostalCode 4017a the Property is Company Zip Code 4017d
  • the Representation/Association is Code 4017e
  • the Type is CCT 4017f
  • the Type Name is Code 4017g
  • the Length is from one to ten 4017h.
  • the Cardinality between GDT Address 4000a and CompanyPostalCode 4017a is zero or one 4017i.
  • CompanyPostalCode 4015a may be restricted (see 4017j).
  • CityName 401Sa is the name of the city in the address.
  • the Property is City Name 4018d
  • the Representation/Association is Name 4018e
  • the Type is CCT 4018f
  • the Type Name is Text 4018g
  • the Length is from zero to forty 401 Sh.
  • the Cardinality between GDT Address 4000a and CityName 4018a is zero or one 4018i.
  • CityName 4018a may be restricted (see 4018jV
  • AdditionalCityName 4019a is the name of the city of residence if it differs from the city in the postal address. AdditionalCityName may have different semantics (field HOME ClTY in the ADRC) and therefore may not be handled using Cardinality. It is analogous to AdditionaJHouselD. For AdditionalCityName 4019a, the Property is ⁇ ,
  • Additional City Name 4019d the Representation/Association is Name 4019e
  • the Type is CCT 4019f
  • ihe Type Name is Text 4019g
  • the Length is from zero to forty 401%.
  • the Cardinality between the GDT Address 4000a and AdditionalCityName 4019a is zero or one 4019i .
  • AdditionalCityName 4019a may be restricted (see 4019j).
  • DistrictName 4020a is the name of the district. For DislrictName 4020a, the
  • Ptoperty is District Name 4020d
  • the Representation/ Association is Name 402Oe
  • the Type is CCT 402Of
  • the Type Name is Text 402Og
  • the Length is from zero to forty 402Oh.
  • the Cardinality between the GDT Address 4000a and DistrictName 4020a is zero or one 402Oi. DistrictName 4020a may be restricted (see 402Oj).
  • POB ⁇ xID 4021a is the number of the post-office box. For POBoxED 4021a, the
  • PO Box Identification 4021d the Representation/Association is Identifier 402 Ie
  • the Type is CCT 402 I f
  • the Type Name is Identifier 402 Ig
  • the Length is from one to ten 402 Ih.
  • the Cardinality between the GDT Address 4000a and POBoxID 4021a is zero or one 402 Ii. CityName 4021a may be restricted (see 402Ij).
  • POBoxIndicator 4022a specifies whether the post-office box has a number that is unknown.
  • the Property is PO Box Indicator 4018d
  • the Representation/Association is Indicator 401 Se
  • the Type is CCT 401 Sf
  • the Type Name is Indicator 401Sg.
  • POBoxCountryCode 4023a is the country code for the post-office box in the address.
  • the Property is PO Box Country Code 4023d
  • the Representation/ Association is Code 4023e
  • the Type is GDT 4023f
  • the Type Name is CountryCode 4023 g.
  • the Cardinality between GDT Address 4000a and POBoxCountryCode 4023a is zero or one 4023h.
  • POBoxRegionCode 4024a is the code for the region of the country for the post- office box in the address.
  • the Property is PO Box Region Code 4024d
  • the Representation/Association is Cede 4024e
  • the Type is GDT -!024f
  • the Type Name is Region Code 4024g.
  • the Cardinality between GDT Address ⁇ 100Oa and POBoxRegionCode 4024a is zero or one 4024h.
  • POBoxCityName 4025a is the name of the city for the post-office box in the address.
  • the Property is PO Box City name 4025d
  • the. Representation/Association is Name 4025e
  • the Type is CCT 4025f
  • the Type Name is Text 4025g
  • the Length is from zero to forty 4025h.
  • the Cardinality between GDT Address 4000a and POBoxCityName 4025a is zero or one 4025i.
  • POBoxCityName 4025a may be restricted (see 4025j).
  • StreetName 4026a is the name of the street in the address.
  • the Property is Street name 4026d
  • the Representation/Association is Name 4026e
  • the Type is CCT 4026f
  • the T ⁇ e Name is Text 4026g
  • the Length is from zero to sixty 4026h.
  • the Cardinality between GDT Address 4000a and SvreetName 4026a is zero or one 4026i.
  • POBoxCityName 4026a may be restricted (see 4026J). -
  • StreetPrefixName 4027a is an additional prefix in the address and precedes the street name in the previous line.
  • the Property is Street Prefix Name 4027d
  • the Representation/Association is Name 4027e
  • the Type is CCT 4027f
  • the Type Name is Text 4027g
  • the Length is from zero to forty 4027h.
  • the Cardinality • between GDT Address 4000a and StreetPrefixNams 4027a is from zero to two 4027i. StreetPrefixName 4027a may be restricted (see 4027j)
  • StreetSuffixName 4028a is an additional suffix in the address and comes after the street name in the subsequent line.
  • the Property is Street Suffix Name 402Sd 3 the Representation/Association is Name 402Se
  • the Type is CCT 4O28.f
  • the Type Name is Text 4028g
  • the Length is from zero to forty 402Sh.
  • the Cardinality between GDT Address 4000a and StreetSuffixName 4028a is from zero to two 402Si. StreetPrefixName 402Sa may be restricted (see '!028J).
  • HouseID 4029a is the house number for the street in the address.
  • HouseID 4029a For the HouseID 4029a, the Property is House Identification 4029d, the Representation/ Association is Identifier 4029e, the Type is CCT 4029f, the Type Name is Identifier 4029g, and the Length is from one to ten 4029h.
  • the Cardinality between GDT Address 4000a and HouseED 5 4029a is zero or one 4029i.
  • HouseID 4029a may be restricted (see 4029j).
  • AdditionalHouseU 4030a is an addition to the house number, e.g., apartment number.
  • the Property is Additional House Identification 403Od 5
  • the Representation/ Association is Identifier 403Oe
  • the Type is CCT 403Of
  • the Type Name is Identifier 403Og
  • the Length is from one to ten 403Oh.
  • the Cardinality 10 between GDT Address 4000a and AdditionalHouseID is zero or one 403Oi. AdditionalHouseID 4030a may be restricted (see 403Oj).
  • BuildingID 4031a is the number or abbreviation for a building, e.g., WDF03. JFor the BuildingID 4030a, the Property is Building Identification 403Od, the Representation/ Association is Identifier 403Oe, the Type is CCT 403Of, the Type Name is i 5 Identifier 403Og, the Length is from one to twenty 403Oh.
  • BuildingID 4031 a is zero or one 403Oi. BuildingID 4030a may be . restricted (see 403Oj).
  • FloorlD 4032a is the number of the floor in the building.
  • the Property is Floor Identification 4032d
  • the Representation/Association is Identifier 4032e
  • 0 • the Type is CCT 4032f
  • the Type Name is Identifier 4032g
  • ihe Length is from one to ten 4032h.
  • the Cardinality between GDT Address 4000a and FloorlD 4032a is zero or one 4032i.
  • FloorlD 4032a may be restricted (see 4032j).
  • RoomID 4033a is the number of the room in the building.
  • the Property is Room Identification 4033 d
  • the Representation/Association is Identifier 5 4033e
  • the Type is CCT 4033f
  • the Type Name is Identifier 4033g
  • the Length is from one to ten 4033h.
  • the Cardinality between GDT Address 4000a and RoomID 4033a is zero or one 4033i. RoomID 4033a may be restricted (see 4033J).
  • CareOfName 4034a is a different receiver when the receiver is not the same as the addressee.
  • the Property is Care of name 4034d
  • the 0 Representation/Association is Name 4034e
  • the Type is CCT 4034f
  • the Type Name is Text 4034g
  • the Length is from zero to ten 4034h.
  • the Cardinality between the GDT Address 4000a and CareOfName 4034a is zero or one 4034i.
  • CareofName 4034a may be restricted (see 4034j).
  • Description 4035 a is an addition to the address that refers to any special details.
  • the Property is Description 403Od
  • the Representation/ Association is Text 403Oe
  • the Type is GDT 403Of
  • the Type Name is Description 403Og.
  • the Cardinality between GDT Address 4000a and Description 4035a is unbounded 403Oh.
  • TaxJurisdictionCode 4036a is the tax jurisdiction code belonging to the address.
  • TaxJurisdictionCode 4036a the Category is Element 4036b, the Object Class is Address 4036c, the Property is Tax Jurisdiction Code 4036d, the Representation/Association is Code 4036e, the Type is GDT 4046f, and the Type Name is TaxJurisdictionCode 4036g.
  • the Cardinality between the GDT Address 4000a and TaxJurisdictionCode 4036a is zero or one 4036h.
  • TimeZoneDifferenceValue 4037a is the difference (in hours) between the local time zone of the location defined by PhysicalAddress 4012a and UTC (Coordinated Universal Time).
  • tbe Category is Element 4037b
  • the Object Class is Address 4037c
  • the Property is Time Zone Difference Value 4037d
  • ti»e Representation/Association is Value 4037e
  • the Type is GDT - l 037f
  • the Type Name is TimeZoneDifferenceVaiue 4037g.
  • the Cardinality between the GDT Address 4000a and TimeZoneDifference Value 4037a is zero or one 4037h.
  • GeoCoordinates 4038a contains the geographic data, i.e., longitude and latitude, specified in accordance with the WGS 84 reference system, with which a location on the globe can be dete ⁇ nined.
  • LatitudeMeasure is the geographic latitude in degrees.
  • LongitudeMeasure is the Geographic longitude in degrees.
  • the measurement unit degrees for each is specified by the attribute "unitCode” Southern latitudes are generally negative and northern latitudes are generally positive. Also, western longitudes are negative and eastern longitudes are positive. Positive values do not require a positive sign (+) for a prefix. However, negative values may have a negative sign (-) for a prefix.
  • the unitCode "DD" corresponds to the unit for the degree of an angle (UN/CEFACT Rec.
  • GeoCoordinates 4038a the Category is Element 4038b, the Object Class is Address 4038c, the Property is GeoCoordinates 4038d, the Representation/Association is GeoCoordinates 403Se, the Type is GDT 4038f, and the Type Name is GeoCoordinates 4038g.
  • the Cardinality between the GDT Address 4000a and GeoCoordinates 4038a is zero or one 403Sh.
  • Communication 4049a contains information about communication paths with which a person or organization can be reached.
  • the Category is Element 4049b, the Object Class is Address 4049c, the Property is Communication 4049d, and the Representation/Association is Details 4049e.
  • Communication 4049a is comprised of CorrespondenceLanguageCode 4040a, Telephone 4042a, MobilePhone 4047a, Facsimile 4052a, email 4058a, and Web 4063a.
  • CorrespondenceLanguageCode 4040a specifies the language for written correspondence.
  • the Category is Element 4040b
  • the Object Class is Communication 4040c
  • the Property is Correspondence
  • Language Code 404Od the Representation/Association is Code 404Oe
  • Type GDT 404Of
  • Type Name LanguageCode 404Og.
  • the Cardinality may be zero or one 404Oh.
  • Telephone 4042a contains one telephone number in each instance.
  • the Category is Element 4042b, the Object Class i.s Communication 4042c, the Property is Telephone 4042d, and ihe Representation/Association is Details 4042e.
  • the Cardinality between the GDT Address 4000a and Telephone 4042a is unbounded 4042 f.
  • Telephone is comprised of Number 4043a, NumberDetaltlndicator 4044a, NumberDescription 4045a, and NumberUsageDeniallndicator 4046a.
  • the Category is Element 4043b
  • the Object Class is telephone
  • 4043c the Property is Phone Number 4043d
  • the Representation/A ssocation is Phone Number 4043e
  • the Type- is GDT 4043 f
  • the Type Name is Phone Number 4043g.
  • the Cardinality between the GDT Address 4000a and Number 4043a is one 4043h.
  • NumberDefaultlndicator 4044a indicates whether a telephone number is the default number for the address. In certain variations, there may be a default telephone number, provided the address contains a telephone number. The default value is "false.”
  • the Category is Element 4044b
  • the Object Class is Telephone 4044c
  • the Property is Number Default Indicator 4044d
  • the Representation/Association is Indicator 4044e
  • the Type is CCT 4044f
  • Type Name is Indicator 4044g.
  • the Cardinality between the GDT Address 4000a and NumberDefaultlndicator 4044a is one 4044h.
  • NuniberDescription 4045a is an addition to the telephone number that refers to special details or that contains other unstructured information.
  • the Category is Element 4045b
  • the Object Class is telephone 4045c
  • the Property is Number Description 4045d
  • the Representation/Association is Text 4045e
  • the Type is GDT 4045f
  • the Type Name is Description 4045g.
  • the Cardinality between the GDT Address 4000a and NumberDescription 4045a is unbounded 4045h.
  • NumberUsageDenial 4046a indicates whether the telephone number may be used or 5 not. If this indicator is set to "true,” this means that, in accordance with the legal requirements of the respective country, the telephone number may not be used. There are exceptions, however. For example, return calls requested by the business partner or calls made for service purposes may still be permitted. Furthermore, it is advisable to save telephone numbers so that calls from business partners can still be identified, even if this
  • ! ⁇ indicator is set. The default is "false.”
  • the Category is Element 4046b
  • the Object Class is telephone 4046c
  • the Property is Number Usage Denial Indicator 4046d
  • tlie Representation/Association is Indicator 4046e
  • the Type is CCT 4046f
  • the Type Name is Indicator 4046g.
  • the Cardinality between the GDT Address 4000a mid NumberUsageDenial 4046a is one 4046h.
  • MobilePhone 4047a contains a mobile phone number in each instance.
  • IvIobilePhone 4047a the Category is Element 4047b, the Object Class is Communication 4047c, ihe Property is Mobile Phone 4047d, and the Representation/Association is Details 4047e.
  • the Cardinality between the GDT Address 4000a and MobilePhone 4047a is unbounded 4047f.
  • MobilePhone 4047a is also comprised of Number 4048a, 0 NumberDefaultlndicator 4049a, NTumberDescription 4050a, and NumberUsageDeniallndicator 405 Ia.
  • the Category is Element 4048b
  • the Object Class is Mobilephone 4048c
  • the Property is Phone Number 404Sd
  • the Representation/Association is Phone Number 4048e
  • the Type is GDT 4048f
  • the Type Name is Phone Number 5 4048g.
  • the Cardinality between the GDT Address ⁇ 00Oa and Number 4048a is one 404Sh.
  • NumberDefaultlndicator 4049a indicates whether a mobile phone number is the default mobile phone number for the address. In certain variations, there may be a default mobile phone number, provided the address contains a mobile phone number.
  • the Category is Element 4049b
  • the Object Class is 0 Mobilephone 4049c
  • the Property is Number Default Indicator 4049d
  • NumberDescription 4050a is an addition to the mobile phone number that refers to special details or that contains other unstructured information.
  • the Category is Element 4050b
  • the Object Class is Mobilephone 4050c
  • the Property is Number Description 405Od
  • the Representation/Association is Text 405Oe
  • the Type is 5 GDT 405Of
  • the Type Name is Description 405Og.
  • the Cardinality between the GDT Address 4000a and NumberDescription 4050a is unbounded 405Oh.
  • NumberUsageDeniallndicator 4051a indicates whether the mobile phone number may be used or not. If this indicator is set to "true," this means that, in accordance with the legal requirements of the respective country, the mobile phone number may not be used. i 0 There are exceptions, however. For example, return calls requested by the business partner or calls made for service purposes may still be permitted. Further, mobile phone numbers may be saved so that calls from business partners and the like can still be identified, even if the indicator is set.
  • the Category is Element 4051b
  • the Object Class is Mobilephone 4051c
  • the Property is Number Usage Denial Indicator 4051d
  • J 5 the Representation/Association is Indicator 4051 c
  • the Type is CCl 4051 f
  • the Type Name is Indicator 4051 g.
  • the Cardinality between the GDT Address 4000a and NumberUsageDeniallndicator 4051a is one 405 Ih.
  • Facsimile 4052a contains a fax number in each instance.
  • the Category is Element 4052b
  • the Object Class is Communication 4052c
  • the Property is 0 Facsimile 4052d
  • the Representation/Association is Dehils 4052e.
  • the Cardinality between the GDT Address 4000a and Facsimile 4052a is unbounded 4052f.
  • Facsimile 4052a is also comprised of Number 4053a, NumberDefaultlndicator 4054a, NumberDescription 4055a, and NumberUsageDeniallndicator 4056a.
  • the Category is E 4053b
  • the Object Class is Facsimile 4053c
  • 5 the Property is Phone Number 4053d
  • the Representation/ Associateion is Phone Number 4053e
  • the Type is GDT 4053f
  • the Type Name is Phone Number 4053g
  • the Cardinality between the GDT Address 4000a and Number 4053a is one 4053h.
  • NumberDefaultlndicator 4054a indicates whether a fax number is the default number for the address. In certain variations, there is a default fax number, provided the 0 address contains a fax number.
  • the Category is Element 4054b
  • the Object Class is Facsimile 4054c
  • the Property is Number Default Indicator 4054d
  • the Representation/Association is Indicator 4054e
  • the Type is CCT 4054f
  • the Type Name is Indicator 4054g.
  • the Cardinality between the GDT Address 4000a and NumberDefaultlndicator 4054a is one 4054h.
  • NumberDescription 4055a is an addition to the fax number that refers to special details or that contains other unstructured information.
  • the Category is Element 4055b
  • the Object Class is Facsimile 4055c
  • the Property is Number Description 4055d
  • the Representation/Association is Text 4055e
  • the Type is GDT 4055f
  • the Type Name is Description 4055g.
  • the Cardinality between the GDT Address 4000a and NumberDescription 4055a is unbounded 4055h.
  • NumberUsageDenial 4056a indicates whether the fax number may be used or not. If this indicator is set to "true," this means that, in accordance with the legal requirements of the respective country, the fax number may not be used. There are exceptions, however. For example, response faxes requested by the business partner or faxes sent for service purposes and the like may still be permitted. Furthermore, it is advisable to save fax numbers so that faxes sent by business partners and the like can still be identified, even if the indicator is set.
  • NumberUsageDenial 4056a the Category is Element 4056b, the Object Class is Facsimile 4056c, the Property is Number Usage Denial Indicator 4056d, the Representation/Association is Indicator 405 ⁇ e, the Type is CCT 4056f, and the Type Name is Indicator 4056g.
  • the Cardinality between rhe GDT Address 4000a and NumberUsageDenial 4056a is one 4056b.
  • Email 4058a contains an email address in each instance.
  • the Category is Element 4058b
  • the Object Class is Communication 4058c
  • the Property is Email 4058d
  • the Representation/Association is Details 4058e.
  • the Cardinality between the GDT Address 4000a and Email 4058a is unbounded 4058h.
  • Email 4058 also comprises Address 4059a, AddressDefaultlndicator 4060a, AddressDescription 4061a, and AddressUsageDeniallndicator 4062a.
  • Address 4059a specifies the email address.
  • the Category is Element 4059b
  • the Object Class is Email 4059c
  • the Property is Email Address 4059d
  • the Representation/Association is Email Address 4059e
  • the Type is GDT 4059f
  • the Type Name is Email Address 4059g.
  • the Cardinality between the GDT Address 4000a and Address 4059a is one 4053h.
  • AddressDefaultlndicator 4060a indicates whether an email address is the default email address for this address. There may be a default email address, provided there are any email addresses for this address.
  • the Category is Element 4060b
  • the Object Class is Email 4060c
  • the Property is Email Address Default Indicator 406Od
  • the Representation/Association is Indicator 406Oe
  • the Type is CCT 406Of
  • the Type Name is Indicator 406Og.
  • the Cardinality between the GDT Address 4000a and AddressDefaultlndicator 4060a is one 406Oh.
  • AddressDescription 4061a is an addition to the email address that refers to special details or that contains other unstructured information.
  • the Category is Element 4061b
  • the Object Class is Email 4061c
  • the Property is Email Address Description 406 Id
  • the Representation/Association is Text 406 Ie
  • the Type is GDT 406 If
  • the Type Name is Description 406 Ig.
  • the Cardinality between the GDT Address 4000a and AddressDescription 4061a is unbounded 406 Ih.
  • AddressUsageDeniallndicator 4062a indicates whether the e-mail address may be used oj' not. If this indicator is set to "true," this means that, in accordance with the iegal requirements of the respective country, the email address may not be used. There are exceptions, for example, responses to email enquiries may still be permitted. Furthermore, email addresses may be saved so that emails sent by business partners and the like can still be identified, even if the indicator is set.
  • the Category is Element 4062b
  • the Object Class is Email 4062c
  • Lhe Property is Email address Usage Denial Indicator 4062d
  • the Representation/Association is Indicator 4062e
  • the Type Name is Indicator 4062g.
  • the Cardinality between the GDT Address 4000a and AddressUsageDeniallndicator 4062a is one 4062h.
  • Web 4063a contains a Web address in each instance.
  • the Category is Element 4063b.
  • the Object Class is Communication 4063c
  • the Property is Web 4063d
  • the Representation/Association is Details 4063e.
  • the Cardinality between the GDT Address 4000a and Web 4063a is unbounded 4063f.
  • Web 4063a is also comprised of Address 4064a, AddressDefaultlndicator 4065a, and AddressDescription 4066a.
  • Address 4064a specifies the URI of a Web site. The length is long enough to accommodate a generated URI.
  • the Category is Element 4064 b, ihe Object Class is Web 4064c, the Property is Web Address 4064d, the Representation/Association is Address 4064e, the Type is GDT 4064f, and the Type Name is Web Address 4064g.
  • the Cardinality between the GDT Address 4000a and Address 4064a is one 4064h.
  • AddressDefaultlndicator 4065a indicates whether a Web address is the default Web address for this address. There may be a default Web address, provided the address contains a Web address.
  • the Category is Element 4065b
  • the Object Class is Web 4065c
  • the Property is Address Default Indicator 4065d
  • the Representation/Association is Indicator 4065e
  • the Type is CCT 4065f
  • the Type Name is Indicator 4065 g.
  • the Cardinality between the GDT Address 4000a and AddressDefaultlndicator 4065a is one 4065h.
  • Address Description 4066a is an addition to the Web address that refers to special details or that contains other unstructured information.
  • the Category is Element 4066b
  • the Object Class is Web 4066c
  • the Property is Address
  • GDT Address 4000a An example of GDT Address 4000a is: ⁇ Address>
  • This example address produces the following result, which can be printed out for a label-
  • the addresses of technical objects which describe a physical location, are represented by an appropriate field selection, e.g., the address of the organization without 0 OrganisationFormattedName and Communication.
  • the GDT AdjustmentReasonCode 4100 is a coded representation for the reason for an adjustment.
  • An example of GDT AdjustmentReasonCode 4100 is: ⁇ AdjustmentReasonCode>CANCELED_PROMOTION ⁇ / AdjustmentReasonCode >.
  • the structure of GDT AdjustmentReasonCode 4100 is depicted in Figure 41.
  • the illustrative code is general and can be used in many contexts.
  • the standard code list to be used in an interface depends on the particular context. In a variation, a standard code list is used. If an interface supports one of the lists or if the supported code lists are disjunctive, none of the attributes may be requiied for identification of the particular standard code lists.
  • the possible code values are subsets of the "Adjustment Reason Code List” of the "EAN.UCC XML Business Message Standards, version 1.3 (July 2003).” These include CANCELED _PROMOTION, DLSCONTINUED- PRODUCT, DISTRIBUTIONJSSUE, EXPANDEDJPROMOTION, FORWARD_BUY, INVENTORY_POLICY_CHANGE, NEWJLOCATION, NEW_PRODUCT, NEW_PR0M0T10N, ORDER.
  • a GDT Allowedlndicator 4200 indicates whether something, such as a specific procedure, operation or status, is allowed or not.
  • An example of GDT Allowedlndicator 4200 is: ⁇ LowerCaseAllowedIndicator>l ⁇ e ⁇ /LowerCaseAUowedIndicator>.
  • GDT Allowed Indicator 4200 The structure of GDT Allowed Indicator 4200 is depicted in Figure 42.
  • the Property ib Allowed 4202 the Property ib Allowed 4202.
  • the GDT Allowedlndicator 4200 can have the values true or false. True means that something is allowed while false means that something is not allowed. For each GDT Allowedlndicator 4200, what is allowed or not allowed may be indicated precisely. This is reflected in an appropriate name prefix. For example, a Negative Value Allowedlndicator specifies whether negative numeric values are allowed, while a
  • the GDT Allowedlndicator 4200 may be used to indicate whether a customer is allowed to submit an online purchase order in lower-case letters.
  • the business significance of "what is allowed" may be described for the Allowedlndicator in addition to using the name prefix.
  • a GDT Amount 4300 is an amount with the corresponding currency unit.
  • GDT Amount 4300 The structure of GDT Amount 4300 is depicted in Fig. 43.
  • the Properly is Amount 4302
  • the Representation/Association is Amount 4304
  • the Type is CCT 4306
  • the Type Name is Amount 4308.
  • GDT Amount 4300 is used Io represent amounts, costs, remunerations, and fees.
  • the amount value in GDT Amount 4300 may be represented with a maximum of 22 predecimal places and 6 decimal places. Both positive and negative amounts can be used. Amount 4300 may also include the attribute currencyCode which refers to the currency unit in accordance with the JSO 4217 three-character code. A currency may be specified. (i) AmouiitBalaucelndicator
  • a GDT AmcuntBalance ⁇ ndicdtor 4400 indicates whether an amount is a balance or :iot.
  • An example of GDT AmountBalancelndicator 4 ⁇ 00 is: ⁇ mountBalancelndicator>tme ⁇ /AmountBala ⁇ celndicator>.
  • GDT AmountBalaiicelndxator 4400 The structure of GDT AmountBalaiicelndxator 4400 is depicted in Fig. M.
  • the Property is Amount Balance 4402
  • Representation/Association is Indicator 4404, the Type is CCT 4406, and the Type Name Indicator is 4408.
  • Balancelndicator can have either the value true or false. True signifies that the amount specified is a balance False signifies that the amount specified is not a balance.
  • GDT Amount 4400 can be used to indicate whether the balance of all open receivables is transferred in a message to a party or whether the amount transferred is an individual receivable. A balance amount may also be positive or negative. In the context of an interface, the amount to which the GDT Amount 4400 refers and the business significance of the balance may be described. 0 " ) AspectID
  • a GDT AspectID 4500 is a unique identifier for an aspect.
  • An aspect determines a selection of attributes relevant for the aspect for a predefined object type.
  • An example of GDT AspectID 4500 is: ⁇ AspectID>DETAIWAspectlD>.
  • the structure of GDT AspectID 4500 is depicted in Figure 45.
  • the Object Class is Aspect 4502
  • the Property is Identification 4504
  • the Representation/Association is Identifier 4506
  • the Type is CCT 4508
  • the Type Name is Identifier 4510 and the length is from one to forty 4512.
  • a GDT AspectID 4500 can be used as the CatalogueItemAspectID to specify which properties (and their values) are to be displayed in the view for a catalog item.
  • the "LIST” aspect contains those product properties that are required to select a product from a list quickly.
  • the "DETAIL” aspect contains all the properties, while the “COMPARISON” aspect contains those that are useful for comparing the details of two products.
  • a view of a predefined object is a restriction of the object's attributes.
  • An aspect is a semantic criterion that is used to decide which attributes belong to a particular object view. When a given aspect is applied to various object types, the result is a view. For this reason, an aspect usual Iy has many different views.
  • a CCT Attachment 4600 is an arbitrary document type that is related to either the whole, message or just a particular part.
  • the structure of CCT Attachment 4600 is depicted in Figure 46.
  • Attachment 4600 includes attributes id 4612 and filename 4632.
  • the Property is Attachment 4602
  • the Representation/Association is Binary Object 4604
  • the Type is xsd 4606
  • the Type Name is normalizedString 4608.
  • the CCT Attachment 4600 is Title 4610. Attribute id 4612 uniquely identifies the binary content within the message that corresponds to the SOAP or ebXML messaging protocols.
  • the Category is Attribute 4614
  • the Object Class is Attachment 4616
  • the Property is Identification 4618
  • the Representation/Association is Identifier 4620
  • the Type is xsd 4622
  • the Type Name is string 4624
  • the Length is from one to thirty five 4626
  • the Cardinality is one 4628.
  • the CCT Id 4612 may be unique as used for references using the manifest 4630.
  • Attribute filename 4632 contains the relevant name or file name of the binary content.
  • the structure of CCT Filename 4632 is depicted in Fig. 46.
  • the Category is Attribute 4634
  • the Object Class is Attachment 4636
  • the Property is Filename 4638
  • the Representation/Association is Text 4640.
  • the Type is xsd 4642
  • the Type Name is String 4644
  • the length is up to seventy 4646
  • Cardinality is zero or one 4648.
  • CCT BinaryObject 4600 is based on the XML-scheme-specific built-in data type xsd:normalizedString and can be used to represent an intelligible title or name of the binary object.
  • the attachment may be sent in the same message in the form of a MEVIE attachment.
  • the technical referencing is done using the manifest of the respective message protocol (SOAP or ebXML messaging).
  • SOAP or ebXML messaging The value from the "id" attribute is used as the referencing code. Every attachment may have this attribute and the identifiers may be unique in the same document instance.
  • Attachments are similar to the attachments in electronic message transfer (for example, STMP).
  • the attachments may be documents that can be read by humans, such as word-processing documents, spreadsheet documents, presentation documents, and the like. These documents can be in many different formats (e.g., doc. pdf, ppt, xls, and the like.).
  • the binary data streams of Attachment should not be stored on a Web server as a file.
  • the global data type "WebAddress" is available for this purpose.
  • a CDT AttachmentWebAddress 4700 is a Web address for a document of any type that is related to the transmitted message or pait of the message, but is not itself transmitted as part of the message.
  • An example of CDT AttachmentWebAddress 4700 is: ⁇ AttathmentWebAddress>www.dbc.com/ Attachments/HelloWorld.txt ⁇ /AttachmentWebAddress>.
  • CDT AttachmentWebAddress 4700 The strucnire of CDT AttachmentWebAddress 4700 is depicted in Figure 47.
  • the Object Class Qualification is Attachment 4702
  • the Object Class is Web Address 4704
  • the Property is Address 4706
  • CDT AttachmentWebAddress 4700 may support http and https URI schemes.
  • the CDT AttachmentWebAddress 4700 may also be used to transmit a link to an attachment, instead of transmitting the attachment itself. The recipient can use the transmitted link to access the attachment.
  • a GDT BatchID 4800 is a unique identifier for one batch in the context of a material number. Batches are non-reproducible, homogenous subsets of a product, whose characteristics lie within the batch characteristics defined for the product.
  • An example of GDT BatchID 4800 is: ⁇ BatchID> CH20021015 ⁇ / BatchID >.
  • GDT BatchID 4800 The structure of GDT BatchID 4800 is depicted in Figure 48.
  • the Category is Complex Type 4802
  • the Object Class is Batch 4804
  • the Property is Identification 4806
  • the Representation/Association is Identifier 480S
  • the Type is CCT 4810
  • the Data Type is Identifier 4812
  • the Length is from one to ten 4S14.
  • the GDT BatchID 4800 may comprise letters, numbers, and displayable special characters, with the possible exception of "*," "&,” and,"".
  • the identifier may be 15 uppercase and the GDT BatchID 4800 may not begin with blank characters or contain. consecutive blank characters.
  • the GDT BatchID 4800 value range includes combinations of the permitted characters up to a maximum length of 10 characters.
  • SchemeID identifies an identification scheme.
  • the identification scheme represents the context that is used to identify an object.
  • SchemeID may be unique within the agency ' 20 that manages this identification scheme.
  • the structure of GDT schemeID 4816 is depicted in Fig. 48.
  • the Category is Attribute 4818
  • the Object Class is Identification Scheme 4820
  • the Property is Identification 4822
  • the Representation/Association is Identifier 4824, the Type is xsd 3126, the Data Type is Token 4828, the Cardinality is zero or one 4830.
  • the GDT schemeID 4816 may be Optional 4832.
  • 25 SchenieVersionID identifies the version of an identification scheme.
  • the structure of GDT schemeVersionID 4834 is depicted in Fig. 48.
  • the Category is Attribute 4836, the Object Class is Identification Scheme 4838.
  • the Property is Version 4840
  • the Representation/Association is Identifier 4842
  • the Type is xsd 4844
  • the Data Type is Token 4846
  • the Cardinality is zero or one 4848.
  • the GDT 30 schemeVersionID 4834 may be optional 4850.
  • SchemeAgencyID identifies the agency that manages an identification scheme.
  • the agencies from DE 3055 may be used as the default, but the roles defined in DE 3055 may not be used.
  • GDT BatchID 4800 may be unique within the identification scheme that is managed by SchemeAgencyID.
  • the Category is Attribute 4854
  • the Object Class is IdentificationSchemeAgency 4856
  • the Property is Identification 4858
  • the Representation/Association is Identifier 4860
  • the Type is xsd 4862
  • the Data Type is Token 4864
  • Cardinality is zero or one 4866.
  • the GDT schemeAgencyID 4852 may be optional 4868.
  • SchemeAgencySchemeID identifies the identification scheme that represents the context for agency identification.
  • the Category is Attribute 4872
  • the Object Class is IdentificationSchemeAgency 4874
  • the Property is Scheme 4876.
  • the Representation/Association is Identifier 4878
  • the Type is xsd 4880
  • the Data Type is Token 4882
  • the Cardinality is zero or one 4884.
  • the GDT i 0 schemeAgencySchemeID 4870 may be optional 4886.
  • SchemeAgencySchemeAgencyID identifies the agency that manages the SchemeAgencySchemeID. This attribute may contain values from DE 3055 (excluding roles).
  • the Category is Attribute 4890
  • the Object Class is IdentificationSchemeAgency 4892
  • the Property is SchemeAgency 15 489 ⁇
  • the Representation/Association is Identifier 4896
  • the Type is xsd 4898
  • the Data Type is Token 4S99
  • Cardinality is zero or one 4801 A.
  • the GDT schemeAgercySchemeAgencyID 4888 may be optional 4802A.
  • the GDT BatchID 4800 may be used to identify batches. Specifying attributes may be optional. By default, the system may assume that the batch identified by the GDT .0 .BarchID 4800 is a manufacturer batch and therefore no attributes are required.
  • the GDT BiddingConditionCode 4900 is a coded representation of the bidding conditions for a bid invitation property.
  • An example of GDT BiddingConditionCode 4900 is: ⁇ QuoteQuantityBiddingConditionCode>01 ⁇ / QuoteQuantityBiddingConditionCode >. 5
  • the structure of GDT Bidding Condition Code 4900 is depicted in Figure 49.
  • the Object Class is Bidding 4902
  • the Property is Condition 4904
  • the Representation/Association is Code 4906
  • the Type is CCT 4908
  • the Type Name is Code 4910
  • Length is two 4912.
  • the GDT BiddingConditionCode 4900 may have the values 01 through 04.
  • 01 0 means that a bid is mandatory for a bid invitation property, and the property valuation may not be changed.
  • 02 means a bid is mandatory for a bid invitation property, and the property valuation can be changed.
  • 03 means a bid may be optional for a bid invitation property, and the property valuation cannot be changed.
  • 04 means a bid may be optional for a bid invitation property, and the property valuation can be changed
  • Illustrative bid invitation properties for which bidding conditions can be specified may include quantity, price, and terms of delivery.
  • the GDT BiddingConditionCode 4900 may be a proprietary code list with fixed predefined values. Changes to the permitted values may involve changes to the interface.
  • GDT BusinessDocumentMessageHeader 5000 comprises business info ⁇ nation from the perspective of the sender application for identifying a business document within a message (if applicable, with a reference to a previous instance of a business document within a previous message), information about the sender, and any information about the receiver.
  • An example of GDT BusinessDocumentMessageHeader 5000 is: ⁇ PurchaseOrderRequest>
  • the structure of GDT Business Document Message Header 5000 is depicted in Figure 50.
  • the GDT Business Document Message Header 5000 includes elements ID 5010, ReferenceID 5028, CreationDateTime 5046, SenderParty 5062, and RecipientParty 5078.
  • the Object Class is Business Document Message 5002
  • the Property is Header 5004
  • the Representation/Association is Details 5006.
  • the Type is GDT 5008.
  • ID 5010 is the identifier for the instance of the business document within a (technical) message that is generated by the business application level at the sender.
  • the Category is Element 5012
  • the Objecc Class is Business Document Message 5014
  • the Property is Identification 5016
  • the Representation/Association is identifier 501 S
  • ' • he Type is GDT 5020
  • the Type Name id Business Document Message ID 5022 the Length is from one to thirty-five 5024
  • Cardinality is zero or one 5026.
  • ReferenceID 5028 is the identifier of another instance of a business document in another (technical) message that the BusinessDocument references (a BusinessDocument can link to another BusinessDocumentMessage to represent a business interrelation or a dependency).
  • the Category is Element 5030
  • the Object Class is Business Document Message 5032
  • the Property is Reference Identification 5034
  • the Representation/Association is Identifier 5036
  • the Type is GDT 5038
  • the Type Name is Business Document Message ID 5040
  • the Length is from one to thirty-five 5042.
  • the Cardinality is zero or one 5044.
  • CreationDateTime 5046 is a date and time stamp (to the second) for when a message is created for the business document within the business application.
  • the Category is Element 5048
  • the Object Class is Business Document Message 5050
  • the Property is Creation Date Time 5052
  • the Representation/Association is Date Time 5054
  • the Type is GDT 5056
  • the Type Name is Date Time 505S.
  • the Cardinality is one 5060.
  • SenderParty 5062 is the party that creates and sends the BusinessDocument at business application level.
  • SenderParty contains a unique sender identification.
  • the identifiers contained in SenderParty can also be used for internal forwarding at application level.
  • the contact person in it contains the necessary direct contact information in case there are problems or errors during processing of the respective BusinessDocument.
  • the Category is Element 5064
  • the Object Class is Business Document Message 5066
  • the Property is Sender 5068
  • the Representation/Association is Party 5070
  • the Type is GDT 5072
  • the Type Name is Business Document Message Header Party 5074
  • the Cardinality is zero or one 5076.
  • RecipientParty 5078 is the party that receives and processes the BusinessDocumeni at business application level.
  • RecipientParty may contain a unique receiver identification.
  • the identifiers contained in RecipientParty can also be used for inte ⁇ ial forwarding at application level.
  • the contact person in it contains the contact information in case there are problems or errors du ⁇ ng processing of the respective BusinessDocument.
  • the structure of GDT Recipient Party 5078 is depicted in Fig. 50.
  • the Category is Element 5080
  • the Object Class is Business Document Message 5082
  • the Propeity is Recipient 5084
  • the Representation/Association is Party 5086
  • the Type is GDT 5088
  • the Type Name is Easiness Document Message Header Party 5090
  • the Caidinalky is tr ⁇ m zero to n 5092.
  • GDT BusinessDocumentMessageHeader 5000 may be used for B2B scenarios. If required, GDT BusinessDocumentMessageHeader 5C00 can also be used in BusinessDocumeni s intended for A2A scenarios.
  • GDT BusinessDocumentMessageHeader 5000 may be used for numerous purposes.
  • GDT BusinessDocumentMessageHeader 5000 may be used for forwarding to the relevant position or target person within a business application, for tracing and monitoring of a BusinessDocument and its processing status at business application level, and for managing and monitoring business processes.
  • GDT BusinessDocumentMessageHeader 5000 may also be us 3d for administration and error handling.
  • the unique identification can be used for referencing and in the case of eixors at business application level, the contact person in SenderParty or RecipientParty can be contacted directly.
  • the name, telephone number, e-mail address, fax number, and the like, can be transmitted by the GDT BusinessDocumentMessageHeader 5000 for this purpose.
  • GDT BusinessDocumentMessageHeader 5000 may also be used for converting general information to other standards, such as IDoc, UN/CEFACT. ANSI X.12, ODETTE, TRADACOMMS, XCBL, OAG BODS, and RosettaNet-PIPs. These are standards that represent reference data for the business application level according to predefined conventions. In a variation, this may be guaranteed if the general header information of a BusinessDocument is identical to the envelope or header information of the respective 5 default message.
  • the ReferenceID is used to represent references that originate from the succession of BusinessDocuments in the BusinessDocument choreography. This may include query/response or request/confirmation messages.
  • the respective interface document may identify the previous BusinessDocument to which the ReferenceID refers, i.e., what the
  • GDT BusinessDocumentMessageHeader 5000 Comparing GDT BusinessDocumentMessageHeader 5000 to the header information from the message transfer protocols such as "Reliable Messaging,” “OASIS ebXML MSG,” “OASIS ebXML CPP/CPA,” and “Rosetta Net RNIF 2.0,” demonstrates that the GDT BusinessDocumentMessageHeader 5000 may contain redundant information compared to
  • GDT BusinessDocumentMessageHeader 5000 may be used at business application level instead of at a technical level.
  • the information in this case is information that can be sent, received, and processed at Ihis ievel.
  • GDT BusinessDocumentMessageHeader 5000 may be based on UN/CEFACT Standard BusinessDocumentMessage Header Technical Specification - Working Draft - 0 Revision 2.2.5" dated 26 November 2003.
  • the ID (BusinessDocumentMessagelD) of the GDT BusinessDocumentMessageHeader 5000 may be distinguishable from the technical Messaged (the XI message).
  • the BusinessDocumentMessageID is issued by " the business application and is stable over the entire lifetime of the BusinessDocument. It also remains unchanged even when the message is sent via multiple, successive middleware 5 systems.
  • the technical Messaged is issued at the level of the technical middleware system and generally changes each time the BusinessDocument is resent or forwarded by a middleware system and when the BusinessDocument is split into multiple technical messages by a middleware system.
  • GDT BusinessDocumentMessageHeaderParty 5100 is information about a party that is responsible for sending or receiving a BusinessDocument at a business application level.
  • GDT BusinessDocumentMessageHeaderParty 5100 contains the necessary general business information about an involved sender or receiver party.
  • a party is typically a natural person, organization, or business partner group in which a company has a business or intra-enterprise interest. This could be a person, organization, or group within or outside of the company.
  • An example of GDT BusinessDocumentMessageHeaderParty 5100 is: ⁇ PurchaseOrderRequest> ⁇ MessageHeader> ⁇ SenderParty>
  • schemeAgencylD "016" can correspond to Dun & Bradstreet according to the code list DE 3055.
  • scherneID PartyID
  • schemeAgencyID "BPL_300” specifies that the scheme was assigned by the SAP CMDM system "BPL_300.”
  • GDT Business Document Message Header Party 5100 The structure of GDT Business Document Message Header Party 5100 is depicted in Figure 51.
  • the Object Class is Business Document Message Header Party 5102 and the Property is Details 5104.
  • InternalID 5106 refers to the proprietary identifier used when SenderParty or RecipieritParty use common master data (Extended Enterprise) or when they are in alignment with regard to the semantics and use of InternalID.
  • the Category is Element 5108
  • the Object Class is Business Document Message Header Party 5110
  • the Property is Internal Identification 5112
  • Representation/Association is Identifier 5114, the Type is GDT 5116, the Type Name is Party Internal ID 51 18, and the Cardinality is zero or one 5120.
  • StandardID 5122 refers to the standardized identifier for SenderParty or RecipientParty of the organization based on the code list DE 3055.
  • the Category is Element 5 124
  • the Object Class is Business Document Message Header Party 5126
  • the Property is Standard Identification 5128
  • the Representation/Association is Identifier 5130
  • the Type is GDT 5132
  • the Type Name is Party Standard ID 5134
  • the Cardinality is from zero to n 5136.
  • ContactPerson refers to the contact person of the party.
  • the Category is Element 5140, the Object Class is Business Document Message.
  • Header Party 5142 the Property is Contact Person 5144, the Representation/Association is Contact Person 5146, lhe Type is GDT 5148. the Type Name is Contact Person 5150, and the Cardinality is zero or one 5152.
  • the GDT BusinessDocumentMessageHeaderParty 5] 00 may be used in the Business DocumentMessageHeader of a BusinessDocument. This GDT is meant for defining lhe SenderParty or RecipientParty. The different IDs of a GDT BusinessDocumentMessageHeaderParty 5100 may identify the same party.
  • a party may be identified using an InternalID or Standard ID.
  • lntemalID is when SenderParty and RecipientParty use common master data or are in alignment with regard to the semantics and use of IntemallD.
  • StandardID is when SenderParty and RecipientParty can manage standardized identifiers. Of all of the IDs available to the SenderParry, generally those IDs the RecipientParty is expected to understand are used in a BusinessDocument. Either company-internal ID or a standardized ID can be used for identification.
  • GDT BusinessDocumentMessageHeaderParty 5100 can be used for the details and identification of the sender or recipient of a BusinessDocument. Furthermore, additional information about the contact person, including address, can be defined, which makes it possible to contact this person directly should any problems or errors occur when validating or processing the inbound BusinessDocument. (q) BusinessDocumentMessageID
  • a GDT BusinessDocumentMessageID 5200 may be a unique identifier of a business document in a message that is issued by the sender business application.
  • An example of GDT BusinessDocumentMessageID 5200 is: ⁇ PurchaseOrderRequest>
  • GDT 3usiness Document Message ID 5200 The structure of GDT 3usiness Document Message ID 5200 is depicted in Figure 52.
  • the Category is Complex Type 5202
  • the Object Class is Business Document Message 5204
  • the Property is Identification 5206
  • the Representation/ Association is Identifier 5208.
  • the Type is CCT 5210
  • the Type Name is Identifier 5212
  • the Length is from one to thirty-five 5214.
  • the GDT Business Document Message ID 5200 may be a restricted GDT.
  • SchemcID 5218 identifies an identification scheme. These identification schemes may be provided by a code list, such as the SAP MessageTypes. The "schemelD" attribute is not required if the GDT BusinessDocumentMessageID 5200 is unique within a schemeAgencylD.
  • the Category is Attribute 5220
  • the Object Class is Identification Scheme 5222
  • the Property is Identification 5224
  • the Representation/ Association is Identifier 5226
  • the Type is xsd 5228
  • the Type-Name is Token 5230
  • Length is from one to sixty 5232
  • Cardinality is zero or one 5234.
  • SchemeAgencylD 5236 may be covered by the agency ID of the sender.
  • the schemeAgencylD contains the unique identification of the respective business system from which the BusinessDocument was sent.
  • the Category is Attribute 5238
  • the Object Class is Identification Scheme Agency 5240
  • the Property is Identification 5242
  • the Representation/Association is Identifier 5244
  • the Type is xsd 5246
  • the Type Name is Token 5248
  • the Length is from one to sixty 5250.
  • the Cardinality between the GDT BusinessDocumentMessageID 5200 and SchemeAgencyID is zero or one 5252.
  • SchemeAgencySchemeAgencyID contains the unique identification of the agency that manages the scheme AgencylD. This attribute may contain values from DE 3055 (excluding roles). This attribute is not required if this information comes unequivocally from the sender.
  • GDT BusinessDocumentMessageID 5200 identification is a sequential number comprising a maximum of 35 characters. The number may be positive. This representation complies with the UN/EDIFACT conventions (see DE 0340 (Interactive Message Reference Number)).
  • the GDT BusinessDocumentMessageID 5200 is a unique identification for at least the entire lifetime of a BusinessDocument.
  • the identification is generated by the respective business application of the creator and, in a variation, may not be created or interpreted by fbe technical message transfer systems.
  • the technical MessageID depends on the respective technical transfer protocol ar>d may not be associated with the GDT Bu ⁇ inessDocumentMessagelD 5200.
  • the BusinessDociment is the payload in the message.
  • the MessageID can change as a result of the forwarding mechanisms of the respective middleware systems or the different transfer protocols used.
  • mapping can be performed to the in-house message code.
  • schemeID 5202 identifies the message type. If a Sender is unknown because it is not given by SenderParty and Identification of business level at the sender is standardized, then schemeID 5202 identifies the message type, schemeAgencyID 5204 identifies the standardized ID for the agency that generates the MessageID, and SchemeAgencySchemeAgencyID 5206 identifies the agency from DE 3055 that manages the standardized ID schemeAgencyld.
  • schemeID 5202 identifies the message type
  • schemeAgencyID 5204 identifies the proprietary ID for the agency that generates the MessageID
  • SchemeAgencySchemeAgencyID 5206 identifies 'ZZZ' which is mutually defined from DE 3055.
  • schemeID 5202 identifies the message type and schemeAgencyID 5204 identifies the unique ID of the business system that may be unique within an agency. In this scenario, uniqueness is ensured by the sender and the Sender is not required in internal communication.
  • GDT BusinessTransactionBlockedlndicator 5300 indicates whether or not the execution of a business transaction is blocked.
  • An example of GDT BusinessTransactionBlockedlndicator 5300 is: ⁇ DeliveryExecutionBlockedIndicator>true ⁇ /DeliveryExecutionBlockedIndicator>.
  • GDT Business Transaction Blocked Indicator 5300 The structure of GDT Business Transaction Blocked Indicator 5300 is depicted in Figure 53.
  • the Object Class is Business Transaction 5302
  • the Property is Blocked Indicator 5304
  • the Representation/Association is Indicator 5306
  • the Type is CCT 5308
  • the Type Name is Indicator 5310.
  • GDT BusinessTransactionBlockedlndicator 5300 may have the value true or false. True indicates that the execution of a business transaction is blocked. False indicates -that the execution of a business transaction is not blocked.
  • the GDT BusinessTransactionBlockedlndicator 5300 can be used in various environments, such as in delivery and in billing.
  • this data type- is used by a requesting application (e.g., Sales) to send a delivery request to Supply Chain Execution (e.g., for planning purposes) at an early stage, but, at the same time, to inform Supply Chain Execution that the delivery should not be executed yet since several points still have to be clarified with the customer, necessary papers are missing, or the customer's credit limit has been exceeded or has not yet been checked.
  • a requesting application e.g., Sales
  • Supply Chain Execution e.g., for planning purposes
  • this data type is used by a requesting application (e.g., Sales) to set up a billing due list in billing but, at the same time, to specify that billing may not yet be executed. It is possible that the requesting application first executes a release procedure, that the customer-specific prices have not yet been determined, that certain necessary documents have not yet been received (letter of credit procedure), or that the customer's credit limit has been exceeded. (s) Completedlndicator
  • a GDT Completedlndicator 5400 indicates whether an object is completed in a business sense or not.
  • GDT Completedlndicator 5400 may relate to business translations (for example, invoice creation, delivery, sourcing) or to objects that have the character of a transaction (for example, product catalog transfer in multiple steps).
  • An example of GDT Completedlndicator 5400 is: ⁇ CompletedIndicator>false ⁇ /CompletedIndicator>.
  • GDT Completedlndicator 5400 The structure of GDT Completedlndicator 5400 is depicted in Fig. 54.
  • the Property is Completed Indicator 5402
  • the Representation/Association is Indicator 5404
  • the Type is CCT 5406
  • the Type Name is Indicator 5408.
  • the GDT Completedlndicator 5400 can have the values true or false. True indicates that an object is completed. False indicates that an object is not completed.
  • the GDT Completedlndicator 5400 is used to indicate that the processing of an object has been completed, even if further processing steps are being run in a different context (for example, sourcing for a requirement may be completed but procurement of the requirement calls for further process steps).
  • a Completedlndicator or a Cancelledlndicator can be used depending on whether it is desired to emphasize that processing of the object has been completed properly (Completedlndicator) or that the object has been canceled in the sense of an exception- situation (Canceiledlndicator).
  • a GDT BusinessTransactionDocumentGroupID 5500 may uniquely identify a group of business documents that are to be considered as one group within a business process.
  • An example of GDT BusinessTransactionDocumentGroupID 5500 is: ⁇ DeliveryGroupID>471 ⁇ l DeliveryGroupID>.
  • GDT Business Transaction Document Group ID 5500 The structure of GDT Business Transaction Document Group ID 5500 is depicted in Figure 55.
  • the Object Class is Business Transaction Document 5502
  • the Property is Group Identification 5504
  • the Representation/Association is Indicator 5506
  • the Type is CCT 550S
  • the Type Name is Identifier 5510
  • the Length is from one to ten 5512.
  • the GDT Business Transaction Document Group ID 5500 may be a restricted GDT.
  • GDT BusinessTransactionDocumentGroupID 5500 is used to identify documents that belong together to enable them to be processed together by the application. "BusinessTransactionDocument” is replaced by the description of each document in the XML instance, e.g., "PurchaseOrder” for a purchase order, "Delivery” for a delivery, and the like.
  • a GDT BusinessTransactionDocumentID 5600 is a unique identifier for a document 5 in a business transaction.
  • llie structure of GDT Business Transaction Document ID 5600 is depicted in Figure 56.
  • the Object Class is Business Transaction Document 5602
  • the Property is Identification 5604
  • the l.'i Repiesentation/Association is Identifier 5606
  • the Type is CCT 5608.
  • the Type Name is Identifier 5610
  • the Length is from one to thirty-five 5612.
  • the GDT Business Transaction Document ID 5600 may be a restricted GDT.
  • the Category is Attribute 561 S
  • the Object Class is Identification Scheme 5620
  • ihe I'loperty is Identification 5622
  • the 0 Representation/ Association is .Identifier 5624
  • the Type is xsd 5626
  • the Type Name is
  • Token 5628 and the Length is from one to sixty 5630.
  • the Cardinality is zero or one 5632.
  • the Category is Attribute 5636
  • the Object Class is Identification Scheme Agency 5638
  • the Property is Identification 5640
  • the Representation/Association is Identifier 5642
  • the Type is xsd 5644
  • the Type Name is 5 Token 5646
  • the Length is from one to sixty 5648
  • the Cardinality is zero or one 5650.
  • the Category is Attribute 5618.
  • the Object Class is Identification Scheme 5620
  • the Property is Identification 5622
  • the Representation/Association is Identifier 5624
  • the Type is xsd 5626
  • the Type Name is Token 562S
  • the Length is from one to sixty 5630.
  • the Cardinality is zero or one 5632. 0
  • the Category is Attribute 5654
  • Object Class is Identification Scheme Agency 5656.
  • the Property is Scheme 5658
  • the Representation/Association is Identifier 5660
  • the Type is xsd 5662
  • the Type Name is Token 5664.
  • the Length is from one to sixty 5666.
  • the Cardinality is zero or one 5668.
  • the Category is Attribute 5672
  • the Object Class is Identification Scheme Agency 5674
  • the Property is Scheme Agency 5676
  • the Representation/Association is Identifier 5678
  • the Type is xsd 56S0
  • the Type Name is Token 5682
  • the Length is three 5684.
  • the Cardinality is zero or one 5686.
  • a business process uses GDT BusinessTransactionDocumentID 5600 to uniquely identity a document, such as a purchase order or an invoice in a business transaction.
  • a partner uses a GDT BusinessTransactionDocumentID 5600 to inform another partner of the identification of a business transaction document in an initial step, e.g., when creating data for the business transaction or sending it for the first time. The second partner can use this identifier to reference the business transaction document in the subsequent process.
  • GDT BusinessTransactionDocumen tltemGroupID 5700 uniquely identifies a group of business document items that are to be characterized as a group within a business document.
  • An example of GDT BusinessTransactionDocumentationGroupID 5700 is: ⁇ BeliveryItemGroupID> 123 ⁇ /DeliveryItemGroupID >.
  • GDT Business Transaction Document Item Group ID 5700 The structure of GDT Business Transaction Document Item Group ID 5700 is depicted in Figure 57.
  • the Object Class is Business Transaction Document Item 5702
  • the Property is Group Identification 5704
  • the Representation/Association is Identifier 5706
  • the Type is CCT 5708,
  • the Type Name is Identifier 5710
  • the Length is three 5712.
  • the GDT Business Transaction Document Item Group ID 5700 may be restricted.
  • a freely-definable numeric sequence may be used for display purposes. In a variation, it is a 3-digit, numeric text field. Leading zeros are also displayed.
  • NUMC3 numeric text field having a freely-definable 3-character string using the character set ⁇ "0,” “1,” “2,” “3,” “4.” “5,” “6,” “7,” “8,” “9” ⁇ may be used. Otherwise, a corresponding mapping may be necessary, but it might not be unique due to the use of a larger number of characters. In this case, the uniqueness may have to be ensured explicitly. This requirement, however, may not be ensured explicitly per definition/data type and therefore may be documented.
  • the GDT BusinessTransactionDocumentationGroupID 5700 is used to indicate the items of a business document that belong together for a unique identification of this item grouping in subsequent steps.
  • delivery groups are used to check the availability of materials that may be delivered together. Items that belong to the same delivery group may be delivered at the same time. Therefore, from the point of view of the availability check, the products/materials selected in the highlighted items may be available in sufficient quantities at the same time on the requested date so that the requirement can be fulfilled.
  • the "BusinessTransactionDocument” is replaced by the description of the respective document, e.g., "PurchaseOrder” for a purchase order, "Delivery” for a delivery, and the like.
  • a CDT BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 is a coded representation of the business type of a hierarchical relationship between items of a BusinessTransactionDocument.
  • BusinessTransactionDocumentltemHierarchyRelalionshipTypeCode 5800 in the context of a purchase order item is: ⁇ HierarchyRelationshipTypeCode>001 ⁇ /HierarchyRelationshipTypeCode: ⁇
  • CDT Business Transaction Document Item Hierarchy Relationship Type Code 5800 The structure of CDT Business Transaction Document Item Hierarchy Relationship Type Code 5800 is depicted in Figure 58.
  • the Object Class Qualification is Business Transaction Document Item Hierarchy 5802
  • the Object Class is Relationship 5804
  • the Property is Type Code 5806
  • the Representation/Association is Code 5808
  • the Type is GDT 5810
  • the Type is Relationship Type Code 5812
  • Length is three 5814.
  • the CDT Business Transaction Document Item Hierarchy Relationship Type Code 5800 may be restricted.
  • the GDT BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 is based on the GDT ObjectStructureRelationshipTypeCode.
  • Elements of type BusinessTransactionDocumentltemHierarchyTypeCode can have values 001, 002, 003, or 006.
  • 001 means that the relationship is a bill of material relationship
  • 002 means the relationship is a grouping relationship (one object in this relationship is part of a logical grouping to another object)
  • 003 means the relationship is a discount in kind relationship
  • 006 means the relationship is a substitution product relationship.
  • the CDT BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 is used together with a ParentltemID to map item hierarchies.
  • An item hierarchy is a tree of subordinated items, where the
  • BusinessTransactionDocumeritHierarchyRelationshipTypeCode 5800 describes the meaning of the hierarchical level of an item.
  • BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 which types of lower-level items are permitted in each use context and which integrity conditions apply to items in a hierarchy of a particular CDT BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 may be explicitly
  • J 5 defined. In particular, it may be specified how hierarchies with different
  • BusinessTransactioiuOocumentltemHierarchyRelatioi.ishipTypeCodesi can be combined with each other. For example: When a bill of material hierarchy and a grouping hierarchy exist for one item, and when a grouping hierarchy exists for an item.
  • CDT 0 BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 there may be one hierarchy for each item, that is, the same CDT 0 BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 is specified for lower-level items.
  • a purchase order can contain items that have both a bill of material hierarchy and a discount in kind hierarchy.
  • the CDT BusinessTransactionDocumentltemHierarchyRelationshipTypeCode 5800 may be a proprietary code list with fixed predefined values. In that case, changes to 5 the permitted values may involve changes to the interface.
  • BusinessTransactionDocument is replaced by the description of the specific business transaction document, for example "PurchaseOrdev” for a purchase order, "Delivery” for a delivery, and the like.
  • GDT BusinessTransactionDocumentItemID 0 A GDT BusinessTransactionDocumentltemID 5900 is a unique identifier of an item or sub item of a document within a business transaction and is unique in the context of the business transaction.
  • An example of BusinessTransactionDocumentltemID is: ⁇ ItemID>13 ⁇ /Item.D>.
  • the structure of GDT Business Transaction Document Item ID 5900 is depicted in Figure 59.
  • the Object Class is Business Transaction Document Item 5902
  • the Property is Identification 5904
  • the Representation/Association is Identifier 5906
  • the Type is CCT 5908
  • the Type Name is Identifier 5910
  • the Length is from one to ten 5912.
  • the GDT Business Transaction Document Item ID 5900 may be restricted 5914.
  • GDT BusinessTransactionDocumentltemID 5900 is a sequence of numbers with a maximum often characters. Leading zeros may not be significant at the recipient and may not be sent. Business transactions, such as purchase orders or invoices, may be divided into items and sub items. GDT BusinessTransactionDocumentltemID 5900 is used in a business process to identify uniquely an item or sub item within a business transaction. A partner uses its GDT BusinessTransactionDocumentltemID 5900 to inform the other partner of its identification of the item in an initial step, for example, when creating an item or transmitting it for the first time. The second partner can then use this identifier to reference the lespective item of the document in the subsequent process.
  • a GDT BusinessTransactionDocumentItemScheduleLineID 6000 is a unique identifier that uses a deadline to identify the schedule line of a document item within a business transaction.
  • An example of GDT BusinessTransactionDocumentltemScheduleLinelD 6000 is:
  • GDT Business Transaction Document Item Schedule Line ID 6000 The structure of GDT Business Transaction Document Item Schedule Line ID 6000 is depicted in Figure 60.
  • the Object Class is Business Transaction Document Item Schedule Line 6002
  • the Property is Identification 6004
  • the Representation/Association is Identifier 6006
  • the Type is CCT 6008
  • the Type Name is Identifier 6010
  • the Length is From one to four 6012.
  • the GDT Business Transaction Document Item Schedule Line ID 6000 may be restricted 6014. Documents such as purchase orders, sales orders, or invoices are divided into items. Items are then further divided according to schedule lines. Each of these schedule lines specifies a deadline and relevant product quantities for this deadline.
  • BusinessTransactionDocument is replaced by the description of each document in the XML instance, e.g., "PurchaseOrder” for a purchase order, "Delivery” for a delivery, and the like.
  • a GDT ThirdPartylndicator 6100 indicates whether or not a document item is used in the context of a third-party deal.
  • An example of GDT ThirdPartylndicator 6100 in the context of a document item is: ⁇ ThirdPartyDealIndicator>tiue ⁇ / ThirdParty Deal Indicator >.
  • GDT Third Party Indicator 6100 The structure of GDT Third Party Indicator 6100 is depicted in Figure 61.
  • the Object Class is Business Transaction Document Item 6102
  • the Property is third Party Deal Indicator 6104
  • the Representation/Association term is Indicator 6 ⁇ 06
  • the Type is CCT 6108
  • the Type Name is Identifier 6110.
  • the GDT ThirdPartylndicator 6100 can have the values true or false. True indicates that the object is used in the context of a third-party deal. False indicates that the object is not used in the ⁇ context of a third-party deal.
  • the GDT ThirdPartyIndicator 6100 is used to indicate that a document item is used in the context of a third-party deal.
  • a third-part ⁇ ' deal may be a process in which a company processes a sales order via a third party rather than fulfilling it directly itself.
  • the context to which the BusinessTransactionDocumentltemThirdPartyDeallndicator refers may be clear from the usage of the GDT.
  • the GDT BusinessTransactionDocumentltemTypeCode 6200 is a coded representation of the type of an item in a document that occurs in business transactions.
  • the document item type describes the business nature of similar document items and defines the basic features of the document items of this type.
  • An example of GDT BusinessTransactionDocumentltemTypeCode 6200 is: ⁇ BusinessTransactionDocumentItemTypeCode>001 ⁇ /BusinessTransactionDocumentItemT ypeCode>.
  • GDT Business Transaction Document Item Type Code 6200 The structure of GDT Business Transaction Document Item Type Code 6200 is depicted in Figure 62.
  • the Object Class is Business Transaction Document Item 6202
  • the Property is Type 6204
  • the Representation/Association is Code 6206
  • the Type is CCT 6208
  • the Type Name is Code 6210
  • the Length is three 6212.
  • the GDT Business Transaction Document Item Type Code 6200 may be restricted 6214.
  • GDT BusinessTransactionDocumentltemTypeCode 6200 can have a value from 001 to 004.
  • 001 identifies a purchase order item that specifies an ordered product or additional information on ordered products. This includes information on free goods, substitute products and value limits.
  • 002 identifies an invoice item that specifies prices and taxes for a delivered product (including completed work) and, if necessary, more information on this product.
  • 003 identifies a credit memo item that specifies refunded prices and taxes for a delivered product (including completed work) and, if necessary, more information on this product.
  • 004 identifies a delivery cost item that specifies delivery costs incurred by the ' purchaser on top of the actual product costs.
  • BusiiiessTransactionDocumentltemTypeCode may be 001. If BusinessTransactionDocumentTypeCode is 004, BusiiiessTransactionDocumentItemTypeCode may be 002, 003, or 004. If BusinessTransactionDocumentTypeCod is 005, BusinessTransactionDocumentltemTypeCode may be 001.
  • the GDT BusinessTransactionDocumentltemTypeCode 6200 categorizes an item in a document that is sent if the concrete semantic meaning of the item or sub-item is not defined by the message itself or if semantically different items can occur in one message.
  • an invoice can contain a delivery costs item that is to be shown separately.
  • the BusinessTransactionDocumentltemTypeCode 6200 corresponds to VBTYP + POSAR in Sales or BSTYP in Purchasing or MRM_REFERENZBELEG in Invoice Verification, and the like, at a less detailed level.
  • a CDT BusinessTransactionDocumentLocation 6300 contains the information that is exchanged in business documents about a location relevant for business transactions. This information identifies the location and its address. The identification may be a company- internal ED, a standardized ED, or one or several partner-specific IDs.
  • a location is a logical or a physical place. An ID for a location assigned by a party identifies in the name the role the assigning party plays in the business transaction. At present, the role descriptions are Buyer, Seller, ProductRecipient, Vendor, BiIlTo, and BillFrom.
  • An example of CDT BusinessTransactionDocumentLocation 6300 is: ⁇ InventoryChange>
  • CDT Business Transaction Document Location 6300 The structure of CDT Business Transaction Document Location 6300 is depicted in Figure 63.
  • the Object Class is Business Transaction Document Location 6302 and the Representation/Association is Details 6304.
  • the Category is Element 6308, the Object Class is Business Transaction Document Location 6310, the Property Qualifier is Internal 6312, the Property is Identification 6314, the Representation/Association is Identifier 6316, the Type is CDT 6318, and the Type Name is Location Internal ID 6320.
  • the Cardinality is zero or one 6322.
  • the Category is Element 6326
  • the Object Class is Business Transaction Document Location 6328
  • the Property Qualifier is Standard 6330
  • the Property is Identification 6332
  • the Representation/Association is Identifier 6334
  • the Type is CDT 6336
  • the Type Name is Location Standard ID 6338.
  • the Cardinality is from zsro to n. 6340.
  • the Category is Element 6344, the Object Class is Business Transaction Document Location 6346, the Property Qualifier is Buyer 6363, the Property is Identification 6350, the Representation/Association is Identifier 6352, the Type is CDT 6354, and the Type Name is Location Party ID 6356.
  • the Cardinality is zero or one 6358.
  • the Category is Element 6362, the Object Class is Business Transaction Document Location 6364, the Property Qualifier is Seller 6366, the Property is Identification 6368, the Representation/Association is Identifier 6370, the Type is CDT 6372, and the Type Name is Location Party ID 6374.
  • the Cardinality is zero or one 6376.
  • the Category is Element 6362
  • the Object Class is Business Transaction Document Location 6364
  • the Property Qualifier is Seller 6366
  • the Property is Identification 636S
  • the Representation/Association is Identifier 6370
  • the Type is CDT 6372
  • the Type Name is Location Party ID 6374.
  • the Cardinality is zero or one 6376.
  • the Product Recipient ID 6378 the Category is Element 6380
  • the Object Class is Business Transaction Document Location 6390
  • the Property Qualifier is Product Recipient 6392
  • the Property is Identification 6394
  • the Representation/Association is Identifier 6396
  • the Type is CDT 6398
  • the Type Name is Location Party ID 6399.
  • the Cardinality is zero or one 6301 A.
  • Vendor ID 6302A For the Vendor ID 6302A, the Category is Element 6303A, ihe Object Class is. Business Transaction Document Location 6304A, ihe Property Qualifier is Vendor 6305A, the Property is Identification 6306A, the Representation/Association is Identifier 6307 A, .the Type is CDT 630SA, and the Type Name is Location Party ID 6309A.
  • the Cardinality is zero..or one ⁇ 310A.
  • the Category is Element 6312A
  • the Object Class is - Business Transaction Document Location 6313 A
  • the Property Qualifier is Bill To 6314A
  • the Property is Identification 6315A
  • the Representation/ Association is Identifier 6316A
  • the Type is CDT 6317A
  • the Type Name is Location Party ID 6318A.
  • the Cardinality is zero or one 6319A.
  • the Category is Element 6321 A
  • the Object Class is Business Transaction Document Location 6322A
  • the Property Qualifier is Bill From 6323 A
  • the Property is Identification 6324A
  • the Representation/Association is Identifier 6325A
  • the Type is CDT 6326A
  • the Type Name is Location Party ID 6327A.
  • the Cardinality is zero or one 6328A.
  • the Category is Element 6330A
  • the Object Class is Business Transaction Document Location 633 IA
  • the Property Qualifier is Bidder 6332A
  • the Property is Identification 6333A
  • the P.epresentation/Association is Identifier 6334A
  • the Type is CDT 6335A
  • the Type Name is Location Party ID 6336A.
  • the Cardinality is zero or one 6337A.
  • the Category is Element 6339A
  • the Object Class is Business Transaction Document Location 6340A
  • the Property is Address 6341 A
  • the Representation/Association is Address 6342A
  • the Type is GDT 6343A
  • the Type Name is Address 6344A.
  • the Cardinality is zero or one 6345A.
  • the Category is Element 6347A
  • the Object Class is Business Transaction Document Location 6348A
  • the Property is Note 6349A 5
  • the Representation/Association is Text 6350A
  • the Type is GDT 635 IA
  • the Type Name is Note 6352A.
  • the Cardinality is zero or one 6353 A.
  • InternalID refers to a proprietary identifier that is used when both sender and recipient can access shared master data (extended enterprise).
  • Standard ID refers to a standardized identifier, whose identification schemes may be managed by an agency from the DE 3055 code list.
  • Buyer ID refers to an identifier that is used by the BuyerParty proprietarily for this location.
  • SellerID refers (.o an identifier that is used by the SellerParty yiOprietarily for this location.
  • ProductRecipientGD refers to an identifier that is used by the ProductR ecipientParty prop ⁇ etarily for this localion.
  • VendorID refeis to an identifier That is used by the Vend ⁇ rParty proprietarily for this location.
  • BiIlToID refers to an identifier that is used by the BillToParty proprietarily for this location.
  • BillFromID refers to an identifier that is used by the BillFromParty proprietarily for this location.
  • BidderID refers to an • identifier that is used by the BidderParty proprietarily for this location.
  • Address is an address that describes the location by specifying information such as postal address, geographic coordinates, or any other information that specifies a location. Note refers to an additional information such as direction. When defining addresses, organization addresses may be supported. The different
  • IDs of a CDT BusinessTransactionDocurnentLocation 6300 identify the same location.
  • a location may be identified by lhe InternalID when sender and recipient can access shared master data, by the StandardID when sender and recipient can manage standardized identifiers, or by the PartylDs: when sender and recipient are intereisted in the Party IDs assigned by the parties involved. From all of the IDs available to the sender, the IDs that the recipient is expected to understand may be used.
  • a CDT BusinessTransacti ⁇ nDocumentParty 6400 contains the information that is exchanged - in accordance with common business understanding - in business documents about a party involved in business transactions. This information is used to identify the party and the party's address, as well as the party's contact person and the contact person's address. This identification can take place using an internal ID, a standardized ID, or IDs assigned by the parties involved.
  • a party is a natural person, organization, or business partner group in which a company has a business or intra-enterprise interest. This could be a person, organization, or group within or outside of the company.
  • An ED assigned by a party identifies in the name the role the assigning party plays in the business transaction. At present, the roles are Buyer, Seller, ProductRecipient, Vendor, BiIlTo, BillFrom and Bidder.
  • An example of CDT BusinessTransactionDocnmentParty 6400 is: ⁇ PurchaseOrder>
  • schemeAgencyID "016" corresponds to Dun&Bradstreet according to code list D3055 that means that the DUNS number is assigned by Dun&Bradstreet.
  • code list D3055 that means that the DUNS number is assigned by Dun&Bradstreet.
EP06765436.8A 2005-02-25 2006-02-27 DERIVED CONSISTENT SET OF INTERFACES DERIVED FROM A BUSINESS OBJECT MODEL Withdrawn EP1875428A4 (en)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US65659805P 2005-02-25 2005-02-25
US11/145,464 US8655756B2 (en) 2004-06-04 2005-06-03 Consistent set of interfaces derived from a business object model
PCT/US2005/019961 WO2005122078A2 (en) 2004-06-04 2005-06-03 Consistent set of interfaces derived from a business object model
PCT/US2005/021481 WO2006038924A2 (en) 2004-06-18 2005-06-17 Consistent set of interfaces derived from a business object model
US11/155,368 US8694397B2 (en) 2004-06-18 2005-06-17 Consistent set of interfaces derived from a business object model
PCT/US2005/022137 WO2006012160A2 (en) 2004-06-25 2005-06-24 Consistent set of interfaces derived from a business object model
US11/166,065 US8606723B2 (en) 2004-06-04 2005-06-24 Consistent set of interfaces derived from a business object model
US72948005P 2005-10-21 2005-10-21
US11/364,538 US8744937B2 (en) 2005-02-25 2006-02-27 Consistent set of interfaces derived from a business object model
PCT/IB2006/001401 WO2006117680A2 (en) 2005-02-25 2006-02-27 Consistent set of interfaces derived from a business object model

Publications (2)

Publication Number Publication Date
EP1875428A2 true EP1875428A2 (en) 2008-01-09
EP1875428A4 EP1875428A4 (en) 2013-11-20

Family

ID=37308361

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06765436.8A Withdrawn EP1875428A4 (en) 2005-02-25 2006-02-27 DERIVED CONSISTENT SET OF INTERFACES DERIVED FROM A BUSINESS OBJECT MODEL

Country Status (1)

Country Link
EP (1) EP1875428A4 (un)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8006177B1 (en) * 1998-10-16 2011-08-23 Open Invention Network, Llc Documents for commerce in trading partner networks and interface definitions based on the documents

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
No further relevant documents disclosed *
See also references of WO2006117680A2 *

Also Published As

Publication number Publication date
EP1875428A4 (en) 2013-11-20

Similar Documents

Publication Publication Date Title
US8744937B2 (en) Consistent set of interfaces derived from a business object model
US8606723B2 (en) Consistent set of interfaces derived from a business object model
US8694397B2 (en) Consistent set of interfaces derived from a business object model
US8655756B2 (en) Consistent set of interfaces derived from a business object model
US8924269B2 (en) Consistent set of interfaces derived from a business object model
US8566193B2 (en) Consistent set of interfaces derived from a business object model
US8374931B2 (en) Consistent set of interfaces derived from a business object model
US8775280B2 (en) Managing consistent interfaces for financial business objects across heterogeneous systems
US20020049622A1 (en) Vertical systems and methods for providing shipping and logistics services, operations and products to an industry
US7917434B2 (en) Method for planning commercial financing payment
US20060053027A1 (en) Transport logistics systems and methods
US20020095355A1 (en) Computer-implemented international trade system
JP2001527248A (ja) 統合されたビジネス−トゥー−ビジネスのウェブコマースおよびビジネス自動化システム
WO2006117680A2 (en) Consistent set of interfaces derived from a business object model
KR20100024907A (ko) 다중거래처의 비엘정산업무 통합처리시스템
Osborne et al. Supply chain management for bulk materials in the coal industry
Bansal Technology scorecards: Aligning IT investments with business performance
US20110307358A1 (en) Managing Consistent Interfaces for Cash Flow Expense and Receipt Explanation, Company Financials Process Control, Miscellaneous Subledger Account, and Receivables Payables Entry Business Objects Across Heterogeneous Systems
EP1782356A2 (en) Consistent set of interfaces derived from a business object model
EP1875428A2 (en) Consistent set of interfaces derived from a business object model
Gusso Optimization of administrative processes in beer export: a case study
Kabluchko Management of supply chains involving maritime transport in the digital economy
Saldanha Choosing the right information coordinating mechanism for the international ocean shipping process
Bossakov Information Asymmetry in Contract Logistics: Problems and Solutions
Lobaugh Paperless payables pays off

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070920

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ZIEMENDORF, BRIT

Inventor name: ZADRO, RENATO

Inventor name: WINKEL, RUDOLF

Inventor name: WEISS, BURKHARD

Inventor name: WAGNER, ANDRE

Inventor name: THOME, FRANK

Inventor name: STOTZ, SERGEJ

Inventor name: STEPHAN, JAN

Inventor name: SIEVERS, RALF

Inventor name: SCHULZE, DAGMAR

Inventor name: SCHUELER, ARNULF

Inventor name: SALA, PAOLA

Inventor name: REINEMUTH, FRANK

Inventor name: REDMANN, MICHAEL

Inventor name: RADCKE, RUEDIGER

Inventor name: PODHAJSKY, GEORG

Inventor name: PETER, MARKUS

Inventor name: OPPERT, TILL

Inventor name: NOWOTNY, DIETMAR

Inventor name: NN, RAMESH

Inventor name: MAKRIS, OTTO

Inventor name: LOTZ, MARCUS

Inventor name: KUSTER, CORINNE

Inventor name: KROMPHOLZ, ANDREAS

Inventor name: KRAEHMER, THILO

Inventor name: KOESTER, ARNDT

Inventor name: KIWON, ADAM

Inventor name: KENNTNER, JOACHIM

Inventor name: KEMMER, JOHANN

Inventor name: HOFMANN, CHRISTINE

Inventor name: HETZER, STEPHAN

Inventor name: HARTMANN, NILS

Inventor name: GROSS, PATRICK

Inventor name: GROSS, ANTONIA

Inventor name: GOLDMANN, DANIEL

Inventor name: GNAN, WERNERE

Inventor name: FRANKE, STEFAN

Inventor name: EGETOFT, KARSTEN

Inventor name: DROUIN, PHILLIPPE

Inventor name: DOERNER, ROBERT

Inventor name: DIELSCHNEIDER, RALF

Inventor name: DELEDDA, GIOVANI

Inventor name: COLLE, RENZO

Inventor name: BROSSLER, ANDREAS

Inventor name: BOCK, DANIEL

Inventor name: BIEHLER, MARKUS

Inventor name: BECKER, DIRK

Inventor name: KUEHL, AXEL

Inventor name: RASCH, JOCHEN

Inventor name: SEUBERT, MICHAEL

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ZIEMENDORF, BRIT

Inventor name: ZADRO, RENATO

Inventor name: WINKEL, RUDOLF

Inventor name: WEISS, BURKHARD

Inventor name: WAGNER, ANDRE

Inventor name: THOME, FRANK

Inventor name: STOTZ, SERGEJ

Inventor name: STEPHAN, JAN

Inventor name: SIEVERS, RALF

Inventor name: SCHULZE, DAGMAR

Inventor name: SCHUELER, ARNULF

Inventor name: SALA, PAOLA

Inventor name: REINEMUTH, FRANK

Inventor name: REDMANN, MICHAEL

Inventor name: RADCKE, RUEDIGER

Inventor name: PODHAJSKY, GEORG

Inventor name: PETER, MARKUS

Inventor name: OPPERT, TILL

Inventor name: NOWOTNY, DIETMAR

Inventor name: NN, RAMESH

Inventor name: MAKRIS, OTTO

Inventor name: LOTZ, MARCUS

Inventor name: KUSTER, CORINNE

Inventor name: KROMPHOLZ, ANDREAS

Inventor name: KRAEHMER, THILO

Inventor name: KOESTER, ARNDT

Inventor name: KIWON, ADAM

Inventor name: KENNTNER, JOACHIM

Inventor name: KEMMER, JOHANN

Inventor name: HOFMANN, CHRISTINE

Inventor name: HETZER, STEPHAN

Inventor name: HARTMANN, NILS

Inventor name: GROSS, PATRICK

Inventor name: GROSS, ANTONIA

Inventor name: GOLDMANN, DANIEL

Inventor name: GNAN, WERNERE

Inventor name: FRANKE, STEFAN

Inventor name: EGETOFT, KARSTEN

Inventor name: DROUIN, PHILLIPPE

Inventor name: DOERNER, ROBERT

Inventor name: DIELSCHNEIDER, RALF

Inventor name: DELEDDA, GIOVANI

Inventor name: COLLE, RENZO

Inventor name: BROSSLER, ANDREAS

Inventor name: BOCK, DANIEL

Inventor name: BIEHLER, MARKUS

Inventor name: BECKER, DIRK

Inventor name: KUEHL, AXEL

Inventor name: RASCH, JOCHEN

Inventor name: SEUBERT, MICHAEL

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ZIEMENDORF, BRIT

Inventor name: ZADRO, RENATO

Inventor name: WINKEL, RUDOLF

Inventor name: WEISS, BURKHARD

Inventor name: WAGNER, ANDRE

Inventor name: THOME, FRANK

Inventor name: STOTZ, SERGEJ

Inventor name: STEPHAN, JAN

Inventor name: SIEVERS, RALF

Inventor name: SCHULZE, DAGMAR

Inventor name: SCHUELER, ARNULF

Inventor name: SALA, PAOLA

Inventor name: REINEMUTH, FRANK

Inventor name: REDMANN, MICHAEL

Inventor name: RADCKE, RUEDIGER

Inventor name: PODHAJSKY, GEORG

Inventor name: PETER, MARKUS

Inventor name: OPPERT, TILL

Inventor name: NOWOTNY, DIETMAR

Inventor name: NN, RAMESH

Inventor name: MAKRIS, OTTO

Inventor name: LOTZ, MARCUS

Inventor name: KUSTER, CORINNE

Inventor name: KROMPHOLZ, ANDREAS

Inventor name: KRAEHMER, THILO

Inventor name: KOESTER, ARNDT

Inventor name: KIWON, ADAM

Inventor name: KENNTNER, JOACHIM

Inventor name: KEMMER, JOHANN

Inventor name: HOFMANN, CHRISTINE

Inventor name: HETZER, STEPHAN

Inventor name: HARTMANN, NILS

Inventor name: GROSS, PATRICK

Inventor name: GROSS, ANTONIA

Inventor name: GOLDMANN, DANIEL

Inventor name: GNAN, WERNERE

Inventor name: FRANKE, STEFAN

Inventor name: EGETOFT, KARSTEN

Inventor name: DROUIN, PHILLIPPE

Inventor name: DOERNER, ROBERT

Inventor name: DIELSCHNEIDER, RALF

Inventor name: DELEDDA, GIOVANI

Inventor name: COLLE, RENZO

Inventor name: BROSSLER, ANDREAS

Inventor name: BOCK, DANIEL

Inventor name: BIEHLER, MARKUS

Inventor name: BECKER, DIRK

Inventor name: KUEHL, AXEL

Inventor name: RASCH, JOCHEN

Inventor name: SEUBERT, MICHAEL

DAX Request for extension of the european patent (deleted)
R17D Deferred search report published (corrected)

Effective date: 20110519

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 19/00 20110101AFI20110901BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20131023

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 40/02 20120101ALI20131017BHEP

Ipc: G06Q 10/10 20120101AFI20131017BHEP

Ipc: G06F 19/00 20110101ALI20131017BHEP

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAP SE

17Q First examination report despatched

Effective date: 20150609

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20151020