Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta

[Jacopo Cappellato]

Hi Jim, (and others interested in helping with the implementation of the
accounting component)

can I add you to the list of "people interested" in this page:

http://docs.ofbiz.org/display/OFBADMIN/New+Features+Roadmap+-+Draft

?

If you (or others in this list) are willing to help with the
implementation I will do my best to help to organize the work in the
community (and also implement something).

The main question to the ones interested are:

- are there specific tasks you would like to work on?
- if not, we can help to assign/distribute tasks, but it would be useful
to know what is your area of expertise: tech (Java, minilang,
screen/form widgets, etc...) or business (OFBiz data model, existing
services, general AR/AP...)

I've recently (yesterday and the day before it) I've cleaned up some
stuff in the accounting component (and implemented some new screens) and
now I have a clearer view of what is already available and what needs to
be done: now I'm sure that we can relatively quickly implement some good
stuff here with your help, so guys don't be shy!!!

Jacopo



Jim Barrows wrote:

> Ok, so we still want to build this.. only better :)
>
> On Nov 20, 2007 5:12 PM, David E Jones <[hidden email]> wrote:
>> That is very old, and a lot has changed since then, including what
>> happened to this code base. All of the lower level stuff including the
>> data structures and GL posting services are part of OFBiz, but the
>> higher level things such as reports and automated posting mapping
>> services (from things like invoices, payments, inventory changes, etc)
>> are all part of the HPL licensed financials component from Open Source
>> Strategies, part of the opentaps distribution (semi-fork these days,
>> lots of stuff implemented that doesn't go back into OFBiz).
>>
>> For more information you should see their site at
>> opensourcestrategies.com. The HPL (Honest Public License) is a not an
>> OSI approved license and has some rather unpleasant terms in it, the
>> goal being to force contributions or purchase of a commercial license
>> (just like pretty much all "open source" companies that dual license,
>> usually with GPL though). The main thing with HPL is that if you make
>> it available over the internet it explicitly states that this is
>> public distribution of the software (for  more details see the license
>> itself).
>>
>> In any case, that is why you're seeing discussion of implementing
>> these things even though there is an OFBiz add-on that has them, and
>> hence all of the references to another project that is licensed in
>> terms that make it hard to build a community around, and that can't be
>> included with OFBiz, etc.
>>
>> -David
>>
>>
>>
>> On Nov 20, 2007, at 4:54 PM, Jim Barrows wrote:
>>
>>> So what is the status?  Do we have to pay for it?  Is it done?  i
>>> would think that in 2 years it would've gotten done by now.
>>>
>>> On Nov 20, 2007 4:48 PM, BJ Freeman <[hidden email]> wrote:
>>>> Here is and update from couple of years ago.
>>>> previously there was discussion about the frame work of this.
>>>> if I did all these out, is there a place on the documentation site we
>>>> can put them to save a lot of re discussion.
>>>>
>>>> David E. Jones sent the following on 9/23/2005 4:16 PM:
>>>>> Update: Accounting/GL Now in Beta Testing
>>>>>
>>>>> The Open For Business Accounting and General Ledger (GL)
>>>>> application is
>>>>> now moving into beta testing. Currently, it can  support the
>>>>> accounting
>>>>> needs of most product-retail businesses that use Open For Business,
>>>>> including:
>>>>>
>>>>>   * Support for multiple organizations and multiple currencies
>>>>>   * Setting up chart of accounts with unlimited depth
>>>>>   * General Ledger posting for most key business processes
>>>>>   * Financial reports including trial balance, income statements,
>>>>> and
>>>>>     balance sheets
>>>>>   * Screens to create and manage both Accounts Receivable (AR) and
>>>>>     Accounts Payable (AP) invoices and payments
>>>>>   * Screens for managing tax liabilities across multiple
>>>>> jurisdictions
>>>>>   * Administrative features such as periodic closings
>>>>>   * Flexible entry and maintenance of payments and invoice
>>>>> (including
>>>>>     application payments to invoices, etc)
>>>>>   * Export to outside accounting applications (QBXML for
>>>>> QuickBooks is
>>>>>     included)
>>>>>
>>>>> This application is fully integrated with the rest of OFBiz,
>>>>> including
>>>>> ecommerce, Point Of Sales, order manager, and facilities
>>>>> manager.  It
>>>>> drops into your hot-deploy/ directory and runs right  away.  If
>>>>> you need
>>>>> other accounting-related features, such as  payroll, it is fairly
>>>>> easy
>>>>> to develop a plug in for it.
>>>>>
>>>>> If you would like to learn more about the GL application, there is a
>>>>> video from the St. Louis Users' Conference
>>>>> (http://www.ofbiz.org/VideosConf.html) and an online demo
>>>>> (http://www.opensourcestrategies.com/ofbiz/demos.php).
>>>>>
>>>>> How to Make it Open Source
>>>>>
>>>>> The Accounting and General Ledger is developed under a community
>>>>> funding
>>>>> model. The idea is to get community funding to help cover the cost
>>>>> of
>>>>> developing a large, complex application. We think this is a very
>>>>> fair
>>>>> user-driven model because it can produce open source software with
>>>>> either a large number of small contributors or a small number of
>>>>> larger
>>>>> contributors. As an added incentive, those who contribute over
>>>>> $3,000
>>>>> can begin to use the application immediately and benefit from all
>>>>> its
>>>>> features for a fraction of the cost of in-house development.
>>>>>
>>>>> We've currently received sponsorship for about half the development
>>>>> costs ($26,000 out of about $50,000) and require another $24,000 to
>>>>> reach our goal and release it under an open source license. This
>>>>> means
>>>>> that we can get there with just eight user-contributors with
>>>>> $3,000 each
>>>>> or, alternatively, a hundred contributors of under $250 each.
>>>>>
>>>>> -Si Chen
>>>>> -David E. Jones
>>>>>
>>>>> P.S. Special thanks to all who have contributed labor and funds to
>>>>> this
>>>>> effort, including: Open Source Strategies, Undersun Consulting, Ant
>>>>> Websystems, Masterfile Corp, and others.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>> --
>>> James A Barrows
>>
>
>
>

[SkipDever]

Jacopo

I can help with this.  My experience is in Java and general accounting stuff
having already implemented this fully in another language.  However, I need
to get A/R and EOQ Purchasing finished before I will have any time to give
to it which I suspect will be around the first of the year.  I'm a nub with
widgets (although I don't find it hard).

I have some strong feelings about how Si has done this though.  My primary
concern is that some organizations prefer to post to the G/L in real time
and others prefer to do batch review/post.  I hope we can do something like
have a property or PartyAcctPreference that flips the switch.

I would only like to be involved if we can agree to spend the time to do
user-friendly, intuitive screens.

I have zero understanding of the needs of European accounting requirements
(if they are different) and the differences with U.S. ones.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Thursday, November 22, 2007 10:38 PM
To: [hidden email]; [hidden email]
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta


Hi Jim, (and others interested in helping with the implementation of the
accounting component)

can I add you to the list of "people interested" in this page:

http://docs.ofbiz.org/display/OFBADMIN/New+Features+Roadmap+-+Draft

?

If you (or others in this list) are willing to help with the
implementation I will do my best to help to organize the work in the
community (and also implement something).

The main question to the ones interested are:

- are there specific tasks you would like to work on?
- if not, we can help to assign/distribute tasks, but it would be useful
to know what is your area of expertise: tech (Java, minilang,
screen/form widgets, etc...) or business (OFBiz data model, existing
services, general AR/AP...)

I've recently (yesterday and the day before it) I've cleaned up some
stuff in the accounting component (and implemented some new screens) and
now I have a clearer view of what is already available and what needs to
be done: now I'm sure that we can relatively quickly implement some good
stuff here with your help, so guys don't be shy!!!

Jacopo



Jim Barrows wrote:

> Ok, so we still want to build this.. only better :)
>
> On Nov 20, 2007 5:12 PM, David E Jones <[hidden email]> wrote:
>> That is very old, and a lot has changed since then, including what
>> happened to this code base. All of the lower level stuff including the
>> data structures and GL posting services are part of OFBiz, but the
>> higher level things such as reports and automated posting mapping
>> services (from things like invoices, payments, inventory changes, etc)
>> are all part of the HPL licensed financials component from Open Source
>> Strategies, part of the opentaps distribution (semi-fork these days,
>> lots of stuff implemented that doesn't go back into OFBiz).
>>
>> For more information you should see their site at
>> opensourcestrategies.com. The HPL (Honest Public License) is a not an
>> OSI approved license and has some rather unpleasant terms in it, the
>> goal being to force contributions or purchase of a commercial license
>> (just like pretty much all "open source" companies that dual license,
>> usually with GPL though). The main thing with HPL is that if you make
>> it available over the internet it explicitly states that this is
>> public distribution of the software (for  more details see the license
>> itself).
>>
>> In any case, that is why you're seeing discussion of implementing
>> these things even though there is an OFBiz add-on that has them, and
>> hence all of the references to another project that is licensed in
>> terms that make it hard to build a community around, and that can't be
>> included with OFBiz, etc.
>>
>> -David
>>
>>
>>
>> On Nov 20, 2007, at 4:54 PM, Jim Barrows wrote:
>>
>>> So what is the status?  Do we have to pay for it?  Is it done?  i
>>> would think that in 2 years it would've gotten done by now.
>>>
>>> On Nov 20, 2007 4:48 PM, BJ Freeman <[hidden email]> wrote:
>>>> Here is and update from couple of years ago.
>>>> previously there was discussion about the frame work of this.
>>>> if I did all these out, is there a place on the documentation site we
>>>> can put them to save a lot of re discussion.
>>>>
>>>> David E. Jones sent the following on 9/23/2005 4:16 PM:
>>>>> Update: Accounting/GL Now in Beta Testing
>>>>>
>>>>> The Open For Business Accounting and General Ledger (GL)
>>>>> application is
>>>>> now moving into beta testing. Currently, it can  support the
>>>>> accounting
>>>>> needs of most product-retail businesses that use Open For Business,
>>>>> including:
>>>>>
>>>>>   * Support for multiple organizations and multiple currencies
>>>>>   * Setting up chart of accounts with unlimited depth
>>>>>   * General Ledger posting for most key business processes
>>>>>   * Financial reports including trial balance, income statements,
>>>>> and
>>>>>     balance sheets
>>>>>   * Screens to create and manage both Accounts Receivable (AR) and
>>>>>     Accounts Payable (AP) invoices and payments
>>>>>   * Screens for managing tax liabilities across multiple
>>>>> jurisdictions
>>>>>   * Administrative features such as periodic closings
>>>>>   * Flexible entry and maintenance of payments and invoice
>>>>> (including
>>>>>     application payments to invoices, etc)
>>>>>   * Export to outside accounting applications (QBXML for
>>>>> QuickBooks is
>>>>>     included)
>>>>>
>>>>> This application is fully integrated with the rest of OFBiz,
>>>>> including
>>>>> ecommerce, Point Of Sales, order manager, and facilities
>>>>> manager.  It
>>>>> drops into your hot-deploy/ directory and runs right  away.  If
>>>>> you need
>>>>> other accounting-related features, such as  payroll, it is fairly
>>>>> easy
>>>>> to develop a plug in for it.
>>>>>
>>>>> If you would like to learn more about the GL application, there is a
>>>>> video from the St. Louis Users' Conference
>>>>> (http://www.ofbiz.org/VideosConf.html) and an online demo
>>>>> (http://www.opensourcestrategies.com/ofbiz/demos.php).
>>>>>
>>>>> How to Make it Open Source
>>>>>
>>>>> The Accounting and General Ledger is developed under a community
>>>>> funding
>>>>> model. The idea is to get community funding to help cover the cost
>>>>> of
>>>>> developing a large, complex application. We think this is a very
>>>>> fair
>>>>> user-driven model because it can produce open source software with
>>>>> either a large number of small contributors or a small number of
>>>>> larger
>>>>> contributors. As an added incentive, those who contribute over
>>>>> $3,000
>>>>> can begin to use the application immediately and benefit from all
>>>>> its
>>>>> features for a fraction of the cost of in-house development.
>>>>>
>>>>> We've currently received sponsorship for about half the development
>>>>> costs ($26,000 out of about $50,000) and require another $24,000 to
>>>>> reach our goal and release it under an open source license. This
>>>>> means
>>>>> that we can get there with just eight user-contributors with
>>>>> $3,000 each
>>>>> or, alternatively, a hundred contributors of under $250 each.
>>>>>
>>>>> -Si Chen
>>>>> -David E. Jones
>>>>>
>>>>> P.S. Special thanks to all who have contributed labor and funds to
>>>>> this
>>>>> effort, including: Open Source Strategies, Undersun Consulting, Ant
>>>>> Websystems, Masterfile Corp, and others.
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------

--

>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>> --
>>> James A Barrows
>>
>
>
>

[David E Jones]

On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:

> I have some strong feelings about how Si has done this though.  My  
> primary
> concern is that some organizations prefer to post to the G/L in real  
> time
> and others prefer to do batch review/post.  I hope we can do  
> something like
> have a property or PartyAcctPreference that flips the switch.

The original design I did for the accounting stuff includes journal  
management for un-posted transactions. The implementation was supposed  
to put transactions that failed auto-posting into an error journal to  
be manually reviewed, but if there was a switch like this somewhere we  
could certainly use the journaling feature for what you are  
describing, and it could even be configured to queue up certain types  
of transactions but not others (like all purchase invoices for  
example, but not sales invoices or inventory changes due to the  
extreme volume; assuming a company where that is the case for sake of  
example).

> I would only like to be involved if we can agree to spend the time  
> to do
> user-friendly, intuitive screens.

Feedback on screen designs, probably starting with putting down end-
user processes to support (use cases if you will) would be great.

-David

[SkipDever]

That sounds splendiferous to me.  All but two of my old customers have
switch to full auto-post.  I think it was a matter of comfort and they were
happy to put in the 4 hours a day to make sure their precious GLs were
sparkling.  I am sure the comfort level these days is a good deal higher.

Skip

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Thursday, November 22, 2007 11:31 PM
To: [hidden email]
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta



On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:

> I have some strong feelings about how Si has done this though.  My
> primary
> concern is that some organizations prefer to post to the G/L in real
> time
> and others prefer to do batch review/post.  I hope we can do
> something like
> have a property or PartyAcctPreference that flips the switch.

The original design I did for the accounting stuff includes journal
management for un-posted transactions. The implementation was supposed
to put transactions that failed auto-posting into an error journal to
be manually reviewed, but if there was a switch like this somewhere we
could certainly use the journaling feature for what you are
describing, and it could even be configured to queue up certain types
of transactions but not others (like all purchase invoices for
example, but not sales invoices or inventory changes due to the
extreme volume; assuming a company where that is the case for sake of
example).

> I would only like to be involved if we can agree to spend the time
> to do
> user-friendly, intuitive screens.

Feedback on screen designs, probably starting with putting down end-
user processes to support (use cases if you will) would be great.

-David

[Jacopo Cappellato]

David, all,

I'm really interested in knowing more about the design for journal
management.
I did some research (existing data model and services) and it seems to
me that:

* a journal (GlJournal) is used to group together a set of accounting
transactions (AcctgTrans)
* a journal can be used to verify the correctness of all the
transactions associated to it (there is a service to check the trial
balance of a journal)
* a journal can be used to quickly post all the transactions associated
to it in one batch

My questions are:

1) who should create a journal and when? automatically by the system? by
users? or manager?
2) can a transaction be created without specifying a journal?
3) can a journal contain both posted and unposted transactions?
4) should we create a GlJournal.journalTypeId field to define an error
journal for transactions that failed auto-posting (as suggested by
David) and possibly other types (e.g. to group automatically posted
transactions from manually posted ones)

I've also created a new Wiki page to help to get this ball rolling:

http://docs.ofbiz.org/x/sgw

I'll do my best to add relevant information there as well.

Jacopo

David E Jones wrote:

>
> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>
>> I have some strong feelings about how Si has done this though.  My
>> primary
>> concern is that some organizations prefer to post to the G/L in real time
>> and others prefer to do batch review/post.  I hope we can do something
>> like
>> have a property or PartyAcctPreference that flips the switch.
>
> The original design I did for the accounting stuff includes journal
> management for un-posted transactions. The implementation was supposed
> to put transactions that failed auto-posting into an error journal to be
> manually reviewed, but if there was a switch like this somewhere we
> could certainly use the journaling feature for what you are describing,
> and it could even be configured to queue up certain types of
> transactions but not others (like all purchase invoices for example, but
> not sales invoices or inventory changes due to the extreme volume;
> assuming a company where that is the case for sake of example).
>
>> I would only like to be involved if we can agree to spend the time to do
>> user-friendly, intuitive screens.
>
> Feedback on screen designs, probably starting with putting down end-user
> processes to support (use cases if you will) would be great.
>
> -David
>

[David E Jones]

On Nov 23, 2007, at 3:39 AM, Jacopo Cappellato wrote:

> David, all,
>
> I'm really interested in knowing more about the design for journal  
> management.
> I did some research (existing data model and services) and it seems  
> to me that:
>
> * a journal (GlJournal) is used to group together a set of  
> accounting transactions (AcctgTrans)
> * a journal can be used to verify the correctness of all the  
> transactions associated to it (there is a service to check the trial  
> balance of a journal)
> * a journal can be used to quickly post all the transactions  
> associated to it in one batch
>
> My questions are:
>
> 1) who should create a journal and when? automatically by the  
> system? by users? or manager?

This would depend on the business process that is implemented on top  
of the data model and these lower level services that exist.

In my reply to Skip's message I described two possible scenarios: one  
for an error journal and another for a manual posting (for review or  
whatever) journal.

> 2) can a transaction be created without specifying a journal?

Yes. In fact I think this is the only thing done in the opentaps auto-
posting services, I don't think they use journals at all.

> 3) can a journal contain both posted and unposted transactions?

Yes. The posting status is on the AcctgTrans entity, so is independent  
of the journal.

> 4) should we create a GlJournal.journalTypeId field to define an  
> error journal for transactions that failed auto-posting (as  
> suggested by David) and possibly other types (e.g. to group  
> automatically posted transactions from manually posted ones)

There may already be something for this, but if not then yes it would  
make sense just to make the UI easier. From the code and configuration  
perspective I think the current approach used elsewhere (and that  
should be applied here if not already) is to specify each journal by  
ID for a particular purpose, like journal 12345 is the error journal  
for organization 54321.

-David

> I've also created a new Wiki page to help to get this ball rolling:
>
> http://docs.ofbiz.org/x/sgw
>
> I'll do my best to add relevant information there as well.
>
> Jacopo
>
> David E Jones wrote:
>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>> I have some strong feelings about how Si has done this though.  My  
>>> primary
>>> concern is that some organizations prefer to post to the G/L in  
>>> real time
>>> and others prefer to do batch review/post.  I hope we can do  
>>> something like
>>> have a property or PartyAcctPreference that flips the switch.
>> The original design I did for the accounting stuff includes journal  
>> management for un-posted transactions. The implementation was  
>> supposed to put transactions that failed auto-posting into an error  
>> journal to be manually reviewed, but if there was a switch like  
>> this somewhere we could certainly use the journaling feature for  
>> what you are describing, and it could even be configured to queue  
>> up certain types of transactions but not others (like all purchase  
>> invoices for example, but not sales invoices or inventory changes  
>> due to the extreme volume; assuming a company where that is the  
>> case for sake of example).
>>> I would only like to be involved if we can agree to spend the time  
>>> to do
>>> user-friendly, intuitive screens.
>> Feedback on screen designs, probably starting with putting down end-
>> user processes to support (use cases if you will) would be great.
>> -David
>

[SkipDever]

Jacopo

Traditionally, a general journal is the middle step or "glue" in a GL
system.  Every number in a General Ledger account is the sum of it's general
journal entries.  In computer terms, the general ledger typically also
contains a reference to the creating document.

There can never be a single journal entry except for maintenance in
correcting errors (rounding errors and the like). A journal entry consists
of two or more transactions, a debit and a credit, the sum of which is zero
when subtracting the debits from the credits for that transaction.  There
should also be a reference document that is the basis for the transaction,
e.g. an invoice number, shipping number,  payment number etc.  In other
words, all activity in the system that involves something of value whether
or not it involves an outside party should have at least a pair of journal
entries and this includes non-cash things like moving inventory between
stores, depreciating fixed assets, good-will rightoffs, etc.  I say "at
least" because several transactions have many journal entries.  An invoice
for example involves at least a debit to cash or receivables, a credit to a
sales account and maybe a credit to a tax and or shipping account, a credit
to inventory, and a debit to cost of goods sold, etc.

This is all provided for in AcctTrans and AcctingTransEntry (although in my
view having a product, shipping, invoice, payment, etc ids would be better
having a single "supportingDocumentId" used in conjuction with a
"documentTypeId" as this would allow for unforseen transaction types).  I do
however understand the value of having individual document Ids so
getRelated() can be used.  Its just that it looks so messy.

Journal entries are always made in conjuction with and at the same time as
the original document is produced, and should be in my view part of the
database begin/commit.  This ensures that if the underlying document is
written, the required journal entries are written or none are.  It therefore
should be difficult to impossible for the journal to get out of wack with
the business and most large businesses I have been involved with over the
years is VERY concerned with the accounting of their money, not to mention
Sarbanes requirements in the U.S.

You should be able to select a journal transaction, and see the entries that
comprise it and view the original document(s) that created it using related
entities.  If we insist that every journal entry has a supporting document
(which I think we should), we will have to create another entity to hold
manual postings which happen frequently, and no doubt others as well.

In some businesses, the general ledger is auto-posted from the journal in
real time.  In others, the transaction is marked as isposted="F" and the
posting to the GL is handled by an accounting type human who reviews all the
unposted journal transactions before posting them to the GL (batch mode
posting).  This is a prime candidate for a SECA on the AcctTrans commit if
we just add a single entry "autopost"="T/F" to it (or maybe there is
somewhere else we can get this flag from for a SECA?).

If correctly correlated using a transaction class field, the journal can be
used to produce detailed cash flow statements and other similar
sub-documents.  The GL itself is traditionally used to produce balance and
income statements.

How you end up implementing it is of course up to you, but all the pieces
that I have described are provided for in the data model with the possible
exception of supportingDocumentId.

Skip



-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Friday, November 23, 2007 2:40 AM
To: [hidden email]
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta


David, all,

I'm really interested in knowing more about the design for journal
management.
I did some research (existing data model and services) and it seems to
me that:

* a journal (GlJournal) is used to group together a set of accounting
transactions (AcctgTrans)
* a journal can be used to verify the correctness of all the
transactions associated to it (there is a service to check the trial
balance of a journal)
* a journal can be used to quickly post all the transactions associated
to it in one batch

My questions are:

1) who should create a journal and when? automatically by the system? by
users? or manager?
2) can a transaction be created without specifying a journal?
3) can a journal contain both posted and unposted transactions?
4) should we create a GlJournal.journalTypeId field to define an error
journal for transactions that failed auto-posting (as suggested by
David) and possibly other types (e.g. to group automatically posted
transactions from manually posted ones)

I've also created a new Wiki page to help to get this ball rolling:

http://docs.ofbiz.org/x/sgw

I'll do my best to add relevant information there as well.

Jacopo

David E Jones wrote:

>
> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>
>> I have some strong feelings about how Si has done this though.  My
>> primary
>> concern is that some organizations prefer to post to the G/L in real time
>> and others prefer to do batch review/post.  I hope we can do something
>> like
>> have a property or PartyAcctPreference that flips the switch.
>
> The original design I did for the accounting stuff includes journal
> management for un-posted transactions. The implementation was supposed
> to put transactions that failed auto-posting into an error journal to be
> manually reviewed, but if there was a switch like this somewhere we
> could certainly use the journaling feature for what you are describing,
> and it could even be configured to queue up certain types of
> transactions but not others (like all purchase invoices for example, but
> not sales invoices or inventory changes due to the extreme volume;
> assuming a company where that is the case for sake of example).
>
>> I would only like to be involved if we can agree to spend the time to do
>> user-friendly, intuitive screens.
>
> Feedback on screen designs, probably starting with putting down end-user
> processes to support (use cases if you will) would be great.
>
> -David
>

[David E Jones]

Some notes on journals (GlJournal), transactions (AcctgTrans),  
transaction entries (AcctgTransEntry), etc:

1. they are optional, transactions do not have to be associated with a  
journal
2. a transaction is not associated with a GL account and does not  
represent a debit or credit, each entry in a transaction does
3. journals are not meant to be balanced, individual transactions are  
(checking to see whether or not an entire journal is balanced is  
simply a matter of seeing if each transaction is balanced
4. origin "documents" (detail records) are associated with the  
transaction entry, and there are structures for this in OFBiz

I think this is mostly a difference in terminology, most of the rest  
of what you wrote sounds correct to me based on my understanding based  
on my research and collaboration with others on accounting systems.

-David


On Nov 23, 2007, at 1:09 PM, skip@thedevers wrote:

> Jacopo
>
> Traditionally, a general journal is the middle step or "glue" in a GL
> system.  Every number in a General Ledger account is the sum of it's  
> general
> journal entries.  In computer terms, the general ledger typically also
> contains a reference to the creating document.
>
> There can never be a single journal entry except for maintenance in
> correcting errors (rounding errors and the like). A journal entry  
> consists
> of two or more transactions, a debit and a credit, the sum of which  
> is zero
> when subtracting the debits from the credits for that transaction.  
> There
> should also be a reference document that is the basis for the  
> transaction,
> e.g. an invoice number, shipping number,  payment number etc.  In  
> other
> words, all activity in the system that involves something of value  
> whether
> or not it involves an outside party should have at least a pair of  
> journal
> entries and this includes non-cash things like moving inventory  
> between
> stores, depreciating fixed assets, good-will rightoffs, etc.  I say  
> "at
> least" because several transactions have many journal entries.  An  
> invoice
> for example involves at least a debit to cash or receivables, a  
> credit to a
> sales account and maybe a credit to a tax and or shipping account, a  
> credit
> to inventory, and a debit to cost of goods sold, etc.
>
> This is all provided for in AcctTrans and AcctingTransEntry  
> (although in my
> view having a product, shipping, invoice, payment, etc ids would be  
> better
> having a single "supportingDocumentId" used in conjuction with a
> "documentTypeId" as this would allow for unforseen transaction  
> types).  I do
> however understand the value of having individual document Ids so
> getRelated() can be used.  Its just that it looks so messy.
>
> Journal entries are always made in conjuction with and at the same  
> time as
> the original document is produced, and should be in my view part of  
> the
> database begin/commit.  This ensures that if the underlying document  
> is
> written, the required journal entries are written or none are.  It  
> therefore
> should be difficult to impossible for the journal to get out of wack  
> with
> the business and most large businesses I have been involved with  
> over the
> years is VERY concerned with the accounting of their money, not to  
> mention
> Sarbanes requirements in the U.S.
>
> You should be able to select a journal transaction, and see the  
> entries that
> comprise it and view the original document(s) that created it using  
> related
> entities.  If we insist that every journal entry has a supporting  
> document
> (which I think we should), we will have to create another entity to  
> hold
> manual postings which happen frequently, and no doubt others as well.
>
> In some businesses, the general ledger is auto-posted from the  
> journal in
> real time.  In others, the transaction is marked as isposted="F" and  
> the
> posting to the GL is handled by an accounting type human who reviews  
> all the
> unposted journal transactions before posting them to the GL (batch  
> mode
> posting).  This is a prime candidate for a SECA on the AcctTrans  
> commit if
> we just add a single entry "autopost"="T/F" to it (or maybe there is
> somewhere else we can get this flag from for a SECA?).
>
> If correctly correlated using a transaction class field, the journal  
> can be
> used to produce detailed cash flow statements and other similar
> sub-documents.  The GL itself is traditionally used to produce  
> balance and
> income statements.
>
> How you end up implementing it is of course up to you, but all the  
> pieces
> that I have described are provided for in the data model with the  
> possible
> exception of supportingDocumentId.
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:[hidden email]]
> Sent: Friday, November 23, 2007 2:40 AM
> To: [hidden email]
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In  
> Beta
>
>
> David, all,
>
> I'm really interested in knowing more about the design for journal
> management.
> I did some research (existing data model and services) and it seems to
> me that:
>
> * a journal (GlJournal) is used to group together a set of accounting
> transactions (AcctgTrans)
> * a journal can be used to verify the correctness of all the
> transactions associated to it (there is a service to check the trial
> balance of a journal)
> * a journal can be used to quickly post all the transactions  
> associated
> to it in one batch
>
> My questions are:
>
> 1) who should create a journal and when? automatically by the  
> system? by
> users? or manager?
> 2) can a transaction be created without specifying a journal?
> 3) can a journal contain both posted and unposted transactions?
> 4) should we create a GlJournal.journalTypeId field to define an error
> journal for transactions that failed auto-posting (as suggested by
> David) and possibly other types (e.g. to group automatically posted
> transactions from manually posted ones)
>
> I've also created a new Wiki page to help to get this ball rolling:
>
> http://docs.ofbiz.org/x/sgw
>
> I'll do my best to add relevant information there as well.
>
> Jacopo
>
> David E Jones wrote:
>>
>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>
>>> I have some strong feelings about how Si has done this though.  My
>>> primary
>>> concern is that some organizations prefer to post to the G/L in  
>>> real time
>>> and others prefer to do batch review/post.  I hope we can do  
>>> something
>>> like
>>> have a property or PartyAcctPreference that flips the switch.
>>
>> The original design I did for the accounting stuff includes journal
>> management for un-posted transactions. The implementation was  
>> supposed
>> to put transactions that failed auto-posting into an error journal  
>> to be
>> manually reviewed, but if there was a switch like this somewhere we
>> could certainly use the journaling feature for what you are  
>> describing,
>> and it could even be configured to queue up certain types of
>> transactions but not others (like all purchase invoices for  
>> example, but
>> not sales invoices or inventory changes due to the extreme volume;
>> assuming a company where that is the case for sake of example).
>>
>>> I would only like to be involved if we can agree to spend the time  
>>> to do
>>> user-friendly, intuitive screens.
>>
>> Feedback on screen designs, probably starting with putting down end-
>> user
>> processes to support (use cases if you will) would be great.
>>
>> -David
>>
>
>

[SkipDever]

David

Based on experience as well as "Accounting and Budgeting" page 271, every GL
account is associated with one (the one being the beginning balance entry)
or more AcctgTrans/AcctgTransEntry.  If you cannot reproduce how you got to
some figure in the GLAccount, what's the point?

Each AcctgTransEntry has a field for glAccountId which is thankfully
specified as "id-ne".

I agree that it is only required to make sure that each AcctgTrans and
associated AcctgTransEntrys zero's out.

I do not agree that AcctgTrans are optional unless you do not desire to
maintain a General Ledger at all.  The whole point of a journal is to
provide an audit trail and without it, the contents of GLAccount are
worthless, actually, worse that worthless.  Providing a field to specify the
originating document is optional I agree, but it gives one more point of
reference for the audit trail.

Ofbiz does have a GLJournal entity, but I don't see the point of it noone
uses it.  The AcctgTrans/AcctgTransEntry is the Journal and audit trail
unless some similiar pair of entities is invented to replace them.

I also agree that journals are not meant to be balanced. There is just too
much data there to manipulate regularly.  However, so long as each
AcctgTrans and associated AcctgTransEntrys balance and committed as one
atomic operation, it is in fact balanced.

I do not agree that "a transaction is not associated with a GL account and
does not  represent a debit or credit" unless you are talking about
transactions not associated with the general ledger and in particular
AcctgTrans/AcctgTransEntry for Ofbiz.  Every tupple in AcctgTransEntry needs
a glaccountId and debitCreditFlag,  and if the sum of debits and credits in
the AcctgTransEntry that are associated with a single AcctgTrans balance,
then the GL will balance when the posting is made.  I have made my
production postgres server require glaccountId and debitCreditFlag or the
commit is rejected.  If I could enforce this in Ofbiz, I would.

I agree that document reference is already well represented in Ofbiz
AcctgTrans/AcctgTransEntry.  I will go further and say that a well
structured and auditable general ledger is fully represented in existing
Ofbiz entities except for a manual entry "document" entity for manual
postings (except for the possibility of error journal you mentioned the
other day which I think is a splendid idea).

It is only required to make sure to implement the code in such a way all GL
transactions (those creating entries in AcctgTrans/AcctgTransEntry) are
atomic and debits balance with credits within themselves to end up with a
world class system accounting (leaving aside some of the really nifty things
you can do for large, multi-departmental organizations).

Given your superior experience here (mine is many years old), I am betting
we are disagreeing over semantic issues.

Skip

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Friday, November 23, 2007 6:20 PM
To: [hidden email]
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta



Some notes on journals (GlJournal), transactions (AcctgTrans),
transaction entries (AcctgTransEntry), etc:

1. they are optional, transactions do not have to be associated with a
journal
2. a transaction is not associated with a GL account and does not
represent a debit or credit, each entry in a transaction does
3. journals are not meant to be balanced, individual transactions are
(checking to see whether or not an entire journal is balanced is
simply a matter of seeing if each transaction is balanced
4. origin "documents" (detail records) are associated with the
transaction entry, and there are structures for this in OFBiz

I think this is mostly a difference in terminology, most of the rest
of what you wrote sounds correct to me based on my understanding based
on my research and collaboration with others on accounting systems.

-David


On Nov 23, 2007, at 1:09 PM, skip@thedevers wrote:

> Jacopo
>
> Traditionally, a general journal is the middle step or "glue" in a GL
> system.  Every number in a General Ledger account is the sum of it's
> general
> journal entries.  In computer terms, the general ledger typically also
> contains a reference to the creating document.
>
> There can never be a single journal entry except for maintenance in
> correcting errors (rounding errors and the like). A journal entry
> consists
> of two or more transactions, a debit and a credit, the sum of which
> is zero
> when subtracting the debits from the credits for that transaction.
> There
> should also be a reference document that is the basis for the
> transaction,
> e.g. an invoice number, shipping number,  payment number etc.  In
> other
> words, all activity in the system that involves something of value
> whether
> or not it involves an outside party should have at least a pair of
> journal
> entries and this includes non-cash things like moving inventory
> between
> stores, depreciating fixed assets, good-will rightoffs, etc.  I say
> "at
> least" because several transactions have many journal entries.  An
> invoice
> for example involves at least a debit to cash or receivables, a
> credit to a
> sales account and maybe a credit to a tax and or shipping account, a
> credit
> to inventory, and a debit to cost of goods sold, etc.
>
> This is all provided for in AcctTrans and AcctingTransEntry
> (although in my
> view having a product, shipping, invoice, payment, etc ids would be
> better
> having a single "supportingDocumentId" used in conjuction with a
> "documentTypeId" as this would allow for unforseen transaction
> types).  I do
> however understand the value of having individual document Ids so
> getRelated() can be used.  Its just that it looks so messy.
>
> Journal entries are always made in conjuction with and at the same
> time as
> the original document is produced, and should be in my view part of
> the
> database begin/commit.  This ensures that if the underlying document
> is
> written, the required journal entries are written or none are.  It
> therefore
> should be difficult to impossible for the journal to get out of wack
> with
> the business and most large businesses I have been involved with
> over the
> years is VERY concerned with the accounting of their money, not to
> mention
> Sarbanes requirements in the U.S.
>
> You should be able to select a journal transaction, and see the
> entries that
> comprise it and view the original document(s) that created it using
> related
> entities.  If we insist that every journal entry has a supporting
> document
> (which I think we should), we will have to create another entity to
> hold
> manual postings which happen frequently, and no doubt others as well.
>
> In some businesses, the general ledger is auto-posted from the
> journal in
> real time.  In others, the transaction is marked as isposted="F" and
> the
> posting to the GL is handled by an accounting type human who reviews
> all the
> unposted journal transactions before posting them to the GL (batch
> mode
> posting).  This is a prime candidate for a SECA on the AcctTrans
> commit if
> we just add a single entry "autopost"="T/F" to it (or maybe there is
> somewhere else we can get this flag from for a SECA?).
>
> If correctly correlated using a transaction class field, the journal
> can be
> used to produce detailed cash flow statements and other similar
> sub-documents.  The GL itself is traditionally used to produce
> balance and
> income statements.
>
> How you end up implementing it is of course up to you, but all the
> pieces
> that I have described are provided for in the data model with the
> possible
> exception of supportingDocumentId.
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:[hidden email]]
> Sent: Friday, November 23, 2007 2:40 AM
> To: [hidden email]
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
> Beta
>
>
> David, all,
>
> I'm really interested in knowing more about the design for journal
> management.
> I did some research (existing data model and services) and it seems to
> me that:
>
> * a journal (GlJournal) is used to group together a set of accounting
> transactions (AcctgTrans)
> * a journal can be used to verify the correctness of all the
> transactions associated to it (there is a service to check the trial
> balance of a journal)
> * a journal can be used to quickly post all the transactions
> associated
> to it in one batch
>
> My questions are:
>
> 1) who should create a journal and when? automatically by the
> system? by
> users? or manager?
> 2) can a transaction be created without specifying a journal?
> 3) can a journal contain both posted and unposted transactions?
> 4) should we create a GlJournal.journalTypeId field to define an error
> journal for transactions that failed auto-posting (as suggested by
> David) and possibly other types (e.g. to group automatically posted
> transactions from manually posted ones)
>
> I've also created a new Wiki page to help to get this ball rolling:
>
> http://docs.ofbiz.org/x/sgw
>
> I'll do my best to add relevant information there as well.
>
> Jacopo
>
> David E Jones wrote:
>>
>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>
>>> I have some strong feelings about how Si has done this though.  My
>>> primary
>>> concern is that some organizations prefer to post to the G/L in
>>> real time
>>> and others prefer to do batch review/post.  I hope we can do
>>> something
>>> like
>>> have a property or PartyAcctPreference that flips the switch.
>>
>> The original design I did for the accounting stuff includes journal
>> management for un-posted transactions. The implementation was
>> supposed
>> to put transactions that failed auto-posting into an error journal
>> to be
>> manually reviewed, but if there was a switch like this somewhere we
>> could certainly use the journaling feature for what you are
>> describing,
>> and it could even be configured to queue up certain types of
>> transactions but not others (like all purchase invoices for
>> example, but
>> not sales invoices or inventory changes due to the extreme volume;
>> assuming a company where that is the case for sake of example).
>>
>>> I would only like to be involved if we can agree to spend the time
>>> to do
>>> user-friendly, intuitive screens.
>>
>> Feedback on screen designs, probably starting with putting down end-
>> user
>> processes to support (use cases if you will) would be great.
>>
>> -David
>>
>
>

[Jacopo Cappellato]

Skip,

first of all, thanks for your notes.
Please, see my comments inline:

skip@thedevers wrote:

> David
>
> Based on experience as well as "Accounting and Budgeting" page 271, every GL
> account is associated with one (the one being the beginning balance entry)
> or more AcctgTrans/AcctgTransEntry.  If you cannot reproduce how you got to
> some figure in the GLAccount, what's the point?
>
> Each AcctgTransEntry has a field for glAccountId which is thankfully
> specified as "id-ne".
>
> I agree that it is only required to make sure that each AcctgTrans and
> associated AcctgTransEntrys zero's out.
>
> I do not agree that AcctgTrans are optional unless you do not desire to
> maintain a General Ledger at all.  The whole point of a journal is to

I'm pretty sure that what David meant in his message was that journals
(GlJournal) are optional; AcctgTrans and AcctgTransEntries are not.

> provide an audit trail and without it, the contents of GLAccount are
> worthless, actually, worse that worthless.  Providing a field to specify the
> originating document is optional I agree, but it gives one more point of
> reference for the audit trail.
>
> Ofbiz does have a GLJournal entity, but I don't see the point of it noone
> uses it.  The AcctgTrans/AcctgTransEntry is the Journal and audit trail
> unless some similiar pair of entities is invented to replace them.

Not sure to understand you here, but I guess that you are confirming
what David said: GLJournal are optional, AcctgTrans/AcctgTransEntry are
not, the AcctgTransEntry records are the ones that determine the
balances of accounts (GLAccount).

>
> I also agree that journals are not meant to be balanced. There is just too
> much data there to manipulate regularly.  However, so long as each
> AcctgTrans and associated AcctgTransEntrys balance and committed as one
> atomic operation, it is in fact balanced.
>
> I do not agree that "a transaction is not associated with a GL account and
> does not  represent a debit or credit" unless you are talking about

Again, I'm pretty sure that David here is saying: a transaction
(AcctgTrans) is not associated to a GL account (GlAccount), but each of
its associated entries (AcctgTransEntry) is associated to a GL account
(GlAccount)

> transactions not associated with the general ledger and in particular
> AcctgTrans/AcctgTransEntry for Ofbiz.  Every tupple in AcctgTransEntry needs
> a glaccountId and debitCreditFlag,  and if the sum of debits and credits in
> the AcctgTransEntry that are associated with a single AcctgTrans balance,
> then the GL will balance when the posting is made.  I have made my
> production postgres server require glaccountId and debitCreditFlag or the
> commit is rejected.  If I could enforce this in Ofbiz, I would.
>
> I agree that document reference is already well represented in Ofbiz
> AcctgTrans/AcctgTransEntry.  I will go further and say that a well
> structured and auditable general ledger is fully represented in existing
> Ofbiz entities except for a manual entry "document" entity for manual
> postings (except for the possibility of error journal you mentioned the
> other day which I think is a splendid idea).
>
> It is only required to make sure to implement the code in such a way all GL
> transactions (those creating entries in AcctgTrans/AcctgTransEntry) are
> atomic and debits balance with credits within themselves to end up with a
> world class system accounting (leaving aside some of the really nifty things
> you can do for large, multi-departmental organizations).
>
> Given your superior experience here (mine is many years old), I am betting
> we are disagreeing over semantic issues.

Yes, it seems to me too a semantic issue only.

Jacopo

>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Friday, November 23, 2007 6:20 PM
> To: [hidden email]
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
>
> Some notes on journals (GlJournal), transactions (AcctgTrans),
> transaction entries (AcctgTransEntry), etc:
>
> 1. they are optional, transactions do not have to be associated with a
> journal
> 2. a transaction is not associated with a GL account and does not
> represent a debit or credit, each entry in a transaction does
> 3. journals are not meant to be balanced, individual transactions are
> (checking to see whether or not an entire journal is balanced is
> simply a matter of seeing if each transaction is balanced
> 4. origin "documents" (detail records) are associated with the
> transaction entry, and there are structures for this in OFBiz
>
> I think this is mostly a difference in terminology, most of the rest
> of what you wrote sounds correct to me based on my understanding based
> on my research and collaboration with others on accounting systems.
>
> -David
>
>
> On Nov 23, 2007, at 1:09 PM, skip@thedevers wrote:
>
>> Jacopo
>>
>> Traditionally, a general journal is the middle step or "glue" in a GL
>> system.  Every number in a General Ledger account is the sum of it's
>> general
>> journal entries.  In computer terms, the general ledger typically also
>> contains a reference to the creating document.
>>
>> There can never be a single journal entry except for maintenance in
>> correcting errors (rounding errors and the like). A journal entry
>> consists
>> of two or more transactions, a debit and a credit, the sum of which
>> is zero
>> when subtracting the debits from the credits for that transaction.
>> There
>> should also be a reference document that is the basis for the
>> transaction,
>> e.g. an invoice number, shipping number,  payment number etc.  In
>> other
>> words, all activity in the system that involves something of value
>> whether
>> or not it involves an outside party should have at least a pair of
>> journal
>> entries and this includes non-cash things like moving inventory
>> between
>> stores, depreciating fixed assets, good-will rightoffs, etc.  I say
>> "at
>> least" because several transactions have many journal entries.  An
>> invoice
>> for example involves at least a debit to cash or receivables, a
>> credit to a
>> sales account and maybe a credit to a tax and or shipping account, a
>> credit
>> to inventory, and a debit to cost of goods sold, etc.
>>
>> This is all provided for in AcctTrans and AcctingTransEntry
>> (although in my
>> view having a product, shipping, invoice, payment, etc ids would be
>> better
>> having a single "supportingDocumentId" used in conjuction with a
>> "documentTypeId" as this would allow for unforseen transaction
>> types).  I do
>> however understand the value of having individual document Ids so
>> getRelated() can be used.  Its just that it looks so messy.
>>
>> Journal entries are always made in conjuction with and at the same
>> time as
>> the original document is produced, and should be in my view part of
>> the
>> database begin/commit.  This ensures that if the underlying document
>> is
>> written, the required journal entries are written or none are.  It
>> therefore
>> should be difficult to impossible for the journal to get out of wack
>> with
>> the business and most large businesses I have been involved with
>> over the
>> years is VERY concerned with the accounting of their money, not to
>> mention
>> Sarbanes requirements in the U.S.
>>
>> You should be able to select a journal transaction, and see the
>> entries that
>> comprise it and view the original document(s) that created it using
>> related
>> entities.  If we insist that every journal entry has a supporting
>> document
>> (which I think we should), we will have to create another entity to
>> hold
>> manual postings which happen frequently, and no doubt others as well.
>>
>> In some businesses, the general ledger is auto-posted from the
>> journal in
>> real time.  In others, the transaction is marked as isposted="F" and
>> the
>> posting to the GL is handled by an accounting type human who reviews
>> all the
>> unposted journal transactions before posting them to the GL (batch
>> mode
>> posting).  This is a prime candidate for a SECA on the AcctTrans
>> commit if
>> we just add a single entry "autopost"="T/F" to it (or maybe there is
>> somewhere else we can get this flag from for a SECA?).
>>
>> If correctly correlated using a transaction class field, the journal
>> can be
>> used to produce detailed cash flow statements and other similar
>> sub-documents.  The GL itself is traditionally used to produce
>> balance and
>> income statements.
>>
>> How you end up implementing it is of course up to you, but all the
>> pieces
>> that I have described are provided for in the data model with the
>> possible
>> exception of supportingDocumentId.
>>
>> Skip
>>
>>
>>
>> -----Original Message-----
>> From: Jacopo Cappellato [mailto:[hidden email]]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: [hidden email]
>> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
>> Beta
>>
>>
>> David, all,
>>
>> I'm really interested in knowing more about the design for journal
>> management.
>> I did some research (existing data model and services) and it seems to
>> me that:
>>
>> * a journal (GlJournal) is used to group together a set of accounting
>> transactions (AcctgTrans)
>> * a journal can be used to verify the correctness of all the
>> transactions associated to it (there is a service to check the trial
>> balance of a journal)
>> * a journal can be used to quickly post all the transactions
>> associated
>> to it in one batch
>>
>> My questions are:
>>
>> 1) who should create a journal and when? automatically by the
>> system? by
>> users? or manager?
>> 2) can a transaction be created without specifying a journal?
>> 3) can a journal contain both posted and unposted transactions?
>> 4) should we create a GlJournal.journalTypeId field to define an error
>> journal for transactions that failed auto-posting (as suggested by
>> David) and possibly other types (e.g. to group automatically posted
>> transactions from manually posted ones)
>>
>> I've also created a new Wiki page to help to get this ball rolling:
>>
>> http://docs.ofbiz.org/x/sgw
>>
>> I'll do my best to add relevant information there as well.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>>
>>>> I have some strong feelings about how Si has done this though.  My
>>>> primary
>>>> concern is that some organizations prefer to post to the G/L in
>>>> real time
>>>> and others prefer to do batch review/post.  I hope we can do
>>>> something
>>>> like
>>>> have a property or PartyAcctPreference that flips the switch.
>>> The original design I did for the accounting stuff includes journal
>>> management for un-posted transactions. The implementation was
>>> supposed
>>> to put transactions that failed auto-posting into an error journal
>>> to be
>>> manually reviewed, but if there was a switch like this somewhere we
>>> could certainly use the journaling feature for what you are
>>> describing,
>>> and it could even be configured to queue up certain types of
>>> transactions but not others (like all purchase invoices for
>>> example, but
>>> not sales invoices or inventory changes due to the extreme volume;
>>> assuming a company where that is the case for sake of example).
>>>
>>>> I would only like to be involved if we can agree to spend the time
>>>> to do
>>>> user-friendly, intuitive screens.
>>> Feedback on screen designs, probably starting with putting down end-
>>> user
>>> processes to support (use cases if you will) would be great.
>>>
>>> -David
>>>
>>
>

[SkipDever]

What is the feeling of the developers here about using JFreeChart:

http://www.jfree.org/jfreechart/

Here is the GNU Lesser General Public Licence  license:

http://www.gnu.org/licenses/lgpl.html

that it utilizes.  I am writing the screens for an AR collections tool and
want to present the last 6 to 12 months of sales and a picture (bar chart in
this case) is worth a thousand words.

Can a commit which uses JFreeChart be accepted?

Skip

[Jacques Le Roux]

De : "skip@thedevers" <[hidden email]>
> What is the feeling of the developers here about using JFreeChart:
>
> http://www.jfree.org/jfreechart/

I never used it but it seems to have the favor of developers

> Here is the GNU Lesser General Public Licence  license:
>
> http://www.gnu.org/licenses/lgpl.html
>
> that it utilizes.  I am writing the screens for an AR collections tool and
> want to present the last 6 to 12 months of sales and a picture (bar chart in
> this case) is worth a thousand words.
>
> Can a commit which uses JFreeChart be accepted?

Noway : GPL is incompatible with ASL2
http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz#LibrariesIncludedinOFBiz-Somenotesonlicenses

Jacques

> Skip
>

[Jacopo Cappellato]

skip@thedevers wrote:

> What is the feeling of the developers here about using JFreeChart:
>
> http://www.jfree.org/jfreechart/
>
> Here is the GNU Lesser General Public Licence  license:
>
> http://www.gnu.org/licenses/lgpl.html
>
> that it utilizes.  I am writing the screens for an AR collections tool and
> want to present the last 6 to 12 months of sales and a picture (bar chart in
> this case) is worth a thousand words.
>
> Can a commit which uses JFreeChart be accepted?

Yes, it is acceptable, but, have a look at this page:

http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz

because there are some notes about LGPL libraries:

"We can use, but can not include, libraries licensed with LGPL. The
licensing quirk here is that we can write code that uses the libraries
but can't include (distribute) the libraries themselves. This means that
we have to have the build.xml files out of the box with exclusions for
these source files. For each one we should document which jar files are
needed, where they can be obtained, and which build.xml file(s) need to
be changed to compile the Java files that depend on them."

Hope it helps,

Jacopo

>
> Skip

[Jacques Le Roux]

De : "Jacopo Cappellato" <[hidden email]>

> skip@thedevers wrote:
> > What is the feeling of the developers here about using JFreeChart:
> >
> > http://www.jfree.org/jfreechart/
> >
> > Here is the GNU Lesser General Public Licence  license:
> >
> > http://www.gnu.org/licenses/lgpl.html
> >
> > that it utilizes.  I am writing the screens for an AR collections tool and
> > want to present the last 6 to 12 months of sales and a picture (bar chart in
> > this case) is worth a thousand words.
> >
> > Can a commit which uses JFreeChart be accepted?
>
> Yes, it is acceptable, but, have a look at this page:

Sorry I missed the "Lesser". Besides, I put a link to http://people.apache.org/~rubys/3party.html#principle4 from the librairies
link below
<<To have a more complete view on licences compatibilty please use this proposed ASF policy : Software License Criteria and
Categories>>

Jacques

>
> http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz
>
> because there are some notes about LGPL libraries:
>
> "We can use, but can not include, libraries licensed with LGPL. The
> licensing quirk here is that we can write code that uses the libraries
> but can't include (distribute) the libraries themselves. This means that
> we have to have the build.xml files out of the box with exclusions for
> these source files. For each one we should document which jar files are
> needed, where they can be obtained, and which build.xml file(s) need to
> be changed to compile the Java files that depend on them."
>
> Hope it helps,
>
> Jacopo
>
> >
> > Skip
>

[David E Jones]

On Nov 24, 2007, at 2:45 AM, Jacopo Cappellato wrote:

> skip@thedevers wrote:
>> What is the feeling of the developers here about using JFreeChart:
>> http://www.jfree.org/jfreechart/
>> Here is the GNU Lesser General Public Licence  license:
>> http://www.gnu.org/licenses/lgpl.html
>> that it utilizes.  I am writing the screens for an AR collections  
>> tool and
>> want to present the last 6 to 12 months of sales and a picture (bar  
>> chart in
>> this case) is worth a thousand words.
>> Can a commit which uses JFreeChart be accepted?
>
> Yes, it is acceptable, but, have a look at this page:
>
> http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz
>
> because there are some notes about LGPL libraries:
>
> "We can use, but can not include, libraries licensed with LGPL. The  
> licensing quirk here is that we can write code that uses the  
> libraries but can't include (distribute) the libraries themselves.  
> This means that we have to have the build.xml files out of the box  
> with exclusions for these source files. For each one we should  
> document which jar files are needed, where they can be obtained, and  
> which build.xml file(s) need to be changed to compile the Java files  
> that depend on them."

This is the correct legal side of things for LGPL libraries.

 From a practical perspective because of this LGPL libraries are a  
real pain and unless there simply is no alternative we don't really  
want them in the project.

You don't have to read the mailing lists very long to see that the  
size and complexity of OFBiz is a big problem for lots of people. We  
have tried to simplify certain things to soften this blow (not  
possible everywhere, business requirements do tend to get complex) and  
the install and run process is a big one of those. Requiring the  
separate download and insertion of LGPL libraries and changing build  
files adds a lot to the difficulty of getting whatever requires the  
library to a functional state, and also tends to result in lots of  
questions to the mailing list for help getting it working, and  
complaints that it isn't working.

In short it is allowed but because of this strongly discouraged.

-David

[David E Jones]

It sounds here like you are confusing a transaction (AcctgTrans) with  
a journal (GlJournal). When I say journal I really do mean journal,  
aka GlJournal as I made explicit in my previous message.

-David


On Nov 23, 2007, at 8:15 PM, skip@thedevers wrote:

> David
>
> Based on experience as well as "Accounting and Budgeting" page 271,  
> every GL
> account is associated with one (the one being the beginning balance  
> entry)
> or more AcctgTrans/AcctgTransEntry.  If you cannot reproduce how you  
> got to
> some figure in the GLAccount, what's the point?
>
> Each AcctgTransEntry has a field for glAccountId which is thankfully
> specified as "id-ne".
>
> I agree that it is only required to make sure that each AcctgTrans and
> associated AcctgTransEntrys zero's out.
>
> I do not agree that AcctgTrans are optional unless you do not desire  
> to
> maintain a General Ledger at all.  The whole point of a journal is to
> provide an audit trail and without it, the contents of GLAccount are
> worthless, actually, worse that worthless.  Providing a field to  
> specify the
> originating document is optional I agree, but it gives one more  
> point of
> reference for the audit trail.
>
> Ofbiz does have a GLJournal entity, but I don't see the point of it  
> noone
> uses it.  The AcctgTrans/AcctgTransEntry is the Journal and audit  
> trail
> unless some similiar pair of entities is invented to replace them.
>
> I also agree that journals are not meant to be balanced. There is  
> just too
> much data there to manipulate regularly.  However, so long as each
> AcctgTrans and associated AcctgTransEntrys balance and committed as  
> one
> atomic operation, it is in fact balanced.
>
> I do not agree that "a transaction is not associated with a GL  
> account and
> does not  represent a debit or credit" unless you are talking about
> transactions not associated with the general ledger and in particular
> AcctgTrans/AcctgTransEntry for Ofbiz.  Every tupple in  
> AcctgTransEntry needs
> a glaccountId and debitCreditFlag,  and if the sum of debits and  
> credits in
> the AcctgTransEntry that are associated with a single AcctgTrans  
> balance,
> then the GL will balance when the posting is made.  I have made my
> production postgres server require glaccountId and debitCreditFlag  
> or the
> commit is rejected.  If I could enforce this in Ofbiz, I would.
>
> I agree that document reference is already well represented in Ofbiz
> AcctgTrans/AcctgTransEntry.  I will go further and say that a well
> structured and auditable general ledger is fully represented in  
> existing
> Ofbiz entities except for a manual entry "document" entity for manual
> postings (except for the possibility of error journal you mentioned  
> the
> other day which I think is a splendid idea).
>
> It is only required to make sure to implement the code in such a way  
> all GL
> transactions (those creating entries in AcctgTrans/AcctgTransEntry)  
> are
> atomic and debits balance with credits within themselves to end up  
> with a
> world class system accounting (leaving aside some of the really  
> nifty things
> you can do for large, multi-departmental organizations).
>
> Given your superior experience here (mine is many years old), I am  
> betting
> we are disagreeing over semantic issues.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Friday, November 23, 2007 6:20 PM
> To: [hidden email]
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In  
> Beta
>
>
>
> Some notes on journals (GlJournal), transactions (AcctgTrans),
> transaction entries (AcctgTransEntry), etc:
>
> 1. they are optional, transactions do not have to be associated with a
> journal
> 2. a transaction is not associated with a GL account and does not
> represent a debit or credit, each entry in a transaction does
> 3. journals are not meant to be balanced, individual transactions are
> (checking to see whether or not an entire journal is balanced is
> simply a matter of seeing if each transaction is balanced
> 4. origin "documents" (detail records) are associated with the
> transaction entry, and there are structures for this in OFBiz
>
> I think this is mostly a difference in terminology, most of the rest
> of what you wrote sounds correct to me based on my understanding based
> on my research and collaboration with others on accounting systems.
>
> -David
>
>
> On Nov 23, 2007, at 1:09 PM, skip@thedevers wrote:
>
>> Jacopo
>>
>> Traditionally, a general journal is the middle step or "glue" in a GL
>> system.  Every number in a General Ledger account is the sum of it's
>> general
>> journal entries.  In computer terms, the general ledger typically  
>> also
>> contains a reference to the creating document.
>>
>> There can never be a single journal entry except for maintenance in
>> correcting errors (rounding errors and the like). A journal entry
>> consists
>> of two or more transactions, a debit and a credit, the sum of which
>> is zero
>> when subtracting the debits from the credits for that transaction.
>> There
>> should also be a reference document that is the basis for the
>> transaction,
>> e.g. an invoice number, shipping number,  payment number etc.  In
>> other
>> words, all activity in the system that involves something of value
>> whether
>> or not it involves an outside party should have at least a pair of
>> journal
>> entries and this includes non-cash things like moving inventory
>> between
>> stores, depreciating fixed assets, good-will rightoffs, etc.  I say
>> "at
>> least" because several transactions have many journal entries.  An
>> invoice
>> for example involves at least a debit to cash or receivables, a
>> credit to a
>> sales account and maybe a credit to a tax and or shipping account, a
>> credit
>> to inventory, and a debit to cost of goods sold, etc.
>>
>> This is all provided for in AcctTrans and AcctingTransEntry
>> (although in my
>> view having a product, shipping, invoice, payment, etc ids would be
>> better
>> having a single "supportingDocumentId" used in conjuction with a
>> "documentTypeId" as this would allow for unforseen transaction
>> types).  I do
>> however understand the value of having individual document Ids so
>> getRelated() can be used.  Its just that it looks so messy.
>>
>> Journal entries are always made in conjuction with and at the same
>> time as
>> the original document is produced, and should be in my view part of
>> the
>> database begin/commit.  This ensures that if the underlying document
>> is
>> written, the required journal entries are written or none are.  It
>> therefore
>> should be difficult to impossible for the journal to get out of wack
>> with
>> the business and most large businesses I have been involved with
>> over the
>> years is VERY concerned with the accounting of their money, not to
>> mention
>> Sarbanes requirements in the U.S.
>>
>> You should be able to select a journal transaction, and see the
>> entries that
>> comprise it and view the original document(s) that created it using
>> related
>> entities.  If we insist that every journal entry has a supporting
>> document
>> (which I think we should), we will have to create another entity to
>> hold
>> manual postings which happen frequently, and no doubt others as well.
>>
>> In some businesses, the general ledger is auto-posted from the
>> journal in
>> real time.  In others, the transaction is marked as isposted="F" and
>> the
>> posting to the GL is handled by an accounting type human who reviews
>> all the
>> unposted journal transactions before posting them to the GL (batch
>> mode
>> posting).  This is a prime candidate for a SECA on the AcctTrans
>> commit if
>> we just add a single entry "autopost"="T/F" to it (or maybe there is
>> somewhere else we can get this flag from for a SECA?).
>>
>> If correctly correlated using a transaction class field, the journal
>> can be
>> used to produce detailed cash flow statements and other similar
>> sub-documents.  The GL itself is traditionally used to produce
>> balance and
>> income statements.
>>
>> How you end up implementing it is of course up to you, but all the
>> pieces
>> that I have described are provided for in the data model with the
>> possible
>> exception of supportingDocumentId.
>>
>> Skip
>>
>>
>>
>> -----Original Message-----
>> From: Jacopo Cappellato [mailto:[hidden email]]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: [hidden email]
>> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
>> Beta
>>
>>
>> David, all,
>>
>> I'm really interested in knowing more about the design for journal
>> management.
>> I did some research (existing data model and services) and it seems  
>> to
>> me that:
>>
>> * a journal (GlJournal) is used to group together a set of accounting
>> transactions (AcctgTrans)
>> * a journal can be used to verify the correctness of all the
>> transactions associated to it (there is a service to check the trial
>> balance of a journal)
>> * a journal can be used to quickly post all the transactions
>> associated
>> to it in one batch
>>
>> My questions are:
>>
>> 1) who should create a journal and when? automatically by the
>> system? by
>> users? or manager?
>> 2) can a transaction be created without specifying a journal?
>> 3) can a journal contain both posted and unposted transactions?
>> 4) should we create a GlJournal.journalTypeId field to define an  
>> error
>> journal for transactions that failed auto-posting (as suggested by
>> David) and possibly other types (e.g. to group automatically posted
>> transactions from manually posted ones)
>>
>> I've also created a new Wiki page to help to get this ball rolling:
>>
>> http://docs.ofbiz.org/x/sgw
>>
>> I'll do my best to add relevant information there as well.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>>
>>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>>
>>>> I have some strong feelings about how Si has done this though.  My
>>>> primary
>>>> concern is that some organizations prefer to post to the G/L in
>>>> real time
>>>> and others prefer to do batch review/post.  I hope we can do
>>>> something
>>>> like
>>>> have a property or PartyAcctPreference that flips the switch.
>>>
>>> The original design I did for the accounting stuff includes journal
>>> management for un-posted transactions. The implementation was
>>> supposed
>>> to put transactions that failed auto-posting into an error journal
>>> to be
>>> manually reviewed, but if there was a switch like this somewhere we
>>> could certainly use the journaling feature for what you are
>>> describing,
>>> and it could even be configured to queue up certain types of
>>> transactions but not others (like all purchase invoices for
>>> example, but
>>> not sales invoices or inventory changes due to the extreme volume;
>>> assuming a company where that is the case for sake of example).
>>>
>>>> I would only like to be involved if we can agree to spend the time
>>>> to do
>>>> user-friendly, intuitive screens.
>>>
>>> Feedback on screen designs, probably starting with putting down end-
>>> user
>>> processes to support (use cases if you will) would be great.
>>>
>>> -David
>>>
>>
>>
>
>

[SkipDever]

That is the confusion then,

I have always associated a General Journal as the detail and audit trail
behind General Ledger number.  The GLJournl entity is not that.  The
AcctgTrans/AcctgTransEntry entities are, hence my assuming that they were
the general journal we were talking about.

Skip

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Saturday, November 24, 2007 4:20 AM
To: [hidden email]
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta



It sounds here like you are confusing a transaction (AcctgTrans) with
a journal (GlJournal). When I say journal I really do mean journal,
aka GlJournal as I made explicit in my previous message.

-David


On Nov 23, 2007, at 8:15 PM, skip@thedevers wrote:

> David
>
> Based on experience as well as "Accounting and Budgeting" page 271,
> every GL
> account is associated with one (the one being the beginning balance
> entry)
> or more AcctgTrans/AcctgTransEntry.  If you cannot reproduce how you
> got to
> some figure in the GLAccount, what's the point?
>
> Each AcctgTransEntry has a field for glAccountId which is thankfully
> specified as "id-ne".
>
> I agree that it is only required to make sure that each AcctgTrans and
> associated AcctgTransEntrys zero's out.
>
> I do not agree that AcctgTrans are optional unless you do not desire
> to
> maintain a General Ledger at all.  The whole point of a journal is to
> provide an audit trail and without it, the contents of GLAccount are
> worthless, actually, worse that worthless.  Providing a field to
> specify the
> originating document is optional I agree, but it gives one more
> point of
> reference for the audit trail.
>
> Ofbiz does have a GLJournal entity, but I don't see the point of it
> noone
> uses it.  The AcctgTrans/AcctgTransEntry is the Journal and audit
> trail
> unless some similiar pair of entities is invented to replace them.
>
> I also agree that journals are not meant to be balanced. There is
> just too
> much data there to manipulate regularly.  However, so long as each
> AcctgTrans and associated AcctgTransEntrys balance and committed as
> one
> atomic operation, it is in fact balanced.
>
> I do not agree that "a transaction is not associated with a GL
> account and
> does not  represent a debit or credit" unless you are talking about
> transactions not associated with the general ledger and in particular
> AcctgTrans/AcctgTransEntry for Ofbiz.  Every tupple in
> AcctgTransEntry needs
> a glaccountId and debitCreditFlag,  and if the sum of debits and
> credits in
> the AcctgTransEntry that are associated with a single AcctgTrans
> balance,
> then the GL will balance when the posting is made.  I have made my
> production postgres server require glaccountId and debitCreditFlag
> or the
> commit is rejected.  If I could enforce this in Ofbiz, I would.
>
> I agree that document reference is already well represented in Ofbiz
> AcctgTrans/AcctgTransEntry.  I will go further and say that a well
> structured and auditable general ledger is fully represented in
> existing
> Ofbiz entities except for a manual entry "document" entity for manual
> postings (except for the possibility of error journal you mentioned
> the
> other day which I think is a splendid idea).
>
> It is only required to make sure to implement the code in such a way
> all GL
> transactions (those creating entries in AcctgTrans/AcctgTransEntry)
> are
> atomic and debits balance with credits within themselves to end up
> with a
> world class system accounting (leaving aside some of the really
> nifty things
> you can do for large, multi-departmental organizations).
>
> Given your superior experience here (mine is many years old), I am
> betting
> we are disagreeing over semantic issues.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Friday, November 23, 2007 6:20 PM
> To: [hidden email]
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
> Beta
>
>
>
> Some notes on journals (GlJournal), transactions (AcctgTrans),
> transaction entries (AcctgTransEntry), etc:
>
> 1. they are optional, transactions do not have to be associated with a
> journal
> 2. a transaction is not associated with a GL account and does not
> represent a debit or credit, each entry in a transaction does
> 3. journals are not meant to be balanced, individual transactions are
> (checking to see whether or not an entire journal is balanced is
> simply a matter of seeing if each transaction is balanced
> 4. origin "documents" (detail records) are associated with the
> transaction entry, and there are structures for this in OFBiz
>
> I think this is mostly a difference in terminology, most of the rest
> of what you wrote sounds correct to me based on my understanding based
> on my research and collaboration with others on accounting systems.
>
> -David
>
>
> On Nov 23, 2007, at 1:09 PM, skip@thedevers wrote:
>
>> Jacopo
>>
>> Traditionally, a general journal is the middle step or "glue" in a GL
>> system.  Every number in a General Ledger account is the sum of it's
>> general
>> journal entries.  In computer terms, the general ledger typically
>> also
>> contains a reference to the creating document.
>>
>> There can never be a single journal entry except for maintenance in
>> correcting errors (rounding errors and the like). A journal entry
>> consists
>> of two or more transactions, a debit and a credit, the sum of which
>> is zero
>> when subtracting the debits from the credits for that transaction.
>> There
>> should also be a reference document that is the basis for the
>> transaction,
>> e.g. an invoice number, shipping number,  payment number etc.  In
>> other
>> words, all activity in the system that involves something of value
>> whether
>> or not it involves an outside party should have at least a pair of
>> journal
>> entries and this includes non-cash things like moving inventory
>> between
>> stores, depreciating fixed assets, good-will rightoffs, etc.  I say
>> "at
>> least" because several transactions have many journal entries.  An
>> invoice
>> for example involves at least a debit to cash or receivables, a
>> credit to a
>> sales account and maybe a credit to a tax and or shipping account, a
>> credit
>> to inventory, and a debit to cost of goods sold, etc.
>>
>> This is all provided for in AcctTrans and AcctingTransEntry
>> (although in my
>> view having a product, shipping, invoice, payment, etc ids would be
>> better
>> having a single "supportingDocumentId" used in conjuction with a
>> "documentTypeId" as this would allow for unforseen transaction
>> types).  I do
>> however understand the value of having individual document Ids so
>> getRelated() can be used.  Its just that it looks so messy.
>>
>> Journal entries are always made in conjuction with and at the same
>> time as
>> the original document is produced, and should be in my view part of
>> the
>> database begin/commit.  This ensures that if the underlying document
>> is
>> written, the required journal entries are written or none are.  It
>> therefore
>> should be difficult to impossible for the journal to get out of wack
>> with
>> the business and most large businesses I have been involved with
>> over the
>> years is VERY concerned with the accounting of their money, not to
>> mention
>> Sarbanes requirements in the U.S.
>>
>> You should be able to select a journal transaction, and see the
>> entries that
>> comprise it and view the original document(s) that created it using
>> related
>> entities.  If we insist that every journal entry has a supporting
>> document
>> (which I think we should), we will have to create another entity to
>> hold
>> manual postings which happen frequently, and no doubt others as well.
>>
>> In some businesses, the general ledger is auto-posted from the
>> journal in
>> real time.  In others, the transaction is marked as isposted="F" and
>> the
>> posting to the GL is handled by an accounting type human who reviews
>> all the
>> unposted journal transactions before posting them to the GL (batch
>> mode
>> posting).  This is a prime candidate for a SECA on the AcctTrans
>> commit if
>> we just add a single entry "autopost"="T/F" to it (or maybe there is
>> somewhere else we can get this flag from for a SECA?).
>>
>> If correctly correlated using a transaction class field, the journal
>> can be
>> used to produce detailed cash flow statements and other similar
>> sub-documents.  The GL itself is traditionally used to produce
>> balance and
>> income statements.
>>
>> How you end up implementing it is of course up to you, but all the
>> pieces
>> that I have described are provided for in the data model with the
>> possible
>> exception of supportingDocumentId.
>>
>> Skip
>>
>>
>>
>> -----Original Message-----
>> From: Jacopo Cappellato [mailto:[hidden email]]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: [hidden email]
>> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
>> Beta
>>
>>
>> David, all,
>>
>> I'm really interested in knowing more about the design for journal
>> management.
>> I did some research (existing data model and services) and it seems
>> to
>> me that:
>>
>> * a journal (GlJournal) is used to group together a set of accounting
>> transactions (AcctgTrans)
>> * a journal can be used to verify the correctness of all the
>> transactions associated to it (there is a service to check the trial
>> balance of a journal)
>> * a journal can be used to quickly post all the transactions
>> associated
>> to it in one batch
>>
>> My questions are:
>>
>> 1) who should create a journal and when? automatically by the
>> system? by
>> users? or manager?
>> 2) can a transaction be created without specifying a journal?
>> 3) can a journal contain both posted and unposted transactions?
>> 4) should we create a GlJournal.journalTypeId field to define an
>> error
>> journal for transactions that failed auto-posting (as suggested by
>> David) and possibly other types (e.g. to group automatically posted
>> transactions from manually posted ones)
>>
>> I've also created a new Wiki page to help to get this ball rolling:
>>
>> http://docs.ofbiz.org/x/sgw
>>
>> I'll do my best to add relevant information there as well.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>>
>>> On Nov 23, 2007, at 12:02 AM, skip@thedevers wrote:
>>>
>>>> I have some strong feelings about how Si has done this though.  My
>>>> primary
>>>> concern is that some organizations prefer to post to the G/L in
>>>> real time
>>>> and others prefer to do batch review/post.  I hope we can do
>>>> something
>>>> like
>>>> have a property or PartyAcctPreference that flips the switch.
>>>
>>> The original design I did for the accounting stuff includes journal
>>> management for un-posted transactions. The implementation was
>>> supposed
>>> to put transactions that failed auto-posting into an error journal
>>> to be
>>> manually reviewed, but if there was a switch like this somewhere we
>>> could certainly use the journaling feature for what you are
>>> describing,
>>> and it could even be configured to queue up certain types of
>>> transactions but not others (like all purchase invoices for
>>> example, but
>>> not sales invoices or inventory changes due to the extreme volume;
>>> assuming a company where that is the case for sake of example).
>>>
>>>> I would only like to be involved if we can agree to spend the time
>>>> to do
>>>> user-friendly, intuitive screens.
>>>
>>> Feedback on screen designs, probably starting with putting down end-
>>> user
>>> processes to support (use cases if you will) would be great.
>>>
>>> -David
>>>
>>
>>
>
>

[SkipDever]

Hmmm

Well, I somehow missed that in the licensing.  This stuff is so confusing.
My brain gets numb halfway through and I end of just glancing at most of it.
So, has anyone any experience with an Apache style licensed charting
software they would like to recommend?

Skip

[SkipDever]

I am thinking about the implementation of this.

As I mentioned, I am strongly motivated to make each entry in
AcctgTrans/AcctgTransEntry an atomic part of the underlying reason for the
enter, say an Invoice creation.  If the AcctgTrans/AcctgTransEntry creation
fails, the Invoice creation should be rolled back as well to the integrity
of the business is maintained.

On the other hand, it is my expectation that most Ofbiz users will not use
this or want the overhead.

So, my question.  Can a SECA be used?  If the code in a SECA that is
associated with a commit on some entity generates an exception, is the
associated transaction rolled back?  For example, if a SECA was tied to an
Invoice commit and that code caused an exception, would the Invoice commit
be rolled back too?

Skip

[Jacopo Cappellato]

skip@thedevers wrote:

> I am thinking about the implementation of this.
>
> As I mentioned, I am strongly motivated to make each entry in
> AcctgTrans/AcctgTransEntry an atomic part of the underlying reason for the
> enter, say an Invoice creation.  If the AcctgTrans/AcctgTransEntry creation
> fails, the Invoice creation should be rolled back as well to the integrity
> of the business is maintained.
>
> On the other hand, it is my expectation that most Ofbiz users will not use
> this or want the overhead.
>
> So, my question.  Can a SECA be used?  If the code in a SECA that is

Yes, this is what we should really implement.

> associated with a commit on some entity generates an exception, is the
> associated transaction rolled back?  For example, if a SECA was tied to an
> Invoice commit and that code caused an exception, would the Invoice commit
> be rolled back too?

Yes... and no :-)
If in the seca you set the service call as sync then everything will be
rolled back (if the accounting transaction fails); if you set the seca
as async then it will not.
I'd say that by default we should keep the accounting secas as async,
but some customer could change them to async.

Does it make sense?

Jacopo

>
> Skip