RE: [ubl-dev] Creating a new document... where to start?

[david.lyon@computergrid.net]

Roger,

I think you'll find that orders and invoices are always a messy business. It's
an imperfect science that when all else fails, through more clerks at it or
just yell down the phone louder... it all works out in the end. That would be
the SMB approach that I have seen.

After all, my broad sweeping statement, is that it depends in which industry you
are implementing has a great deal to do with how much attention is paid to line
items.

In manufacturing, an enormous amount of detail seems to be applied to line
items, especially tracking which items have come in according to the job.

I don't know if other people are finding this, but a decade ago, all the action
was in large companies. They were the only ones that could afford IT and EDI.

Now it seems that the activity is in medium sized companies who have just grown
out of "small". Whilst having a tenth of the budget of large companies, there
seem to be twenty times as many.

All want the best and latest software, and have the money to pay.

I think it is a very good time for UBL

David



Quoting Roger Bass <Roger@traxian.com>:

> Stephen et al,
> 
> My company's experience in implementing our solution to connect small
> businesses (SMB) and enterprises is that it's not a problem when an SMB
> is receiving an inbound document that is "large" (in the sense of tagset
> size relative to SBP tagset size) - the more limited (SBP) tagset is
> typically included, and they can just drop/archive the other stuff.
> 
> The issues arise with the typical enterprise requirement for a "large"
> tagset for *their* inbound documents, say an invoice from an SMB
> supplier. 
> 
> So, in your terms, the relevant message, from enterprises in particular,
> is: "I'm prepared to accept SBP-messages (even though my preferred
> format contains these other tags)". Small biz oriented solutions such as
> ours would likely send and receive SBP-compliant messages as a matter of
> course.
> 
> It's not entirely clear to us what (other than having a lot of SMBs
> implemented) would drive enterprises to do this. ERP solution providers
> such as SAP might carry some weight, but these issues are driven by AP /
> Order Entry validation processes, which are much deeper than just the
> standard used to communicate the document, and not lightly changed.
> 
> Roger.
> 
> 
> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] 
> Sent: Tuesday, June 22, 2004 9:53 PM
> To: ubl-dev@lists.oasis-open.org
> Cc: paul_johnston@seventhproject.co.uk
> Subject: Re: [ubl-dev] Creating a new document... where to start?
> 
> Ken
> 
> Mmm..  Thanks for that. But (I'll acknowledge my colleague Paul
> Johnston's
> idea
> behind this).. what I need is a way for a SBP-user to say to anyone 'I'd
> like pro-SBP
> (i.e. SBP-friendly) messages please' e.g. when sending the order -
> 'Please
> return
> an SBP-friendly invoice,etc'
> 
> With ebXML I guess that could be in the CPA and that gets registered.
> This
> gives
> small businesses the means to say 'I want SBP-friendly orders' before
> any
> document
> gets sent.
> 
> UBL does have an order response code in the order. Maybe it should have
> a
> general response code in every document.
> 
> Steve
> 
> ----- Original Message -----
> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
> To: <ubl-dev@lists.oasis-open.org>
> Sent: Wednesday, June 23, 2004 1:03 AM
> Subject: Re: [ubl-dev] Creating a new document... where to start?
> 
> 
> > At 2004-06-22 20:55 +0100, Stephen Green wrote:
> > >You expound on 'constraints' and explain that XSD needn't be used
> > >to express them,
> > >
> > >but:-
> > >
> > >If XSD were to be used;
> > >
> > >Is there a (standard or accepted) way to say in or with the XSD
> > >what *kind of constraint* we are using? (I refer to the kinds of
> constraint
> > >at the end of your message)
> >
> > Nope, not that I can think of.
> >
> > >If not, can we invent one?
> >
> > Not that would be schema expression independent (so as to allow schema
> > expressions in many possible schema expression languages to determine
> it).
> >
> > If we had an attribute or element in the instance, we might imply the
> > semantic of "standardized full UBL" when that information item is
> absent,
> > or "contextualized UBL" when the information item is present, and then
> > publish a mechanism by which we syntactically represent context in the
> > information item.
> >
> > Say it were an attribute ... when absent in the instance, a processing
> > application can assume it has the full range of UBL to expect.  When
> > present in the instance, it might have values, say "SBP" for the small
> > business profile, or "SBP:Auto" for the small business profile used in
> the
> > automotive industry.
> >
> > Then, we could add the constraint to each profile that the context
> > information item be properly formatted for that profile ... then when
> you
> > validate the instance against the profile, rogue values would be
> flagged,
> > and when you validate the instance against full UBL all values would
> be
> > acceptable.
> >
> > But I'm wary of signalling the context physically in the instance ...
> but
> I
> > don't know why I'm uneasy about that.  On the surface it seems to make
> > sense: an application can recognize from the context which set of
> > supplemental or derivative constraints are needed for validation.  But
> I
> > think the reason goes very deep.
> >
> > >P.S.  I guess 'context' gives us a way to say the *reason* for the
> > >constraint(s)
> >
> > Yes, but its "messy".  Not only would we have to introduce such an
> > information item into UBL 1.1, but I'm wondering if it is somehow
> breaking
> > the arbitrariness of the flexibility of applying different schemas to
> > different instances.  Perhaps not ... I am anxious to hear other
> users'
> > comments.
> >
> > You see, the thing is that an application that is tied to the SBP need
> only
> > validate that an instance fits the SBP constraints on top of the UBL
> > constraints ... of what use is a signal to say "this is an SBP
> instance"
> > when a validation task will tell an application that anyway.
> >
> > In fact, maybe now I'm thinking it is too limiting to actually tag a
> UBL
> > instance to be an SBP instance ... what if a fully-supported UBL
> > application outputs an XML instance that meets the user's needs, and
> it
> > just coincidentally happens to meet the SBP constraints: an SBP
> application
> > will successfully work with it because it passes the SBP constraints.
> If
> > it doesn't pass the constraints then it could never have been used.
> If
> the
> > SBP were looking for a signal, and that signal either wasn't there or
> we
> > made the signal a mandatory part of the SBP profile, then the user
> loses
> > out on possible benefits of using the SBP software that they would
> have
> > been able to use had the validation been based solely on the presence
> of
> > UBL information items, not on the value of a magic attribute.  But
> without
> > the explicit signal the instance is simultaneously usable in all of
> the
> > possible UBL contexts to which it validates.
> >
> > So all that thinking aloud to come to the conclusion that, "no", don't
> put
> > anything into the instance to signal it is an SBP instance .... just
> let
> > validation assess that it is an SBP instance so as to put the burden
> back
> > on the application and the flexibility back in the hands of the
> > users.  Whenever they happen to create an instance that passes SBP
> > validation, they have the flexibility to use SBP software.  If their
> > particular needs one Thursday afternoon requires them to use
> additional
> > properties, then they have those additional properties and SBP
> software
> > rejects the instance, but that's okay because the user should have
> avoided
> > those properties and validated the SBP constraints if it was important
> that
> > they had to use SBP software.  And, from time to time users may have
> > instances that are simultaneously usable in software that supports a
> number
> > of different profiles, and then they don't have to do anything at all
> to
> > take advantage of all of that software.
> >
> > ...................... Ken
> >
> > --
> > Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
> > World-wide on-site corporate, govt. & user group XML/XSL training.
> > G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> > Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
> > Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> > Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
> > Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
> >
> >
> 
> 




-------------------------------------------------------