Dear all,
I'm a member of a committee that works on a Croatian standard for e-Invoice based on UBL.
We studied UBL version 2.0 as a base, but found out that we had a few fields in our business model for which we could not find a proper mapping.
Here they are:
1. InvoiceReference
Invoice could contain a reference to another invoice, most often expressed through the invoiceID and date. This information is most often used in DebitNote or CreditNote.
Example of business context is when supplier sends a CreditNote document to the buyer because on one of the previous invoices there was an error and the price was higher than it should have been. Now, when supplier wants to issue the document to give buyer a credit for the difference, there should be a reference to the original document (invoice) that contained the error.
Use UBL 2.0 Credit Note or Debit Note (UBL-CreditNote-2.0.xsd, UBL-DebitNote-2.0.xsd)
as required. Or, if that is not acceptable for some reason, use
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>ABCD123456...</cbc:ID>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
2. OfferReference
Invoice could contain reference to the offer that started the whole transaction
<cac:AdditionalDocumentReference>
<cbc:ID></cbc:ID>
<cbc:DocumentTypeCode></cbc:DocumentTypeCode>
<cbc:DocumentType> </cbc:DocumentType>
</cac:AdditionalDocumentReference>
and best practice might be to create a codelist including 'Offer' for the DocumentTypeCode
(agreeing this codelist with trading partners, say, as part of tech appendix to terms) and/or use
<cbc:DocumentType>Offer</cbc:DocumentType> with or without DocumentTypeCode
Using a code might be necessary to cater for more complete automation in matching
invoices to offers, if that is what is needed; otherwise just prose DocumentType might be
enough - for human readability and human matching (say an auditor) of invoice to offer.
3. BusinesEventOrActivityIndicator
Invoice (especially Debit Note and Credit Note) could contain the codes and corresponding explanations of the business events that resulted in issuing the invoice.
Example of business context is that ,e.g. a Credit Note is usually a result of wrongly calculated price on one of previous invoices, but there could also be another reasons for issuing it. It is sometimes important to exactly know the reason why it has been issued (expressed through the code of the type of business transaction that cause it and corresponding explanation), so that it could trigger the specific action on the recipient side.
set up descriptions of profiles for the various processes and assign IDs to these
(e.g. in technical appendix of terms of trading)
then use
/in:Invoice/cbc:ProfileID
e.g.
<cbc:ProfileID>bpid:urn:oasis:names:draft:bpss:ubl-2-sbs-invoice-notification-draft</cbc:ProfileID>
(which is an example using the small business subset)
4. PlaceOfProcessing
Part of the enterprise responsible for processing of e-invoice (usually address or ID of regional headquarter – potentially expressed as GLN).
In some enterprises there are rules where the paper invoices should be sent to (to which address - usually regional headquarters), so that regional headquarter office could check whether the prices and the quantities match with the supplied goods and approve (or disapprove) its further processing.
When converting to e-invoicing, this information is still required because the business rules within the company that decide who should give approval for the invoice are still in place (and they are based on that address – business processes and internal ERP systems are still set up for processing paper invoices and they need this information, although the address of the “inbox” will be the same for all the e-invoices).
Sounds like this is still AccountingCustomerParty (but if you mean the party making
payment and it differs from AccountingCustomerParty then use PayeeParty)
If the invoice is paid by a party other than the party processing the invoice then
the invoice processing party is AccountingCustomerParty and the paying party
is PayeeParty. Both might be different to OriginatorParty which does not appear
in invoice (does appear in order). (If you really needed to have the Originator
info included in invoice, either have it in Order and get it from there via OrderReference
or extend invoice to include it - last resort)
I’d appreciate if you could help us to find out the best solution for the problems mentioned above, as we would like to avoid treating them as extensions if possible.
Best regards,
Darko Gulija
Knowledge Management Consultant
Infodom d.o.o.
A. Žaje 61/110000 Zagreb, Croatia
T: +385 1 3090 507
F: +385 1 3040 593
