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

["Stephen Green" <stephengreenubl@gmail.com>]

Sounds like the right approach

Good luck

-- 
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 05/02/2008, Michael Strasser <Michael.Strasser@brisbane.qld.gov.au> wrote:
> 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.
> **********************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>