[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Consistent accounting recognition by parties in ecommerce
Problem: E-commerce systems send requests for resources such as inventory or money (decrements in resources) without unambiguously identifying the offsetting resource increment(s) at the same point in time, or unambiguously communicating the timing of recognition of accounting events. Example: a request for inventory may not indicate whether this is a prepaid, or accounts payable, or other terms required for accounting. Causes of the problem: * Senders don't have contracts in electronic form. * No standard format for terms of contracts; adoption cannot happen. * Even if contracts existed in electronic form, the additional cost, computing and bandwidth to generate *balanced* resource messages from sender and transmit, would influence adoption decisions. * asyymmetry of benefit: the author bears computing cost while the recipient gets the admin savings. * Receivers of such messages would anyways need to verify them against contracts rather than releasing money and goods without controls. * Timing of legal recognition anyways involves logistical facts outside the electronic environment such as physical dispatch or receipt of goods. Capturing this data comprehensively/globally would be costly. * There is no clear consensus among community of developers or vendors of collaboration patterns and business process, that enforcing the same timing and character of recognition (including balanced entries) by both trading partners is either possible, or within their scope. Result: The two parties' assessment of both character and timing of recognition into payables, receivables, inventory, or other accounts will sometimes be inconsistent. In other words, the accounting processes will not be completely automated and they will be costly. The consequences of any separately maintained lists such as AR and AP include: * The redundant data stores attract updates from different classes of users, at different times, and different levels of aggregation such as by the statement, by invoice or by line item, for differing time segments etc. * Neither data store is usually correct, complete, or timely. * Costs arise due to business errors based on wrong information (overdrafts, credit/collection errors, etc.) * Time is wasted confirming and reconciling one against the other, even when the systems are in agreement. * Systems are developed to address the problems, by automating the checking and comparison of the two lists, or to post all changes to both lists, etc. * Those secondary systems introduce rigidity and problems throughout the software environment. .. I think I know the answer and it doesn't involve refinements in metadata and message content such as ebXML, even if ebXML were somehow to become a complete unambiguous replication system. The answer is to have the transaction database in a shared public place, where the core facts about contract and exchange are enshrined. Amount, date, product/quantity are the real core components. Whenever any economic event occurs, whoever needs to have it booked must go to the public transaction database and input their version of the event. The other party should go and approve the event or reject it. All parties would have views of the transactions which they initiated, or are named as a recipient. All of the facts of the exchange that are actually part of the shared contract with the other party would be in the public repository (not the private parts of their accounting entries). This scheme does not require any disclosure or loss of privacy because it focuses on things the trading partners already share in their "communications." This is the only "Repository" that's worth building, in my opinion. The shared transaction repository would solve the problems and achieve the results needed by SMEs, even if it was plain english text fields instead of EDI elements because there is exactly one master copy of the deal. If I were the guv, the UCC would be amended that no contract be enforceable unless it's posted in a licensed public repository. That would solve a *lot* of problems, with a rather trivial cost of database/network. For example the thing could be hardwired to the banking system. "Money" is nothing but your "row" in a database, at some central bank. Here is your "money". Just consider, how ridiculously complicated we have allowed this "money" system to become: My Account My General Central Bank My Bank in my bank ledger ========= ========= ========= ========= --> ========= ========= --> ========= ========= --> ========= ========= --> ========= --> ========= equals ========= cash in bank ========= --> ========= ========= receivables ========= --> ========= ========= receivables ========= --> ========= ========= receivables ========= ========= payables ========= ========= payables ========= ========= payables ========= (...) ========= ========= Note that my receivables and payables, are really NOTHING but future- dated rows in the real money database, with repudiability and risk built into them (which is absolutely NOT wanted by most people or businesses 99% of the time). This is YOUR money! Control it. Within a shared transaction repository, if you don't post your agreement to both sides of the contract, you don't get your goods. If you hit "POST" that sucker is posted, baby. Below is just an example, to think about, among many scenarios. WELCOME TO STATE OF NEVADA PUBLIC TRANSACTION REPOSITORY 15MAR2001 ENTER YOUR ACCOUNT CODE: [ JILLS:213467236 ] ENTER YOUR PASSPHRASE: [ *********** ] ENTER THE OTHER PARTY: [ ] ENTER THE AMOUNT: [ ] ENTER THE DATE TO EXECUTE: [ ] ENTER THE DESCRIPTION [ ] OR UPLOAD YOUR DOCUMENT OR MESSAGE: [../data/POtortilla41.xml ] ...pause SESSION COMPLETE # NEVADA:27468356354545 I'm going to push this link out here, because I think its significant. http://www.mobiletransaction.org/pdf/MeT-Account-Based-Payment-20010221.pdf It is a hardware lockbox with your signing keys, keypad and display hardwired in silicon. Hard to crack silicon devices. After you input your little session on the shared repository above, Your cellphone rings, via bluetooth from the PC. You get a little WAP screen: WELCOME TO STATE OF NEVADA PTR 15MAR2001 SESSION# NEVADA:27468356354545 ORIGINATOR: TRES HERMANOS MEX RESTAURANT RECIPIENT: PUGET SOUND TORTILLAS SEATTLE VALUE: 237.50 DO YOU AGREE TO SIGN? [ SIGN ] ...pause SESSION COMPLETE # NEVADA:27468356354545 Nothing happens. When the other party posts an acceptance of the transaction, it becomes real. If he doesn't sign his acceptance by SMTP, HTTP, SOAP, IRC chat, carrier pigeon etc. he doesn't get his money. I'm skipping a lot. When you review your inbox, you see the vendor accepted your order and it is real. You're done. Everything is done-- payment, tax, bookkeeping, billing. At the end of the month if you're curious you could fetch your trial balance with a group-by query but why bother. This automatically settles your payroll and sales tax because you would name the tax agency in the journal entry you uploaded. Incidentally it will be hard for the payee to not get paid, not know they have been paid, not know exactly what you ordered, etc. If you don't get your tortillas, you drag and drop the transaction over onto the LAWYER icon, and pay $10 for a small claims filing. The guy doesn't show up with proof of delivery, you get your refund. Anyway, empirical reputation metrics on that shared host could be maintained, for any party who wished to maintain them or disclose them, which would be basically, everybody. Let's quit messin' around, can we, at least, reconcile the AR/AP? Money is the root element. Everything else is debatable but Once we agree on the money let's book it: ------PARTY A's BOOKS---- common -----PARTY B's BOOKS ------- <bla> <bla> <yada><yada> <yada><bla> <bla><bla><bla> <bla><bla><bla> <bla><bla><hare><hare> <bla><heebie><jeebie> <bla><bla><bla><bla><bla> <bla><bla><bla><bla><bla> <bla><bla><bla><bla><bla><bla><money><bla><bla><bla><bla><bla><bla> <bla><hare><hare><bla><bla> <bla><yada><yada><bla><bla> <yada><yada><bla><bla> <hubba><hubba><bla><bla> <whoopie><bla><bla> <bla><bla><bla> <bla><bla> <bla><bla> <bla> <bla> You're solving the wrong problem by trying to disambiguate all the bla bla's. tODD http://WWW.GLdialtone.com/endredundancy.htm http://WWW.GLdialtone.com/str.htm
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC