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

[Stephen Green <stephengreenubl@gmail.com>]

It will be a good use case for the CEFACT work, as it
has been for UBL, to see how usable it is in systems
used by small businesses - including open source ones.
The usability of XBRL in such systems has already been
found somewhat wanting. Important though to note
that XBRL-GL is not the same as XBRL per se - it is
a simplified profile of XBRL for use for general ledgers
and, while it should be suitable for small business
systems there are some challenges inherited from
XBRL like the imported schemas and the use of
substitution groups based on them. Now these could be
useful comparisons for any CEFACT work because we
know that small business finance systems find the
complexity of XBRL somewhat challenging and even
perhaps more so than UBL. If CEFACT schemas (or
models combined, if that is how it works, with the CEFACT
XML naming and design rules to create schemas) are
too complex or the principles of thier use too complex
(or the documentation, etc) they will be too expensive for
small business software companies and software houses
to implement. By the looks of the list of working groups
just sent I would guess there might indeed be something
of a barrier to entry rising against SME (SMB) adoption,
especially in open source systems. Unfortunately it is
not easy to keep up with all the CEFACT committees and
committee processes if you happen to be trying to make
sense of and profile their deliverables for small business
adoption. It seems even more of a challenge to do this
than it is with UBL TC or UBL Small Business SC work.
The latter has proven too much of a challenge for workers
so far. A more determined (and resourced) effort might be
sufficient and sustainable but it does look like doing the
same again within the equivalent CEFACT groups would be
a bit beyond even a determined and sustained effort unless
supported by a fairly large and well financed sponsor. This
is sad and only my own opinion - sad because the future
of UBL seems to lie in CEFACT efforts which are yet to be
proven a viable environment, I think, for development of
a set of accounting and document profiles for small business
systems and software companies/houses.

I hope my opinions here are pessimistic and I'm proven
wrong but better still if the CEFACT committees will ensure
that those who wish to create profiles viable for OAccounts,
etc are given a helping hand sufficient to get their efforts off
the ground and sustained in the long term.

Best regards

Stephen D Green

co-founder of UBL Small Business Subcommittee


2009/3/7 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
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice