[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Multiple supplier account invoice
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 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. Colts
Neck Solutions LLC From: Diogo Almeida
[mailto:diogo.borges.almeida@gmail.com] Hello Stephen,
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]