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

["Robert Lemense" <r.lemense@skynet.be>]

First sending failed;
Message replay; apologies in case of multiple receipt

Rgds
Robert Lemense


----- Original Message ----- 
From: "Robert Lemense" <r.lemense@belgacom.net>
To: "'Martin Kleppmann'" <martin@eptcomputing.com>; 
<ubl-dev@lists.oasis-open.org>
Cc: "UN/CEFACT TBG Steering Group" <UNCEFACT-TBG-STEER@LISTS.UNECE.ORG>; 
"Dobbing David" <ddobbing@attglobal.net>; <michael.conroy@wanadoo.fr>; 
"Lesourd Michel (edificas)" <mlesourd@edificas.org>; "de Bonhome Olivier" 
<olivier@odb.be>; "Bernard Alain (TBG12 Cefact)" 
<bernard.a.uncefact@gmail.com>
Sent: Saturday, March 07, 2009 4:28 PM
Subject: Re: [ubl-dev] UBL for storing accounting data


> Hi folks,
>
> I got these mails and some others from different friends of UN-Cefact TBGs 
> and ICG who considered I could perhaps help Martin.
> I want to thank my Cefact colleagues.
>
> My name is Robert Lemense
> I am chairing Cefacts' TBG12 that is dealing with "Accounting and Audit".
>
> 1.    Since 1994, accounting practitioners have been facing electronic 
> messages being in EDIFACT, X12 and now xml. We have joined the UN 
> standardisation organisation in 1997 to highlight accounting and 
> accountants issues in s paperless organisation.
> ebXML and Cefacts' UMM was a good opportunity to stress the need for 
> internal interoperability between the whole supply chain and back office 
> bookkeeping requirements.
> Since 2001 TBG12 members have been concerned about linkage of electronic 
> business transactions with accounting.
> TBG12 proposed a (project) concept called "accounting token" which is able 
> to encapsulate in the related transaction message a set of accounting 
> information that is needed to directly derive the proper accounting entry.
> The concept is explained in a document that can be downloaded from:
> http://www.uncefactforum.org/TBG/TBG12/TBG12%20Documents/BRS_TBG12_acccounting_token-updateMar2007_.doc
>
> 2.    TBG12 has defined in 2001 a businees model for accounting and 
> auditing practices in a document called TIC-CR (in French, sorry).
> This business model is focusing on accounting/audit practice and 
> relationship between small and medium size enterprises and their 
> accounting or auditing firm.
> The business model is the basis for projects development within UN-Cefact 
> TBG12;
> The projects proposed so far are:
> - Accounting Entry message
> - Chart of Accounts message
> - Ledger message
> - Trial Balance message
> - Reporting message
>
> 3. Current status:
> 3.1    Accounting Entry message is completely approved and the related 
> documentation will be published with the CCL08B which should be available 
> very shortly.
> In the meantime, the basis documentation that was submitted can be 
> dowloaded from TBG12 webpage
> Accounting Entry BRS:
> http://www.uncefactforum.org/TBG/TBG12/TBG12%20Documents/BRS%20accounting%20Entry%20v1_2_final.zip
> Accounting Entry RSM:
> http://www.uncefactforum.org/TBG/TBG12/TBG12%20Documents/RSM%20accounting%20entry%201.0_final.zip
>
> 3.2    Chart of Accounts is in development;
> After a period of public comments, the BRS is submitted for approval of 
> the Cefact FMG;
> The submitted paper can be dowloaded from UNECE/Cefact web site:
> http://www.unece.org/cefact/forum_grps/tbg/TBG12_BRSChartofAccounts.doc
>
> 3.3    Reporting
> Financial Reporting is a joint project between TBG18 (Agriculture) and 
> TBG12 which aims to produce a reporting e-message aiming to transport 
> yearly financial statements which must be filed by cooperative 
> organisations in the French agriculture sector toward the corresponding 
> sectorial public authority.
> The BRS describing the project is currently under public review. The 
> submitted paper is downloadable from
> http://www.unece.org/cefact/forum_grps/tbg/TBG12-TBG18_BRSReporting.doc
>
>
> 4. TBG12 will be meeting during the Forum UN-Cefact to take place in 
> Rome/Italy from 20 to 24 April.
>
> Feel free to ask for more details.
>
> Regards,
> Robert Lemense
> UN-Cefact TBG12 Chair
>
>
>
> ----- Original Message ----- 
> From: "Fulton Wilcox" <fulton.wilcox@coltsnecksolutions.com>
> To: "'Martin Kleppmann'" <martin@eptcomputing.com>; 
> <ubl-dev@lists.oasis-open.org>
> Sent: Thursday, March 05, 2009 4:41 PM
> Subject: RE: [ubl-dev] UBL for storing accounting data
>
>
>> 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>
>