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: Fw: [ubl-dev] Creating a new document... where to start?


Sorry, forgot to select 'Reply All'...
Message attached below
Steve


> Thanks Roger,
> 
> But what happens when an order, say, comes in to an SMB with
> line level items that the app can only handle at document level?
> Presumably some of that data is at risk of either having to be
> summarized/summed with potential for error or at least of not
> being able to be passed back to the trading partner in the invoice.
> 
> I suppose if the small app can't handle line level discount it can
> just add up any in the document and store it internally at header
> level but what about more complex issues? What if it received
> more than one tax code per line but couldn't handle that? Doesn't
> there need to be either agreement to not be getting these things
> or a lot of exception handling code adding to the cost of the app?
> The potential for overly complex business rule decisions when
> it comes to tax and discount, etc and even multiple allowance/charges
> which can't be catered for in the app - the potential for program
> error and questionable workarounds must surely be quite great.
> 
> Steve
> 
> ----- Original Message -----
> From: "Roger Bass" <Roger@traxian.com>
> To: "Stephen Green" <stephen_green@seventhproject.co.uk>;
> <ubl-dev@lists.oasis-open.org>
> Cc: <paul_johnston@seventhproject.co.uk>
> Sent: Wednesday, June 23, 2004 7:42 PM
> Subject: RE: [ubl-dev] Creating a new document... where to start?
> 
> 
> 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
> >
> >
> 
> 


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