OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Mapping business model fields to UBL 2.0


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.

 

2.       OfferReference

Invoice could contain reference to the offer that started the whole transaction

 

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.

 

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).

 

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

 

 

cid:image001.jpg@01C9E2A2.6A723A20

Infodom d.o.o.
A. Žaje 61/1

10000 Zagreb, Croatia

T:     +385 1 3090 507

F:     +385 1 3040 593

W:   www.infodom.hr

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]