RE: [ubl-dev] UBL for storing accounting data

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

You are facing a pretty complex challenge, partly because of business
process complexity and partly because of implementation diversity. 

To do what you describe, my view is that your only feasible method is to
move the data transaction by transaction (which if how UBL is normally
used). Your web-based application would send customer orders to the
accounting system one-by-one as UBL orders, with translation so that an
external order can be imported using the accounting application's batch load
processes.

The challenge comes because your use case generates substantial accounting
system complexities. For example, if a customer uses a credit card, the
receivable that is set up in the accounting system is not a receivable from
the customer, but from the credit card company. Indeed, the actual customer
might or might not be set up as an individual "customer" in the customer
master. Information regarding the physical transaction might need to be
reflected in inventory-related aspects of the accounting system, and there
are various tax implications that may be recorded. The accounting system
also may have some managerial accounting features (customer service
performance, sales person, sales channel performance, etc.) that are
supported by special-purpose tables or special-purpose fields in general
accounting tables. If the customer successfully protests a credit card
charge, a lot of the information regarding the transaction needs to be
rolled back or offset by another transaction or set of transactions within
the accounting system.

For the most part, accounting systems try to mask this complexity from the
individual user, with the accounting system relying on various
package-specific rules, user organization configuration choices, master data
management choices, etc. The package also automates a lot of database
housekeeping functionality - assigning package-specific transaction IDs,
building database keys, indexing them, timestamping, recording user IDs,
etc.

If as I described above, if you deliver specific sales transactions to be
imported via the accounting system's batch import process (presuming one
exists), then the imported transaction automatically invokes all of the
built-in functionality of the accounting package. On the other hand, if you
use some form of direct synchronization (e.g., initiate writes directly to
the accounting package's database) you have to do an enormous amount of
rules replication, data editing, and database housekeeping in a way that is
consistent with the overall accounting system operation as defined by a
given user organization. Given the regulatory significance of accounting,
bypassing the system carries substantial risk.

Note that Business Intelligence offers a different, often attractive option,
which is to export accounting system information regarding a transaction and
use ETL to join the external transaction data (e.g., a UBL sales order) with
an internal system version of that same transaction to create an
all-encompassing view of that transaction. BI opens up more opportunities,
because you can also incorporate web-oriented data (e.g., mouse clicks, what
sort of browser, first-time visitor, etc.).


						Fulton Wilcox
						Colts Neck Solutions LLC






-----Original Message-----
From: Martin Kleppmann [mailto:martin@eptcomputing.com] 
Sent: Wednesday, March 04, 2009 5:19 PM
To: ubl-dev@lists.oasis-open.org
Subject: [ubl-dev] UBL for storing accounting data

Hello all,

Just joined the list :-) I am doing some work with UBL at the moment  
and would like to ask for some opinions from the community.

I am developing an open source library in Ruby for dealing with  
invoicing and payments[1], focussing particularly on small, web-based  
businesses. In developing this library, the question arose of how to  
integrate that data with accounting systems (e.g. use cases like: if  
somebody buys the product on my website, and they pay by card and are  
automatically issued with an invoice, how do those invoices and  
payment records get into the software which I use for bookkeeping).

There are many different accounting/bookkeeping packages out there,  
and as far as I could tell, there was no sensible, open format or  
protocol for interchanging accounting data between different  
applications. Many applications have an API (usually based on some  
barely documented ad hoc XML schema) but each API is different,  
creating an integration nightmare.

Therefore I think that the world needs an open standard for  
representing and interchanging accounting data. I would like to call  
it OAccounts (O for open) and I have written up a vague  
introduction[2]. And I have no interest in re-inventing the wheel,  
which brings me to UBL.

The data stored in an accounting system (for small/medium businesses  
at least, which is all I know) is basically: a list of suppliers, and  
a list of invoices/payments for each supplier; a list of customers,  
and a list of invoices/payments for each customer; a few special-case  
accounts for dealing with tax, payroll etc.; and a balance sheet.

I think it would be possible to store most of the information which an  
accounting system requires in UBL documents of five types: Statement,  
Invoice, CreditNote, SelfBilledInvoice and SelfBilledCreditNote. (If  
you wanted to include stockkeeping, you could probably use the  
Catalogue stuff too, but I'm not using that at the moment.) They may  
need a few minor extension, but I think that a lot of it could be  
vanilla UBL documents. The XML files could then be arranged in a  
fairly straightforward directory structure. As a transfer protocol, I  
envisage a simple, RESTful[4] approach over HTTP, and you could even  
get an audit trail by tracking changes to the XML files with a  
standard version control system such as git[5].

I am planning to sketch out my ideas for a specification, and start  
work on a simple reference implementation, over the next few weeks. Of  
course the whole process and the results will be free and open, and I  
would welcome any contributions and comments.

But those are just my ideas. What I would love to hear from you is:

* Is there already some open standard for accounting data which I have  
missed?

* What is your reaction to using UBL in such a way? Abusing/bending  
the standard, or sensible application?

* Do you think OASIS should be involved in this? I could imagine first  
trying out a few approaches in an informal setting outside OASIS, and  
when we've learnt what works and what doesn't, bring it back inside  
and standardise it properly (as a separate standard based on UBL?).  
But I'm new to OASIS so I don't know your usual way of doing things.

* Can you contribute? There are many ways you could help, from  
proofreading/commenting and helping spread the word to actively  
contributing by writing.

I look forward to hearing your comments. Thanks!

Martin

[1] http://ept.github.com/invoicing/
[2] http://is.gd/lJL5
[3] http://ept.github.com/oaccounts/
[4] http://en.wikipedia.org/wiki/Representational_State_Transfer
[5] http://git-scm.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org