[OpenSpending] Follow-up to transaction standard call

Sat Oct 20 10:47:17 UTC 2012

I think that Unit 4 - whose Aggresso ERP package is used in the UK local
authority and education sectors - have already done some interesting work on
enabling the upstream payment system to generate transparency data (and in
linked data form to boot).  

Besides detailed drill down on who authorised it, what specific goods was it
for (not just category), and which supplier was it, other requests I have
heard from time to time are about location of the work and location that
benefited, link to the contract documentation, date of supply (to track for
instance speed of paying bills, a big problem for SMEs dealing with many
public agencies).  In some circumstances it would also be good to know the
source of funding (eg is this general discretionary spending of the agency
concerned, or is it a pass-through payment on behalf of another).

Regards

Andrew

From: openspending-bounces at lists.okfn.org
[mailto:openspending-bounces at lists.okfn.org] On Behalf Of Lucy Chambers
Sent: 20 October 2012 00:16
To: James McKinney; openspending
Subject: Re: [OpenSpending] Follow-up to transaction standard call

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/47cc2185/attachment.html>