[ubl-dev] A 'Lite' Profile for UBL

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Folks

 

I'd like to soon post an update of the Prototype 0.1 of the proposed lightweight profile for UBL

called UBL Lite.

 

I'd like to drop the word 'Deprecated' as per Jon Bosak's request (it can be too easily

misinterpreted) and update the rules accordingly to be just one rule, as follows:-

 

"All Business Information Entities (BIEs) designated in the profile as 'Recommended' MUST NOT

be ignored in conforming business applications whereas other BIEs MAY be ignored by such

applications".

 

I'd then propose an updated set of tables for Invoice, Order and Reusable models with the

column added as before to show 'Recommended' ('R') BIEs but without the label 'D' for other BIEs

(they would just be left unlabelled, I propose).

 

Please send any objections to the list and if I get the idea it is acceptable I'll try to send an updated

prototype at the start of September, calling it UBL 1.0 Lite Profile 0.2 ('UBL Lite' for short).

 

I do not anticipate further changes to the models of UBL before submission but one never knows :-)

 

I've thought about whether to specify profile-recommended attributes (i.e. so-called Supplementary

Components, such as those which define the source of a codelist or a code value for a Code element)

or whether such granularity should be left just to guidelines for best practise and to implementer

discretion.

 

It has also been commented offlist that maybe the scope for the profile stops with one locality (i.e. UK)

but I tend to think that it could be applied across the EU at least and at best may be quite appropriate

for much of the world. I anticipate some surprises when comparing the minimal requirements for orders

and invoices in lightweight applications between geographic regions and I personally think that there may be

a common subset which covers most areas requirements and so lends support to finance applications

for small businesses in particular which might be sold in many countries. Support for differing tax rules

might be catered for by such a subset when only lightweight support is in mind.  It was my opinion that

support of tax be left in the invoice but perhaps this is unreasonable for North American small business

finance applications. *

 

Comments? Objections?

 

I'd be especially interested in hearing from developers of lightweight business apps covering muliple

localities e.g. EU and North America or EU and Asia or Asia and South America. Remember this is a subset

of UBL so it cannot cater for requirements not catered for by the full UBL documents. Anything required

for inclusion in UBL 1.1 but not in UBL 1.0 would have to wait for a UBL Lite profile for UBL 1.1

 

Any comments too on how best to proceed with the establishing of such a profile as this? My inclination

is to try to avoid change as much as possible to promote stability since we do not yet have the benefit

of the full OASIS standardisation process which a TC process could afford. This way the content of the

specification might gain maximum recognition even prior to any formal standardisation. Perhaps just

a few interations in line with UBL 1.0 changes, then a major version according to the UBL 1.0 release

with further changes being left until the time between minor UBL version release.

 

All the best

 

Stephen Green

 

 

* My own opinion:

 

I feel that UBL does lend itself to such a clearly defined subset since there are few choices avaliable in

what to leave in and what to leave out. It really just seems to come down to things like - should tax be

in or out (if left in, it is really self-evident that it should be left out at line level when a lightweigt profile

is considered). So applying typical small app features as restrictions leaves little scope for choice with

fully valid instances and mere subsetting as the aim. Features follow those of UBL itself. There are a few

decisions I have made in producing a prototype such as to leave Credit Card payment details out of the

order (and allow applications to include these as optional extras which other apps may or may not support)

and to include in the invoice the ability to specify 'cheque payable to...' in an invoice without resorting to

the use of the Note entity. Other aspects of a document such as the handling of hazardous goods are

obviously no going to be supported by anything like a majority of lightweight appliactions or be expected

to be so by general small businesses when this would then be an extra overhead for small businesses

which did not need such details. The idea too is to leave out any requirement for businesses to support

features (such as unnecessary line-level detail) which cannot be supported by the lower end small

business applications. Hence perhaps requiring support of tax in the invoice is unreasonable  or should

be adapted further for North American small business finance applications. If there were mutually

exclusive needs of small business apps in EU/Asia and in North America say then perhaps the answer

is a lite profile for EU/Asia, etc and another for N.America.