[OpenSpending] Follow-up to transaction standard call

[Lucy Chambers]

Hi James,

Thank you very much for writing this all up, I think that it is worth
circulating it straight away to the list in order to get their thoughts.

@all - James McKinney has taken the time to run the proposal for a spending
standard as discussed on the last community call by an accountant. He
raises some concerns about whether the focus of our current efforts should
in fact be a standard for transactions, or to actually focus on the
contracts as the most interesting source of information.

James, I also agree with you that it is worth looking into the SAP, Oracle
etc guidelines on this information. I am led to believe that  the majority
of the world's governments actually use software from a very small number
of providers.

In order to help shape the discussion further, it would be useful to know
from those on the list:

* What questions would you need to be able to answer using
transaction-level spending data?

I am currently writing up meeting notes and am prepared to organise another
call soon if people feel this would be helpful. Let's consider James'
points and I will proceed accordingly,

Thoughts?

Lucy



On Friday, October 19, 2012, James McKinney wrote:

> Hi Lucy,
>
> Feel free to forward to openspending list if appropriate.
>
> I asked an accountant for feedback on the standard. She has not worked for
> government. Two big questions were:
>
> 1. Do you already have data that you want to represent using this standard?
> 2. What are the use cases and requirements for this standard?
>
> The high-level process in government (and in many corporations) is for
> example:
>
> A budget for office supplies is set to $10,000.
> Purchase orders are made throughout the year, eg a purchase order is made
> to buy $1,000 of paper.
> Processing the purchase order creates a commitment, so that only $9,000 of
> the budget is considered available.
>
> The commitment can then:
> 1) be cancelled
> 2) be relieved when the paper is received
> 3) the actual cost is lower than the commitment, so the difference is
> uncommitted
> 4) the actual cost exceeds the commitment, in which case authorization
> must be given to increase the commitment from the same budget or another
> budget
>
> Searching these keywords brings you fascinating documentation like
> Oracle's JD Edwards EnterpriseOne's chapter on "Processing Purchase Order
> Commitments".
>
> A few things come out of even just this simple explanation:
>
> 1) If you want data at this low level, then you are signing yourself up to
> create your own government-scale accounting system, which is a Herculean
> effort. Will you be modelling all the back and forth that occurs when the
> commitment must be changed? In accounting systems, changes are considered
> transactions. The current standard has no concept of ledgers, so I assume
> you (wisely) will not go in this direction.
>
> 2) The current transactions.txt has amount_budgeted, amount_allocated,
> amount_executed, but it rarely works that way. Organizational units (eg
> departments) don't create a budget for each purchase of office supplies. A
> unit would have one budget for office supplies, which multiple transactions
> deplete.
>
> 3) In an accounting system, there will be no difference between the amount
> allocated and the amount executed. You can't balance the books if it's
> otherwise! In all cases, there would be a transaction to change the amount
> committed (allocated) to match the amount that must be paid (executed).
>
> On the call, one justification that I remember for having both fields is,
> for example, if a contractor doesn't cash a cheque. But in that case, the
> money doesn't get recycled - it stays in Accounts Payable. Accounting
> systems rarely care when cheques are actually cashed. If money is in
> Accounts Payable, then in the government's view *it's no longer its money.*
>
> Clarifications:
>
> In a call for tender for paving a specific road, the government would
> estimate the cost, and contractors would submit bids which will differ from
> the estimate. The government estimate wouldn't be amount_budgeted, it would
> be amount_estimated. The money for the contract would come from a larger
> "road work" budget.
>
> If we look at USAspending.gov, those aren't transactions, they're
> contracts. There will be many transactions tied to a single contract. But
> do you care about all the component transactions, or do you care about the
> contract as the basic unit of interest? If so, then this project should
> focus on contracts, not transactions.
>
> If the focus really is on transactions, then I would study the
> documentation that SAP, Oracle and others have for their government-focused
> accounting products. (Of course, most governments rely on ancient
> custom-made DOS programs and the like.)
>
> Use cases:
>
> I think a good use case is the comparison between budgeted and actual
> spending. You don't need to go as low-level as transactions to do this,
> though.
>
> Last note:
>
> It might actually be very easy to model transactions. But what you get for
> modelling transactions is probably not what you want. A transaction is a
> transfer of money between two accounts - but a lot of the time both
> accounts will belong to the government! I don't think people want a long
> list of transactions leading up to each transfer of money to a third-party.
> And I don't think people want each transfer of money made to a third-party
> as part of the same contract. Am I right? If so, transaction-level spending
> is not the right focus.
>
> Looking forward to your thoughts,
>
> James
>
>

-- 
Lucy Chambers
Project Coordinator,
School of Data <http://schoolofdata.org/> &
OpenSpending<http://openspending.org/>
Open Knowledge Foundation <http://okfn.org/>
Skype: lucyfediachambers
Twitter: @lucyfedia <https://twitter.com/#!/lucyfedia>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending/attachments/20121020/97158c1c/attachment.html>