[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Multiple supplier account invoice
Sorry Diogo, on my method 4) listed I should add that the OASIS SET TC aims to allow interoperability improvements even when the document isn't an OASIS UBL 2.0 Invoice as defined by the standard schema but merely based on the UBL NDR. That's because two documents defined with schemas conforming to the UBL NDR will be based on the CCTS standard, in turn based on the ISO data dictionary standard ISO 11179 and this fact can be used to help find equivalent or near equivalent components (especially using SET tools). So even custom documents can have interoperability results when other aspects of UBL (the NDR) are implemented, as with other standards based on CCTS (OAGIS and new GS1XML). Interoperability between such standards, even, can be to some extent interoperable. Tools should help with this in future if all goes to plan. Maybe some do already. e.g with combination of SET ontology and a reasoner plus extra code for the tricky bits. - Steve 2009/1/30 Stephen Green <stephengreenubl@gmail.com>: > What you decide to do will obviously depend what constraints you are > working to - and requirements of course. You've not mentioned these. > Many software writers might want to cater for a broad possible set of > constraints since the needs/systems of future trading partners won't > be known. It might be that working to a widely used, open profile (or > creating your own if you have the influence to get it adopted) is a way > to minimise the limits on whose software/systems can read your > invoices (and vice versa). These probably will be for broad requirements > and not likely include multiple-customer-account invoices (unless perhaps > the profile is one for procurement cards or the like and even here a > statement might be the document used). > > In the extreme case of no constraints, if almost infinite customisations > of the document are feasible (when the other party in the transaction either > does not automate processing - typing the invoice into their system or > not even using a system), there are plenty of other possibilities, e.g: > > 4. don't use the UBL invoice: either, 4a), use software which allows both > parties to define their invoice-like document ad hoc, perhaps basing the > schema (generated?) on the UBL NDR or deriving it from the UBL invoice, etc > or, 4b), let one party create the document schema and the other use it too. > In both cases interoperability with future parties' systems is unlikely. > > 5. add an extension to the extension point in the UBL 2.0 Invoice (or other > document type?): e.g. have something based on the following to cater for > different lines being for different customer accounts - > <AccountMatch> > <LineID>1</LineID> > <SupplierAssignedAccountID>xyz</SupplierAssignedAccountID> > </AccountMatch> > Create your own schema for it and agree it with trading parties. Trouble > again is that future parties' systems can't necessarily be expected to > understand the structure (unless you can get it adopted in advance). Maybe > that won't matter if there is no need for their systems to sort one account > and its invoice line from another. Advantage: standard or a convenient profile > of standard OASIS UBL 2.0 Invoice can be used (at least, if a profile then > one which allows the use of the extension point). > > 6. use an outermost wrapper of XML (or MIME attachment perhaps if the > Invoice and attachment can be kept together in processing) to do the same > as (5) for one or more Invoices. Need an xsd:Any for the Invoice(s) and the > extension can either go in an Any or can be part of the wrapper. I call this > pattern/design a treasury tag (having spent years handling paper invoices > tied together with them and with extra, handwritten details attached too. > Advantage: can even use this with a profile/subset of UBL Invoice which > doesn't allow use of the UBL extension (and/or can use with UBL 1.0). > > These are just a few further possibilities. So you see it rather depends on > your constraints (and/or those of the various trading parties who might use > the UBL Invoice). > > Best compare the above with the official (though not yet standard) UBL > customisation guidelines in case I'm out of line with some of this. > > And no, you shouldn't expect to do what you want to do with the additional > ID and still expect to be able to claim conformance (in my opinion) as the > definitions *are* normative conformance requirements (as far as I know), > not with OASIS UBL 2.0. UBL is otherwise, apart form conformance to the > schemas which is a strict conformance requirement, quite open in what it > lest you do with the instances. It is designed for the process activity diagrams > shown in the spec but is liberal in constraining how the schemas are used. > This is, IMO, its strength - allowing openness and very broad adoption. It > probably works best when you use it in the 80:20 scenario it was designed > for. How conformant you want to be is up to you and/or your requirements. > > Best regards > > Steve > > 2009/1/30 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: >> Option 2 seems preferable, because it keeps things simple for the entity >> being invoiced and for the following steps in the invoicing/payment cycle. >> >> >> >> In the "bad old days" of paper and fax (too often, still with us), there >> were incentives for packing as many transactions into one >> document/transactions as possible – to save postage, handling, avoid >> starting and restarting the fax process, etc. Also, high cost per character >> charged by EDI VANs encouraged terseness and compression. The people at both >> ends often had to decompress and parse their way through the complexity >> although at great cost and frequent error. >> >> >> >> On the other hand, machines can easily handle multiple "atomic" transactions >> with, for example, individual invoices constructed at lowest meaningful >> level (e.g., for the customer entity, by PO, line item and specific >> transaction). Parsing the "atomic" transaction and editing it (e.g., is this >> a valid PO, line item, and transaction? ) is pretty simple and with >> comparatively small likelihood of processing failure, presuming supporting >> transactions have been processed (e.g., receiving). Note than unless seller >> "account" is at the same level of granularity as buyer purchase order, and >> invoice by "account" is not sufficiently granular. >> >> >> >> Implementing atomic granularity means the creation of more, but simpler >> transactions, Doing so reduces the need for human intervention and, if >> intervention is needed, the edit step (e.g., if on a given transaction a >> unit price is too high) will focus attention on the offending transaction. >> >> >> >> Sending "atomic" transactions also helps avoid confusion and complexity in >> subsequent steps – e.g., remittance advice. Too often, if the selling party >> sends a complex invoice, and the customer short pays (for good or bad >> reasons), the buyer's system may not send to the seller's the right >> information to figure out exactly what was short paid, which in turn may >> delay or corrupt cash application. Creating compound/complex transactions >> also creates a nightmare for people doing ETL to feed data warehouses and >> performance management systems (e.g., an invoice for, say, 300 transaction >> valued at $12,000 will be shown in some "unpaid" status because of a $50 >> dispute over one transaction, unless the ETL process can itself "atomize" >> the compound/complex trandsaction). >> >> >> >> One difficulty one faces in converting processes to electronic interchanges >> is that SMEs will view needlessly complex relics of paper processes as being >> part of the "requirements" as opposed to part of the problem. Indeed, there >> are people who were and continue to want to be rewarded for introducing >> complexity rather than using the power of the computer to substitute cycles >> for complexity. We need to try to make sure that KISS (keep it simple, >> stupid) is valued and that people get rewarded for applying computer cycles >> and KISS in place of complexity. >> >> >> >> >> >> >> Fulton Wilcox >> >> >> Colts Neck Solutions LLC >> >> >> >> >> >> >> >> ________________________________ >> >> From: Diogo Almeida [mailto:diogo.borges.almeida@gmail.com] >> Sent: Friday, January 30, 2009 6:15 AM >> To: ubl-dev@lists.oasis-open.org >> Subject: Fwd: [ubl-dev] Multiple supplier account invoice >> >> >> >> Hello Stephen, >> >> First of all, thanks for the prompt feedback. >> >> Interoperability is, indeed, the main issue preventing me from considering >> the use of extensions or customizations, that would then need to be >> implemented by the other parties involved in the UBL exchange process. >> >> Considering your comments and the links that you have provided I'm guessing >> that there are only 3 options on the table (correct me if I got it wrong): >> 1) Use the AdditionalAccountID, even though it states that it refers to >> third party accounts, instead of supplier accounts; >> 2) Create a separate invoice for each account that is being billed; >> 3) Extend / Customize the UBL Invoice schema to the particular need that I'm >> describing. >> >> I do agree that the schema does not provide great support for these kind of >> scenarios, where you want to bill multiple accounts. >> >> However you said something that I wish to double check: As is, the >> AddicionalAccountID is to be used for this purpose in the current version of >> UBL? >> >> Best regards, >> Diogo Almeida >> >> -- > > > > -- > Stephen D. Green > > Document Engineering Services Ltd > > > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]