Definition Type: Element
Name: GetMatchDocument
Namespace: http://www.openapplications.org/oagis/9
Type: nsA:GetMatchDocumentType
Containing Schema: GetMatchDocument.xsd
Abstract
Documentation:
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.
Collapse XSD Schema Diagram:
Drilldown into DataArea in schema getmatchdocument_xsd Drilldown into ApplicationArea in schema meta_xsd Drilldown into languageCode in schema meta_xsd Drilldown into systemEnvironmentCode in schema meta_xsd Drilldown into versionID in schema meta_xsd Drilldown into releaseID in schema meta_xsd Drilldown into BusinessObjectDocumentType in schema meta_xsd Drilldown into GetMatchDocumentType in schema getmatchdocument_xsdXSD Diagram of GetMatchDocument in schema getmatchdocument_xsd (Open Applications Group (OAGIS))
Collapse XSD Schema Code:
<xsd:element name="GetMatchDocument" type="GetMatchDocumentType">
    <xsd:annotation>
        <xsd:documentation source="http://www.openapplications.org/oagis/9">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.

</xsd:documentation>
    </xsd:annotation>
</xsd:element>
Collapse Child Elements:
Name Type Min Occurs Max Occurs
ApplicationArea nsA:ApplicationArea (1) (1)
DataArea nsA:DataArea (1) (1)
Collapse Child Attributes:
Name Type Default Value Use
releaseID nsA:releaseID Required
versionID nsA:versionID Optional
systemEnvironmentCode nsA:systemEnvironmentCode Production Optional
languageCode nsA:languageCode en-US Optional
Collapse Derivation Tree: