Re: [ubl-dev] Preparing for UBL

[David Lyon <david.lyon@computergrid.net>]

On Fri, 20 May 2005 5:37 am, Stephen Green wrote:
> David
>
> I also wonder just how much of the long list below (which
> probably isn't exhaustive!) your product implements.

Computergrid is a completely different class of application
than traditional products.

Rather than being an Accounting system built on a 
database with an XML or EDI output interface, Computergrid
is built on XML/UBL documents directly.

It can print paper Invoices/Purchase Orders just like
any traditional system, but is entirely XML based.

> Wouldn't there still be some or even much of the below
> that customers would still need to cover (e.g. finance
> system integration and arrangements with the authorities).

Oh yes, but just like any other system they can get
consultants/IT Professionals to do that sort of stuff. 

The whole thing is about creating more opportunities
for customisation than less.

Those with the most toys win... or at least have the
most fun....

>
> >>> "Stephen Green" <stephen_green@seventhproject.co.uk> 20/05/05 10:15:10
> >>> >>>
>
> Hi David
>
> What sort of subset of UBL does Computergrid use?
>
> I ask because the SMEs who use Computergrid would
> need to trade with businesses which don't use it,
> wouldn't they.
>
> Many thanks
>
> Steve
>
>
> ----- Original Message -----
> From: "David Lyon" <david.lyon@computergrid.net>
> To: <ubl-dev@lists.oasis-open.org>
> Sent: Friday, May 20, 2005 5:39 PM
> Subject: Re: [ubl-dev] Preparing for UBL
>
> > Stephen,
> >
> > Yes they could do all that...
> >
> > alternatively, they could just spend the $300 and buy a
> > product like Computergrid which provides the capabilities
> > that they need.
> >
> > This is what we are doing in the Computer Industry in
> > Australia - enabling Computer shops to be up and running
> > with UBL in about half an hour.
> >
> > Small businesses just aren't like Government departments
> > or big companies - just don't have endless time or budgets
> > to play with. It's got to work quickly and simply..
> >
> > As good as it may be.. if an open source UBL system requires
> > 300 hours to get going, the real cost is 300 * whatever the
> > hourly rate is. That may run into the thousands...
> >
> > Not all businesses want to waste that sort of money on
> > UBL... so people need to be clear about what the real costs
> > of "free" UBL actually are.
> >
> > Anyway... food for thought...
> >
> > Regards
> >
> > David
> >
> > On Thu, 19 May 2005 10:02 am, Stephen Green wrote:
> > > Micah
> > >
> > > A few simplistic notes (all my own opinion, etc and not to be relied on
> > > without checking
> > > out for accuracy, IP, regulations, etc...):
> > >
> > > you need trading partners who:
> > >
> > > - are willing to adopt UBL (persuasion and/or pressure needed here)
> > >
> > > - have the resources to adopt UBL (this you are already helping with
> > > the SBS) My own main
> > > item on my personal task list of how to prepare for adoption is to help
> > > with the SBS or
> > > equivalent and to fill any similar gaps to make adoption easier,
>
> preferably
>
> > > working with OASIS)
> > >
> > > - have themselves other trading partners who are willing to adopt UBL -
> > > hence getting UBL
> > > into horizontal acceptance would help prepare for adoption here, as
> > > with the SBS but also
> > > (as again you are already helping to do :-) ) with getting UBL into
> > > mass tools support
> > > such as encouraging XForms support for UBL in products like OOo (which
> > > arguably has
> > > an added advantage, perhaps politically and economically, of being free
> > > open source)
> > >
> > >
> > > then with regard to gaps and addressing the BPM side a bit you need:
> > >
> > > - for there to be (either because you or others have produced it or you
>
> or
>
> > > others have persuaded
> > > a suitable organisation to produce it on your and yourtrading partners'
> > > behalf) a specification
> > > of a suitable workflow or set of collaborations (as in ebXML-BPSS) to
>
> which
>
> > > trading partner agreements
> > > (for example, but not limited to, ebCPPs and ebCPAs) can refer. This
>
> helps
>
> > > with identification and
> > > thence routing and reliable handling of exchanged messages. Resources
> > > or relevant standards to
> > > your business may determine how you do this or prepare to do it. You
>
> might
>
> > > decide to set up a
> > > ebRegistry or UDDI registry to hold the various specs. For a BPSS you
>
> might
>
> > > need a registry to be
> > > set up on your and your trading partners' behalf by a suitable body or
> > > agency. If you are not
> > > in a suitable industry for it to be done by an industry body which your
> > > trading partners also regard
> > > then there might be problems (this is the bit I might find most
>
> difficult)
>
> > > - a suitable way to create the agreements and specs and for your
> > > trading partners to do so too
> > > (maybe you can help some of them do this, or maybe an agency you have
> > > in common can, or maybe
> > > your own agency would help them as well as you) - perhaps VANs will
>
> restyle
>
> > > themselves for this
> > > as DaveW mentioned
> > >
> > > - if you want super systems with full automation then the above needs
> > > to
>
> be
>
> > > done 'properly' - at
> > > least there may be limits imposed on how it can be done (perhaps it's
>
> still
>
> > > a bit early for this and besides
> > > you or your potential trading partners may find it too challenging,
>
> risky
>
> > > and politically unacceptable as yet)
> > >
> > > - for the BPSS and maybe for the CPP/CPAs and for any other
> > > preparations for trading I can think
> > > of you would need to identify the exact processes you wish to engage in
> > > with UBL (perhaps mixing
> > > with other standards too). In a BPSS you'd need to break this into
> > > collaborations, essentially binary
> > > (or more comlex) but one-way messages are possible. This can be helped
>
> with
>
> > > patterns (ebBP TC just
> > > mentioned that an Invoice might be a one-way 'exchange' and can use the
> > > pattern for this called
> > > 'Notification'. I guess for many either just the Invoice or just the
>
> Order
>
> > > or Order/OrderResponse
> > > (depending perhaps on your postion in a supply chain and your influence
> > > among you trading partners)
> > > would be the first for concentrating on for return on investment.
>
> Denmark
>
> > > and Sweden have started with
> > > Invoice and then started looking towards the Order. I'd prefer to start
> > > with the Order/OrderResponse
> > > where these could be used with web trading sites provided by suppliers
>
> who
>
> > > might then send OrderResponse
> > > messages and later Invoices too. A credit note might be handy but this
> > > doesn't exist in UBL yet and besides
> > > there may be less ROI for it (fewer messages) but it may be mandatory
>
> that
>
> > > you not mix paper with
> > > electronic in the same process (depends on local regulations perhaps)
> > >
> > > - you may need to clear the whole thing with stakeholders, auditors
>
> (local
>
> > > and industry), tax offices, etc
> > >
> > > Maybe there needs to be better help for these things in OASIS and even
>
> in
>
> > > the UBL TC (e.g. providing
> > > ebBPSS documents for the UBL processes, besides the SBS and form specs,
> > > etc) to help those in a
> > > more horizontal setting (not have a major industry body to provide them
>
> for
>
> > > your supply chain). That's
> > > the sort of position of need of help I would be in.
> > >
> > >
> > > Then you (and your trading partners but perhaps with different software
>
> for
>
> > > your different roles) need software to:
> > > - handle messages, perhaps routing depending on a message header such
> > > as ebMS
> > > - extract data for integration with legacy systems, etc
> > > - produce return messages at several 'layers' (e.g. for the messaging
>
> layer
>
> > > such as for reliable messaging, etc,
> > > for the general business layer e.g. to signal a message receieved,
> > > processed successfully, etc  the specific
> > > business message layer e.g. from your finance system e.g, to return an
> > > OrderResponse to an Order or an
> > > OrderResponseSimple)
> > >  - perhaps to add SSL, etc
> > >  - to send messages from the finance system or various message layers
> > >  - provide an audit trail
> > >  - archive messages and perhaps related artifacts with them or
>
> separately
>
> > >  - involve humans where necessary (e.g. on certain errors or where
> > > there were message contents that couldn't be
> > >     understood or just for every message contents before it gets into
>
> the
>
> > > finance system or perhaps to manually
> > >     or semi-manually input messages)
> > >  - in some cases you might need to use special software to extract
> > > paper-based output or input
> > >     into UBL (as with Denmark's) or from UBL into paper-based
>
> documentation
>
> > > (e.g. with UNLayout and Ken's stylesheets)
> > >  - some may wish to get software to automate the finding and
>
> arrabgements
>
> > > with suitable suppliers or buyers, etc
> > >  - validation software, e.g. based on Schematron, script or the like or
> > > perhaps using proprietary software
> > >
> > > Then you might need to customise UBL and produce tighter schemas
>
> specific
>
> > > to your needs (and get the
> > > trading partners to accept them too, perhaps combining theirs and
>
> yours),
>
> > > perhaps producing schematron
> > > schemas to help with the validation (yours and/or theirs). This assumes
> > > tighter coupling of trading partners
> > > and maybe you can do better than that with UBL (e.g. if there were to
> > > be
>
> a
>
> > > very common implementaion
> > > of UBL in readily available or even free-opensource software which met
>
> most
>
> > > requirements just enough
> > > to justify the extar work using it to get data to and from your systems
>
> and
>
> > > likewise appealled to your
> > > potential trading partners and had sufficient acceptance in the legal,
> > > government and finance departments
> > > to be allowed for this purpose e.g. being sufficiently non-exclusive
> > > for public sector use  --  e.g. OOo etc??)
> > >
> > > That's all I dare write for now.
> > >
> > > All the best
> > >
> > > Steve
> > >
> > >
> > > ----- Original Message -----
> > > From: "Micah Dubinko" <micah@dubinko.info>
> > > To: <ubl-dev@lists.oasis-open.org>
> > > Sent: Tuesday, May 17, 2005 11:15 PM
> > > Subject: [ubl-dev] Preparing for UBL
> > >
> > > > I am researching for an article on UBL. What steps would you
> > > > recommend an organization to take in order to prepare for UBL
> > > > adoption?
> > > >
> > > > I'm also interested in any links between UBL and BPM, especially as
> > > > real-world experiences. Can anyone elaborate?
> > > >
> > > > Thanks!
> > > >
> > > > .micah
> > > >
> > > > --
> > > >   Available for consulting. XForms, web forms, information overload.
> > > >   Micah Dubinko                           mailto:micah@dubinko.info
> > > >   Brain Attic, L.L.C.                        http://brainattic.info
> > > >   Yahoo IM: mdubinko                                +1 623 298 5172
> > > >   Learn XForms today: http://xformsinstitute.com
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> >
> > --
> > Computergrid : The ones with the most connections win.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

-- 
Computergrid : The ones with the most connections win.