[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]