GetMatchDocument schema, example, validation rules, validation stylesheet |
GetMatchDocument type: GetMatchDocument | |
The purpose of the GetMatchDocument is to enable a business application module to request information concerning invoice matching from another business application. The reply to this BOD is the ShowMatchDocument. This BOD does not usually cause updates to occur. There are several possible business applications in several environments that may use this capability. The description and the pictures below visualize the possible use of this BOD. In certain application suites, purchase order and invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application. The invoice matching process may include several document types, including the following: Two way match - Purchase Order and the Invoice Three way match - Purchase Order, Invoice, and the Receipt Four way match – Purchase Order, Invoice, Receipt, and Inspection results Note: For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching. When matching takes place in the purchasing application, the purchasing application may have to request the accounts payable application to provide the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched. This is the generally the situation when the invoice is initially entered into the accounts payable application. Note that in some situations, accounts payable will send invoices to the purchasing application unsolicited. In others, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters. When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched. Alternatively, the accounts payable application can request the information. The purpose of the GetMatchDocument is to enable both the accounts payable application and the purchasing application to request the transactions that are required to be matched. In both cases, the receiving application will use the ShowMatchDocument to return the requested information. |
GetMatchDocument extends: BusinessObjectDocument | |||||||
Structure: |
![]() |
||||||
Elements: |
|
GetMatchDocumentDataArea extends: DataArea | ||||||||||
Structure: |
![]() |
|||||||||
Elements: |
|
GetMatchDocument Scenario Diagram |
Get schema |
Get type: Get | |
The GET verb is to communicate to a business software component a request for an existing piece of information to be returned. The GET may be paired with most of the nouns defined in the OAGIS specification.The response to this request is the SHOW verb. The behavior of a BOD with a GET verb is quite predictable across most of the nouns it may be paired with.The GET is designed to retrieve a single piece of information by using that information's primary retrieval field, or key field. The GET verb is not used to request several documents at once. The GETLIST verb is designed to achieve that purpose and will be covered in more detail later.Selection Criteria:There are two types of selection capabilities for most BOD's that use the GET verb.1) The first selection capability is called Field-Based Selection. Within a GET-based Business Object Document, the first Data Type that occurs in a specific BOD structure is commonly used to provide the Field-Based Selection criteria. This is always defined within the specific BOD and is commonly the required fields for that specific Data type.The Field-Based Selection enables the requester to provide a value or values (in the case of multiple required Field Identifiers), in the required fields. Then the responding component uses those values to find and return the requested information to the originating business software component.2) The second type of selection capability for GET-based BODs is called Data Type Selection. Data Type selection enables the requester to identify which Data Types within the noun are requested to be returned in the response. The use of this capability is described for each corresponding Data Type for all BODs that use the GET verb. The Data Types are identified for retrieval within the GET instance of a BOD by including the name of the Data Type in the meta data but without any Field Identifiers or Segments identified within the Data Type. This will signify to the responding application that all of the data that corresponds to that Data Type is to be included in the response.If the Data Type is not requested, the Data Type identifier is not included in the GET request and this will signify to the responding component that the Data Type is not to be returned. |
Get extends: RequestVerb | |||||||||
Structure: |
![]() |
||||||||
Attributes: |
|
MatchDocument schema |
MatchDocument type: MatchDocument | |
Identifies an internal document containing matching information. Essential it holds cross reference information among the customer Purchase Order and the Suppier Invoice. It supports N-way matching. |
Header type: MatchDocumentHeader | |
Header information for the matching document instance. |
Line type: MatchDocumentLine | |
Line level infoi\rmatoin for the matching doucment. |
MatchPoint type: MatchPoint | |
A Match Line (like geometric lines) must consist of at least 2 Match Points. A Match Point can match different lines in documents identified in other Match Points. It is not required that LineNumbers are the same. |
MatchCriteria type: MatchCriteria | |
The Match Criteria is included in the match document to identify the type of information being matched. It identifies the information for the associated matching document. |
MatchCriteria | ||||||||||||||||||||||
Match Criteria identifies the detailed information that is being matched. Typically this is the unit price, unit quantity the the extended amount. |
||||||||||||||||||||||
Structure: |
![]() |
|||||||||||||||||||||
Elements: |
|
MatchDocument extends: Document | |
Structure: |
![]() |
MatchDocumentHeader extends: DocumentHeader | |||||||||||||||||||||||||
A Matching Document is a document in and of itself. It may exist in an ERP application, just like a Sales Order. The Matching Document essentially holds a cross reference among the documents being matched. The header contains general and financial information. The document references used in the Header are for all of the doucments being matched in addition to documents that are not explicitly part of the matching process, but still need to be referenced, such as a Quote. However, since matching is essentiall N-way, even a Quote could be matched. Note that the Status on the MatchDocument indicates whether the Match was successful or was a failure. |
|||||||||||||||||||||||||
Structure: |
![]() |
||||||||||||||||||||||||
Elements: |
|
MatchDocumentLine extends: DocumentLine | |||||||||||||
A Match Line contains the information for the matching cross reference among the documents being matched. Each Match Line contains 2 or more Match Points. A Match Point represents the document being matched and the matching critieria. |
|||||||||||||
Structure: |
![]() |
||||||||||||
Elements: |
|
MatchPoint | |||||||||||||
A Match Point identifies a document and the matching critier that is matched with other Match Points. The DocumentReference must be mutually exclusive of the other Match Point Document References for the Match Line. |
|||||||||||||
Structure: |
![]() |
||||||||||||
Elements: |
|
Verb Common Files |
Verb.xsd schema |
AcknowledgableVerb extends: ConfirmableVerb | |||||||||
Structure: |
![]() |
||||||||
Attributes: |
|
AcknowledgementType restricts: xs:NMTOKEN | |||||||
Enumerations: |
|
ConfirmableVerb extends: Verb | |||||||||
Structure: |
![]() |
||||||||
Attributes: |
|
ConfirmType restricts: xs:NMTOKEN | |||||||
Enumerations: |
|
Expression restricts: xs:string | |
ExpressionCriteria | |||||||||
Structure: |
![]() |
||||||||
Elements: |
|
||||||||
Attributes: |
|
RequestVerb extends: ConfirmableVerb | |||||||
Structure: |
![]() |
||||||
Elements: |
|
VerbBase.xsd schema |
Verb type: Verb | |
Verb | |
Structure: |
![]() |
Noun Common Files |
Document.xsd schema |
Document extends: Noun | ||||||||||
Structure: |
![]() |
|||||||||
Elements: |
|
DocumentHeader | ||||||||||||||||||||||||||||
Structure: |
![]() |
|||||||||||||||||||||||||||
Elements: |
|
DocumentLine | |||||||
Structure: |
![]() |
||||||
Elements: |
|
DocumentOrderHeader restricts: DocumentHeader | |||||||||||||||||||||||||
Structure: |
![]() |
||||||||||||||||||||||||
Elements: |
|