OFBiz
  1. OFBiz
  2. OFBIZ-1243

Billing Accounts: wrong balance if payments are applied using the standard UI (cause: status of OrderPaymentPreference is not updated)

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: accounting
    • Labels:
      None

      Description

      From a mail by Rashko Rejmer with subject "RE: Billing Accounts" posted to the user ML on 2007-09-14:

      "If you create order that is payed with billing account(BA) then in OrderPaymentPreference
      entity is created record with status PAYMENT_NOT_RECEIVED. The account
      balance is calculated considering this entries and payments that are applied
      to the billing account, but are not applied to the invoice.
      Everything is OK if you create order, then invoice it, then create payment
      and apply it only to the BA(the best UI is throught the new form and service
      created recently in r574962 -
      https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billingAccountId=9010)
      and then use the capture ability from the BA -> invoices screen to apply
      this payment to the invoice too. In that case the the BA balance behaves as
      it should. This is because capture ability invokes the service
      "processCaptureSplitPayment" that takes care to update the status of the
      OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED).

      The problem is if you apply payments to the invoice from another UI(E.g
      https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paymentId=demo10000)
      the OrderPaymentPreference record is not updated - so BA balance is wrong."

        Activity

        Hide
        Jacopo Cappellato added a comment -

        I did more research on this and I'd say that this is not a bug strictly related to payments to billing accounts, that are working properly.
        The problem is a more general issue with offline payments: if an offline payments is received and applied to an invoice using the general purpose "Payment" screens in the Accounting application then the OrderPaymentPreference of the order(s) associated to the invoice is not updated to reflect this;
        you can recreate this with the following steps:
        1) enter an order and select the "offline" payment method for it
        2) approve the order and quick ship it
        3) do not use the "receive payments" link in the order detail screen; instead, go to Accounting->Payments and create a new incoming payments; then apply it to the order's invoice.
        The status of the OrderPaymentPreference will not change (NOT_RECEIVED) and in the order detail screen the "receive payment" link will still be visible.

        In order to fix this we shouldf probably add some logic to the "*paymentApplication" services to verify if there are OrderPaymentPreferences associated to the invoice and change their status.

        Show
        Jacopo Cappellato added a comment - I did more research on this and I'd say that this is not a bug strictly related to payments to billing accounts, that are working properly. The problem is a more general issue with offline payments: if an offline payments is received and applied to an invoice using the general purpose "Payment" screens in the Accounting application then the OrderPaymentPreference of the order(s) associated to the invoice is not updated to reflect this; you can recreate this with the following steps: 1) enter an order and select the "offline" payment method for it 2) approve the order and quick ship it 3) do not use the "receive payments" link in the order detail screen; instead, go to Accounting->Payments and create a new incoming payments; then apply it to the order's invoice. The status of the OrderPaymentPreference will not change (NOT_RECEIVED) and in the order detail screen the "receive payment" link will still be visible. In order to fix this we shouldf probably add some logic to the "*paymentApplication" services to verify if there are OrderPaymentPreferences associated to the invoice and change their status.
        Hide
        David E. Jones added a comment -

        or maybe implement it as an ECA and always have the OrderPaymentPreference status updated this way

        Show
        David E. Jones added a comment - or maybe implement it as an ECA and always have the OrderPaymentPreference status updated this way
        Hide
        Jacopo Cappellato added a comment -

        David,

        yes the ECA seems the best approach and I'd like to work on this.
        However I will probably need some advices about the logic of the new service

        Is the process we have to implement similar to this one?

        ECA on createPaymentApplication --> get the invoiceId to which the payment is applied --> get the orderId from the OrderItemBilling (and OrderAdjustmentBilling?) --> get the OrderPaymentPreferences --> compare (by payment method type) the amounts in the OrderPaymentPreferences with the sum of all the PaymentApplications related to the invoices associated to the orderId; if the OrderPaymentPreference.maxAmount <= sum(PaymentApplication.amount) (for the same payment method type) then mark the OrderPaymentPreference as received

        Show
        Jacopo Cappellato added a comment - David, yes the ECA seems the best approach and I'd like to work on this. However I will probably need some advices about the logic of the new service Is the process we have to implement similar to this one? ECA on createPaymentApplication --> get the invoiceId to which the payment is applied --> get the orderId from the OrderItemBilling (and OrderAdjustmentBilling?) --> get the OrderPaymentPreferences --> compare (by payment method type) the amounts in the OrderPaymentPreferences with the sum of all the PaymentApplications related to the invoices associated to the orderId; if the OrderPaymentPreference.maxAmount <= sum(PaymentApplication.amount) (for the same payment method type) then mark the OrderPaymentPreference as received
        Hide
        David E. Jones added a comment -

        Yes, that sequence looks about right (and a lot more detail than I've looked into so far on this one...).

        Many of those steps have a one to many relationship, for each some of them it might make sense to call another service instead of in-lining, but that is of course just a little detail of implementation (random thought...).

        Show
        David E. Jones added a comment - Yes, that sequence looks about right (and a lot more detail than I've looked into so far on this one...). Many of those steps have a one to many relationship, for each some of them it might make sense to call another service instead of in-lining, but that is of course just a little detail of implementation (random thought...).

          People

          • Assignee:
            Unassigned
            Reporter:
            Jacopo Cappellato
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development