[
https://issues.apache.org/jira/browse/OFBIZ-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharan Foga updated OFBIZ-4513:
-------------------------------
Sprint: Bug Crush Event - 21/2/2015
> Make customer refunds possible for billing account payments
> -----------------------------------------------------------
>
> Key: OFBIZ-4513
> URL: https://issues.apache.org/jira/browse/OFBIZ-4513
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
> Affects Versions: Trunk
> Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4513.patch
>
>
> We at [Lusini|http://www.lusini.de/] 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
> * 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
> * 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.
> * 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
