LoadPurchaseLedgerInvoice schema, example, validation rules, validation stylesheet |
LoadPurchaseLedgerInvoice type: LoadPurchaseLedgerInvoice | |
In certain application suites, purchase order / 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 accounts payable application may have to inform the purchasing application of the unapproved supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, 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. The purpose of the LoadPurchaseLedgerInvoice is to transmit data to create an unapproved open item in either a payables application or a purchasing application. The scope of the LoadPurchaseLedgerInvoice indicates that the supplier’s invoice has not yet been approved and the invoice is to be used as part of the invoice matching process. OAGIS has already defined the scenario for invoices that are approved for payment in a separate BOD namely LoadPayable. |
LoadPurchaseLedgerInvoice extends: BusinessObjectDocument | |||||||
Structure: |
![]() |
||||||
Elements: |
|
LoadPurchaseLedgerInvoiceDataArea extends: DataArea | ||||||||||
Structure: |
![]() |
|||||||||
Elements: |
|
LoadPurchaseLedgerInvoice Scenario Diagram |
Load schema |
Load type: Load | |
This verb is used to initiate the adding of a document or data entity to another business application. Generally this verb is used when maintenance to the document will then pass to the receiving application permanently. An example of this is Load Payable or Load Receivable, where once the request is processed, the sending application has no direct control over the document or entity again. |
Load extends: Verb | ||||||||||
Structure: |
![]() |
|||||||||
Elements: |
|
PurchaseLedgerInvoice schema |
PurchaseLedgerInvoice type: PurchaseLedgerInvoice | |
A PurchaseLedgerInvoice represents a not yet approved for payment purchase ledger invoice or debit memo. A PurchaseLedgerInvoice uses an InvoiceReference to reference the original suppliers invoice. |
Header type: PurchaseLedgerInvoiceHeader | |
Line type: PurchaseLedgerInvoiceLine | |
PurchaseLedgerInvoice extends: FinancialDocument | |
A purchase ledger invoice or debit memo that has not yet been approvedfor payment. Deprecation of VOUCHER, ORIGREF: From OAGIS 7.2.1: ORIGREF is the link that ties back to a sub ledger transaction entry ID. It is the identifier of an original transaction or document. For example, it could be the receipt or the summarized inventory activity. This is the singular field that refers to an audit record. Together with the Sender information, the ORIGREF is part of the referencing system, which will enable drill back audit trail functionality. PN: The ORIGREF field represents the voucher or unapproved invoice identifier. VOUCHER is the internal identifier associated with the external supplier’s invoice. REMITTANCE refers to a reference identifier to print on remittance advice, for example, supplier invoice number. In OAGIS 8: All of these can be accomplished with an InvoiceReference. I never understood why there was an ORIGREF, a VOUCHER and a REMITTANCE. I left REMITTANCE field in until the RemittanceAdvice BOD is part of OAGIS. Deprecation of USERID: An AccountingContact semantic has been added and is used within the CustomerParty instance of the PurchaseLedgerInvoice. |
|
Structure: |
![]() |
PurchaseLedgerInvoiceHeader extends: FinancialDocumentHeader | |||||||
Structure: |
![]() |
||||||
Elements: |
|
PurchaseLedgerInvoiceLine extends: FinancialDocumentLine | |||||||
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 |
FinancialDocument.xsd schema |
FinancialDocument extends: Document | |
Structure: |
![]() |
FinancialDocumentHeader extends: DocumentHeader | |||||||||||||||||||||||||||||||||||||
Structure: |
![]() |
||||||||||||||||||||||||||||||||||||
Elements: |
|
FinancialDocumentLine extends: DocumentLine | |||||||
Structure: |
![]() |
||||||
Elements: |
|
Document.xsd schema |
Document extends: Noun | ||||||||||
Structure: |
![]() |
|||||||||
Elements: |
|
DocumentHeader | ||||||||||||||||||||||||||||
Structure: |
![]() |
|||||||||||||||||||||||||||
Elements: |
|
DocumentLine | |||||||
Structure: |
![]() |
||||||
Elements: |
|
DocumentOrderHeader restricts: DocumentHeader | |||||||||||||||||||||||||
Structure: |
![]() |
||||||||||||||||||||||||
Elements: |
|