Re: [ubl-dev] Modelling internal documents with UBL v2.0

["Michael Strasser" <Michael.Strasser@brisbane.qld.gov.au>]

Stephen (and others)
 

Thank you all very much for your suggestions and schemas. I have 
to attend to other work and will look at them closely when 
I have more time.

I may not be have been clear in at the outset but we are not yet 
communicating any of this with other organisations. I am using 
UBL because I wanted a base on which to design these XML documents. 

My approach will be to start with greatly simplified UBL documents 
to meet our minimum requirements. For example, the source system 
stores many (all?) addresses as three lines of text so I will use 
only cac:AddressLine/cbc:Line elements instead of individual address 
components.


Thanks again

Michael Strasser
Brisbane City Council
Brisbane, Australia


>>> "Stephen Green" <stephengreenubl@gmail.com> 5/02/2008 07:21 >>>

Hi Michael

Would the documents suggested be of use in your situation?
i.e. P.Order, R.F.Q. and Remittance Advice from UBL 2.0
plus a custom Requisition (Warehouse Requisition) and a
custom Despatch Request as drafted? Would the Order
Change from UBL 2.0 be of use?

My experience in local government tells me there is not so
much of a need to implement all these documents since it tends
to be expensive to implement each document type (validation
etc) and not all documents give the same return on investment,
hence Invoice and Purchase Order (or Order Responses) seem
to be the main ones implemented initially. I therefore wonder
whether, in local government, implementing unusual documents
or even those not yet supported out-of-the-box by UBL is all
that realistic as a first step. You may find that you need a fair
bit of subsetting of initially the main documents - Order and
Invoice and maybe Order Response (and/or Order Response
Simple) before they can be implemented and this may take a
fair bit of your resources. Those implementations of UBL we
are most aware of have been of drastically cut down subsets
of first Invoice then Order, particularly a limited implementation
of just the Invoice to start with, not necessarily on its own but
possibly accompanying a scanned image of the invoice (like
an index for OCR-extracted data from the scanned invoice).

Otherwise you might find getting others in your supply chain to
all implement those same documents using UBL and using the
same subsets as your organisation, perhaps without existing
ready-made software to support this all round, a challenge to
say the least. Just designing and agreeing to use the same
subsets throughout the chain may be such a challenge that you
are forced to settle on just the PO at first (since you do not
mention the need for the Invoice). Of course the use of UBL
compliant custom documents internally may be viable but then
why use UBL internally at all, why even use electronic documents,
why not just use data straight to fax from database if there is no
external party involved? And if documents are preferred even for
internal use, why should they be based on standard documents
if you don't yet have other standard documents implemented?

These are questions from experience - mine and others' (mainly
others'). Sorry not so many answers as questions. From UK
Gov experience in general I've found that the big challenge is to
first seek agreement across the public sector or at least across
the local government sector on which documents to concentrate
resources on implementing in order get an economy of scale. So
much resource went into establishing which standards to use
(e-GIF) then on creating subsets for those standards which met
the broadest possible range of needs in the sector, then on
fostering third party software support from the local software
industry - all resource intensive programs with lots of consultancy
(and wining and dining :-) but not too much to show for it at first.
Having the kind of Government that can follow it through to full
adoption (like Denmark seems to be doing) is the key factor before
risking wasting resources on something that won't get finished.

The easy answer is wait and see what the software industry near
you decides to support, unless you've free access to central gov
funding and power, say, to be able to influence the industry in
what might seem to be the public interest. Or influence on the
central government development of e-GIF standards, etc which
seek to do the same.

With regard to UBL's complexity, it's all about subsetting, in my
opinion, and that means influence again on getting the subset
widely adopted and bought into - enough to make it feasible for
the whole supply chain as it were. In EU it has been going on
on a regional level for the public sector but whether it follows
through to adoption, even then, remains to be seen. One hopes.
Adoption may depend a lot on cost of adoption and that may in
turn depend on reducing complexity radically enough (like pruning
roses) but those aren't the only factors. There's also politics like
attitudes to open standards / processes and consultant-intensive
customization projects and preferred software suppliers and their
preferred standards in turn. Best to try to figure all this out before
diving in to implementation.

Best regards

-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk 
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

On 01/02/2008, Michael Strasser <Michael.Strasser@brisbane.qld.gov.au> wrote:
> I am new to UBL (but not to XML) and am looking to model five documents to be generated by one of our systems that will be converted into faxes to be sent both internally and externally. I looked for standard XML vocabularies for such documents and naturally found UBL.
>
> The documents are Purchase Order, Remittance Advice, Request for Quotation, Warehouse Requesition and Request for Delivery (expedite letters for ordered items outstanding). The first three map directly to their UBL namesakes.
>
> The other two are not so simple. My instinct is that Warehouse Requisition is really a type of order where the seller is another part of our organisation. I'm not sure about Request for Delivery. I suspect that UBL-Order may model it as well but I'm don't know if these requests can refer to multiple previous orders. Does this sound reasonable or have I missed a document type?
>
> I may also ask questions about how to cope with UBL's complexity. The range of choices appear overwhelming at first and I am looking for some best-practice or common-practice advice in using documents and common components. That advice may be from the list or from resources you recommend.
>
> I really appreciate any help you can give on any of these matters.
>
>
> Regards
>
> Michael Strasser
> Enterprise ICT Architecture
> Brisbane City Council
> Brisbane, Australia


**********************************************************************
   This message has passed through an insecure network.
    Please direct all enquiries to the message author.
**********************************************************************