Payments tab in Billing Account.

[amailx-ofbiz]

Hi,
When a BillingAccount is selected. The EditBillingAccount screen has a tab for Payment. The Code behind it finds all the payments applied to a BillingAccount.
 
When should a Payment be applied to BillingAccount?
How will this payment apply to Invoice?


Regards
Anil Patel




Regards
Motel Imperial Moses Lake          Motel The Sundowner In Quincy
www.motelimperial.com              www.motelsundowner.com
SPEND A NIGHT - NOT A FORTUNE      SPEND A NIGHT - NOT A FORTUNE

[Si Chen-2]

Payment increases balance of a Billing Account.  Invoice decreases  
it.  These payments are not related to invoices.


On Jul 11, 2006, at 10:37 AM, <[hidden email]> <amailx-
[hidden email]> wrote:

> Hi,
> When a BillingAccount is selected. The EditBillingAccount screen  
> has a tab for Payment. The Code behind it finds all the payments  
> applied to a BillingAccount.
>
> When should a Payment be applied to BillingAccount?
> How will this payment apply to Invoice?
>
>
> Regards
> Anil Patel
>
>
>
>
> Regards
> Motel Imperial Moses Lake          Motel The Sundowner In Quincy
> www.motelimperial.com              www.motelsundowner.com
> SPEND A NIGHT - NOT A FORTUNE      SPEND A NIGHT - NOT A FORTUNE

[David E Jones-2]

Si Chen wrote:
> Payment increases balance of a Billing Account.  Invoice decreases it.  
> These payments are not related to invoices.

This is not quite correct...

A Payment applied to a BillingAccount should still be applied to an Invoice. If a Payment comes in before the Invoice, then the Invoice should be "applied" to the Payment when it comes in, or as they come in.

There still seems to be some confusion about BillingAccounts. This has been discussed before, so I'm not sure how to put it best...

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

- keep track of "credit" available to a customer for purchase on account
- keep track of Payments in advance
- keep track of a sub-set of Payments and Invoices for a specific client, ie allow them to have multiple billings accounts
- allow multiple authorized parties to bill against the same account which one party is responsible for paying

Perhaps the best way to see how these might work is just to look at the data structure, and to do so with no assumptions but rather focusing on finding questions instead of answers, and then once those questions are laid out (perhaps on paper if need be) then find the answers to the bigger picture.

I haven't reviewed the implementation of all of these things in detail to verify they are working like this, other than review here and there of commits and work done. If anything is assuming that Payments assigned to a BillingAccount are never assigned to Invoices, then that needs to be corrected. I'm not sure what that would even mean because in order for books to balance and for Payments and Invoices to be "closed", they have to be assigned.

-David

[amailx-ofbiz]

David,
I applied a Payment to a billingaccount. Now If I want apply it to a Invoice. The Problem is the Screens that are used to apply a Payment does not let do this.

Can you or somebody review these screens. Once we know what to do, I'll redo the code and provide a Patch for it.

Regards
Anil Patel



David E Jones <[hidden email]> wrote:

Si Chen wrote:
> Payment increases balance of a Billing Account.  Invoice decreases it.  
> These payments are not related to invoices.

This is not quite correct...

A Payment applied to a BillingAccount should still be applied to an Invoice. If a Payment comes in before the Invoice, then the Invoice should be "applied" to the Payment when it comes in, or as they come in.

There still seems to be some confusion about BillingAccounts. This has been discussed before, so I'm not sure how to put it best...

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

- keep track of "credit" available to a customer for purchase on account
- keep track of Payments in advance
- keep track of a sub-set of Payments and Invoices for a specific client, ie allow them to have multiple billings accounts
- allow multiple authorized parties to bill against the same account which one party is responsible for paying

Perhaps the best way to see how these might work is just to look at the data structure, and to do so with no assumptions but rather focusing on finding questions instead of answers, and then once those questions are laid out (perhaps on paper if need be) then find the answers to the bigger picture.

I haven't reviewed the implementation of all of these things in detail to verify they are working like this, other than review here and there of commits and work done. If anything is assuming that Payments assigned to a BillingAccount are never assigned to Invoices, then that needs to be corrected. I'm not sure what that would even mean because in order for books to balance and for Payments and Invoices to be "closed", they have to be assigned.

-David

[David E Jones-2]

Which screens are you looking at?

There may be an issue with the screen, or there may be an issue with a Payment being considered applied when it is applied to a BillingAccount rather than when it is actually applied to an Invoice as it should be.

The main entity in question is PaymentApplication. When a Payment is applied to a BillingAccount there should be a record there, but if the PaymentApplication record(s) doesn't have the invoiceId field populated it should not be considered applied to an Invoice and therefore "consumed".

If you could look into the code that would be great, or if others reading in who have experience in this area and wrote those screens could get involved that would be great.

-David


[hidden email] wrote:

> David,
> I applied a Payment to a billingaccount. Now If I want apply it to a Invoice. The Problem is the Screens that are used to apply a Payment does not let do this.
>
> Can you or somebody review these screens. Once we know what to do, I'll redo the code and provide a Patch for it.
>
> Regards
> Anil Patel
>
>
>
> David E Jones <[hidden email]> wrote:
>
> Si Chen wrote:
>> Payment increases balance of a Billing Account.  Invoice decreases it.  
>> These payments are not related to invoices.
>
> This is not quite correct...
>
> A Payment applied to a BillingAccount should still be applied to an Invoice. If a Payment comes in before the Invoice, then the Invoice should be "applied" to the Payment when it comes in, or as they come in.
>
> There still seems to be some confusion about BillingAccounts. This has been discussed before, so I'm not sure how to put it best...
>
> 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):
>
> - keep track of "credit" available to a customer for purchase on account
> - keep track of Payments in advance
> - keep track of a sub-set of Payments and Invoices for a specific client, ie allow them to have multiple billings accounts
> - allow multiple authorized parties to bill against the same account which one party is responsible for paying
>
> Perhaps the best way to see how these might work is just to look at the data structure, and to do so with no assumptions but rather focusing on finding questions instead of answers, and then once those questions are laid out (perhaps on paper if need be) then find the answers to the bigger picture.
>
> I haven't reviewed the implementation of all of these things in detail to verify they are working like this, other than review here and there of commits and work done. If anything is assuming that Payments assigned to a BillingAccount are never assigned to Invoices, then that needs to be corrected. I'm not sure what that would even mean because in order for books to balance and for Payments and Invoices to be "closed", they have to be assigned.
>
> -David
>
>
>
>

[amailx-ofbiz]

The findPayments screen (/accounting/control/findPayments) has a list of Payments. The last column "Amount to Apply". If a payment is applied to billingAccount (/accounting/control/editPaymentApplications), This amount reduces correspondingly.

After a payment is applied to billingAccount The current screen will let only update Amount, or billingAccountId.

To apply a Payment to invoice, First we have to reduce the amount applied to billingAccount. This makes the amount available for applying to something else.

Is this the right Process?

Anil Patel






"David E. Jones" <[hidden email]> wrote:
Which screens are you looking at?

There may be an issue with the screen, or there may be an issue with a Payment being considered applied when it is applied to a BillingAccount rather than when it is actually applied to an Invoice as it should be.

The main entity in question is PaymentApplication. When a Payment is applied to a BillingAccount there should be a record there, but if the PaymentApplication record(s) doesn't have the invoiceId field populated it should not be considered applied to an Invoice and therefore "consumed".

If you could look into the code that would be great, or if others reading in who have experience in this area and wrote those screens could get involved that would be great.

-David


[hidden email] wrote:

> David,
> I applied a Payment to a billingaccount. Now If I want apply it to a Invoice. The Problem is the Screens that are used to apply a Payment does not let do this.
>
> Can you or somebody review these screens. Once we know what to do, I'll redo the code and provide a Patch for it.
>
> Regards
> Anil Patel
>
>
>
> David E Jones  wrote:
>
> Si Chen wrote:
>> Payment increases balance of a Billing Account.  Invoice decreases it.  
>> These payments are not related to invoices.
>
> This is not quite correct...
>
> A Payment applied to a BillingAccount should still be applied to an Invoice. If a Payment comes in before the Invoice, then the Invoice should be "applied" to the Payment when it comes in, or as they come in.
>
> There still seems to be some confusion about BillingAccounts. This has been discussed before, so I'm not sure how to put it best...
>
> 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):
>
> - keep track of "credit" available to a customer for purchase on account
> - keep track of Payments in advance
> - keep track of a sub-set of Payments and Invoices for a specific client, ie allow them to have multiple billings accounts
> - allow multiple authorized parties to bill against the same account which one party is responsible for paying
>
> Perhaps the best way to see how these might work is just to look at the data structure, and to do so with no assumptions but rather focusing on finding questions instead of answers, and then once those questions are laid out (perhaps on paper if need be) then find the answers to the bigger picture.
>
> I haven't reviewed the implementation of all of these things in detail to verify they are working like this, other than review here and there of commits and work done. If anything is assuming that Payments assigned to a BillingAccount are never assigned to Invoices, then that needs to be corrected. I'm not sure what that would even mean because in order for books to balance and for Payments and Invoices to be "closed", they have to be assigned.
>
> -David
>
>
>
>

[David E Jones-2]

Side note: it looks like Si is looking at this stuff and fixed in rev 421016 the initial BillingAccount creation (from briefly looking at the patch appears that the currency UOM was missing).

For the general process: it should not be necessary to un-apply the Payment from the BillingAccount before applying it to an Invoice. The UI should really not count PaymentApplications without an invoiceId on them.

I should also note, just in case it isn't doing this... that Payment applications should maintain the billingAccountId when applied to an invoice if either the Payment or the Invoice was associated with that BillingAccount before.

I hope that helps more than confuses or inconveniences...

-David



[hidden email] wrote:

> The findPayments screen (/accounting/control/findPayments) has a list of Payments. The last column "Amount to Apply". If a payment is applied to billingAccount (/accounting/control/editPaymentApplications), This amount reduces correspondingly.
>
> After a payment is applied to billingAccount The current screen will let only update Amount, or billingAccountId.
>
> To apply a Payment to invoice, First we have to reduce the amount applied to billingAccount. This makes the amount available for applying to something else.
>
> Is this the right Process?
>
> Anil Patel
>
>
>
>
>
>
> "David E. Jones" <[hidden email]> wrote:
> Which screens are you looking at?
>
> There may be an issue with the screen, or there may be an issue with a Payment being considered applied when it is applied to a BillingAccount rather than when it is actually applied to an Invoice as it should be.
>
> The main entity in question is PaymentApplication. When a Payment is applied to a BillingAccount there should be a record there, but if the PaymentApplication record(s) doesn't have the invoiceId field populated it should not be considered applied to an Invoice and therefore "consumed".
>
> If you could look into the code that would be great, or if others reading in who have experience in this area and wrote those screens could get involved that would be great.
>
> -David
>
>
> [hidden email] wrote:
>> David,
>> I applied a Payment to a billingaccount. Now If I want apply it to a Invoice. The Problem is the Screens that are used to apply a Payment does not let do this.
>>
>> Can you or somebody review these screens. Once we know what to do, I'll redo the code and provide a Patch for it.
>>
>> Regards
>> Anil Patel
>>
>>
>>
>> David E Jones  wrote:
>>
>> Si Chen wrote:
>>> Payment increases balance of a Billing Account.  Invoice decreases it.  
>>> These payments are not related to invoices.
>> This is not quite correct...
>>
>> A Payment applied to a BillingAccount should still be applied to an Invoice. If a Payment comes in before the Invoice, then the Invoice should be "applied" to the Payment when it comes in, or as they come in.
>>
>> There still seems to be some confusion about BillingAccounts. This has been discussed before, so I'm not sure how to put it best...
>>
>> 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):
>>
>> - keep track of "credit" available to a customer for purchase on account
>> - keep track of Payments in advance
>> - keep track of a sub-set of Payments and Invoices for a specific client, ie allow them to have multiple billings accounts
>> - allow multiple authorized parties to bill against the same account which one party is responsible for paying
>>
>> Perhaps the best way to see how these might work is just to look at the data structure, and to do so with no assumptions but rather focusing on finding questions instead of answers, and then once those questions are laid out (perhaps on paper if need be) then find the answers to the bigger picture.
>>
>> I haven't reviewed the implementation of all of these things in detail to verify they are working like this, other than review here and there of commits and work done. If anything is assuming that Payments assigned to a BillingAccount are never assigned to Invoices, then that needs to be corrected. I'm not sure what that would even mean because in order for books to balance and for Payments and Invoices to be "closed", they have to be assigned.
>>
>> -David
>>
>>
>>
>>
>
>

[Si Chen-2]

David,

I just checked this out.  If you create a return for store credit, a  
Payment was created and applied to the Return Invoice, and then a  
separate PaymentApplication was created with the billingAccountId.    
Later when the billing account was used to pay for an order, a  
Payment was created and applied to the Sales Invoice, then a separate  
PaymentApplication was created with the BillingAccountId.  So in each  
case a PaymentApplication was created with the billingAccountId and  
no invoiceId.

I hope this clears it up.

Si

On Jul 11, 2006, at 11:34 AM, David E Jones wrote:

>
>
> Si Chen wrote:
>> Payment increases balance of a Billing Account.  Invoice decreases  
>> it.  These payments are not related to invoices.
>
> This is not quite correct...
>
> A Payment applied to a BillingAccount should still be applied to an  
> Invoice. If a Payment comes in before the Invoice, then the Invoice  
> should be "applied" to the Payment when it comes in, or as they  
> come in.
>
> There still seems to be some confusion about BillingAccounts. This  
> has been discussed before, so I'm not sure how to put it best...
>
> 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):
>
> - keep track of "credit" available to a customer for purchase on  
> account
> - keep track of Payments in advance
> - keep track of a sub-set of Payments and Invoices for a specific  
> client, ie allow them to have multiple billings accounts
> - allow multiple authorized parties to bill against the same  
> account which one party is responsible for paying
>
> Perhaps the best way to see how these might work is just to look at  
> the data structure, and to do so with no assumptions but rather  
> focusing on finding questions instead of answers, and then once  
> those questions are laid out (perhaps on paper if need be) then  
> find the answers to the bigger picture.
>
> I haven't reviewed the implementation of all of these things in  
> detail to verify they are working like this, other than review here  
> and there of commits and work done. If anything is assuming that  
> Payments assigned to a BillingAccount are never assigned to  
> Invoices, then that needs to be corrected. I'm not sure what that  
> would even mean because in order for books to balance and for  
> Payments and Invoices to be "closed", they have to be assigned.
>
> -David
>
>

[Leon Torres-2]

David E. Jones wrote:
>
> Side note: it looks like Si is looking at this stuff and fixed in rev
> 421016 the initial BillingAccount creation (from briefly looking at the
> patch appears that the currency UOM was missing).

That's right, this turned out to be the bug that was preventing the
BillingAccounts from showing up in the payment method selection of ordermgr and
ecommerce checkout.  Now customers can get store credit for a return and select
that credit as a payment method.

- Leon

[Hans Bakker]

I wrote the payment applicationprogram some time ago. When using the screens
the payment can be applied to another payment, invoice or taxGeoId or billing
account. Currently the payment can only be applied once: so when it is
applied to an invoice it cannot also be applied to a billing account,
taxAuthGeoId or other payment.

I can help you change this, but need to know how it should work exactly.
Is it only the billing account which can be assigned additionaly or does this
apply to the taxAuthGeoId too?


--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc


On Wednesday 12 July 2006 04:31, David E. Jones wrote:

> Which screens are you looking at?
>
> There may be an issue with the screen, or there may be an issue with a
> Payment being considered applied when it is applied to a BillingAccount
> rather than when it is actually applied to an Invoice as it should be.
>
> The main entity in question is PaymentApplication. When a Payment is
> applied to a BillingAccount there should be a record there, but if the
> PaymentApplication record(s) doesn't have the invoiceId field populated it
> should not be considered applied to an Invoice and therefore "consumed".
>
> If you could look into the code that would be great, or if others reading
> in who have experience in this area and wrote those screens could get
> involved that would be great.
>
> -David
>
> [hidden email] wrote:
> > David,
> > I applied a Payment to a billingaccount. Now If I want apply it to a
> > Invoice. The Problem is the Screens that are used to apply a Payment does
> > not let do this.
> >
> > Can you or somebody review these screens. Once we know what to do, I'll
> > redo the code and provide a Patch for it.
> >
> > Regards
> > Anil Patel
> >
> >
> >
> > David E Jones <[hidden email]> wrote:
> >
> > Si Chen wrote:
> >> Payment increases balance of a Billing Account.  Invoice decreases it.
> >> These payments are not related to invoices.
> >
> > This is not quite correct...
> >
> > A Payment applied to a BillingAccount should still be applied to an
> > Invoice. If a Payment comes in before the Invoice, then the Invoice
> > should be "applied" to the Payment when it comes in, or as they come in.
> >
> > There still seems to be some confusion about BillingAccounts. This has
> > been discussed before, so I'm not sure how to put it best...
> >
> > 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):
> >
> > - keep track of "credit" available to a customer for purchase on account
> > - keep track of Payments in advance
> > - keep track of a sub-set of Payments and Invoices for a specific client,
> > ie allow them to have multiple billings accounts - allow multiple
> > authorized parties to bill against the same account which one party is
> > responsible for paying
> >
> > Perhaps the best way to see how these might work is just to look at the
> > data structure, and to do so with no assumptions but rather focusing on
> > finding questions instead of answers, and then once those questions are
> > laid out (perhaps on paper if need be) then find the answers to the
> > bigger picture.
> >
> > I haven't reviewed the implementation of all of these things in detail to
> > verify they are working like this, other than review here and there of
> > commits and work done. If anything is assuming that Payments assigned to
> > a BillingAccount are never assigned to Invoices, then that needs to be
> > corrected. I'm not sure what that would even mean because in order for
> > books to balance and for Payments and Invoices to be "closed", they have
> > to be assigned.
> >
> > -David

[Si Chen-2]

Anil,

Before writing more code, check this process first:

1.  Create an order
2.  Quick ship it
3.  Return it for a store credit
4.  Create another order for the same customer
5.  Use the billing account to pay for it
6.  Quick ship the second order

Now look at how the BillingAccount, OrderHeader, Invoice, Payment,  
and PaymentApplication entities are created.

I suspect that what you're suggesting is not necessary, and what Hans  
has created so far should meet your needs: namely, you'd create a  
Payment, apply it to your invoice, then apply a Billing Account to  
that Payment again.

Si


On Jul 11, 2006, at 2:10 PM, <[hidden email]> <amailx-
[hidden email]> wrote:

> David,
> I applied a Payment to a billingaccount. Now If I want apply it to  
> a Invoice. The Problem is the Screens that are used to apply a  
> Payment does not let do this.
>
> Can you or somebody review these screens. Once we know what to do,  
> I'll redo the code and provide a Patch for it.
>
> Regards
> Anil Patel
>
>
>
> David E Jones <[hidden email]> wrote:
>
> Si Chen wrote:
>> Payment increases balance of a Billing Account.  Invoice decreases  
>> it.
>> These payments are not related to invoices.
>
> This is not quite correct...
>
> A Payment applied to a BillingAccount should still be applied to an  
> Invoice. If a Payment comes in before the Invoice, then the Invoice  
> should be "applied" to the Payment when it comes in, or as they  
> come in.
>
> There still seems to be some confusion about BillingAccounts. This  
> has been discussed before, so I'm not sure how to put it best...
>
> 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):
>
> - keep track of "credit" available to a customer for purchase on  
> account
> - keep track of Payments in advance
> - keep track of a sub-set of Payments and Invoices for a specific  
> client, ie allow them to have multiple billings accounts
> - allow multiple authorized parties to bill against the same  
> account which one party is responsible for paying
>
> Perhaps the best way to see how these might work is just to look at  
> the data structure, and to do so with no assumptions but rather  
> focusing on finding questions instead of answers, and then once  
> those questions are laid out (perhaps on paper if need be) then  
> find the answers to the bigger picture.
>
> I haven't reviewed the implementation of all of these things in  
> detail to verify they are working like this, other than review here  
> and there of commits and work done. If anything is assuming that  
> Payments assigned to a BillingAccount are never assigned to  
> Invoices, then that needs to be corrected. I'm not sure what that  
> would even mean because in order for books to balance and for  
> Payments and Invoices to be "closed", they have to be assigned.
>
> -David
>
>
>

[amailx-ofbiz]

Si,
When a Payment is created and Applied to a BillingAccount. Now if it has to be applied to a Invoice. This is something that  I find difficulty with.

If a Payment is already applied to a Invoice, Then What benifit do we get by applying it to BillingAccount.

Or Is it that,
If a Invoice is applied to a BillingAccount,  Payment should be applied to Invoice and also set BillingAccountId in PaymentApplication record. So that the total Invoice amount and Payment amount whould balance for a BillingAccount number.

Regards
Anil Patel







Si Chen <[hidden email]> wrote: Anil,

Before writing more code, check this process first:

1.  Create an order
2.  Quick ship it
3.  Return it for a store credit
4.  Create another order for the same customer
5.  Use the billing account to pay for it
6.  Quick ship the second order

Now look at how the BillingAccount, OrderHeader, Invoice, Payment,  
and PaymentApplication entities are created.

I suspect that what you're suggesting is not necessary, and what Hans  
has created so far should meet your needs: namely, you'd create a  
Payment, apply it to your invoice, then apply a Billing Account to  
that Payment again.

Si


On Jul 11, 2006, at 2:10 PM,  
[hidden email]> wrote:

> David,
> I applied a Payment to a billingaccount. Now If I want apply it to  
> a Invoice. The Problem is the Screens that are used to apply a  
> Payment does not let do this.
>
> Can you or somebody review these screens. Once we know what to do,  
> I'll redo the code and provide a Patch for it.
>
> Regards
> Anil Patel
>
>
>
> David E Jones  wrote:
>
> Si Chen wrote:
>> Payment increases balance of a Billing Account.  Invoice decreases  
>> it.
>> These payments are not related to invoices.
>
> This is not quite correct...
>
> A Payment applied to a BillingAccount should still be applied to an  
> Invoice. If a Payment comes in before the Invoice, then the Invoice  
> should be "applied" to the Payment when it comes in, or as they  
> come in.
>
> There still seems to be some confusion about BillingAccounts. This  
> has been discussed before, so I'm not sure how to put it best...
>
> 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):
>
> - keep track of "credit" available to a customer for purchase on  
> account
> - keep track of Payments in advance
> - keep track of a sub-set of Payments and Invoices for a specific  
> client, ie allow them to have multiple billings accounts
> - allow multiple authorized parties to bill against the same  
> account which one party is responsible for paying
>
> Perhaps the best way to see how these might work is just to look at  
> the data structure, and to do so with no assumptions but rather  
> focusing on finding questions instead of answers, and then once  
> those questions are laid out (perhaps on paper if need be) then  
> find the answers to the bigger picture.
>
> I haven't reviewed the implementation of all of these things in  
> detail to verify they are working like this, other than review here  
> and there of commits and work done. If anything is assuming that  
> Payments assigned to a BillingAccount are never assigned to  
> Invoices, then that needs to be corrected. I'm not sure what that  
> would even mean because in order for books to balance and for  
> Payments and Invoices to be "closed", they have to be assigned.
>
> -David
>
>
>

[Si Chen-2]

Why don't you follow the steps I suggested and look at the entities?

On Jul 12, 2006, at 9:59 AM, <[hidden email]> <amailx-
[hidden email]> wrote:

> Si,
> When a Payment is created and Applied to a BillingAccount. Now if  
> it has to be applied to a Invoice. This is something that  I find  
> difficulty with.
>
> If a Payment is already applied to a Invoice, Then What benifit do  
> we get by applying it to BillingAccount.
>
> Or Is it that,
> If a Invoice is applied to a BillingAccount,  Payment should be  
> applied to Invoice and also set BillingAccountId in  
> PaymentApplication record. So that the total Invoice amount and  
> Payment amount whould balance for a BillingAccount number.
>
> Regards
> Anil Patel
>
>
>
>
>
>
>
> Si Chen <[hidden email]> wrote: Anil,
>
> Before writing more code, check this process first:
>
> 1.  Create an order
> 2.  Quick ship it
> 3.  Return it for a store credit
> 4.  Create another order for the same customer
> 5.  Use the billing account to pay for it
> 6.  Quick ship the second order
>
> Now look at how the BillingAccount, OrderHeader, Invoice, Payment,
> and PaymentApplication entities are created.
>
> I suspect that what you're suggesting is not necessary, and what Hans
> has created so far should meet your needs: namely, you'd create a
> Payment, apply it to your invoice, then apply a Billing Account to
> that Payment again.
>
> Si
>
>
> On Jul 11, 2006, at 2:10 PM,
> [hidden email]> wrote:
>
>> David,
>> I applied a Payment to a billingaccount. Now If I want apply it to
>> a Invoice. The Problem is the Screens that are used to apply a
>> Payment does not let do this.
>>
>> Can you or somebody review these screens. Once we know what to do,
>> I'll redo the code and provide a Patch for it.
>>
>> Regards
>> Anil Patel
>>
>>
>>
>> David E Jones  wrote:
>>
>> Si Chen wrote:
>>> Payment increases balance of a Billing Account.  Invoice decreases
>>> it.
>>> These payments are not related to invoices.
>>
>> This is not quite correct...
>>
>> A Payment applied to a BillingAccount should still be applied to an
>> Invoice. If a Payment comes in before the Invoice, then the Invoice
>> should be "applied" to the Payment when it comes in, or as they
>> come in.
>>
>> There still seems to be some confusion about BillingAccounts. This
>> has been discussed before, so I'm not sure how to put it best...
>>
>> 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):
>>
>> - keep track of "credit" available to a customer for purchase on
>> account
>> - keep track of Payments in advance
>> - keep track of a sub-set of Payments and Invoices for a specific
>> client, ie allow them to have multiple billings accounts
>> - allow multiple authorized parties to bill against the same
>> account which one party is responsible for paying
>>
>> Perhaps the best way to see how these might work is just to look at
>> the data structure, and to do so with no assumptions but rather
>> focusing on finding questions instead of answers, and then once
>> those questions are laid out (perhaps on paper if need be) then
>> find the answers to the bigger picture.
>>
>> I haven't reviewed the implementation of all of these things in
>> detail to verify they are working like this, other than review here
>> and there of commits and work done. If anything is assuming that
>> Payments assigned to a BillingAccount are never assigned to
>> Invoices, then that needs to be corrected. I'm not sure what that
>> would even mean because in order for books to balance and for
>> Payments and Invoices to be "closed", they have to be assigned.
>>
>> -David
>>
>>
>>
>
>

[David E Jones-2]

[hidden email] wrote:
>
> Or Is it that,
> If a Invoice is applied to a BillingAccount,  Payment should be applied to Invoice and also set BillingAccountId in PaymentApplication record. So that the total Invoice amount and Payment amount whould balance for a BillingAccount number.

This is correct. If you find it's not doing that in the current code, something is wrong.

-David