kshychko / ausdigital-syn-v1

Ausdigital XML Implementation specification
http://ausdigital.org/syn/
0 stars 1 forks source link

Invoice / RCTI / Debit / Credit Differences #4

Open onthebreeze opened 7 years ago

onthebreeze commented 7 years ago

There is almost no difference between a UBL Invoice and a UBL Self Billed Invoice (RCTI)

Also not much difference between a credit note and a debit note.

Some differences are purely technical such as different ordering of the same elements within the document structure (but still have an impact due to xsd sequence validation rules).

Some differences have some evidence of business intent but seem un-necessary such as "creditedQuantity" / "InvoicedQuantity" / "DebitedQuantity" as different names for the invoice line quantity field. Since the document type is already known then just "quantity" would have been sufficient.

Given that process specific business rules related to the "CustomizationID" key will be used to drive rule differences for these different processes anyhow, it seems an unnecessary overhead to have these slightly different schema. It would be more implementer friendly to just have an inovice schema and then define the business rule restrictions for use of the schema as Invoice / RCTI / Debit Note / Credit Note.

Document element comparison spreadsheet is attached here (note that some elements were re-ordered in order to facilitate line by line comparison) InvoiceDocumentComparison.xlsx

onthebreeze commented 7 years ago

The DBC e-Invoicing semantic model defines only the "CoreInvoice" document. It mentions that this document can be used to support RCTI and adjustment invoicing processes but does not define how the document should be used in each context.

Therefore we infer that DBC has decided that it is more appropriate to use a single document for Invoice / RCTI / Debit Note / Credit Note processes. The Ausdigital specifications will do the same but will provide more specifics on rules for each process.

monkeypants commented 7 years ago

OK, if that's the way DBC semantic working group went, I think that's fine. This approach (single document type across multiple process types) will make the rule set cohesive, which is good for testability.