You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2007/11/23 07:38:23 UTC
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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
>>>>> Users@lists.ofbiz.org
>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>> --
>>> James A Barrows
>>
>
>
>
Re: OFBiz user group in FaceBook
Posted by Jacques Le Roux <ja...@les7arts.com>.
I totally agree, we try to make a community not communities... Of course locale communites have sense (because of language), but
sorry to say that all this facebook proposition looks like fork to me...
Thanks
Jacques
De : "BJ Freeman" <bj...@free-man.net>
> I would hope there is a frequent statement in the group to use the
> Mailing list.
> it only waters down the effort to have splinters that are not
> automatically links to th emailing list.
>
>
> Shi Jinghai sent the following on 11/24/2007 12:13 AM:
> > Hi all,
> >
> > I have just created a new group in FaceBook named OFBiz. This group is
> > not a substitute for any others but for a room that OFBiz users and
> > developpers can see the others face to face. Welcome anyone to join this
> > group!
> >
> > http://www.facebook.com/group.php?gid=21218211992
> >
> > Regards,
> >
> > Shi Jinghai/Beijing Langhua Ltd.
> >
> >
> >
> >
> >
>
Re: OFBiz user group in FaceBook
Posted by BJ Freeman <bj...@free-man.net>.
I would hope there is a frequent statement in the group to use the
Mailing list.
it only waters down the effort to have splinters that are not
automatically links to th emailing list.
Shi Jinghai sent the following on 11/24/2007 12:13 AM:
> Hi all,
>
> I have just created a new group in FaceBook named OFBiz. This group is
> not a substitute for any others but for a room that OFBiz users and
> developpers can see the others face to face. Welcome anyone to join this
> group!
>
> http://www.facebook.com/group.php?gid=21218211992
>
> Regards,
>
> Shi Jinghai/Beijing Langhua Ltd.
>
>
>
>
>
OFBiz user group in FaceBook
Posted by Shi Jinghai <sh...@langhua.cn>.
Hi all,
I have just created a new group in FaceBook named OFBiz. This group is
not a substitute for any others but for a room that OFBiz users and
developpers can see the others face to face. Welcome anyone to join this
group!
http://www.facebook.com/group.php?gid=21218211992
Regards,
Shi Jinghai/Beijing Langhua Ltd.
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by BJ Freeman <bj...@free-man.net>.
my thinking on that is to append the partyID of company or sub company
and party groups that are department to the GL
Vince M. Clark sent the following on 11/23/2007 12:00 PM:
> I'm not very familiar with QB's but yes, "classes" sounds like a similar concept.
>
> Basically we just need to report on many "classes" or "dimensions" of transactions. Things like cost center, department, and activity are common dimensions.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> vclark@globalera.com
> (303) 493-6723
>
> ----- Original Message -----
> From: "Jim Barrows" <ji...@gmail.com>
> To: user@ofbiz.apache.org
> Sent: Friday, November 23, 2007 12:37:13 PM (GMT-0700) America/Denver
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
> I'm not entirely sure what you mean by multi-dimensional accounting.
> Are you talking about a facility like QB's classes? only with
> multiple classes per account? Or just being able to have one GL entry
> be tracked back to one or more business transactions(invoice being
> paid etc).
>
> On Nov 23, 2007 11:13 AM, Vince M. Clark <vc...@globalera.com> wrote:
>> I'm glad to see renewed energy in the Accounting functionality. I have one request and will contribute related knowledge whenever possible.
>>
>> Please consider multi-dimensional accounting in the design. The concept of "Internal Org" is a good start, although I am not sure that it's model could be extended for use with additional accounting dimensions.
>>
>> Here is what I can tell from the data model about how Internal Org appears to be used in postings:
>> AcctgTrans contains a header record of the posting.
>> AcctgTransEntry contains the debits and credits, and also stores the "organizationPartyId." So GL reporting by org can be done.
>>
>> To perform multidimensional accounting we must be able to track other dimensions at the debit and credit level (AcctgTransEntry.) This also suggests that the information be derived from sources higher up the stack, like an Invoice.
>>
>> Other systems I have worked on that have this capability store additional columns at the DR/CR level which implies that the number of available dimensions is fixed, not dynamic. This is usually OK. I haven't seen a company go beyond eight dimensions. But this approach definitely limits flexiibility.
>>
>> I have had conversations with others in the community on this topic. Some have suggested that we can derive the reporting from the source documents (Invoices, GL Journal, etc.) and do not need to carry lots of dimensions all the way to posting. But it sure makes reporting easier if we do. There are probably other compelling accounting reasons for storing the dimension with the posting but I'm no accountant.
>>
>> Vince Clark
>> Global Era
>> The Freedom of Open Source
>> vclark@globalera.com
>> (303) 493-6723
>>
>> ----- Original Message -----
>> From: "Jim Barrows" <ji...@gmail.com>
>> To: user@ofbiz.apache.org
>> Sent: Friday, November 23, 2007 10:37:43 AM (GMT-0700) America/Denver
>> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>>
>>
>> Sure, you can add me to the list. I'm a java developer in my day job.
>> I'm learning the rest of OFBIZ. I'm also a team player, I can work
>> on whatever we need to to get the job done.
>> I had planned with starting on the most glaring omissions, the Income
>> and balance sheet. But I haven't actually slung any code for it.
>>
>> On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
>>> 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
>>>>>>>> Users@lists.ofbiz.org
>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>>>>
>>>>>> --
>>>>>> James A Barrows
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> James A Barrows
>>
>
>
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "Vince M. Clark" <vc...@globalera.com>.
I'm not very familiar with QB's but yes, "classes" sounds like a similar concept.
Basically we just need to report on many "classes" or "dimensions" of transactions. Things like cost center, department, and activity are common dimensions.
Vince Clark
Global Era
The Freedom of Open Source
vclark@globalera.com
(303) 493-6723
----- Original Message -----
From: "Jim Barrows" <ji...@gmail.com>
To: user@ofbiz.apache.org
Sent: Friday, November 23, 2007 12:37:13 PM (GMT-0700) America/Denver
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
I'm not entirely sure what you mean by multi-dimensional accounting.
Are you talking about a facility like QB's classes? only with
multiple classes per account? Or just being able to have one GL entry
be tracked back to one or more business transactions(invoice being
paid etc).
On Nov 23, 2007 11:13 AM, Vince M. Clark <vc...@globalera.com> wrote:
> I'm glad to see renewed energy in the Accounting functionality. I have one request and will contribute related knowledge whenever possible.
>
> Please consider multi-dimensional accounting in the design. The concept of "Internal Org" is a good start, although I am not sure that it's model could be extended for use with additional accounting dimensions.
>
> Here is what I can tell from the data model about how Internal Org appears to be used in postings:
> AcctgTrans contains a header record of the posting.
> AcctgTransEntry contains the debits and credits, and also stores the "organizationPartyId." So GL reporting by org can be done.
>
> To perform multidimensional accounting we must be able to track other dimensions at the debit and credit level (AcctgTransEntry.) This also suggests that the information be derived from sources higher up the stack, like an Invoice.
>
> Other systems I have worked on that have this capability store additional columns at the DR/CR level which implies that the number of available dimensions is fixed, not dynamic. This is usually OK. I haven't seen a company go beyond eight dimensions. But this approach definitely limits flexiibility.
>
> I have had conversations with others in the community on this topic. Some have suggested that we can derive the reporting from the source documents (Invoices, GL Journal, etc.) and do not need to carry lots of dimensions all the way to posting. But it sure makes reporting easier if we do. There are probably other compelling accounting reasons for storing the dimension with the posting but I'm no accountant.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> vclark@globalera.com
> (303) 493-6723
>
> ----- Original Message -----
> From: "Jim Barrows" <ji...@gmail.com>
> To: user@ofbiz.apache.org
> Sent: Friday, November 23, 2007 10:37:43 AM (GMT-0700) America/Denver
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
> Sure, you can add me to the list. I'm a java developer in my day job.
> I'm learning the rest of OFBIZ. I'm also a team player, I can work
> on whatever we need to to get the job done.
> I had planned with starting on the most glaring omissions, the Income
> and balance sheet. But I haven't actually slung any code for it.
>
> On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
> > 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
> > >>>>> Users@lists.ofbiz.org
> > >>>>> http://lists.ofbiz.org/mailman/listinfo/users
> > >>>
> > >>>
> > >>> --
> > >>> James A Barrows
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> --
> James A Barrows
>
--
James A Barrows
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jim Barrows <ji...@gmail.com>.
I'm not entirely sure what you mean by multi-dimensional accounting.
Are you talking about a facility like QB's classes? only with
multiple classes per account? Or just being able to have one GL entry
be tracked back to one or more business transactions(invoice being
paid etc).
On Nov 23, 2007 11:13 AM, Vince M. Clark <vc...@globalera.com> wrote:
> I'm glad to see renewed energy in the Accounting functionality. I have one request and will contribute related knowledge whenever possible.
>
> Please consider multi-dimensional accounting in the design. The concept of "Internal Org" is a good start, although I am not sure that it's model could be extended for use with additional accounting dimensions.
>
> Here is what I can tell from the data model about how Internal Org appears to be used in postings:
> AcctgTrans contains a header record of the posting.
> AcctgTransEntry contains the debits and credits, and also stores the "organizationPartyId." So GL reporting by org can be done.
>
> To perform multidimensional accounting we must be able to track other dimensions at the debit and credit level (AcctgTransEntry.) This also suggests that the information be derived from sources higher up the stack, like an Invoice.
>
> Other systems I have worked on that have this capability store additional columns at the DR/CR level which implies that the number of available dimensions is fixed, not dynamic. This is usually OK. I haven't seen a company go beyond eight dimensions. But this approach definitely limits flexiibility.
>
> I have had conversations with others in the community on this topic. Some have suggested that we can derive the reporting from the source documents (Invoices, GL Journal, etc.) and do not need to carry lots of dimensions all the way to posting. But it sure makes reporting easier if we do. There are probably other compelling accounting reasons for storing the dimension with the posting but I'm no accountant.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> vclark@globalera.com
> (303) 493-6723
>
> ----- Original Message -----
> From: "Jim Barrows" <ji...@gmail.com>
> To: user@ofbiz.apache.org
> Sent: Friday, November 23, 2007 10:37:43 AM (GMT-0700) America/Denver
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
> Sure, you can add me to the list. I'm a java developer in my day job.
> I'm learning the rest of OFBIZ. I'm also a team player, I can work
> on whatever we need to to get the job done.
> I had planned with starting on the most glaring omissions, the Income
> and balance sheet. But I haven't actually slung any code for it.
>
> On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
> > 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
> > >>>>> Users@lists.ofbiz.org
> > >>>>> http://lists.ofbiz.org/mailman/listinfo/users
> > >>>
> > >>>
> > >>> --
> > >>> James A Barrows
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> --
> James A Barrows
>
--
James A Barrows
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
There are many dimensions, unlimited really, possible with the ofbiz
data model, especially since it is easy to extend.
As for using the data... reducing redundancy in the operational/
transactional data store is important. If you need a better model for
reporting purposes check out the BI component that Jacopo has been
working on. This is really the point of OLAP (analytical) data stores.
In OFBiz we just use a relational database for both, but the
analytical data store uses a star schema to make dimensional reporting
easier (and WAY faster! especially when it is on a different physical
machine and is not competing with the operational data store for
resources).
-David
On Nov 23, 2007, at 11:13 AM, Vince M. Clark wrote:
> I'm glad to see renewed energy in the Accounting functionality. I
> have one request and will contribute related knowledge whenever
> possible.
>
> Please consider multi-dimensional accounting in the design. The
> concept of "Internal Org" is a good start, although I am not sure
> that it's model could be extended for use with additional accounting
> dimensions.
>
> Here is what I can tell from the data model about how Internal Org
> appears to be used in postings:
> AcctgTrans contains a header record of the posting.
> AcctgTransEntry contains the debits and credits, and also stores the
> "organizationPartyId." So GL reporting by org can be done.
>
> To perform multidimensional accounting we must be able to track
> other dimensions at the debit and credit level (AcctgTransEntry.)
> This also suggests that the information be derived from sources
> higher up the stack, like an Invoice.
>
> Other systems I have worked on that have this capability store
> additional columns at the DR/CR level which implies that the number
> of available dimensions is fixed, not dynamic. This is usually OK. I
> haven't seen a company go beyond eight dimensions. But this approach
> definitely limits flexiibility.
>
> I have had conversations with others in the community on this topic.
> Some have suggested that we can derive the reporting from the source
> documents (Invoices, GL Journal, etc.) and do not need to carry lots
> of dimensions all the way to posting. But it sure makes reporting
> easier if we do. There are probably other compelling accounting
> reasons for storing the dimension with the posting but I'm no
> accountant.
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> vclark@globalera.com
> (303) 493-6723
>
> ----- Original Message -----
> From: "Jim Barrows" <ji...@gmail.com>
> To: user@ofbiz.apache.org
> Sent: Friday, November 23, 2007 10:37:43 AM (GMT-0700) America/Denver
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In
> Beta
>
> Sure, you can add me to the list. I'm a java developer in my day job.
> I'm learning the rest of OFBIZ. I'm also a team player, I can work
> on whatever we need to to get the job done.
> I had planned with starting on the most glaring omissions, the Income
> and balance sheet. But I haven't actually slung any code for it.
>
> On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
>> 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 <jo...@hotwaxmedia.com>
>>> 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 <bj...@free-man.net> 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
>>>>>>> Users@lists.ofbiz.org
>>>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>> --
>>>>> James A Barrows
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> James A Barrows
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "Vince M. Clark" <vc...@globalera.com>.
I'm glad to see renewed energy in the Accounting functionality. I have one request and will contribute related knowledge whenever possible.
Please consider multi-dimensional accounting in the design. The concept of "Internal Org" is a good start, although I am not sure that it's model could be extended for use with additional accounting dimensions.
Here is what I can tell from the data model about how Internal Org appears to be used in postings:
AcctgTrans contains a header record of the posting.
AcctgTransEntry contains the debits and credits, and also stores the "organizationPartyId." So GL reporting by org can be done.
To perform multidimensional accounting we must be able to track other dimensions at the debit and credit level (AcctgTransEntry.) This also suggests that the information be derived from sources higher up the stack, like an Invoice.
Other systems I have worked on that have this capability store additional columns at the DR/CR level which implies that the number of available dimensions is fixed, not dynamic. This is usually OK. I haven't seen a company go beyond eight dimensions. But this approach definitely limits flexiibility.
I have had conversations with others in the community on this topic. Some have suggested that we can derive the reporting from the source documents (Invoices, GL Journal, etc.) and do not need to carry lots of dimensions all the way to posting. But it sure makes reporting easier if we do. There are probably other compelling accounting reasons for storing the dimension with the posting but I'm no accountant.
Vince Clark
Global Era
The Freedom of Open Source
vclark@globalera.com
(303) 493-6723
----- Original Message -----
From: "Jim Barrows" <ji...@gmail.com>
To: user@ofbiz.apache.org
Sent: Friday, November 23, 2007 10:37:43 AM (GMT-0700) America/Denver
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Sure, you can add me to the list. I'm a java developer in my day job.
I'm learning the rest of OFBIZ. I'm also a team player, I can work
on whatever we need to to get the job done.
I had planned with starting on the most glaring omissions, the Income
and balance sheet. But I haven't actually slung any code for it.
On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
> 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
> >>>>> Users@lists.ofbiz.org
> >>>>> http://lists.ofbiz.org/mailman/listinfo/users
> >>>
> >>>
> >>> --
> >>> James A Barrows
> >>
> >
> >
> >
>
>
>
>
--
James A Barrows
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jim Barrows <ji...@gmail.com>.
Sure, you can add me to the list. I'm a java developer in my day job.
I'm learning the rest of OFBIZ. I'm also a team player, I can work
on whatever we need to to get the job done.
I had planned with starting on the most glaring omissions, the Income
and balance sheet. But I haven't actually slung any code for it.
On Nov 22, 2007 11:38 PM, Jacopo Cappellato <ti...@sastau.it> wrote:
> 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
> >>>>> Users@lists.ofbiz.org
> >>>>> http://lists.ofbiz.org/mailman/listinfo/users
> >>>
> >>>
> >>> --
> >>> James A Barrows
> >>
> >
> >
> >
>
>
>
>
--
James A Barrows
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Scott Gray <le...@gmail.com>.
Hi Jacopo
Feel free to add me to the list, I'm no accountant (not even close!) but can
certainly help with implementing new screens and the like.
Regards
Scott
On 23/11/2007, Jacopo Cappellato <ti...@sastau.it> wrote:
>
> 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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
> >>>>> Users@lists.ofbiz.org
> >>>>> http://lists.ofbiz.org/mailman/listinfo/users
> >>>
> >>>
> >>> --
> >>> James A Barrows
> >>
> >
> >
> >
>
>
>
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
De : "Jacopo Cappellato" <ti...@sastau.it>
> Jacques Le Roux wrote:
> >
> > Two persons (former clients of mine) seems to be interested to work on the accouting module on their own free time. One has a
solid
> > background as manager and the other as programmer.
> > I will not work myself on this task but I will try as much as I'm able to to put them on the right track. These persons have
worked
> > with Neogia (not in the Neogia team but as users) and don't want to follow the way Neogia was built on the accounting side. They
> > have a good understanding of the OFBiz accounting model and find it more open that Neogia's. Hopefully new strenghts with an
> > European view on accounting (I know Jacopo has also an European view ;o)
> >
> > Jacques
>
> This is great news, Jacques.
> Of course there is a lot to do, and not only development tasks; as I
> mentioned in one of my last messages, one of the top priority tasks is
> to quickly document the steps required to setup the GL accounting in
> OFBiz, this will be of great help to all the persons interested in
> helping with the development; I already tried to setup a draft of this here:
>
> http://docs.ofbiz.org/x/sgw
>
> (see the paragraph "Current status") but as you can see the information
> can be greatly improved.
I already sent them this link + the link to this thread in Nabble and some other they may need. I also invited them to use OFBiz
MLs.
> Then we also need help to setup some use data/use cases for helping
> developers to share the same scenarios and to help them work on the same
> "wave"; we could prepare seed data and/or instructions to setup a simple
> GL sysytem using OFBiz demo data (i.e. the Company party etc...).
I forward them this message as I'm not sure they already follow MLs
Thanks
Jacques
> Jacopo
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jacques Le Roux wrote:
>
> Two persons (former clients of mine) seems to be interested to work on the accouting module on their own free time. One has a solid
> background as manager and the other as programmer.
> I will not work myself on this task but I will try as much as I'm able to to put them on the right track. These persons have worked
> with Neogia (not in the Neogia team but as users) and don't want to follow the way Neogia was built on the accounting side. They
> have a good understanding of the OFBiz accounting model and find it more open that Neogia's. Hopefully new strenghts with an
> European view on accounting (I know Jacopo has also an European view ;o)
>
> Jacques
This is great news, Jacques.
Of course there is a lot to do, and not only development tasks; as I
mentioned in one of my last messages, one of the top priority tasks is
to quickly document the steps required to setup the GL accounting in
OFBiz, this will be of great help to all the persons interested in
helping with the development; I already tried to setup a draft of this here:
http://docs.ofbiz.org/x/sgw
(see the paragraph "Current status") but as you can see the information
can be greatly improved.
Then we also need help to setup some use data/use cases for helping
developers to share the same scenarios and to help them work on the same
"wave"; we could prepare seed data and/or instructions to setup a simple
GL sysytem using OFBiz demo data (i.e. the Company party etc...).
Jacopo
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "skip@thedevers" <sk...@thedevers.org>
[...]
>
> I have zero understanding of the needs of European accounting requirements
> (if they are different) and the differences with U.S. ones.
Two persons (former clients of mine) seems to be interested to work on the accouting module on their own free time. One has a solid
background as manager and the other as programmer.
I will not work myself on this task but I will try as much as I'm able to to put them on the right track. These persons have worked
with Neogia (not in the Neogia team but as users) and don't want to follow the way Neogia was built on the accounting side. They
have a good understanding of the OFBiz accounting model and find it more open that Neogia's. Hopefully new strenghts with an
European view on accounting (I know Jacopo has also an European view ;o)
Jacques
> Skip
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
Yes, that is correct, I mis-wrote.
The origin "document" (record is probably a better term) triggers/
causes the transaction and not each entry in the transaction.
-David
On Nov 25, 2007, at 1:59 AM, Jacopo Cappellato wrote:
> David,
>
> after reviewing the AcctgTrans and AcctgTransEntry entity I've
> noticed that fixedAssetId, inventoryItemId, physicalInventoryId,
> partyId, roleTypeId, invoiceId, paymentId, finAccountTransId,
> shipmentId, receiptId, workEffortId are in the AcctgTrans entity,
> while partyId and productId are defined in the AcctgTransEntry entity.
> This sounds slightly different from #4 in your notes:
>
> > 4. origin "documents" (detail records) are associated with the
> > transaction entry, and there are structures for this in OFBiz
>
> If the data model is correctly defined, it should be:
>
> 4. origin "documents" (detail records) are associated with the
> transaction
>
> Sorry for the many questions, but I'm moving the information from
> the list to the Wiki page and I want to be sure I understand the
> design.
>
> Thanks,
>
> Jacopo
>
>
> David E Jones wrote:
>> 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
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Nov 25, 2007, at 12:07 PM, skip@thedevers wrote:
> More commonly, there is one post for the sum of the inventory items
> sold.
> However, this method offers some flexibility if you want to split up
> cost of
> goods or maybe you have separate inventory accounts for different
> inventory
> types. For that reason, I like it.
Why thank you, I'm glad to hear some agreement/validation for my
designs in this area. Of course, they really aren't my ideas just an
application of ideas from:
1. The Data Model Resource Book, Revised Edition, Volume 1
(accounting, party, and other related areas)
2. the OMG GL interface specification
3. various books on accounting, including the accounting and supply
chain books at http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
4. the proposed OMG AR/AP interface specification, that lost backing
in 2003 (if I remember the timing right), just looked it up and that
is right, here is some info: http://ledgerism.net/ARAP/arapxml.htm
Anyway, those are good sources for understanding the whys and
wherefores behind accounting in OFBiz, and a bit of history as well.
-David
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
Nice find BJ.
-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Sunday, November 25, 2007 11:32 AM
To: dev@ofbiz.apache.org
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
before I put my two cents in I have searching the Internet and reading
where can I put links like
www.ofm.wa.gov/roadmap/modeling/generalledger/general_ledger_best_practices_
summary.pdf
skip@nevertheless sent the following on 11/25/2007 11:07 AM:
> Jacopo
>
> I can answer for the productId part (I too do not understand having the
> partyId). Si, when he does the transaction for an an invoice, puts the
> individual InvoiceItems a separate AcctgTransEntry record. Then, you have
> only one AcctTrans record and multiple AcctgTransEntry records for the
> inventory part (the sales part is a second and separate transaction) of
one
> invoice.
>
> More commonly, there is one post for the sum of the inventory items sold.
> However, this method offers some flexibility if you want to split up cost
of
> goods or maybe you have separate inventory accounts for different
inventory
> types. For that reason, I like it.
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:tiz@sastau.it]
> Sent: Sunday, November 25, 2007 1:00 AM
> To: dev@ofbiz.apache.org
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
> David,
>
> after reviewing the AcctgTrans and AcctgTransEntry entity I've noticed
> that fixedAssetId, inventoryItemId, physicalInventoryId, partyId,
> roleTypeId, invoiceId, paymentId, finAccountTransId, shipmentId,
> receiptId, workEffortId are in the AcctgTrans entity, while partyId and
> productId are defined in the AcctgTransEntry entity.
> This sounds slightly different from #4 in your notes:
>
> > 4. origin "documents" (detail records) are associated with the
> > transaction entry, and there are structures for this in OFBiz
>
> If the data model is correctly defined, it should be:
>
> 4. origin "documents" (detail records) are associated with the transaction
>
> Sorry for the many questions, but I'm moving the information from the
> list to the Wiki page and I want to be sure I understand the design.
>
> Thanks,
>
> Jacopo
>
>
> David E Jones wrote:
>> 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
>>
>
>
>
>
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by BJ Freeman <bj...@free-man.net>.
before I put my two cents in I have searching the Internet and reading
where can I put links like
www.ofm.wa.gov/roadmap/modeling/generalledger/general_ledger_best_practices_summary.pdf
skip@nevertheless sent the following on 11/25/2007 11:07 AM:
> Jacopo
>
> I can answer for the productId part (I too do not understand having the
> partyId). Si, when he does the transaction for an an invoice, puts the
> individual InvoiceItems a separate AcctgTransEntry record. Then, you have
> only one AcctTrans record and multiple AcctgTransEntry records for the
> inventory part (the sales part is a second and separate transaction) of one
> invoice.
>
> More commonly, there is one post for the sum of the inventory items sold.
> However, this method offers some flexibility if you want to split up cost of
> goods or maybe you have separate inventory accounts for different inventory
> types. For that reason, I like it.
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:tiz@sastau.it]
> Sent: Sunday, November 25, 2007 1:00 AM
> To: dev@ofbiz.apache.org
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
> David,
>
> after reviewing the AcctgTrans and AcctgTransEntry entity I've noticed
> that fixedAssetId, inventoryItemId, physicalInventoryId, partyId,
> roleTypeId, invoiceId, paymentId, finAccountTransId, shipmentId,
> receiptId, workEffortId are in the AcctgTrans entity, while partyId and
> productId are defined in the AcctgTransEntry entity.
> This sounds slightly different from #4 in your notes:
>
> > 4. origin "documents" (detail records) are associated with the
> > transaction entry, and there are structures for this in OFBiz
>
> If the data model is correctly defined, it should be:
>
> 4. origin "documents" (detail records) are associated with the transaction
>
> Sorry for the many questions, but I'm moving the information from the
> list to the Wiki page and I want to be sure I understand the design.
>
> Thanks,
>
> Jacopo
>
>
> David E Jones wrote:
>> 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
>>
>
>
>
>
>
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
Jacopo
I can answer for the productId part (I too do not understand having the
partyId). Si, when he does the transaction for an an invoice, puts the
individual InvoiceItems a separate AcctgTransEntry record. Then, you have
only one AcctTrans record and multiple AcctgTransEntry records for the
inventory part (the sales part is a second and separate transaction) of one
invoice.
More commonly, there is one post for the sum of the inventory items sold.
However, this method offers some flexibility if you want to split up cost of
goods or maybe you have separate inventory accounts for different inventory
types. For that reason, I like it.
Skip
-----Original Message-----
From: Jacopo Cappellato [mailto:tiz@sastau.it]
Sent: Sunday, November 25, 2007 1:00 AM
To: dev@ofbiz.apache.org
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
David,
after reviewing the AcctgTrans and AcctgTransEntry entity I've noticed
that fixedAssetId, inventoryItemId, physicalInventoryId, partyId,
roleTypeId, invoiceId, paymentId, finAccountTransId, shipmentId,
receiptId, workEffortId are in the AcctgTrans entity, while partyId and
productId are defined in the AcctgTransEntry entity.
This sounds slightly different from #4 in your notes:
> 4. origin "documents" (detail records) are associated with the
> transaction entry, and there are structures for this in OFBiz
If the data model is correctly defined, it should be:
4. origin "documents" (detail records) are associated with the transaction
Sorry for the many questions, but I'm moving the information from the
list to the Wiki page and I want to be sure I understand the design.
Thanks,
Jacopo
David E Jones wrote:
>
> 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
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
David,
after reviewing the AcctgTrans and AcctgTransEntry entity I've noticed
that fixedAssetId, inventoryItemId, physicalInventoryId, partyId,
roleTypeId, invoiceId, paymentId, finAccountTransId, shipmentId,
receiptId, workEffortId are in the AcctgTrans entity, while partyId and
productId are defined in the AcctgTransEntry entity.
This sounds slightly different from #4 in your notes:
> 4. origin "documents" (detail records) are associated with the
> transaction entry, and there are structures for this in OFBiz
If the data model is correctly defined, it should be:
4. origin "documents" (detail records) are associated with the transaction
Sorry for the many questions, but I'm moving the information from the
list to the Wiki page and I want to be sure I understand the design.
Thanks,
Jacopo
David E Jones wrote:
>
> 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
>
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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:jonesde@hotwaxmedia.com]
Sent: Saturday, November 24, 2007 4:20 AM
To: dev@ofbiz.apache.org
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:jonesde@hotwaxmedia.com]
> Sent: Friday, November 23, 2007 6:20 PM
> To: dev@ofbiz.apache.org
> 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:tiz@sastau.it]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: dev@ofbiz.apache.org
>> 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
>>>
>>
>>
>
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jacques Le Roux wrote:
> De : "Jacopo Cappellato" <ti...@sastau.it>
>>> 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,
>
> Here I guess Jacopo you meant "I'd say that by default we should keep the accounting secas as sync,"
Yeah, you are right, thanks Jacques, and sorry for the confusion.
Jacopo
>
> Jacques
>
>> but some customer could change them to async.
>>
>> Does it make sense?
>>
>> Jacopo
>>
>>> Skip
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Jacopo Cappellato" <ti...@sastau.it>
> > 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,
Here I guess Jacopo you meant "I'd say that by default we should keep the accounting secas as sync,"
Jacques
> but some customer could change them to async.
>
> Does it make sense?
>
> Jacopo
>
> >
> > Skip
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
Yes,
this is the plan ;-)
As a next step in this effort, in my opinion we should make sure that
all the people interested in working on this are on the same wave... and
the best way of achieving this is to practice with the existing OFBiz GL
stuff (yeah, I know there is not too much at the moment).
For this reason, during the last few days, I've tried to clean up some
of the existing GL screens, and also implemented new stuff to make tests
easier.
Using the UI it should already be possible to:
1) browse all the existing accounts (see the "Chart of Accounts" menu);
these are all the accounts available in the system, but to before you
can do GL on an internal organization you have to associate the ones you
need to the organization
2) using the "Companies" menu, we can select the internal organization
we are interested in, and then in the "Setup" submenu we enter the setup
area: we associate the accounts to the organization, view defaults and
map (this will be important for automatic transaction posting) "accounts
types" to "accounts ids"
3) if, under the "Companies" menu, we select the "accounting" submenu we
can perform some GL tasks: search/view the "accounting transactions",
manually create new ones, search/view the "accounting transactions
entries" (D/C); there is also a very simple Trial Balance report... that
I'm proud of because it is completely written using widgets ;-)
We should all play with these screen because I'm sure that after this we
will have a better idea of how we can help, what we can do, how we can
test our work; and we should probably start thinking about
documenting/sharing some use cases/test data/for the upcoming
development effort.
Jacopo
skip@thedevers wrote:
> Perfect Jacopo
>
> And I learned something too. Sync calls are part of the begin/commit
> transaction and async calls are not. Thanks for the feedback.
>
> In this way, especially if we put all the seca definitions for accounting
> stuff in one file, people can just comment them out or uncomment them if
> they don't want or do want GL accounting done.
>
> Skip
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:tiz@sastau.it]
> Sent: Saturday, November 24, 2007 9:19 AM
> To: dev@ofbiz.apache.org
> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
>
>
> 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
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Nov 24, 2007, at 11:20 AM, skip@thedevers wrote:
> And I learned something too. Sync calls are part of the begin/commit
> transaction and async calls are not. Thanks for the feedback.
There is one exception to this: sync remote calls are not part of the
same transaction right now, even if the remote service is configured
to be called over RMI (definitely not for others like SOAP and such,
and I don't think we have implemented the tx token/etc for RMI).
-David
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
Perfect Jacopo
And I learned something too. Sync calls are part of the begin/commit
transaction and async calls are not. Thanks for the feedback.
In this way, especially if we put all the seca definitions for accounting
stuff in one file, people can just comment them out or uncomment them if
they don't want or do want GL accounting done.
Skip
-----Original Message-----
From: Jacopo Cappellato [mailto:tiz@sastau.it]
Sent: Saturday, November 24, 2007 9:19 AM
To: dev@ofbiz.apache.org
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
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
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: Billing Accounts
Posted by BJ Freeman <bj...@free-man.net>.
there was a lengthy discussion back in 2004 on accounting.
maybe you can pull all those up and get some concisions.'
unfortunately I change computers about 2005 and don't have those
archives handy.
skip@thedevers sent the following on 11/24/2007 9:16 PM:
> I just ran across this in the Wiki from David concerning Billing Accounts
> from back in July.
>
> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>
> The current Ofbiz implementation does not operate as described in this
> document. The "addon" I partially provided here:
>
> https://issues.apache.org/jira/browse/OFBIZ-1421
>
> follows it exactly or nearly so. Furthermore, the logic is so simple. It
> is a shame that billingAccountId ended up in so many entities.
>
> I think these paragraphs bear repeating because he says it so much better
> than me:
>
> "A BillingAccount is essentially nothing. Just forget that it exists in
> relation to regular Invoice and Payment processes. With or without a
> BillingAccount those operate and flow the same.
>
> A BillingAccount simply allows for more organization of Invoices and
> Payments related to things like the following (which is not an exhaustive
> list by any means):"
>
>
>
> Skip
>
>
>
>
Re: Billing Accounts
Posted by David E Jones <jo...@hotwaxmedia.com>.
I can see how this might be confusing. The status has nothing to do
with how much of the payment is applied.
The PMNT_CONFIRMED is the final status for payments sent (if a
confirmation is received, otherwise it is just the sent status;
depends on the company and supplier processes).
The PMNT_RECEIVED status is the final status for payments received.
For more info on these statuses and transitions between them see the
AccountingTypeData.xml file. This pattern is followed throughout OFBiz
for other status sets (one for each type basically).
-David
P.S. It's great to see your involvement and commentary and thoughts
Skip. You might have a better experience if you invested in a little
more study before trying to follow OFBiz... it really can be very
large and confusing if you don't have at least a basic grasp of some
of the patterns (this one is a good example). The best place to get
started, as I've mentioned in other emails, is these free videos and
supporting artifacts:
http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams
On Nov 25, 2007, at 3:58 PM, skip@thedevers wrote:
> David
>
> This "closed" is more of a programming construct than anything real,
> to me
> at least. The status is PMNT_CONFIRMED. PMNT_CONFIRMED cannot be
> set until
> the payment is fully applied, and once set to PMNT_CONFIRMED, payment
> applications cannot be removed. So to me, closed means
> PMNT_CONFIRMED.
>
> In Ofbiz, you cannot set the status to PMNT_CONFIRMED until the
> payment is
> fully applied. This means that if you apply some or all of it to a
> billing
> account, that part of the payment applied to the billing account
> goes out
> into space somewhere, i.e. cannot be applied to a real invoice at
> some later
> point.
>
> My new code has a service triggered by the creation of an invoice
> that goes
> out looking for unapplied payments (and these include credits from
> returns
> etc). If a payment has been applied to a billing account, it will
> not be
> found, so the customer ends up forever having paid some money that
> cannot be
> applied to an invoice, at least not without a lot of what would have
> been
> unnecessary code.
>
> An Invoice remains unpaid (not INVOICE_PAID) until it has a
> paymentapplication(s) to fully cover it. So the issue here is not so
> much
> with the Payment status, but with Invoice status and accounting for
> it and
> providing audit trails.
>
> It is for these reasons that I do not think it should be permitted
> to apply
> a payment to a billing account and why I agree with your statement "A
> BillingAccount is essentially nothing. Just forget that it exists in
> relation to regular Invoice and Payment processes."
>
> Customer payments should remain PMNT_RECEIVED (or something less)
> until
> fully applied to Invoices. For those users who don't want to
> manually apply
> a payment to Invoices one at a time, I have a service that will
> automatically apply a Payment to the oldest Invoice(s).
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Sunday, November 25, 2007 2:03 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Billing Accounts
>
>
>
> A Payment applied to a BillingAccount does not mean the payment is
> closed, in fact I'm not even sure what it means to say a payment is
> closed... did you have something in mind? Whatever it means to you, a
> payment is either not, partially, or fully applied.
>
> -David
>
>
> On Nov 25, 2007, at 11:54 AM, skip@thedevers wrote:
>
>> Jacapo
>>
>> https://localhost:8443/accounting/control/editPaymentApplications
>>
>> and one of them involves applying it to the billing account.
>>
>> I don't see the point in applying a payment to a billing account.
>> Otherwise, how to you know when an invoice is paid? What happens
>> later, do
>> you take the money out of the billing account and apply it to an
>> invoice?
>>
>> There may be some european need that I am not aware of to apply a
>> customer
>> payment to a Tax Authority, but that is not the case in the U.S, so
>> I don't
>> see the point in the Tax Auth Geo ID.
>>
>> The main one for me is applying a payment to a billing account. If
>> there
>> are no invoices to apply to, the Payment should stay open. It makes
>> everything else then so easy.
>>
>>
>> Skip
>>
>>
>>
>> -----Original Message-----
>> From: Jacopo Cappellato [mailto:tiz@sastau.it]
>> Sent: Saturday, November 24, 2007 11:45 PM
>> To: dev@ofbiz.apache.org
>> Subject: Re: Billing Accounts
>>
>>
>> Skip,
>>
>> I very well remember that valuable message from David: it helped me a
>> lot when I've recently refactored the billing accounts.
>> Where is the current implementation not following David's notes?
>>
>> Thanks,
>>
>> Jacopo
>>
>> skip@thedevers wrote:
>>> I just ran across this in the Wiki from David concerning Billing
>>> Accounts
>>> from back in July.
>>>
>>> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>>>
>>> The current Ofbiz implementation does not operate as described in
>>> this
>>> document. The "addon" I partially provided here:
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ-1421
>>>
>>> follows it exactly or nearly so. Furthermore, the logic is so
>>> simple. It
>>> is a shame that billingAccountId ended up in so many entities.
>>>
>>> I think these paragraphs bear repeating because he says it so much
>>> better
>>> than me:
>>>
>>> "A BillingAccount is essentially nothing. Just forget that it
>>> exists in
>>> relation to regular Invoice and Payment processes. With or without a
>>> BillingAccount those operate and flow the same.
>>>
>>> A BillingAccount simply allows for more organization of Invoices and
>>> Payments related to things like the following (which is not an
>>> exhaustive
>>> list by any means):"
>>>
>>>
>>>
>>> Skip
>>
>>
>>
>
>
RE: Billing Accounts
Posted by "skip@thedevers" <sk...@thedevers.org>.
David
This "closed" is more of a programming construct than anything real, to me
at least. The status is PMNT_CONFIRMED. PMNT_CONFIRMED cannot be set until
the payment is fully applied, and once set to PMNT_CONFIRMED, payment
applications cannot be removed. So to me, closed means PMNT_CONFIRMED.
In Ofbiz, you cannot set the status to PMNT_CONFIRMED until the payment is
fully applied. This means that if you apply some or all of it to a billing
account, that part of the payment applied to the billing account goes out
into space somewhere, i.e. cannot be applied to a real invoice at some later
point.
My new code has a service triggered by the creation of an invoice that goes
out looking for unapplied payments (and these include credits from returns
etc). If a payment has been applied to a billing account, it will not be
found, so the customer ends up forever having paid some money that cannot be
applied to an invoice, at least not without a lot of what would have been
unnecessary code.
An Invoice remains unpaid (not INVOICE_PAID) until it has a
paymentapplication(s) to fully cover it. So the issue here is not so much
with the Payment status, but with Invoice status and accounting for it and
providing audit trails.
It is for these reasons that I do not think it should be permitted to apply
a payment to a billing account and why I agree with your statement "A
BillingAccount is essentially nothing. Just forget that it exists in
relation to regular Invoice and Payment processes."
Customer payments should remain PMNT_RECEIVED (or something less) until
fully applied to Invoices. For those users who don't want to manually apply
a payment to Invoices one at a time, I have a service that will
automatically apply a Payment to the oldest Invoice(s).
Skip
-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Sunday, November 25, 2007 2:03 PM
To: dev@ofbiz.apache.org
Subject: Re: Billing Accounts
A Payment applied to a BillingAccount does not mean the payment is
closed, in fact I'm not even sure what it means to say a payment is
closed... did you have something in mind? Whatever it means to you, a
payment is either not, partially, or fully applied.
-David
On Nov 25, 2007, at 11:54 AM, skip@thedevers wrote:
> Jacapo
>
> https://localhost:8443/accounting/control/editPaymentApplications
>
> and one of them involves applying it to the billing account.
>
> I don't see the point in applying a payment to a billing account.
> Otherwise, how to you know when an invoice is paid? What happens
> later, do
> you take the money out of the billing account and apply it to an
> invoice?
>
> There may be some european need that I am not aware of to apply a
> customer
> payment to a Tax Authority, but that is not the case in the U.S, so
> I don't
> see the point in the Tax Auth Geo ID.
>
> The main one for me is applying a payment to a billing account. If
> there
> are no invoices to apply to, the Payment should stay open. It makes
> everything else then so easy.
>
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:tiz@sastau.it]
> Sent: Saturday, November 24, 2007 11:45 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Billing Accounts
>
>
> Skip,
>
> I very well remember that valuable message from David: it helped me a
> lot when I've recently refactored the billing accounts.
> Where is the current implementation not following David's notes?
>
> Thanks,
>
> Jacopo
>
> skip@thedevers wrote:
>> I just ran across this in the Wiki from David concerning Billing
>> Accounts
>> from back in July.
>>
>> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>>
>> The current Ofbiz implementation does not operate as described in
>> this
>> document. The "addon" I partially provided here:
>>
>> https://issues.apache.org/jira/browse/OFBIZ-1421
>>
>> follows it exactly or nearly so. Furthermore, the logic is so
>> simple. It
>> is a shame that billingAccountId ended up in so many entities.
>>
>> I think these paragraphs bear repeating because he says it so much
>> better
>> than me:
>>
>> "A BillingAccount is essentially nothing. Just forget that it
>> exists in
>> relation to regular Invoice and Payment processes. With or without a
>> BillingAccount those operate and flow the same.
>>
>> A BillingAccount simply allows for more organization of Invoices and
>> Payments related to things like the following (which is not an
>> exhaustive
>> list by any means):"
>>
>>
>>
>> Skip
>
>
>
Re: Billing Accounts
Posted by David E Jones <jo...@hotwaxmedia.com>.
A Payment applied to a BillingAccount does not mean the payment is
closed, in fact I'm not even sure what it means to say a payment is
closed... did you have something in mind? Whatever it means to you, a
payment is either not, partially, or fully applied.
-David
On Nov 25, 2007, at 11:54 AM, skip@thedevers wrote:
> Jacapo
>
> https://localhost:8443/accounting/control/editPaymentApplications
>
> and one of them involves applying it to the billing account.
>
> I don't see the point in applying a payment to a billing account.
> Otherwise, how to you know when an invoice is paid? What happens
> later, do
> you take the money out of the billing account and apply it to an
> invoice?
>
> There may be some european need that I am not aware of to apply a
> customer
> payment to a Tax Authority, but that is not the case in the U.S, so
> I don't
> see the point in the Tax Auth Geo ID.
>
> The main one for me is applying a payment to a billing account. If
> there
> are no invoices to apply to, the Payment should stay open. It makes
> everything else then so easy.
>
>
> Skip
>
>
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:tiz@sastau.it]
> Sent: Saturday, November 24, 2007 11:45 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Billing Accounts
>
>
> Skip,
>
> I very well remember that valuable message from David: it helped me a
> lot when I've recently refactored the billing accounts.
> Where is the current implementation not following David's notes?
>
> Thanks,
>
> Jacopo
>
> skip@thedevers wrote:
>> I just ran across this in the Wiki from David concerning Billing
>> Accounts
>> from back in July.
>>
>> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>>
>> The current Ofbiz implementation does not operate as described in
>> this
>> document. The "addon" I partially provided here:
>>
>> https://issues.apache.org/jira/browse/OFBIZ-1421
>>
>> follows it exactly or nearly so. Furthermore, the logic is so
>> simple. It
>> is a shame that billingAccountId ended up in so many entities.
>>
>> I think these paragraphs bear repeating because he says it so much
>> better
>> than me:
>>
>> "A BillingAccount is essentially nothing. Just forget that it
>> exists in
>> relation to regular Invoice and Payment processes. With or without a
>> BillingAccount those operate and flow the same.
>>
>> A BillingAccount simply allows for more organization of Invoices and
>> Payments related to things like the following (which is not an
>> exhaustive
>> list by any means):"
>>
>>
>>
>> Skip
>
>
>
RE: Billing Accounts
Posted by "skip@thedevers" <sk...@thedevers.org>.
Jacapo
https://localhost:8443/accounting/control/editPaymentApplications
and one of them involves applying it to the billing account.
I don't see the point in applying a payment to a billing account.
Otherwise, how to you know when an invoice is paid? What happens later, do
you take the money out of the billing account and apply it to an invoice?
There may be some european need that I am not aware of to apply a customer
payment to a Tax Authority, but that is not the case in the U.S, so I don't
see the point in the Tax Auth Geo ID.
The main one for me is applying a payment to a billing account. If there
are no invoices to apply to, the Payment should stay open. It makes
everything else then so easy.
Skip
-----Original Message-----
From: Jacopo Cappellato [mailto:tiz@sastau.it]
Sent: Saturday, November 24, 2007 11:45 PM
To: dev@ofbiz.apache.org
Subject: Re: Billing Accounts
Skip,
I very well remember that valuable message from David: it helped me a
lot when I've recently refactored the billing accounts.
Where is the current implementation not following David's notes?
Thanks,
Jacopo
skip@thedevers wrote:
> I just ran across this in the Wiki from David concerning Billing Accounts
> from back in July.
>
> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>
> The current Ofbiz implementation does not operate as described in this
> document. The "addon" I partially provided here:
>
> https://issues.apache.org/jira/browse/OFBIZ-1421
>
> follows it exactly or nearly so. Furthermore, the logic is so simple. It
> is a shame that billingAccountId ended up in so many entities.
>
> I think these paragraphs bear repeating because he says it so much better
> than me:
>
> "A BillingAccount is essentially nothing. Just forget that it exists in
> relation to regular Invoice and Payment processes. With or without a
> BillingAccount those operate and flow the same.
>
> A BillingAccount simply allows for more organization of Invoices and
> Payments related to things like the following (which is not an exhaustive
> list by any means):"
>
>
>
> Skip
Re: Billing Accounts
Posted by Jacopo Cappellato <ti...@sastau.it>.
Skip,
I very well remember that valuable message from David: it helped me a
lot when I've recently refactored the billing accounts.
Where is the current implementation not following David's notes?
Thanks,
Jacopo
skip@thedevers wrote:
> I just ran across this in the Wiki from David concerning Billing Accounts
> from back in July.
>
> http://docs.ofbiz.org/display/OFBIZ/Billing+Account
>
> The current Ofbiz implementation does not operate as described in this
> document. The "addon" I partially provided here:
>
> https://issues.apache.org/jira/browse/OFBIZ-1421
>
> follows it exactly or nearly so. Furthermore, the logic is so simple. It
> is a shame that billingAccountId ended up in so many entities.
>
> I think these paragraphs bear repeating because he says it so much better
> than me:
>
> "A BillingAccount is essentially nothing. Just forget that it exists in
> relation to regular Invoice and Payment processes. With or without a
> BillingAccount those operate and flow the same.
>
> A BillingAccount simply allows for more organization of Invoices and
> Payments related to things like the following (which is not an exhaustive
> list by any means):"
>
>
>
> Skip
Billing Accounts
Posted by "skip@thedevers" <sk...@thedevers.org>.
I just ran across this in the Wiki from David concerning Billing Accounts
from back in July.
http://docs.ofbiz.org/display/OFBIZ/Billing+Account
The current Ofbiz implementation does not operate as described in this
document. The "addon" I partially provided here:
https://issues.apache.org/jira/browse/OFBIZ-1421
follows it exactly or nearly so. Furthermore, the logic is so simple. It
is a shame that billingAccountId ended up in so many entities.
I think these paragraphs bear repeating because he says it so much better
than me:
"A BillingAccount is essentially nothing. Just forget that it exists in
relation to regular Invoice and Payment processes. With or without a
BillingAccount those operate and flow the same.
A BillingAccount simply allows for more organization of Invoices and
Payments related to things like the following (which is not an exhaustive
list by any means):"
Skip
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacques Le Roux <ja...@les7arts.com>.
This begins to sounds quite right :o)
Jacques
De : "David E Jones" <jo...@hotwaxmedia.com>
>
> On Nov 24, 2007, at 1:05 PM, Jacopo Cappellato wrote:
>
> > David E Jones wrote:
> >> On Nov 24, 2007, at 9:55 AM, 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.
> >> What I'd prefer to see happen (by default anyway...) is that if the
> >> GL posting fails for some reason the triggering operation
> >> (finalizing an invoice or payment or whatever) would NOT roll back,
> >> instead the partial GL post would be places into an error journal
> >> (if that failed, then a general error resulting in rollback would
> >> be appropriate).
> >> -David
> >
> > This would be optimal.
> >
> > David, how do you think we can specify the error journal for a
> > company (or other types of journals)? Should we implement an entity
> > similar to GlAccountTypeDefault?
>
> I guess it depends on if we want to implement one error journal per
> organization, of if we want more than one so we could have different
> error journals for different accounts or somethings too.
>
> Initially I'd say just one because even if someone wants to implement
> the many most companies should do fine with the one.
>
> For the one the errorGlJournalId or whatever could just go on the
> organization accounting prefs entity (can't remember the exact name of
> that one off the top of my head right now).
>
> -David
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
I would say that the error journal should be a match of the
AcctgTrans/AcctgTransEntry set so that when the errors were corrected, they
could be easily moved.
Skip
-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Saturday, November 24, 2007 12:09 PM
To: dev@ofbiz.apache.org
Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
On Nov 24, 2007, at 1:05 PM, Jacopo Cappellato wrote:
> David E Jones wrote:
>> On Nov 24, 2007, at 9:55 AM, 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.
>> What I'd prefer to see happen (by default anyway...) is that if the
>> GL posting fails for some reason the triggering operation
>> (finalizing an invoice or payment or whatever) would NOT roll back,
>> instead the partial GL post would be places into an error journal
>> (if that failed, then a general error resulting in rollback would
>> be appropriate).
>> -David
>
> This would be optimal.
>
> David, how do you think we can specify the error journal for a
> company (or other types of journals)? Should we implement an entity
> similar to GlAccountTypeDefault?
I guess it depends on if we want to implement one error journal per
organization, of if we want more than one so we could have different
error journals for different accounts or somethings too.
Initially I'd say just one because even if someone wants to implement
the many most companies should do fine with the one.
For the one the errorGlJournalId or whatever could just go on the
organization accounting prefs entity (can't remember the exact name of
that one off the top of my head right now).
-David
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Nov 24, 2007, at 1:05 PM, Jacopo Cappellato wrote:
> David E Jones wrote:
>> On Nov 24, 2007, at 9:55 AM, 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.
>> What I'd prefer to see happen (by default anyway...) is that if the
>> GL posting fails for some reason the triggering operation
>> (finalizing an invoice or payment or whatever) would NOT roll back,
>> instead the partial GL post would be places into an error journal
>> (if that failed, then a general error resulting in rollback would
>> be appropriate).
>> -David
>
> This would be optimal.
>
> David, how do you think we can specify the error journal for a
> company (or other types of journals)? Should we implement an entity
> similar to GlAccountTypeDefault?
I guess it depends on if we want to implement one error journal per
organization, of if we want more than one so we could have different
error journals for different accounts or somethings too.
Initially I'd say just one because even if someone wants to implement
the many most companies should do fine with the one.
For the one the errorGlJournalId or whatever could just go on the
organization accounting prefs entity (can't remember the exact name of
that one off the top of my head right now).
-David
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
David E Jones wrote:
>
> On Nov 24, 2007, at 9:55 AM, 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.
>
> What I'd prefer to see happen (by default anyway...) is that if the GL
> posting fails for some reason the triggering operation (finalizing an
> invoice or payment or whatever) would NOT roll back, instead the partial
> GL post would be places into an error journal (if that failed, then a
> general error resulting in rollback would be appropriate).
>
> -David
>
This would be optimal.
David, how do you think we can specify the error journal for a company
(or other types of journals)? Should we implement an entity similar to
GlAccountTypeDefault?
I'm asking you this because I'd like to wrap up the initial support for
journals, but I'm not sure I've still understood the main picture.
Thanks,
Jacopo
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Nov 24, 2007, at 9:55 AM, 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.
What I'd prefer to see happen (by default anyway...) is that if the GL
posting fails for some reason the triggering operation (finalizing an
invoice or payment or whatever) would NOT roll back, instead the
partial GL post would be places into an error journal (if that failed,
then a general error resulting in rollback would be appropriate).
-David
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
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:jonesde@hotwaxmedia.com]
> Sent: Friday, November 23, 2007 6:20 PM
> To: dev@ofbiz.apache.org
> 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:tiz@sastau.it]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: dev@ofbiz.apache.org
>> 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
>>>
>>
>>
>
>
Re: JFreeChart
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Jacopo Cappellato" <ti...@sastau.it>
> 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
>
RE: JFreeChart
Posted by "skip@thedevers" <sk...@thedevers.org>.
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
Re: JFreeChart
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
Re: JFreeChart
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: JFreeChart
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "skip@thedevers" <sk...@thedevers.org>
> 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
>
JFreeChart
Posted by "skip@thedevers" <sk...@thedevers.org>.
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
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
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:jonesde@hotwaxmedia.com]
> Sent: Friday, November 23, 2007 6:20 PM
> To: dev@ofbiz.apache.org
> 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:tiz@sastau.it]
>> Sent: Friday, November 23, 2007 2:40 AM
>> To: dev@ofbiz.apache.org
>> 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
>>>
>>
>
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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:jonesde@hotwaxmedia.com]
Sent: Friday, November 23, 2007 6:20 PM
To: dev@ofbiz.apache.org
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:tiz@sastau.it]
> Sent: Friday, November 23, 2007 2:40 AM
> To: dev@ofbiz.apache.org
> 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
>>
>
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
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:tiz@sastau.it]
> Sent: Friday, November 23, 2007 2:40 AM
> To: dev@ofbiz.apache.org
> 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
>>
>
>
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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:tiz@sastau.it]
Sent: Friday, November 23, 2007 2:40 AM
To: dev@ofbiz.apache.org
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
>
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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:jonesde@hotwaxmedia.com]
Sent: Thursday, November 22, 2007 11:31 PM
To: dev@ofbiz.apache.org
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
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Posted by "skip@thedevers" <sk...@thedevers.org>.
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:tiz@sastau.it]
Sent: Thursday, November 22, 2007 10:38 PM
To: user@ofbiz.apache.org; dev@ofbiz.apache.org
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 <jo...@hotwaxmedia.com> 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 <bj...@free-man.net> 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
>>>>> Users@lists.ofbiz.org
>>>>> http://lists.ofbiz.org/mailman/listinfo/users
>>>
>>>
>>> --
>>> James A Barrows
>>
>
>
>