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

[SkipDever]

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:[hidden email]]
Sent: Saturday, November 24, 2007 9:19 AM
To: [hidden email]
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

[Jacopo Cappellato]

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:[hidden email]]
> Sent: Saturday, November 24, 2007 9:19 AM
> To: [hidden email]
> 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
>

[David E Jones]

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

[David E Jones]

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

[Jacopo Cappellato]

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

[David E Jones]

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

[Jacques Le Roux]

De : "skip@thedevers" <[hidden email]>
[...]
>
> 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

[Jacques Le Roux]

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

> > 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
>

[Jacques Le Roux]

This begins to sounds quite right :o)

Jacques

De : "David E Jones" <[hidden email]>

>
> 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

[SkipDever]

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:[hidden email]]
Sent: Saturday, November 24, 2007 12:09 PM
To: [hidden email]
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

[SkipDever]

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

[BJ Freeman]

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
>
>
>
>

[Jacopo Cappellato]

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

[Jacopo Cappellato]

Jacques Le Roux wrote:

> De : "Jacopo Cappellato" <[hidden email]>
>>> 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

[Jacopo Cappellato]

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

[Trasca Virgil]

Hi,

     Open source java solutions.

1) http://java-source.net/open-source/charting-and-reporting. jCharts seems to be good and has a very libertine license.

 or

2) javascript chart solution which has Ajax mochikit javascript framework as dependency.

http://www.liquidx.net/plotkit/

or

3) from the ASF apache.org

http://myfaces.apache.org/trinidad/devguide/chart.html


Hope it will help,
Virgil

----- Original Message ----
From: "skip@thedevers" <[hidden email]>
To: [hidden email]
Sent: Saturday, November 24, 2007 8:37:36 AM
Subject: JFreeChart


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

[Jacopo Cappellato]

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
>

[Jacques Le Roux]

Hi Jacopo,

De : "Jacopo Cappellato" <[hidden email]>
> 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
>

[Jacques Le Roux]

Thanks Virgil,

Skip, I'm not sure there is all you need but Trinidad demo looks great :
http://www.irian.at/trinidad-demo/faces/components/chart.jspx and it's an Apache project. I don' t know how it's organised but we
may embed it in OFBiz if using only some jars is possible.

http://www.liquidx.net/plotkit/ is less appealing IMHO

I did not found any example for jCharts

Jacques

De : "Trasca Virgil" <[hidden email]>

> Hi,
>
>      Open source java solutions.
>
> 1) http://java-source.net/open-source/charting-and-reporting. jCharts seems to be good and has a very libertine license.
>
>  or
>
> 2) javascript chart solution which has Ajax mochikit javascript framework as dependency.
>
> http://www.liquidx.net/plotkit/
>
> or
>
> 3) from the ASF apache.org
>
> http://myfaces.apache.org/trinidad/devguide/chart.html
>
>
> Hope it will help,
> Virgil
>
> ----- Original Message ----
> From: "skip@thedevers" <[hidden email]>
> To: [hidden email]
> Sent: Saturday, November 24, 2007 8:37:36 AM
> Subject: JFreeChart
>
>
> 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
>
>
>
>

[SkipDever]

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:[hidden email]]
Sent: Saturday, November 24, 2007 11:45 PM
To: [hidden email]
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