Re: [ubl-dev] Multiple supplier account invoice

[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