« problem solving app in 17 minutes | Main | ideas, problems, broken arms - social objects »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c61c753ef00e551dccb558834

Listed below are links to weblogs that reference transactions, accounting, bah humbug:

Comments

Dennis Howlett

How then do you handle the rule changes? Presumably by altering whatever the rule is in the appropriate place. But how is this fundamentally different to what already happens? Is this about meta data?

sig

In short - back-end instead of up front, or rather presentation instead of representation like this:

Current ways: The transaction is added to the system at the appropriate account, up front. Slotted into a specific "drawer". That's the only place the system "knows" about the transaction, represented by an invoice or some bill-of-something. With a rule change you would have to reapply the transaction to another account or at another time, but in most cases you would have to pay C&L to translate the accounts into a different GAAP (or rule).
(I've done it, preparing for US GAAP, precious three years, months of work and oozes of cash paid for nothing).

If you'd like to run in parallel US and UK GAAP every invoice (or other transaction-representation) would be under the risk of having to be registered into two different accounts (and even parallel systems) up front due to the different rules.

Alternative: The system has the raw data from the actual happenings, from the workflow itself, it knows when the widget changed colour, when it changed owner, when it left our warehouse. All of that workflow results captured, no accounting thinking nor transactions involved. Mind you that a "transaction" is mostly a virtual activity, something defined by a rule. The widget does not bother about ownership, although it does bother about where it is.

For that, at the back end you could have a "template" as in a query plus presentation giving an accounting report. That "template" has it's own logic and applies that to the raw data when queering: "Add up value of all widgets that left our ownership during period A". That'll give the sum of transactions "sales of widgets for period A" according to Rule 1.

Now add another template with a different query using same untouched raw data: "Add up value of all widgets that left our ownership, and that left our premises during period A". That'll give "sales of widgets" following Rule 2.

The two reports (queries) thus yields two different results, each following a different rule (or GAAP) without influencing each other. And they can be run in parallel. Add another GAAP (Rule 3) later down the road, once the "Rule 3 templates" have been defined, using the same old raw data it'll yield all historical and current accounts according to Rule 3.

The comments to this entry are closed.

My Photo

Contact


  • Phone: +33 6 8887 9944
    Skype: sigurd.rinde
    iChat/AIM: sigrind52

Tweet this


Thingamy sites

  • Main site
  • Concept site

Tittin's blog


Hugh's


Enterprise Irregulars


Faves

Twitter Updates

    follow me on Twitter

    alltop


    • Alltop, all the cool kids (and me)

    Subscribe

    Blog powered by Typepad
    Member since 01/2005