OFBiz › OFBiz - Dev

Accounts Receivable

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

SkipDever

RE: Accounts Receivable

Thank you sir.

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: Friday, November 02, 2007 12:54 PM
To: [hidden email]
Subject: Re: Accounts Receivable

Here's the diff:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/src/org/ofbiz/or
der/shoppingcart/CheckOutHelper.java?r1=591283&r2=591282&pathrev=591283

Regards
Scott

On 03/11/2007, skip@theDevers <[hidden email]> wrote:

> Scott
>
> Can you tell me what files were affected? I want to move this fix into my
> production code, but not the whole 591434 svn download.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Friday, November 02, 2007 2:47 AM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> Found and fixed the problem in rev. 591283, quick checkout wasn't
> recalculating shipping and taxes before loading the payment info.
>
> Regards
> Scott
>
> On 02/11/2007, Scott Gray <[hidden email]> wrote:
> > Hi Skip, Jacopo
> >
> > >There are flaws
> > >and complications in the latter in that tax and shipping are not taken
> into
> > >account and shipping charges added later seem to be ignored.
> >
> > I'm just noticing this too, I've got a few orders showing up that have
> > maxAmount set less than the order grand total, that's a bug right?
> >
> > Thanks
> > Scott
> >
> > On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
> > > Hi Skip,
> > >
> > > this looks interesting.
> > > However, from your message, it is not completely clear to me when you
> > > speak about existing features/issues or new features (and issues?) in
> > > your upcoming contribution.
> > >
> > > It would be great if you could split the message into two parts:
> > > 1) one that describes the current situation with focus on possible
> issues
> > > 2) one with your proposal and suggested changes; (and also with new
> > > issues, if there are any)
> > >
> > > This would help a lot to simplify the discussion.
> > >
> > > Thanks,
> > >
> > > Jacopo
> > >
> > >
> > > skip@theDevers wrote:
> > > > I have this mostly working now and I want to run this past you guys

to
> be
> > > > sure there are no objections or thoughts on the methods used. I
would

> be
> > > > especially interested in hereing about any testing in out-of=the=way
> areas I
> > > > need to do.
> > > >
> > > > 1. First, billing accounts are based entirely on the existance of
> Payments
> > > > and Invoices against the billing account (we also take into account
> unbilled
> > > > Orders for available balance computations). We do not use
> > > > PaymentApplication alone or OrderPaymentPreference at all. There

are
> flaws
> > > > and complications in the latter in that tax and shipping are not
taken

> into
> > > > account and shipping charges added later seem to be ignored.
> > > >
> > > > 2. A customer can have multiple billing accounts.
> > > >
> > > > 3. Billing account net balance is the sum of the unpaid portion of
> all
> > > > Invoices against the billing account (including any credits).
> > > >
> > > > 3. Billing account available balance is the billing account limit -
> ((sum
> > > > of unpaid porting of invoices) + (unbilled Orders))
> > > > This has a flaw TODO (I think) in that if an Order is created
> with back
> > > > orders on it and part has been shipped and an invoice created for

that
> part,
> > > > the whole Order will still subtract from the available balance.
> > > >
> > > > 4. When payments are made, they are never applied to just the
billing

> > > > account. They are applied to an invoice belonging to the billing
> account.
> > > > If there is an unapplied balance, a new credit Invoice is created to
> hold
> > > > the unapplied balance.
> > > >
> > > > This all works with Ofbiz code if I manually apply the payments to
> invoices.
> > > > There are many other possible ways to create a billing account
> > > > payment/application and I would have to remove them all except for

one
> which
> > > > calls my new receiveBillingAccountPayment() service and
automatically
> > > > applies the payment to the oldest invoice(s).
> > > >
> > > > This also works with opentaps code if I comment out Si's
> > > > captureBillingAccountPayments and let the Ofbiz service run. There
is
> one
> > > > screen to change in Opentaps code in viewCustomerBillAcct."Customer
> Billing
> > > > Account Transactions" where outstanding invoices are not being
> displayed. I
> > > > also had to modify the Opentaps ftl calls to com.openstragegies.xxx
to
> call
> > > > the same named (and modified) Ofbiz routines.
> > > >
> > > > TODO is a SECA to automatically apply any available credits when a
new

> > > > billing account invoice is created.
> > > >
> > > > Can anyone see any holes in this or have any comments?
> > > >
> > > > Skip
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Scott Gray [mailto:[hidden email]]
> > > > Sent: Thursday, November 01, 2007 3:43 AM
> > > > To: [hidden email]
> > > > Subject: Re: Accounts Receivable
> > > >
> > > >
> > > > Yeah I guess it would help with that, although you still could still
> > > > pay an invoice directly with it (no billingAccountId on the

Invoice),

> > > > but you couldn't associate the Payment with more than one billing
> > > > account unless you went for a many to many relationship. But that's
> > > > fine, I just thought I'd ask as it was the first thing I saw that
> > > > didn't make sense to me.
> > > >
> > > > Thanks
> > > > Scott
> > > >
> > > > On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
> > > >> Hi Scott,
> > > >>
> > > >> Scott Gray wrote:
> > > >>> Hi Jacopo
> > > >>>
> > > >>> I decided to have a look at this stuff and it doesn't make sense

to
> me
> > > >>> why we have the billingAccountId on PaymentApplication rather than
> on
> > > >>> Payment itself?
> > > >> I agree with you that having the billingAccountId in the Payment
> entity
> > > >> would have made things simpler. I did not design this, it was
already
> > > >> there when I've refactored/fixed the billing account processes.
> > > >> However, having the billingAccountId in the PaymentApplication
> improve
> > > >> the flexibility: I could receive a Payment and use one part of it
to

> pay
> > > >> an invoice (not associated to a billing account) and use the
> remaining
> > > >> to 'fill' a billing account.
> > > >>
> > > >> Jacopo
> > > >>
> > > >>> It seems like the logic is pretty much the same
> > > >>> except we're doing it in a roundabout sort of way by creating a
> > > >>> PaymentApplication with null invoiceId just to maintain the link.
> > > >>>
> > > >>> Thanks
> > > >>> Scott
> > > >>>
> > >
> > >
> > >
> >
>
>

SkipDever

RE: Accounts Receivable

In reply to this post by Scott Gray

Scott

In my view, this is kinda the hard way of doing things.

Easy way:

billing account amount = SUM(unpaid invoice amounts)
billing account available balance = billing acount limit - (billing account
amount + uninvoiced orders)

Because customer returns and credits also generate an invoice, this all
works.

Simple as long as you can determine which invoices are unpaid. Of course,
If you are gonna do a proper customer billing statement, you have to know
this anyway.

I have no idea why you guys feel the need to cling to this
OrderPaymentPreferences entity for computing billing accounts.

Skip

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: Friday, November 02, 2007 1:02 PM
To: [hidden email]
Subject: Re: Accounts Receivable

Hrmm that is a bit of problem, perhaps instead of using maxAmount we
should do this:
billing account amount = order grand total -
SUM(otherPaymentPrefs.maxAmount)
We could probably still use maxAmount for storing the calculated
value, but put a seca on resetGrandTotal to recalculate it each time
the order changes?

That way whatever isn't being paid for with other means goes on to the
billing account.

Does anyone know what the use case is for letting a user set the
amount to be billed to the billing account?

Scott

On 03/11/2007, skip@theDevers <[hidden email]> wrote:
> Thats part of the bug Scott. This is set at sale time. However, if you
do

> not do a quick ship (use the Facilities shipping) and you add freight
> charges later, these are not accounted for in the OrderPaymentPreferences.
>
> I have been arguing that while convenient, OrderPaymentPreferences is not
> the data underlying billing account.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Thursday, November 01, 2007 11:48 PM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> Hi Skip, Jacopo
>
> >There are flaws
> >and complications in the latter in that tax and shipping are not taken

into

> >account and shipping charges added later seem to be ignored.
>
> I'm just noticing this too, I've got a few orders showing up that have
> maxAmount set less than the order grand total, that's a bug right?
>
> Thanks
> Scott
>
> On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
> > Hi Skip,
> >
> > this looks interesting.
> > However, from your message, it is not completely clear to me when you
> > speak about existing features/issues or new features (and issues?) in
> > your upcoming contribution.
> >
> > It would be great if you could split the message into two parts:
> > 1) one that describes the current situation with focus on possible

issues

> > 2) one with your proposal and suggested changes; (and also with new
> > issues, if there are any)
> >
> > This would help a lot to simplify the discussion.
> >
> > Thanks,
> >
> > Jacopo
> >
> >
> > skip@theDevers wrote:
> > > I have this mostly working now and I want to run this past you guys to
> be
> > > sure there are no objections or thoughts on the methods used. I would
> be
> > > especially interested in hereing about any testing in out-of=the=way
> areas I
> > > need to do.
> > >
> > > 1. First, billing accounts are based entirely on the existance of
> Payments
> > > and Invoices against the billing account (we also take into account
> unbilled
> > > Orders for available balance computations). We do not use
> > > PaymentApplication alone or OrderPaymentPreference at all. There are
> flaws
> > > and complications in the latter in that tax and shipping are not taken
> into
> > > account and shipping charges added later seem to be ignored.
> > >
> > > 2. A customer can have multiple billing accounts.
> > >
> > > 3. Billing account net balance is the sum of the unpaid portion of

all
> > > Invoices against the billing account (including any credits).
> > >
> > > 3. Billing account available balance is the billing account limit -
> ((sum
> > > of unpaid porting of invoices) + (unbilled Orders))
> > > This has a flaw TODO (I think) in that if an Order is created
with

> back
> > > orders on it and part has been shipped and an invoice created for that
> part,
> > > the whole Order will still subtract from the available balance.
> > >
> > > 4. When payments are made, they are never applied to just the billing
> > > account. They are applied to an invoice belonging to the billing
> account.
> > > If there is an unapplied balance, a new credit Invoice is created to
> hold
> > > the unapplied balance.
> > >
> > > This all works with Ofbiz code if I manually apply the payments to
> invoices.
> > > There are many other possible ways to create a billing account
> > > payment/application and I would have to remove them all except for one
> which
> > > calls my new receiveBillingAccountPayment() service and automatically
> > > applies the payment to the oldest invoice(s).
> > >
> > > This also works with opentaps code if I comment out Si's
> > > captureBillingAccountPayments and let the Ofbiz service run. There is
> one
> > > screen to change in Opentaps code in viewCustomerBillAcct."Customer
> Billing
> > > Account Transactions" where outstanding invoices are not being
> displayed. I
> > > also had to modify the Opentaps ftl calls to com.openstragegies.xxx to
> call
> > > the same named (and modified) Ofbiz routines.
> > >
> > > TODO is a SECA to automatically apply any available credits when a new
> > > billing account invoice is created.
> > >
> > > Can anyone see any holes in this or have any comments?
> > >
> > > Skip
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Gray [mailto:[hidden email]]
> > > Sent: Thursday, November 01, 2007 3:43 AM
> > > To: [hidden email]
> > > Subject: Re: Accounts Receivable
> > >
> > >
> > > Yeah I guess it would help with that, although you still could still
> > > pay an invoice directly with it (no billingAccountId on the Invoice),
> > > but you couldn't associate the Payment with more than one billing
> > > account unless you went for a many to many relationship. But that's
> > > fine, I just thought I'd ask as it was the first thing I saw that
> > > didn't make sense to me.
> > >
> > > Thanks
> > > Scott
> > >
> > > On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
> > >> Hi Scott,
> > >>
> > >> Scott Gray wrote:
> > >>> Hi Jacopo
> > >>>
> > >>> I decided to have a look at this stuff and it doesn't make sense to

me
> > >>> why we have the billingAccountId on PaymentApplication rather than
on
> > >>> Payment itself?
> > >> I agree with you that having the billingAccountId in the Payment
entity
> > >> would have made things simpler. I did not design this, it was already
> > >> there when I've refactored/fixed the billing account processes.
> > >> However, having the billingAccountId in the PaymentApplication
improve
> > >> the flexibility: I could receive a Payment and use one part of it to
> pay
> > >> an invoice (not associated to a billing account) and use the
remaining

> > >> to 'fill' a billing account.
> > >>
> > >> Jacopo
> > >>
> > >>> It seems like the logic is pretty much the same
> > >>> except we're doing it in a roundabout sort of way by creating a
> > >>> PaymentApplication with null invoiceId just to maintain the link.
> > >>>
> > >>> Thanks
> > >>> Scott
> > >>>
> >
> >
> >
>
>

BJ Freeman

Re: Accounts Receivable

skip how does this fit with GL and transactions.

skip@theDevers sent the following on 11/2/2007 12:58 PM:

> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amounts)
> billing account available balance = billing acount limit - (billing account
> amount + uninvoiced orders)
>
> Because customer returns and credits also generate an invoice, this all
> works.
>
> Simple as long as you can determine which invoices are unpaid. Of course,
> If you are gonna do a proper customer billing statement, you have to know
> this anyway.
>
> I have no idea why you guys feel the need to cling to this
> OrderPaymentPreferences entity for computing billing accounts.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Friday, November 02, 2007 1:02 PM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> Hrmm that is a bit of problem, perhaps instead of using maxAmount we
> should do this:
> billing account amount = order grand total -
> SUM(otherPaymentPrefs.maxAmount)
> We could probably still use maxAmount for storing the calculated
> value, but put a seca on resetGrandTotal to recalculate it each time
> the order changes?
>
> That way whatever isn't being paid for with other means goes on to the
> billing account.
>
> Does anyone know what the use case is for letting a user set the
> amount to be billed to the billing account?
>
> Scott
>
> On 03/11/2007, skip@theDevers <[hidden email]> wrote:
>> Thats part of the bug Scott. This is set at sale time. However, if you
> do
>> not do a quick ship (use the Facilities shipping) and you add freight
>> charges later, these are not accounted for in the OrderPaymentPreferences.
>>
>> I have been arguing that while convenient, OrderPaymentPreferences is not
>> the data underlying billing account.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Scott Gray [mailto:[hidden email]]
>> Sent: Thursday, November 01, 2007 11:48 PM
>> To: [hidden email]
>> Subject: Re: Accounts Receivable
>>
>>
>> Hi Skip, Jacopo
>>
>>> There are flaws
>>> and complications in the latter in that tax and shipping are not taken
> into
>>> account and shipping charges added later seem to be ignored.
>> I'm just noticing this too, I've got a few orders showing up that have
>> maxAmount set less than the order grand total, that's a bug right?
>>
>> Thanks
>> Scott
>>
>> On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>> Hi Skip,
>>>
>>> this looks interesting.
>>> However, from your message, it is not completely clear to me when you
>>> speak about existing features/issues or new features (and issues?) in
>>> your upcoming contribution.
>>>
>>> It would be great if you could split the message into two parts:
>>> 1) one that describes the current situation with focus on possible
> issues
>>> 2) one with your proposal and suggested changes; (and also with new
>>> issues, if there are any)
>>>
>>> This would help a lot to simplify the discussion.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>>> skip@theDevers wrote:
>>>> I have this mostly working now and I want to run this past you guys to
>> be
>>>> sure there are no objections or thoughts on the methods used. I would
>> be
>>>> especially interested in hereing about any testing in out-of=the=way
>> areas I
>>>> need to do.
>>>>
>>>> 1. First, billing accounts are based entirely on the existance of
>> Payments
>>>> and Invoices against the billing account (we also take into account
>> unbilled
>>>> Orders for available balance computations). We do not use
>>>> PaymentApplication alone or OrderPaymentPreference at all. There are
>> flaws
>>>> and complications in the latter in that tax and shipping are not taken
>> into
>>>> account and shipping charges added later seem to be ignored.
>>>>
>>>> 2. A customer can have multiple billing accounts.
>>>>
>>>> 3. Billing account net balance is the sum of the unpaid portion of
> all
>>>> Invoices against the billing account (including any credits).
>>>>
>>>> 3. Billing account available balance is the billing account limit -
>> ((sum
>>>> of unpaid porting of invoices) + (unbilled Orders))
>>>> This has a flaw TODO (I think) in that if an Order is created
> with
>> back
>>>> orders on it and part has been shipped and an invoice created for that
>> part,
>>>> the whole Order will still subtract from the available balance.
>>>>
>>>> 4. When payments are made, they are never applied to just the billing
>>>> account. They are applied to an invoice belonging to the billing
>> account.
>>>> If there is an unapplied balance, a new credit Invoice is created to
>> hold
>>>> the unapplied balance.
>>>>
>>>> This all works with Ofbiz code if I manually apply the payments to
>> invoices.
>>>> There are many other possible ways to create a billing account
>>>> payment/application and I would have to remove them all except for one
>> which
>>>> calls my new receiveBillingAccountPayment() service and automatically
>>>> applies the payment to the oldest invoice(s).
>>>>
>>>> This also works with opentaps code if I comment out Si's
>>>> captureBillingAccountPayments and let the Ofbiz service run. There is
>> one
>>>> screen to change in Opentaps code in viewCustomerBillAcct."Customer
>> Billing
>>>> Account Transactions" where outstanding invoices are not being
>> displayed. I
>>>> also had to modify the Opentaps ftl calls to com.openstragegies.xxx to
>> call
>>>> the same named (and modified) Ofbiz routines.
>>>>
>>>> TODO is a SECA to automatically apply any available credits when a new
>>>> billing account invoice is created.
>>>>
>>>> Can anyone see any holes in this or have any comments?
>>>>
>>>> Skip
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Scott Gray [mailto:[hidden email]]
>>>> Sent: Thursday, November 01, 2007 3:43 AM
>>>> To: [hidden email]
>>>> Subject: Re: Accounts Receivable
>>>>
>>>>
>>>> Yeah I guess it would help with that, although you still could still
>>>> pay an invoice directly with it (no billingAccountId on the Invoice),
>>>> but you couldn't associate the Payment with more than one billing
>>>> account unless you went for a many to many relationship. But that's
>>>> fine, I just thought I'd ask as it was the first thing I saw that
>>>> didn't make sense to me.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>>> Hi Scott,
>>>>>
>>>>> Scott Gray wrote:
>>>>>> Hi Jacopo
>>>>>>
>>>>>> I decided to have a look at this stuff and it doesn't make sense to
> me
>>>>>> why we have the billingAccountId on PaymentApplication rather than
> on
>>>>>> Payment itself?
>>>>> I agree with you that having the billingAccountId in the Payment
> entity
>>>>> would have made things simpler. I did not design this, it was already
>>>>> there when I've refactored/fixed the billing account processes.
>>>>> However, having the billingAccountId in the PaymentApplication
> improve
>>>>> the flexibility: I could receive a Payment and use one part of it to
>> pay
>>>>> an invoice (not associated to a billing account) and use the
> remaining
>>>>> to 'fill' a billing account.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> It seems like the logic is pretty much the same
>>>>>> except we're doing it in a roundabout sort of way by creating a
>>>>>> PaymentApplication with null invoiceId just to maintain the link.
>>>>>>
>>>>>> Thanks
>>>>>> Scott
>>>>>>
>>>
>>>
>>
>
>
>
>

SkipDever

RE: Accounts Receivable

Should not be related. What goes into the GL is separate from AR issues.
You should be able to run Ofbiz without a GL if you want.

On the other hand, each of these transactions is a GL candidate.

Si Chen has in fact created a way to report on customer accounts by reading
the transactions out of one of the Acctxxx entities (I forget which one) and
it works. However, it does not and could never provide the detail normally
required for adequate reporting to the customer.

Skip

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Friday, November 02, 2007 7:27 PM
To: [hidden email]
Subject: Re: Accounts Receivable

skip how does this fit with GL and transactions.

skip@theDevers sent the following on 11/2/2007 12:58 PM:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amounts)
> billing account available balance = billing acount limit - (billing
account

> amount + uninvoiced orders)
>
> Because customer returns and credits also generate an invoice, this all
> works.
>
> Simple as long as you can determine which invoices are unpaid. Of course,
> If you are gonna do a proper customer billing statement, you have to know
> this anyway.
>
> I have no idea why you guys feel the need to cling to this
> OrderPaymentPreferences entity for computing billing accounts.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Friday, November 02, 2007 1:02 PM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> Hrmm that is a bit of problem, perhaps instead of using maxAmount we
> should do this:
> billing account amount = order grand total -
> SUM(otherPaymentPrefs.maxAmount)
> We could probably still use maxAmount for storing the calculated
> value, but put a seca on resetGrandTotal to recalculate it each time
> the order changes?
>
> That way whatever isn't being paid for with other means goes on to the
> billing account.
>
> Does anyone know what the use case is for letting a user set the
> amount to be billed to the billing account?
>
> Scott
>
> On 03/11/2007, skip@theDevers <[hidden email]> wrote:
>> Thats part of the bug Scott. This is set at sale time. However, if you
> do
>> not do a quick ship (use the Facilities shipping) and you add freight
>> charges later, these are not accounted for in the

OrderPaymentPreferences.

>>
>> I have been arguing that while convenient, OrderPaymentPreferences is not
>> the data underlying billing account.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Scott Gray [mailto:[hidden email]]
>> Sent: Thursday, November 01, 2007 11:48 PM
>> To: [hidden email]
>> Subject: Re: Accounts Receivable
>>
>>
>> Hi Skip, Jacopo
>>
>>> There are flaws
>>> and complications in the latter in that tax and shipping are not taken
> into
>>> account and shipping charges added later seem to be ignored.
>> I'm just noticing this too, I've got a few orders showing up that have
>> maxAmount set less than the order grand total, that's a bug right?
>>
>> Thanks
>> Scott
>>
>> On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>> Hi Skip,
>>>
>>> this looks interesting.
>>> However, from your message, it is not completely clear to me when you
>>> speak about existing features/issues or new features (and issues?) in
>>> your upcoming contribution.
>>>
>>> It would be great if you could split the message into two parts:
>>> 1) one that describes the current situation with focus on possible
> issues
>>> 2) one with your proposal and suggested changes; (and also with new
>>> issues, if there are any)
>>>
>>> This would help a lot to simplify the discussion.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>>> skip@theDevers wrote:
>>>> I have this mostly working now and I want to run this past you guys to
>> be
>>>> sure there are no objections or thoughts on the methods used. I would
>> be
>>>> especially interested in hereing about any testing in out-of=the=way
>> areas I
>>>> need to do.
>>>>
>>>> 1. First, billing accounts are based entirely on the existance of
>> Payments
>>>> and Invoices against the billing account (we also take into account
>> unbilled
>>>> Orders for available balance computations). We do not use
>>>> PaymentApplication alone or OrderPaymentPreference at all. There are
>> flaws
>>>> and complications in the latter in that tax and shipping are not taken
>> into
>>>> account and shipping charges added later seem to be ignored.
>>>>
>>>> 2. A customer can have multiple billing accounts.
>>>>
>>>> 3. Billing account net balance is the sum of the unpaid portion of
> all
>>>> Invoices against the billing account (including any credits).
>>>>
>>>> 3. Billing account available balance is the billing account limit -
>> ((sum
>>>> of unpaid porting of invoices) + (unbilled Orders))
>>>> This has a flaw TODO (I think) in that if an Order is created
> with
>> back
>>>> orders on it and part has been shipped and an invoice created for that
>> part,
>>>> the whole Order will still subtract from the available balance.
>>>>
>>>> 4. When payments are made, they are never applied to just the billing
>>>> account. They are applied to an invoice belonging to the billing
>> account.
>>>> If there is an unapplied balance, a new credit Invoice is created to
>> hold
>>>> the unapplied balance.
>>>>
>>>> This all works with Ofbiz code if I manually apply the payments to
>> invoices.
>>>> There are many other possible ways to create a billing account
>>>> payment/application and I would have to remove them all except for one
>> which
>>>> calls my new receiveBillingAccountPayment() service and automatically
>>>> applies the payment to the oldest invoice(s).
>>>>
>>>> This also works with opentaps code if I comment out Si's
>>>> captureBillingAccountPayments and let the Ofbiz service run. There is
>> one
>>>> screen to change in Opentaps code in viewCustomerBillAcct."Customer
>> Billing
>>>> Account Transactions" where outstanding invoices are not being
>> displayed. I
>>>> also had to modify the Opentaps ftl calls to com.openstragegies.xxx to
>> call
>>>> the same named (and modified) Ofbiz routines.
>>>>
>>>> TODO is a SECA to automatically apply any available credits when a new
>>>> billing account invoice is created.
>>>>
>>>> Can anyone see any holes in this or have any comments?
>>>>
>>>> Skip
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Scott Gray [mailto:[hidden email]]
>>>> Sent: Thursday, November 01, 2007 3:43 AM
>>>> To: [hidden email]
>>>> Subject: Re: Accounts Receivable
>>>>
>>>>
>>>> Yeah I guess it would help with that, although you still could still
>>>> pay an invoice directly with it (no billingAccountId on the Invoice),
>>>> but you couldn't associate the Payment with more than one billing
>>>> account unless you went for a many to many relationship. But that's
>>>> fine, I just thought I'd ask as it was the first thing I saw that
>>>> didn't make sense to me.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>>> Hi Scott,
>>>>>
>>>>> Scott Gray wrote:
>>>>>> Hi Jacopo
>>>>>>
>>>>>> I decided to have a look at this stuff and it doesn't make sense to
> me
>>>>>> why we have the billingAccountId on PaymentApplication rather than
> on
>>>>>> Payment itself?
>>>>> I agree with you that having the billingAccountId in the Payment
> entity
>>>>> would have made things simpler. I did not design this, it was already
>>>>> there when I've refactored/fixed the billing account processes.
>>>>> However, having the billingAccountId in the PaymentApplication
> improve
>>>>> the flexibility: I could receive a Payment and use one part of it to
>> pay
>>>>> an invoice (not associated to a billing account) and use the
> remaining
>>>>> to 'fill' a billing account.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> It seems like the logic is pretty much the same
>>>>>> except we're doing it in a roundabout sort of way by creating a
>>>>>> PaymentApplication with null invoiceId just to maintain the link.
>>>>>>
>>>>>> Thanks
>>>>>> Scott
>>>>>>
>>>
>>>
>>
>
>
>
>

BJ Freeman

Re: Accounts Receivable

GL has a defualt all in one number for non GL accounting
however if the granularity gets down to individual GL for each customer
account I can see that you would need to do transactions to keep them
uptodated.
and in a GL it has to be a transaction for audit trail.

skip@theDevers sent the following on 11/2/2007 6:15 PM:

> Should not be related. What goes into the GL is separate from AR issues.
> You should be able to run Ofbiz without a GL if you want.
>
> On the other hand, each of these transactions is a GL candidate.
>
> Si Chen has in fact created a way to report on customer accounts by reading
> the transactions out of one of the Acctxxx entities (I forget which one) and
> it works. However, it does not and could never provide the detail normally
> required for adequate reporting to the customer.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Friday, November 02, 2007 7:27 PM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> skip how does this fit with GL and transactions.
>
> skip@theDevers sent the following on 11/2/2007 12:58 PM:
>> Scott
>>
>> In my view, this is kinda the hard way of doing things.
>>
>> Easy way:
>>
>> billing account amount = SUM(unpaid invoice amounts)
>> billing account available balance = billing acount limit - (billing
> account
>> amount + uninvoiced orders)
>>
>> Because customer returns and credits also generate an invoice, this all
>> works.
>>
>> Simple as long as you can determine which invoices are unpaid. Of course,
>> If you are gonna do a proper customer billing statement, you have to know
>> this anyway.
>>
>> I have no idea why you guys feel the need to cling to this
>> OrderPaymentPreferences entity for computing billing accounts.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Scott Gray [mailto:[hidden email]]
>> Sent: Friday, November 02, 2007 1:02 PM
>> To: [hidden email]
>> Subject: Re: Accounts Receivable
>>
>>
>> Hrmm that is a bit of problem, perhaps instead of using maxAmount we
>> should do this:
>> billing account amount = order grand total -
>> SUM(otherPaymentPrefs.maxAmount)
>> We could probably still use maxAmount for storing the calculated
>> value, but put a seca on resetGrandTotal to recalculate it each time
>> the order changes?
>>
>> That way whatever isn't being paid for with other means goes on to the
>> billing account.
>>
>> Does anyone know what the use case is for letting a user set the
>> amount to be billed to the billing account?
>>
>> Scott
>>
>> On 03/11/2007, skip@theDevers <[hidden email]> wrote:
>>> Thats part of the bug Scott. This is set at sale time. However, if you
>> do
>>> not do a quick ship (use the Facilities shipping) and you add freight
>>> charges later, these are not accounted for in the
> OrderPaymentPreferences.
>>> I have been arguing that while convenient, OrderPaymentPreferences is not
>>> the data underlying billing account.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Scott Gray [mailto:[hidden email]]
>>> Sent: Thursday, November 01, 2007 11:48 PM
>>> To: [hidden email]
>>> Subject: Re: Accounts Receivable
>>>
>>>
>>> Hi Skip, Jacopo
>>>
>>>> There are flaws
>>>> and complications in the latter in that tax and shipping are not taken
>> into
>>>> account and shipping charges added later seem to be ignored.
>>> I'm just noticing this too, I've got a few orders showing up that have
>>> maxAmount set less than the order grand total, that's a bug right?
>>>
>>> Thanks
>>> Scott
>>>
>>> On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>> Hi Skip,
>>>>
>>>> this looks interesting.
>>>> However, from your message, it is not completely clear to me when you
>>>> speak about existing features/issues or new features (and issues?) in
>>>> your upcoming contribution.
>>>>
>>>> It would be great if you could split the message into two parts:
>>>> 1) one that describes the current situation with focus on possible
>> issues
>>>> 2) one with your proposal and suggested changes; (and also with new
>>>> issues, if there are any)
>>>>
>>>> This would help a lot to simplify the discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> skip@theDevers wrote:
>>>>> I have this mostly working now and I want to run this past you guys to
>>> be
>>>>> sure there are no objections or thoughts on the methods used. I would
>>> be
>>>>> especially interested in hereing about any testing in out-of=the=way
>>> areas I
>>>>> need to do.
>>>>>
>>>>> 1. First, billing accounts are based entirely on the existance of
>>> Payments
>>>>> and Invoices against the billing account (we also take into account
>>> unbilled
>>>>> Orders for available balance computations). We do not use
>>>>> PaymentApplication alone or OrderPaymentPreference at all. There are
>>> flaws
>>>>> and complications in the latter in that tax and shipping are not taken
>>> into
>>>>> account and shipping charges added later seem to be ignored.
>>>>>
>>>>> 2. A customer can have multiple billing accounts.
>>>>>
>>>>> 3. Billing account net balance is the sum of the unpaid portion of
>> all
>>>>> Invoices against the billing account (including any credits).
>>>>>
>>>>> 3. Billing account available balance is the billing account limit -
>>> ((sum
>>>>> of unpaid porting of invoices) + (unbilled Orders))
>>>>> This has a flaw TODO (I think) in that if an Order is created
>> with
>>> back
>>>>> orders on it and part has been shipped and an invoice created for that
>>> part,
>>>>> the whole Order will still subtract from the available balance.
>>>>>
>>>>> 4. When payments are made, they are never applied to just the billing
>>>>> account. They are applied to an invoice belonging to the billing
>>> account.
>>>>> If there is an unapplied balance, a new credit Invoice is created to
>>> hold
>>>>> the unapplied balance.
>>>>>
>>>>> This all works with Ofbiz code if I manually apply the payments to
>>> invoices.
>>>>> There are many other possible ways to create a billing account
>>>>> payment/application and I would have to remove them all except for one
>>> which
>>>>> calls my new receiveBillingAccountPayment() service and automatically
>>>>> applies the payment to the oldest invoice(s).
>>>>>
>>>>> This also works with opentaps code if I comment out Si's
>>>>> captureBillingAccountPayments and let the Ofbiz service run. There is
>>> one
>>>>> screen to change in Opentaps code in viewCustomerBillAcct."Customer
>>> Billing
>>>>> Account Transactions" where outstanding invoices are not being
>>> displayed. I
>>>>> also had to modify the Opentaps ftl calls to com.openstragegies.xxx to
>>> call
>>>>> the same named (and modified) Ofbiz routines.
>>>>>
>>>>> TODO is a SECA to automatically apply any available credits when a new
>>>>> billing account invoice is created.
>>>>>
>>>>> Can anyone see any holes in this or have any comments?
>>>>>
>>>>> Skip
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Scott Gray [mailto:[hidden email]]
>>>>> Sent: Thursday, November 01, 2007 3:43 AM
>>>>> To: [hidden email]
>>>>> Subject: Re: Accounts Receivable
>>>>>
>>>>>
>>>>> Yeah I guess it would help with that, although you still could still
>>>>> pay an invoice directly with it (no billingAccountId on the Invoice),
>>>>> but you couldn't associate the Payment with more than one billing
>>>>> account unless you went for a many to many relationship. But that's
>>>>> fine, I just thought I'd ask as it was the first thing I saw that
>>>>> didn't make sense to me.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>>>> Hi Scott,
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>> Hi Jacopo
>>>>>>>
>>>>>>> I decided to have a look at this stuff and it doesn't make sense to
>> me
>>>>>>> why we have the billingAccountId on PaymentApplication rather than
>> on
>>>>>>> Payment itself?
>>>>>> I agree with you that having the billingAccountId in the Payment
>> entity
>>>>>> would have made things simpler. I did not design this, it was already
>>>>>> there when I've refactored/fixed the billing account processes.
>>>>>> However, having the billingAccountId in the PaymentApplication
>> improve
>>>>>> the flexibility: I could receive a Payment and use one part of it to
>>> pay
>>>>>> an invoice (not associated to a billing account) and use the
>> remaining
>>>>>> to 'fill' a billing account.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> It seems like the logic is pretty much the same
>>>>>>> except we're doing it in a roundabout sort of way by creating a
>>>>>>> PaymentApplication with null invoiceId just to maintain the link.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Scott
>>>>>>>
>>>>
>>
>>
>>
>
>
>
>

SkipDever

RE: Accounts Receivable

I cannot imaging many real businesses that have a GL account for each
customer. All my clients have thousands of customers making such a strategy
unweildy.

You can though (as Si Chen did) use the generic AcctTransEntry entity and
just extract the relevant records based on the GL account
(ACCOUNTS_RECEIVABLE and a couple of others) in my case and the partyId.
Magically, you have a list of transactions on a billing account. However,
the flaw in this strategy is that it is based on the wrong entity. If
anything should change in the structure of the GL (maybe some overzeleous
new CFO came in and re-organized), your AR records are instantly hosed.

If AR is based on the real underlying data (Invoices and Payments), you have
no such worries.

Skip

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Friday, November 02, 2007 9:15 PM
To: [hidden email]
Subject: Re: Accounts Receivable

GL has a defualt all in one number for non GL accounting
however if the granularity gets down to individual GL for each customer
account I can see that you would need to do transactions to keep them
uptodated.
and in a GL it has to be a transaction for audit trail.

skip@theDevers sent the following on 11/2/2007 6:15 PM:
> Should not be related. What goes into the GL is separate from AR issues.
> You should be able to run Ofbiz without a GL if you want.
>
> On the other hand, each of these transactions is a GL candidate.
>
> Si Chen has in fact created a way to report on customer accounts by
reading
> the transactions out of one of the Acctxxx entities (I forget which one)
and
> it works. However, it does not and could never provide the detail
normally

> required for adequate reporting to the customer.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Friday, November 02, 2007 7:27 PM
> To: [hidden email]
> Subject: Re: Accounts Receivable
>
>
> skip how does this fit with GL and transactions.
>
> skip@theDevers sent the following on 11/2/2007 12:58 PM:
>> Scott
>>
>> In my view, this is kinda the hard way of doing things.
>>
>> Easy way:
>>
>> billing account amount = SUM(unpaid invoice amounts)
>> billing account available balance = billing acount limit - (billing
> account
>> amount + uninvoiced orders)
>>
>> Because customer returns and credits also generate an invoice, this all
>> works.
>>
>> Simple as long as you can determine which invoices are unpaid. Of

course,

>> If you are gonna do a proper customer billing statement, you have to know
>> this anyway.
>>
>> I have no idea why you guys feel the need to cling to this
>> OrderPaymentPreferences entity for computing billing accounts.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Scott Gray [mailto:[hidden email]]
>> Sent: Friday, November 02, 2007 1:02 PM
>> To: [hidden email]
>> Subject: Re: Accounts Receivable
>>
>>
>> Hrmm that is a bit of problem, perhaps instead of using maxAmount we
>> should do this:
>> billing account amount = order grand total -
>> SUM(otherPaymentPrefs.maxAmount)
>> We could probably still use maxAmount for storing the calculated
>> value, but put a seca on resetGrandTotal to recalculate it each time
>> the order changes?
>>
>> That way whatever isn't being paid for with other means goes on to the
>> billing account.
>>
>> Does anyone know what the use case is for letting a user set the
>> amount to be billed to the billing account?
>>
>> Scott
>>
>> On 03/11/2007, skip@theDevers <[hidden email]> wrote:
>>> Thats part of the bug Scott. This is set at sale time. However, if you
>> do
>>> not do a quick ship (use the Facilities shipping) and you add freight
>>> charges later, these are not accounted for in the
> OrderPaymentPreferences.
>>> I have been arguing that while convenient, OrderPaymentPreferences is

not

>>> the data underlying billing account.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Scott Gray [mailto:[hidden email]]
>>> Sent: Thursday, November 01, 2007 11:48 PM
>>> To: [hidden email]
>>> Subject: Re: Accounts Receivable
>>>
>>>
>>> Hi Skip, Jacopo
>>>
>>>> There are flaws
>>>> and complications in the latter in that tax and shipping are not taken
>> into
>>>> account and shipping charges added later seem to be ignored.
>>> I'm just noticing this too, I've got a few orders showing up that have
>>> maxAmount set less than the order grand total, that's a bug right?
>>>
>>> Thanks
>>> Scott
>>>
>>> On 02/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>> Hi Skip,
>>>>
>>>> this looks interesting.
>>>> However, from your message, it is not completely clear to me when you
>>>> speak about existing features/issues or new features (and issues?) in
>>>> your upcoming contribution.
>>>>
>>>> It would be great if you could split the message into two parts:
>>>> 1) one that describes the current situation with focus on possible
>> issues
>>>> 2) one with your proposal and suggested changes; (and also with new
>>>> issues, if there are any)
>>>>
>>>> This would help a lot to simplify the discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> skip@theDevers wrote:
>>>>> I have this mostly working now and I want to run this past you guys to
>>> be
>>>>> sure there are no objections or thoughts on the methods used. I would
>>> be
>>>>> especially interested in hereing about any testing in out-of=the=way
>>> areas I
>>>>> need to do.
>>>>>
>>>>> 1. First, billing accounts are based entirely on the existance of
>>> Payments
>>>>> and Invoices against the billing account (we also take into account
>>> unbilled
>>>>> Orders for available balance computations). We do not use
>>>>> PaymentApplication alone or OrderPaymentPreference at all. There are
>>> flaws
>>>>> and complications in the latter in that tax and shipping are not taken
>>> into
>>>>> account and shipping charges added later seem to be ignored.
>>>>>
>>>>> 2. A customer can have multiple billing accounts.
>>>>>
>>>>> 3. Billing account net balance is the sum of the unpaid portion of
>> all
>>>>> Invoices against the billing account (including any credits).
>>>>>
>>>>> 3. Billing account available balance is the billing account limit -
>>> ((sum
>>>>> of unpaid porting of invoices) + (unbilled Orders))
>>>>> This has a flaw TODO (I think) in that if an Order is created
>> with
>>> back
>>>>> orders on it and part has been shipped and an invoice created for that
>>> part,
>>>>> the whole Order will still subtract from the available balance.
>>>>>
>>>>> 4. When payments are made, they are never applied to just the billing
>>>>> account. They are applied to an invoice belonging to the billing
>>> account.
>>>>> If there is an unapplied balance, a new credit Invoice is created to
>>> hold
>>>>> the unapplied balance.
>>>>>
>>>>> This all works with Ofbiz code if I manually apply the payments to
>>> invoices.
>>>>> There are many other possible ways to create a billing account
>>>>> payment/application and I would have to remove them all except for one
>>> which
>>>>> calls my new receiveBillingAccountPayment() service and automatically
>>>>> applies the payment to the oldest invoice(s).
>>>>>
>>>>> This also works with opentaps code if I comment out Si's
>>>>> captureBillingAccountPayments and let the Ofbiz service run. There is
>>> one
>>>>> screen to change in Opentaps code in viewCustomerBillAcct."Customer
>>> Billing
>>>>> Account Transactions" where outstanding invoices are not being
>>> displayed. I
>>>>> also had to modify the Opentaps ftl calls to com.openstragegies.xxx to
>>> call
>>>>> the same named (and modified) Ofbiz routines.
>>>>>
>>>>> TODO is a SECA to automatically apply any available credits when a new
>>>>> billing account invoice is created.
>>>>>
>>>>> Can anyone see any holes in this or have any comments?
>>>>>
>>>>> Skip
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Scott Gray [mailto:[hidden email]]
>>>>> Sent: Thursday, November 01, 2007 3:43 AM
>>>>> To: [hidden email]
>>>>> Subject: Re: Accounts Receivable
>>>>>
>>>>>
>>>>> Yeah I guess it would help with that, although you still could still
>>>>> pay an invoice directly with it (no billingAccountId on the Invoice),
>>>>> but you couldn't associate the Payment with more than one billing
>>>>> account unless you went for a many to many relationship. But that's
>>>>> fine, I just thought I'd ask as it was the first thing I saw that
>>>>> didn't make sense to me.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> On 01/11/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>>>> Hi Scott,
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>> Hi Jacopo
>>>>>>>
>>>>>>> I decided to have a look at this stuff and it doesn't make sense to
>> me
>>>>>>> why we have the billingAccountId on PaymentApplication rather than
>> on
>>>>>>> Payment itself?
>>>>>> I agree with you that having the billingAccountId in the Payment
>> entity
>>>>>> would have made things simpler. I did not design this, it was already
>>>>>> there when I've refactored/fixed the billing account processes.
>>>>>> However, having the billingAccountId in the PaymentApplication
>> improve
>>>>>> the flexibility: I could receive a Payment and use one part of it to
>>> pay
>>>>>> an invoice (not associated to a billing account) and use the
>> remaining
>>>>>> to 'fill' a billing account.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> It seems like the logic is pretty much the same
>>>>>>> except we're doing it in a roundabout sort of way by creating a
>>>>>>> PaymentApplication with null invoiceId just to maintain the link.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Scott
>>>>>>>
>>>>
>>
>>
>>
>
>
>
>

Jacopo Cappellato

Re: Accounts Receivable

In reply to this post by SkipDever

Hi Skip,

skip@theDevers wrote:

Please, when fixing this, also consider the following situations:

a) if you select, during order entry, an offline payment, then in the
order detail screen you can receive the payment (also a partial payment)
even if there are no invoices for the order: the system creates a
Payment record with no PaymentApplications (the Payment is associated to
the OrderPaymentPreference)

b) an order, associated to a billing account could be only partially
invoiced (partially shipped order)

c) handle payment in advance: the customer fills the billing account
with a payment, and then consume that amount to pay orders

Jacopo

SkipDever

RE: Accounts Receivable

Jacopo

Thanks for pointing these all out. I had already considered b and C , but
was not aware of A. I'll have to explore the entities involved. In case A,
is there a billing account involved?

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Friday, November 02, 2007 11:32 PM
To: [hidden email]
Subject: Re: Accounts Receivable

Hi Skip,

skip@theDevers wrote:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amounts)
> billing account available balance = billing acount limit - (billing
account

SkipDever

RE: Accounts Receivable

In reply to this post by Jacopo Cappellato

I am thinking about the issue of overpayments and credit invoices.
Currently, I am creating a customer return invoice for an overpayment and
applying the unused part of a payment to it.

I like the idea of having this Invoice for detailed reporting. However, it
makes the later re-application of this payment harder. It would be
simplerer to leave the unapplied part of the payment alone (and create a
zero total "informational" Invoice) and then have a seca service that went
out and found un-applied payments to apply whenever a new sales Invoice was
created.

The downside of this simplistic approach is that
SUM(PaymentApplication.amountApplied for a paymentId) has to equal the
Payment.amount. That is currently not the case with returns and I suspect a
few other areas.

I could also use SUM(PaymentApplication.amountApplied for a paymentId +
billingAccountId). That would ignore these extra PaymentApplication which
have the billingAccountId blank.

Anyone have any thoughts on this? If I knew the purpose of the extra
PaymentApplication with the blank billingAccountId, I make a better
decision.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Friday, November 02, 2007 11:32 PM
To: [hidden email]
Subject: Re: Accounts Receivable

Hi Skip,

skip@theDevers wrote:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amounts)
> billing account available balance = billing acount limit - (billing
account