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:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 11:50 AM To: [email protected] Subject: Re: Accounts Receivable Hi Skip, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote: >>>> [EMAIL PROTECTED] 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 >>>> >
