SV: [ubl-dev] Q's about UBL invoice structure in practice?

["Bryan Rasmussen" <BRS@itst.dk>]

>I'm just looking at InvoiceLine and thinking this is the inverse of what
>it should be?! 
I can't say that UBL has often been the most aesthetically pleasing format
either. 

>E.g. - You would more naturally state the OrderReference as a header -
>and then OrderLineReference child items for that parent Order. 
>Similarly the credit note reference would apply to a group of items -
>because they'd all be off the same sales-order - so no need to repeat
>that for EVERY invoice line - instead that should be a header for the
>OrderReference parent again.

I don't know, but I sometimes get Invoices for stuff that does not have an
explicity order reference.


>The way it is right now appears to create massively large XML instances
>- with little ability to prune - unless you adopt a convention where
>the first item has all this - and then subsequent ones do not - and
>assumption is they are all the same, until it changes.  That of course
>makes the validation rules tougher - not just a simple case of exists /
>not exist.
Not too difficult a validation with Schematron, or I assume with CAM.


>I'm just wondering what people are doing in practice here to make this
>intuitive and easy to use?  
Not sure how intuitive and easy to use it CAN be. We are providing Xforms
implementations of what we consider a commonly used subset.