RE: [ubl-dev] Multiple supplier account invoice

[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

--