I am thinking about the issue of overpayments and credit invoices. Currently, I am creating a customer return invoice for an overpayment and applying the unused part of a payment to it.
I like the idea of having this Invoice for detailed reporting. However, it makes the later re-application of this payment harder. It would be simplerer to leave the unapplied part of the payment alone (and create a zero total "informational" Invoice) and then have a seca service that went out and found un-applied payments to apply whenever a new sales Invoice was created. The downside of this simplistic approach is that SUM(PaymentApplication.amountApplied for a paymentId) has to equal the Payment.amount. That is currently not the case with returns and I suspect a few other areas. I could also use SUM(PaymentApplication.amountApplied for a paymentId + billingAccountId). That would ignore these extra PaymentApplication which have the billingAccountId blank. Anyone have any thoughts on this? If I knew the purpose of the extra PaymentApplication with the blank billingAccountId, I make a better decision. Skip -----Original Message----- From: Jacopo Cappellato [mailto:[EMAIL PROTECTED] Sent: Friday, November 02, 2007 11:32 PM To: [email protected] Subject: Re: Accounts Receivable Hi Skip, [EMAIL PROTECTED] wrote: > Scott > > In my view, this is kinda the hard way of doing things. > > Easy way: > > billing account amount = SUM(unpaid invoice amounts) > billing account available balance = billing acount limit - (billing account > amount + uninvoiced orders) > > Because customer returns and credits also generate an invoice, this all > works. > > Simple as long as you can determine which invoices are unpaid. Of course, > If you are gonna do a proper customer billing statement, you have to know > this anyway. > > I have no idea why you guys feel the need to cling to this > OrderPaymentPreferences entity for computing billing accounts. > > Skip > Please, when fixing this, also consider the following situations: a) if you select, during order entry, an offline payment, then in the order detail screen you can receive the payment (also a partial payment) even if there are no invoices for the order: the system creates a Payment record with no PaymentApplications (the Payment is associated to the OrderPaymentPreference) b) an order, associated to a billing account could be only partially invoiced (partially shipped order) c) handle payment in advance: the customer fills the billing account with a payment, and then consume that amount to pay orders Jacopo
