InvoiceLine Item Category

Hello,

 I am researching information on UBL to introduce it in my organisation.

 I noticed that the InvoiceType can contain one-or-many InvoiceLine which are associated with an Item.

 

In my organisation, invoices contain invoice lines too. However, invoice lines are grouped by their item category. The category name is a subheader before each invoice line group whose items are part of the same category. Categories are like "Services", "Software licences", "Subscriptions", "Network hardware", "Server hardware", etc.

Example:

 Subscriptions
-----------------------------------------------------------------------------------
* Invoice Line 1 - Item: yearly subscription ABC $100
* Invoice Line 2 - Item: yearly subscription XYZ $50

---> Subscriptions subtotal = $150 

Software licences
-----------------------------------------------------------------------------------
* Invoice Line 3 - Item: 50 seats licence for software A $50
* Invoice Line 4 - Item: 4 CPU licence for software B $10

---> Software licences subtotal = $60

 

How would you define these categories?

Would it be an InvoiceLine and each invoice line would be in SubInvoiceLine?

Would it be defined in the InvoiceLine Item in one of the various *ItemIdentification ?

Should we extend the InvoiceLineType so they can be grouped by a category ?

Well done so far in your analysis of the use of UBL!

Remember one principle is that the UBL instance must reflect all calculations (even simple ones) that are expected of the recipient. Accordingly, I think you have correctly proposed the use of a subinvoice line below invoice lines. 

Absolutely I would not recommend any kind of extension since it isn't necessary.  Remember that extensions are grouped at the beginning of UBL instances and you would have to make associations, document your non-UBL approach, etc. So definitely do not use extensions.

As for grouping by identification or by type, such would not reveal in the XML the subtotals in the instance and you are expecting the recipient to do things that might be challenging for them. 

But I am not the invoice expert and I hope others will comment.

Better still, I propose that you take this question to the UBL-Dev mailing list so that other UBL developers can make their observations for you. That is a better place for technical back-and-forth than the forms of ubl.xml.org.

Good luck in convincing your organization to use UBL!

. . . . . . . Ken

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I