Details
-
Improvement
-
Status: Patch Available
-
Major
-
Resolution: Unresolved
-
Trunk, Upcoming Branch
-
None
-
None
-
Bug Crush Event - 21/2/2015
Description
We at Lusini made customer refunds possible for billing account payments. The following changes were done:
- changed BillingAccountWorker
- now considers refunded payments in balance
- handling cancelled and voided payment correctly when calculating the billing account unapplied payment sum
- factored out new method getUnappliedPaymentSum()
- fixed PaymentWorker.getPaymentApplied() to ignore billling-account-only applications
- according to http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#N20B07
- "A billing account does not change the flow of the normal Invoice and Payment processes. It simply allows for a more structured organisation of Invoices and Payments."
- so the method should simply ignore payment applications to billing accounts
- according to http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#N20B07
- improving Billing Account and accounting interface
- added form screen to facilitate the creation also outgoing payments for a billing account
- adding link to payment from payment list
- show link to payment in payment applications
- InvoiceServices
- fixed InvoiceServices#checkInvoicePaymentApplications and InvoiceWorker#getInvoiceApplied to distinguish between receipts and disbursements
- only auto-applying payments to sales invoices if payment direction matches invoice type
- moved duplicate code to new methods in InvoiceWorker, consider applications in "unconfirmed" status correctly
- removePaymentApplication does not actually remove the PaymentApplication entity any more when removing the invoice-to-payment application and the PaymentApplication also stores the application to a billing account
- createInvoiceForOrder only automatically applies incoming payments to sales invoices and outgoing payments to purchase invoices
- fixed InvoiceServices#checkInvoicePaymentApplications and InvoiceWorker#getInvoiceApplied to distinguish between receipts and disbursements
- PaymentServices#createPaymentApplication
- when trying to create a payment application with an amount that is higher than the payment amount, use the payment amount instead
- when trying to apply an amount to an invoice/payment that is higher than the invoice/payment amount, use the invoice/payment amount instead
- validating the invoice type
- incoming payments can only be applied to sales invoices and outgoing payments to purchase invoices
- preventing creation of payment applications with 0 or negative amount
- fixing payment type validation that was added by hansbak in r1186102
- compared the right entity fields
- added missing check-errors call
- NOTE: you have to make sure that for billing account payments you use the captureBillingAccountPayments service instead of the createPaymentApplication service for applying a payment to an invoice
- only the captureBillingAccountPayments correctly splits the payment application (split is necessary if payment amount applied to billing account is different than the one applied to the invoice)
- This is a side effect of the practice to use the same PaymentApplication record to both apply the payment to the billing account and to an invoice or another payment. We kept this behavior. It is problematic though:
- One issue we did not yet address here is applying payments to other payments. There is no equivalent of captureBillingAccountPayments when applying payments to payments; so no payment application split is done here.
- This is a side effect of the practice to use the same PaymentApplication record to both apply the payment to the billing account and to an invoice or another payment. We kept this behavior. It is problematic though:
- only the captureBillingAccountPayments correctly splits the payment application (split is necessary if payment amount applied to billing account is different than the one applied to the invoice)
- PaymentGatewayServices
- making sure that invoices are not applied to canceled payment when capturing from the billing account
- fixed missing accounting transaction for invoice payment application with billing account payment
- now triggering createAcctgTransAndEntriesForPaymentApplication directly from captureBillingAccountPayments as this service modifies the PaymentApplication records directly instead of calling the createPaymentApplication service – so the usual SECAs cannot be triggered here
- fixing if statements in test processors
- preserve billingAccountId on PaymentApplications when cancelling invoices
- not deleting PaymentApplication entites any more when un-applying them from an invoice if they apply the payment to a billing account