OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] Preparing for UBL


David

I also wonder just how much of the long list below (which
probably isn't exhaustive!) your product implements.
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).

Still, your response looks very encouraging to me.

All the best

Steve

>>> "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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]