Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll
get another gazillion emails to sort through :). One final issue to deal with for me, and that is credits. Right now, if you overpay, you get an orphan PaymentApplication (no Invoice). This is fine for computing the balance, but there is no detail record when printing a statement. This may be fine (just printing an overpayment line or whatever), but in the past, I have always created a miscellaneous credit that was applied (for aging purposes) when the next order was received (similiar to the way a store credit works now). Does anyone see any harm in creating a store credit (so we can utilize the existing logic) for overpayments? Skip > Hi Scott, > > Scott Gray wrote: > > Hi Jacopo > > > > Our customers generally make payments for a specific invoice or group > > of invoices so this wouldn't work for us. In our current system (non > > web UI) we log a payment and then use a screen with a list of open > > invoices to allocate the payment with the payment balance reducing as > > each invoice is selected. > > > > I think that you have perfectly described what is currently implemented > in OFbiz :-) > Maybe I'm not been very clear on this: I was not suggesting to modify > the existing payment/payment application screens; instead I was > suggesting to add a new option, for billing accounts, to apply billing > account payments to billing account invoices by date; of course you can > continue, also in the billing account, to apply payments to specific > invoices. > > Cheers, > > Jacopo > > > > Regards > > Scott > > > > On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: > >> skip@theDevers wrote: > >>> Jacopo > >>> > >>> As the man with the plan, > >> uhm... me? :-) > >> > >>> I wanted to throw this new plan past you. I have > >>> dug pretty deeply into the existing payment/billing account stuff and > >>> all seems a bit arcane to me and mostly because it looks like payments are > >>> meant to be made from the company to a vendor and from a customer to the > >>> company, all with the same screens. > >>> > >>> I want to create a really easy to use AR payment system. The user enters a > >>> payment and can then either apply the payment to individual invoices (and a > >>> store credit if too much is received) or he can apply it to the billing > >>> account, in which case we automatically apply it to the oldest invoices > >>> first and then to a credit if too much is received. > >>> > >> I'd suggest the following subtasks: > >> > >> a) implement a new service to automatically apply the payments > >> associated to a billing account to the older open invoices associated to > >> the same account; the new service will have one mandatory parameter > >> "billingAccountId" (and maybe one optional parameter "paymentId") and it > >> will: > >> - select the open invoices associated to the billing account and sort > >> them by date (older first) > >> - iterate on the list and for each of them call the service > >> capturePaymentsByInvoice passing in the invoice id and billingAccountId > >> (this is the service that is invoked when you click on the "capture" > >> link near the invoice in the billingaccoun-invoices screen) > >> > >> b) the new service can be invoked by a new link ("apply payments to > >> invoices") at the top of the billing account->invoices screen or (maybe > >> in your custom application) triggered every time you associate a > >> to a billing account. > >> > >> This should cover your requirements but it is also generic enough to be > >> a good fit for OFBiz. > >> > >> What do you think? > >> > >> Jacopo > >> > >>> Is this too simplistic for some reason I am missing? Do others have > >>> needs outside this that would justify a more complicated transaction set? > >>> > >>> Skip > >> > >> > |
Hi Skip,
skip@theDevers wrote: > Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll > get another gazillion emails to sort through :). > > One final issue to deal with for me, and that is credits. Right now, if you > overpay, you get an orphan PaymentApplication (no Invoice). This is fine > for computing the balance, but there is no detail record when printing a > statement. > > This may be fine (just printing an overpayment line or whatever), but in the > past, I have always created a miscellaneous credit that was applied (for > aging purposes) when the next order was received (similiar to the way a > store credit works now). > > Does anyone see any harm in creating a store credit (so we can utilize the > existing logic) for overpayments? > what about using a billing account to catch the overpayment amount? you can associate the amount to the billing account and then use it later. Jacopo > Skip > >> Hi Scott, >> >> Scott Gray wrote: >>> Hi Jacopo >>> >>> Our customers generally make payments for a specific invoice or group >>> of invoices so this wouldn't work for us. In our current system (non >>> web UI) we log a payment and then use a screen with a list of open >>> invoices to allocate the payment with the payment balance reducing as >>> each invoice is selected. >>> >> I think that you have perfectly described what is currently implemented >> in OFbiz :-) >> Maybe I'm not been very clear on this: I was not suggesting to modify >> the existing payment/payment application screens; instead I was >> suggesting to add a new option, for billing accounts, to apply billing >> account payments to billing account invoices by date; of course you can >> continue, also in the billing account, to apply payments to specific >> invoices. >> >> Cheers, >> >> Jacopo >> >> >>> Regards >>> Scott >>> >>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: >>>> skip@theDevers wrote: >>>>> Jacopo >>>>> >>>>> As the man with the plan, >>>> uhm... me? :-) >>>> >>>>> I wanted to throw this new plan past you. I have >>>>> dug pretty deeply into the existing payment/billing account stuff and > it >>>>> all seems a bit arcane to me and mostly because it looks like payments > are >>>>> meant to be made from the company to a vendor and from a customer to > the >>>>> company, all with the same screens. >>>>> >>>>> I want to create a really easy to use AR payment system. The user > enters a >>>>> payment and can then either apply the payment to individual invoices > (and a >>>>> store credit if too much is received) or he can apply it to the > billing >>>>> account, in which case we automatically apply it to the oldest > invoices >>>>> first and then to a credit if too much is received. >>>>> >>>> I'd suggest the following subtasks: >>>> >>>> a) implement a new service to automatically apply the payments >>>> associated to a billing account to the older open invoices associated > to >>>> the same account; the new service will have one mandatory parameter >>>> "billingAccountId" (and maybe one optional parameter "paymentId") and > it >>>> will: >>>> - select the open invoices associated to the billing account and sort >>>> them by date (older first) >>>> - iterate on the list and for each of them call the service >>>> capturePaymentsByInvoice passing in the invoice id and billingAccountId >>>> (this is the service that is invoked when you click on the "capture" >>>> link near the invoice in the billingaccoun-invoices screen) >>>> >>>> b) the new service can be invoked by a new link ("apply payments to >>>> invoices") at the top of the billing account->invoices screen or (maybe >>>> in your custom application) triggered every time you associate a > payment >>>> to a billing account. >>>> >>>> This should cover your requirements but it is also generic enough to be >>>> a good fit for OFBiz. >>>> >>>> What do you think? >>>> >>>> Jacopo >>>> >>>>> Is this too simplistic for some reason I am missing? Do others have > AR >>>>> needs outside this that would justify a more complicated transaction > set? >>>>> Skip >>>> > |
Jacopo
The assumtion for me is that these are all dealing with billing accounts. No billing account, no AR. Stated differently, the sum of billing account invoices - (billing account payments + store credits) = Accounts Receivable. Is there some billing account entity I missed to hold credits? Skip -----Original Message----- From: Jacopo Cappellato [mailto:[hidden email]] Sent: Monday, October 29, 2007 11:50 AM To: [hidden email] Subject: Re: Accounts Receivable Hi Skip, skip@theDevers wrote: > Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll > get another gazillion emails to sort through :). > > One final issue to deal with for me, and that is credits. Right now, if you > overpay, you get an orphan PaymentApplication (no Invoice). This is fine > for computing the balance, but there is no detail record when printing a > statement. > > This may be fine (just printing an overpayment line or whatever), but in the > past, I have always created a miscellaneous credit that was applied (for > aging purposes) when the next order was received (similiar to the way a > store credit works now). > > Does anyone see any harm in creating a store credit (so we can utilize the > existing logic) for overpayments? > what about using a billing account to catch the overpayment amount? you can associate the amount to the billing account and then use it later. Jacopo > Skip > >> Hi Scott, >> >> Scott Gray wrote: >>> Hi Jacopo >>> >>> Our customers generally make payments for a specific invoice or group >>> of invoices so this wouldn't work for us. In our current system (non >>> web UI) we log a payment and then use a screen with a list of open >>> invoices to allocate the payment with the payment balance reducing as >>> each invoice is selected. >>> >> I think that you have perfectly described what is currently implemented >> in OFbiz :-) >> Maybe I'm not been very clear on this: I was not suggesting to modify >> the existing payment/payment application screens; instead I was >> suggesting to add a new option, for billing accounts, to apply billing >> account payments to billing account invoices by date; of course you can >> continue, also in the billing account, to apply payments to specific >> invoices. >> >> Cheers, >> >> Jacopo >> >> >>> Regards >>> Scott >>> >>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: >>>> skip@theDevers wrote: >>>>> Jacopo >>>>> >>>>> As the man with the plan, >>>> uhm... me? :-) >>>> >>>>> I wanted to throw this new plan past you. I have >>>>> dug pretty deeply into the existing payment/billing account stuff and > it >>>>> all seems a bit arcane to me and mostly because it looks like payments > are >>>>> meant to be made from the company to a vendor and from a customer to > the >>>>> company, all with the same screens. >>>>> >>>>> I want to create a really easy to use AR payment system. The user > enters a >>>>> payment and can then either apply the payment to individual invoices > (and a >>>>> store credit if too much is received) or he can apply it to the > billing >>>>> account, in which case we automatically apply it to the oldest > invoices >>>>> first and then to a credit if too much is received. >>>>> >>>> I'd suggest the following subtasks: >>>> >>>> a) implement a new service to automatically apply the payments >>>> associated to a billing account to the older open invoices associated > to >>>> the same account; the new service will have one mandatory parameter >>>> "billingAccountId" (and maybe one optional parameter "paymentId") and > it >>>> will: >>>> - select the open invoices associated to the billing account and sort >>>> them by date (older first) >>>> - iterate on the list and for each of them call the service >>>> capturePaymentsByInvoice passing in the invoice id and billingAccountId >>>> (this is the service that is invoked when you click on the "capture" >>>> link near the invoice in the billingaccoun-invoices screen) >>>> >>>> b) the new service can be invoked by a new link ("apply payments to >>>> invoices") at the top of the billing account->invoices screen or (maybe >>>> in your custom application) triggered every time you associate a > payment >>>> to a billing account. >>>> >>>> This should cover your requirements but it is also generic enough to be >>>> a good fit for OFBiz. >>>> >>>> What do you think? >>>> >>>> Jacopo >>>> >>>>> Is this too simplistic for some reason I am missing? Do others have > AR >>>>> needs outside this that would justify a more complicated transaction > set? >>>>> Skip >>>> > |
skip@theDevers wrote:
> Jacopo > > The assumtion for me is that these are all dealing with billing accounts. > No billing account, no AR. Stated differently, the sum of billing account > invoices - (billing account payments + store credits) = Accounts Receivable. > Is there some billing account entity I missed to hold credits? If you get a payment from a customer, and you completely associate it (with a PaymentApplication record) to the customer's billing account, then you apply it to the invoices in the account and let's say that 10$ are left (overpayment), these dollars will increase tha vailable amount in the billing account (because they are not applied to any invoice) and so you can use them for future orders Jacopo > > Skip > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Monday, October 29, 2007 11:50 AM > To: [hidden email] > Subject: Re: Accounts Receivable > > > Hi Skip, > > skip@theDevers wrote: >> Okeydokey Jacques, moved the discussion here (in spite of the fact that > I'll >> get another gazillion emails to sort through :). >> >> One final issue to deal with for me, and that is credits. Right now, if > you >> overpay, you get an orphan PaymentApplication (no Invoice). This is fine >> for computing the balance, but there is no detail record when printing a >> statement. >> >> This may be fine (just printing an overpayment line or whatever), but in > the >> past, I have always created a miscellaneous credit that was applied (for >> aging purposes) when the next order was received (similiar to the way a >> store credit works now). >> >> Does anyone see any harm in creating a store credit (so we can utilize the >> existing logic) for overpayments? >> > > what about using a billing account to catch the overpayment amount? you > can associate the amount to the billing account and then use it later. > > Jacopo > > >> Skip >> >>> Hi Scott, >>> >>> Scott Gray wrote: >>>> Hi Jacopo >>>> >>>> Our customers generally make payments for a specific invoice or group >>>> of invoices so this wouldn't work for us. In our current system (non >>>> web UI) we log a payment and then use a screen with a list of open >>>> invoices to allocate the payment with the payment balance reducing as >>>> each invoice is selected. >>>> >>> I think that you have perfectly described what is currently implemented >>> in OFbiz :-) >>> Maybe I'm not been very clear on this: I was not suggesting to modify >>> the existing payment/payment application screens; instead I was >>> suggesting to add a new option, for billing accounts, to apply billing >>> account payments to billing account invoices by date; of course you can >>> continue, also in the billing account, to apply payments to specific >>> invoices. >>> >>> Cheers, >>> >>> Jacopo >>> >>> >>>> Regards >>>> Scott >>>> >>>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: >>>>> skip@theDevers wrote: >>>>>> Jacopo >>>>>> >>>>>> As the man with the plan, >>>>> uhm... me? :-) >>>>> >>>>>> I wanted to throw this new plan past you. I have >>>>>> dug pretty deeply into the existing payment/billing account stuff and >> it >>>>>> all seems a bit arcane to me and mostly because it looks like payments >> are >>>>>> meant to be made from the company to a vendor and from a customer to >> the >>>>>> company, all with the same screens. >>>>>> >>>>>> I want to create a really easy to use AR payment system. The user >> enters a >>>>>> payment and can then either apply the payment to individual invoices >> (and a >>>>>> store credit if too much is received) or he can apply it to the >> billing >>>>>> account, in which case we automatically apply it to the oldest >> invoices >>>>>> first and then to a credit if too much is received. >>>>>> >>>>> I'd suggest the following subtasks: >>>>> >>>>> a) implement a new service to automatically apply the payments >>>>> associated to a billing account to the older open invoices associated >> to >>>>> the same account; the new service will have one mandatory parameter >>>>> "billingAccountId" (and maybe one optional parameter "paymentId") and >> it >>>>> will: >>>>> - select the open invoices associated to the billing account and sort >>>>> them by date (older first) >>>>> - iterate on the list and for each of them call the service >>>>> capturePaymentsByInvoice passing in the invoice id and billingAccountId >>>>> (this is the service that is invoked when you click on the "capture" >>>>> link near the invoice in the billingaccoun-invoices screen) >>>>> >>>>> b) the new service can be invoked by a new link ("apply payments to >>>>> invoices") at the top of the billing account->invoices screen or (maybe >>>>> in your custom application) triggered every time you associate a >> payment >>>>> to a billing account. >>>>> >>>>> This should cover your requirements but it is also generic enough to be >>>>> a good fit for OFBiz. >>>>> >>>>> What do you think? >>>>> >>>>> Jacopo >>>>> >>>>>> Is this too simplistic for some reason I am missing? Do others have >> AR >>>>>> needs outside this that would justify a more complicated transaction >> set? >>>>>> Skip > |
Thanks Jacopo, I'll implement it in this way and see how it goes.
Skip -----Original Message----- From: Jacopo Cappellato [mailto:[hidden email]] Sent: Monday, October 29, 2007 12:05 PM To: [hidden email] Subject: Re: Accounts Receivable skip@theDevers wrote: > Jacopo > > The assumtion for me is that these are all dealing with billing accounts. > No billing account, no AR. Stated differently, the sum of billing account > invoices - (billing account payments + store credits) = Accounts Receivable. > Is there some billing account entity I missed to hold credits? If you get a payment from a customer, and you completely associate it (with a PaymentApplication record) to the customer's billing account, then you apply it to the invoices in the account and let's say that 10$ are left (overpayment), these dollars will increase tha vailable amount in the billing account (because they are not applied to any invoice) and so you can use them for future orders Jacopo > > Skip > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Monday, October 29, 2007 11:50 AM > To: [hidden email] > Subject: Re: Accounts Receivable > > > Hi Skip, > > skip@theDevers wrote: >> Okeydokey Jacques, moved the discussion here (in spite of the fact that > I'll >> get another gazillion emails to sort through :). >> >> One final issue to deal with for me, and that is credits. Right now, if > you >> overpay, you get an orphan PaymentApplication (no Invoice). This is fine >> for computing the balance, but there is no detail record when printing a >> statement. >> >> This may be fine (just printing an overpayment line or whatever), but in > the >> past, I have always created a miscellaneous credit that was applied (for >> aging purposes) when the next order was received (similiar to the way a >> store credit works now). >> >> Does anyone see any harm in creating a store credit (so we can utilize >> existing logic) for overpayments? >> > > what about using a billing account to catch the overpayment amount? you > can associate the amount to the billing account and then use it later. > > Jacopo > > >> Skip >> >>> Hi Scott, >>> >>> Scott Gray wrote: >>>> Hi Jacopo >>>> >>>> Our customers generally make payments for a specific invoice or group >>>> of invoices so this wouldn't work for us. In our current system (non >>>> web UI) we log a payment and then use a screen with a list of open >>>> invoices to allocate the payment with the payment balance reducing as >>>> each invoice is selected. >>>> >>> I think that you have perfectly described what is currently implemented >>> in OFbiz :-) >>> Maybe I'm not been very clear on this: I was not suggesting to modify >>> the existing payment/payment application screens; instead I was >>> suggesting to add a new option, for billing accounts, to apply billing >>> account payments to billing account invoices by date; of course you can >>> continue, also in the billing account, to apply payments to specific >>> invoices. >>> >>> Cheers, >>> >>> Jacopo >>> >>> >>>> Regards >>>> Scott >>>> >>>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: >>>>> skip@theDevers wrote: >>>>>> Jacopo >>>>>> >>>>>> As the man with the plan, >>>>> uhm... me? :-) >>>>> >>>>>> I wanted to throw this new plan past you. I have >>>>>> dug pretty deeply into the existing payment/billing account stuff >> it >>>>>> all seems a bit arcane to me and mostly because it looks like payments >> are >>>>>> meant to be made from the company to a vendor and from a customer to >> the >>>>>> company, all with the same screens. >>>>>> >>>>>> I want to create a really easy to use AR payment system. The user >> enters a >>>>>> payment and can then either apply the payment to individual invoices >> (and a >>>>>> store credit if too much is received) or he can apply it to the >> billing >>>>>> account, in which case we automatically apply it to the oldest >> invoices >>>>>> first and then to a credit if too much is received. >>>>>> >>>>> I'd suggest the following subtasks: >>>>> >>>>> a) implement a new service to automatically apply the payments >>>>> associated to a billing account to the older open invoices associated >> to >>>>> the same account; the new service will have one mandatory parameter >>>>> "billingAccountId" (and maybe one optional parameter "paymentId") and >> it >>>>> will: >>>>> - select the open invoices associated to the billing account and sort >>>>> them by date (older first) >>>>> - iterate on the list and for each of them call the service >>>>> capturePaymentsByInvoice passing in the invoice id and >>>>> (this is the service that is invoked when you click on the "capture" >>>>> link near the invoice in the billingaccoun-invoices screen) >>>>> >>>>> b) the new service can be invoked by a new link ("apply payments to >>>>> invoices") at the top of the billing account->invoices screen or (maybe >>>>> in your custom application) triggered every time you associate a >> payment >>>>> to a billing account. >>>>> >>>>> This should cover your requirements but it is also generic enough to be >>>>> a good fit for OFBiz. >>>>> >>>>> What do you think? >>>>> >>>>> Jacopo >>>>> >>>>>> Is this too simplistic for some reason I am missing? Do others have >> AR >>>>>> needs outside this that would justify a more complicated transaction >> set? >>>>>> Skip > |
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? 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 On 30/10/2007, skip@theDevers <[hidden email]> wrote: > Thanks Jacopo, I'll implement it in this way and see how it goes. > > Skip > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Monday, October 29, 2007 12:05 PM > To: [hidden email] > Subject: Re: Accounts Receivable > > > skip@theDevers wrote: > > Jacopo > > > > The assumtion for me is that these are all dealing with billing accounts. > > No billing account, no AR. Stated differently, the sum of billing account > > invoices - (billing account payments + store credits) = Accounts > Receivable. > > Is there some billing account entity I missed to hold credits? > > If you get a payment from a customer, and you completely associate it > (with a PaymentApplication record) to the customer's billing account, > then you apply it to the invoices in the account and let's say that 10$ > are left (overpayment), these dollars will increase tha vailable amount > in the billing account (because they are not applied to any invoice) and > so you can use them for future orders > > Jacopo > > > > > Skip > > > > -----Original Message----- > > From: Jacopo Cappellato [mailto:[hidden email]] > > Sent: Monday, October 29, 2007 11:50 AM > > To: [hidden email] > > Subject: Re: Accounts Receivable > > > > > > Hi Skip, > > > > skip@theDevers wrote: > >> Okeydokey Jacques, moved the discussion here (in spite of the fact that > > I'll > >> get another gazillion emails to sort through :). > >> > >> One final issue to deal with for me, and that is credits. Right now, if > > you > >> overpay, you get an orphan PaymentApplication (no Invoice). This is fine > >> for computing the balance, but there is no detail record when printing a > >> statement. > >> > >> This may be fine (just printing an overpayment line or whatever), but in > > the > >> past, I have always created a miscellaneous credit that was applied (for > >> aging purposes) when the next order was received (similiar to the way a > >> store credit works now). > >> > >> Does anyone see any harm in creating a store credit (so we can utilize > the > >> existing logic) for overpayments? > >> > > > > what about using a billing account to catch the overpayment amount? you > > can associate the amount to the billing account and then use it later. > > > > Jacopo > > > > > >> Skip > >> > >>> Hi Scott, > >>> > >>> Scott Gray wrote: > >>>> Hi Jacopo > >>>> > >>>> Our customers generally make payments for a specific invoice or group > >>>> of invoices so this wouldn't work for us. In our current system (non > >>>> web UI) we log a payment and then use a screen with a list of open > >>>> invoices to allocate the payment with the payment balance reducing as > >>>> each invoice is selected. > >>>> > >>> I think that you have perfectly described what is currently implemented > >>> in OFbiz :-) > >>> Maybe I'm not been very clear on this: I was not suggesting to modify > >>> the existing payment/payment application screens; instead I was > >>> suggesting to add a new option, for billing accounts, to apply billing > >>> account payments to billing account invoices by date; of course you can > >>> continue, also in the billing account, to apply payments to specific > >>> invoices. > >>> > >>> Cheers, > >>> > >>> Jacopo > >>> > >>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: > >>>>> skip@theDevers wrote: > >>>>>> Jacopo > >>>>>> > >>>>>> As the man with the plan, > >>>>> uhm... me? :-) > >>>>> > >>>>>> I wanted to throw this new plan past you. I have > >>>>>> dug pretty deeply into the existing payment/billing account stuff > and > >> it > >>>>>> all seems a bit arcane to me and mostly because it looks like > payments > >> are > >>>>>> meant to be made from the company to a vendor and from a customer to > >> the > >>>>>> company, all with the same screens. > >>>>>> > >>>>>> I want to create a really easy to use AR payment system. The user > >> enters a > >>>>>> payment and can then either apply the payment to individual invoices > >> (and a > >>>>>> store credit if too much is received) or he can apply it to the > >> billing > >>>>>> account, in which case we automatically apply it to the oldest > >> invoices > >>>>>> first and then to a credit if too much is received. > >>>>>> > >>>>> I'd suggest the following subtasks: > >>>>> > >>>>> a) implement a new service to automatically apply the payments > >>>>> associated to a billing account to the older open invoices associated > >> to > >>>>> the same account; the new service will have one mandatory parameter > >>>>> "billingAccountId" (and maybe one optional parameter "paymentId") and > >> it > >>>>> will: > >>>>> - select the open invoices associated to the billing account and sort > >>>>> them by date (older first) > >>>>> - iterate on the list and for each of them call the service > >>>>> capturePaymentsByInvoice passing in the invoice id and > billingAccountId > >>>>> (this is the service that is invoked when you click on the "capture" > >>>>> link near the invoice in the billingaccoun-invoices screen) > >>>>> > >>>>> b) the new service can be invoked by a new link ("apply payments to > >>>>> invoices") at the top of the billing account->invoices screen or > (maybe > >>>>> in your custom application) triggered every time you associate a > >> payment > >>>>> to a billing account. > >>>>> > >>>>> This should cover your requirements but it is also generic enough to > be > >>>>> a good fit for OFBiz. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Jacopo > >>>>> > >>>>>> Is this too simplistic for some reason I am missing? Do others have > >> AR > >>>>>> needs outside this that would justify a more complicated transaction > >> set? > >>>>>> Skip > > > > > |
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 > |
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 > > > |
In reply to this post by Scott Gray
Scott
I have decided to rewrite this logic (and am half way through the process). This whole thing is way more complicated than it needs to be as well as being prone to errors. We have Invoices and Payments (and related) and unbilled OrderHeader. I may run across some other entities in my testing that affect things, but so far, that it and it all works just fine. The other advantage to this is that the customer statemenets I am printing come from exactly the same data. Skip -----Original Message----- From: Scott Gray [mailto:[hidden email]] Sent: Thursday, November 01, 2007 2:59 AM To: [hidden email] Subject: Re: Accounts Receivable 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? 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 On 30/10/2007, skip@theDevers <[hidden email]> wrote: > Thanks Jacopo, I'll implement it in this way and see how it goes. > > Skip > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Monday, October 29, 2007 12:05 PM > To: [hidden email] > Subject: Re: Accounts Receivable > > > skip@theDevers wrote: > > Jacopo > > > > The assumtion for me is that these are all dealing with billing > > No billing account, no AR. Stated differently, the sum of billing account > > invoices - (billing account payments + store credits) = Accounts > Receivable. > > Is there some billing account entity I missed to hold credits? > > If you get a payment from a customer, and you completely associate it > (with a PaymentApplication record) to the customer's billing account, > then you apply it to the invoices in the account and let's say that 10$ > are left (overpayment), these dollars will increase tha vailable amount > in the billing account (because they are not applied to any invoice) and > so you can use them for future orders > > Jacopo > > > > > Skip > > > > -----Original Message----- > > From: Jacopo Cappellato [mailto:[hidden email]] > > Sent: Monday, October 29, 2007 11:50 AM > > To: [hidden email] > > Subject: Re: Accounts Receivable > > > > > > Hi Skip, > > > > skip@theDevers wrote: > >> Okeydokey Jacques, moved the discussion here (in spite of the fact that > > I'll > >> get another gazillion emails to sort through :). > >> > >> One final issue to deal with for me, and that is credits. Right now, > > you > >> overpay, you get an orphan PaymentApplication (no Invoice). This is fine > >> for computing the balance, but there is no detail record when printing a > >> statement. > >> > >> This may be fine (just printing an overpayment line or whatever), but in > > the > >> past, I have always created a miscellaneous credit that was applied (for > >> aging purposes) when the next order was received (similiar to the way a > >> store credit works now). > >> > >> Does anyone see any harm in creating a store credit (so we can utilize > the > >> existing logic) for overpayments? > >> > > > > what about using a billing account to catch the overpayment amount? you > > can associate the amount to the billing account and then use it later. > > > > Jacopo > > > > > >> Skip > >> > >>> Hi Scott, > >>> > >>> Scott Gray wrote: > >>>> Hi Jacopo > >>>> > >>>> Our customers generally make payments for a specific invoice or group > >>>> of invoices so this wouldn't work for us. In our current system (non > >>>> web UI) we log a payment and then use a screen with a list of open > >>>> invoices to allocate the payment with the payment balance reducing as > >>>> each invoice is selected. > >>>> > >>> I think that you have perfectly described what is currently > >>> in OFbiz :-) > >>> Maybe I'm not been very clear on this: I was not suggesting to modify > >>> the existing payment/payment application screens; instead I was > >>> suggesting to add a new option, for billing accounts, to apply billing > >>> account payments to billing account invoices by date; of course you can > >>> continue, also in the billing account, to apply payments to specific > >>> invoices. > >>> > >>> Cheers, > >>> > >>> Jacopo > >>> > >>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote: > >>>>> skip@theDevers wrote: > >>>>>> Jacopo > >>>>>> > >>>>>> As the man with the plan, > >>>>> uhm... me? :-) > >>>>> > >>>>>> I wanted to throw this new plan past you. I have > >>>>>> dug pretty deeply into the existing payment/billing account stuff > and > >> it > >>>>>> all seems a bit arcane to me and mostly because it looks like > payments > >> are > >>>>>> meant to be made from the company to a vendor and from a customer > >> the > >>>>>> company, all with the same screens. > >>>>>> > >>>>>> I want to create a really easy to use AR payment system. The user > >> enters a > >>>>>> payment and can then either apply the payment to individual invoices > >> (and a > >>>>>> store credit if too much is received) or he can apply it to the > >> billing > >>>>>> account, in which case we automatically apply it to the oldest > >> invoices > >>>>>> first and then to a credit if too much is received. > >>>>>> > >>>>> I'd suggest the following subtasks: > >>>>> > >>>>> a) implement a new service to automatically apply the payments > >>>>> associated to a billing account to the older open invoices > >> to > >>>>> the same account; the new service will have one mandatory parameter > >>>>> "billingAccountId" (and maybe one optional parameter "paymentId") and > >> it > >>>>> will: > >>>>> - select the open invoices associated to the billing account and sort > >>>>> them by date (older first) > >>>>> - iterate on the list and for each of them call the service > >>>>> capturePaymentsByInvoice passing in the invoice id and > billingAccountId > >>>>> (this is the service that is invoked when you click on the "capture" > >>>>> link near the invoice in the billingaccoun-invoices screen) > >>>>> > >>>>> b) the new service can be invoked by a new link ("apply payments to > >>>>> invoices") at the top of the billing account->invoices screen or > (maybe > >>>>> in your custom application) triggered every time you associate a > >> payment > >>>>> to a billing account. > >>>>> > >>>>> This should cover your requirements but it is also generic enough to > be > >>>>> a good fit for OFBiz. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Jacopo > >>>>> > >>>>>> Is this too simplistic for some reason I am missing? Do others > >> AR > >>>>>> needs outside this that would justify a more complicated transaction > >> set? > >>>>>> Skip > > > > > |
In reply to this post by Scott Gray
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 > > > |
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 >>> |
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 > >>> > > > |
A quick question here. Isn't maxAmount *not* supposed to tally with the
order amounts? I always thought that maxAmount is simply a "billing instruction", which means "do not charge more than X amount on this credit card". Based on that understanding, I would expect the totalled maxAmount(s) from several payment methods stacked on a single order to be way higher than the order grand total. Say I might have 4-5 credit cards with a combined "maxAmount" of $30K, but my order grand total could be just $50. Is my understanding correct in terms of payment methods and payment gateway concepts? I know that OFBiz doesn't quite handle maxAmount in that way. Yes, I believe there's a bug with the maxAmount whenever it is "assumed" from the "order's total outstanding amount" (amount not addressed by any planned payments). A common way to reproduce this bug is by using a mixture of offline payments and credit card payments for a single order. Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its limits now). Jonathon Scott Gray 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 >>>>> >>>>> >> >> > > > |
In reply to this post by Scott Gray
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 > > >>> > > > > > > > |
In reply to this post by Jacopo Cappellato
Jacapo
With the current situation, there is no guaranteed way to report on the details of a billing account, as in what invoices are unpaid, when an invoice was payed, what payment was applied to what invoice, etc. It is possible to apply a payment to an invoice, but not required. The use of OrderPaymentPreference to compute billing account balances is flawed in that it sometimes misses taxes, and shipping charges or other miscellaneous charges. This is currently a minor issue because the amounts are small and not seen by the customer unless they look closely. However, it becomes a major issue when you start sending out billing statements and especially dunn letters. Also, I just don't like accounting errors and that to me is really the issue here. These numbers are not taken from the underlying data and while they may be right sometimes, because the raw data is not used to construct them, they are guaranteed to be wrong sometime. The raw data in this case are the invoices and payments on the account. Things would be simple if Payments had a billingAccountId field, but alas, because it does not, the PaymentAndApplication view entity can be used in its place. It just makes the reporting a little harder. The above is what this proposal accomplishes, i.e. moving the reporting away from secondary data sources onto the primary. It is accomlished by creating a new org.obfiz.accounting.ar package that contains some new services and routines to replace some existing ones currently found in BillingAccountWorker. I currently have this all in a hot-deploy/ar directory. What is not done is the Ofbiz GUI work. I have been testing the logic using either java standalone applications or modified Opentaps. After getting it running, I would test against Ofbiz, but making sure that I "did the right thing". TODO in Ofbiz GUI is to remove the opportunity to do the wrong thing, which in this case is applying a payment to anything but an invoice. I have a single button click routine to apply a payment to invoices beginning with the oldest, but I have not hooked it up to Ofbiz code and won't unless this becomes mainsteamed. Skip -----Original Message----- From: Jacopo Cappellato [mailto:[hidden email]] Sent: Thursday, November 01, 2007 11:09 PM To: [hidden email] Subject: Re: Accounts Receivable 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 > 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 >>> |
In reply to this post by Scott Gray
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 > > 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 > >> 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 > >>> > > > |
In reply to this post by jonwimp
Jonathon
I would have to defer to your massive Ofbiz knowledge regarding "maxAmount". I personally do not believe the entity should be used at all for billing accounts. What I want to comment on is your statement "Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its limits now)." My response? YAAAAAAAAAAA Skip -----Original Message----- From: Jonathon -- Improov [mailto:[hidden email]] Sent: Friday, November 02, 2007 1:18 AM To: [hidden email] Subject: Re: Accounts Receivable A quick question here. Isn't maxAmount *not* supposed to tally with the order amounts? I always thought that maxAmount is simply a "billing instruction", which means "do not charge more than X amount on this credit card". Based on that understanding, I would expect the totalled maxAmount(s) from several payment methods stacked on a single order to be way higher than the order grand total. Say I might have 4-5 credit cards with a combined "maxAmount" of $30K, but my order grand total could be just $50. Is my understanding correct in terms of payment methods and payment gateway concepts? I know that OFBiz doesn't quite handle maxAmount in that way. Yes, I believe there's a bug with the maxAmount whenever it is "assumed" from the "order's total outstanding amount" (amount not addressed by any planned payments). A common way to reproduce this bug is by using a mixture of offline payments and credit card payments for a single order. Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its limits now). Jonathon Scott Gray 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 >>> 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 >>>> 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 >>>>> >>>>> >> >> > > > |
In reply to this post by Scott Gray
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 > > 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 > > > 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 > > >>> 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 > > >>> > > > > > > > |
Here's the diff:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/src/org/ofbiz/order/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 > > > >>> > > > > > > > > > > > > > |
In reply to this post by SkipDever
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 > > >>> > > > > > > > > |
Free forum by Nabble | Edit this page |