OFBiz
  1. OFBiz
  2. OFBIZ-1381

If you Create and Ship an Order for a billing account and then create a store credit, a second billing account is created

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: Trunk
    • Fix Version/s: None
    • Component/s: accounting, order
    • Labels:
      None

      Description

      If you sell a WG-1111 to DemoCustCompany on a billing account, then ship it, then create a return on a store credit for the same Order/Invoice, the DemoCustomer will end up with two billing accounts. Do it again and he will have three.

      If this is not a "feature" that someone is using, I will fix it.

        Activity

        Hide
        Ashish Vijaywargiya added a comment -

        Based on Mridul's comment we can safely close this issue, Thanks Mridul. Thanks Skip Dever for creating the issue.

        Show
        Ashish Vijaywargiya added a comment - Based on Mridul's comment we can safely close this issue, Thanks Mridul. Thanks Skip Dever for creating the issue.
        Hide
        Mridul Pathak added a comment -

        I have checked multiple business scenarios along with the code itself and this issue cannot be generated, here is how current OOTB workflow works and is the expected behavior,

        1. If there is no billing account associated to a customer a new one is created and store credit is deposited
        2. If there already a billing account associated to the customer store credited would be deposited in the existing billing account
        3. If there are multiple billing accounts associated to the customer billing account with negative balance is given preference else first billing account from the list is selected and store credit is deposited.

        I have also reviewed the code and didn't find any code block that would possible generate this issue. I think we can safely close this issue now.

        Show
        Mridul Pathak added a comment - I have checked multiple business scenarios along with the code itself and this issue cannot be generated, here is how current OOTB workflow works and is the expected behavior, If there is no billing account associated to a customer a new one is created and store credit is deposited If there already a billing account associated to the customer store credited would be deposited in the existing billing account If there are multiple billing accounts associated to the customer billing account with negative balance is given preference else first billing account from the list is selected and store credit is deposited. I have also reviewed the code and didn't find any code block that would possible generate this issue. I think we can safely close this issue now.
        Hide
        Anil K Patel added a comment -

        A useful link for person who will pick up this issue

        https://cwiki.apache.org/confluence/display/OFBIZ/Billing+Account

        Show
        Anil K Patel added a comment - A useful link for person who will pick up this issue https://cwiki.apache.org/confluence/display/OFBIZ/Billing+Account
        Hide
        Adrian Crum added a comment -

        Reopening this because it is a legitimate bug.

        I am not aware of BillingAccount being replaced by FinAccount, and a quick look at the current data model makes it clear that it is not true.

        Show
        Adrian Crum added a comment - Reopening this because it is a legitimate bug. I am not aware of BillingAccount being replaced by FinAccount, and a quick look at the current data model makes it clear that it is not true.
        Hide
        Anil K Patel added a comment -

        Billing account is not preferred method for store credit. It exists in system because it was implemented for handling store credit before FinAccount implementation was done.

        FinAccount should be used for store credit transactions.

        Show
        Anil K Patel added a comment - Billing account is not preferred method for store credit. It exists in system because it was implemented for handling store credit before FinAccount implementation was done. FinAccount should be used for store credit transactions.
        Hide
        Jacopo Cappellato added a comment -

        We need a volunteer willing to review this ticket (especially the last comment from Vikas), recreate the issue and implement the suggested fix (or resolve the ticket if the issue is resolved in the trunk).

        Show
        Jacopo Cappellato added a comment - We need a volunteer willing to review this ticket (especially the last comment from Vikas), recreate the issue and implement the suggested fix (or resolve the ticket if the issue is resolved in the trunk).
        Hide
        Skip Dever added a comment -

        Sounds about right to me

        Show
        Skip Dever added a comment - Sounds about right to me
        Hide
        Vikas Mayur added a comment -

        There have been many changes to the store credit return process, please see OFBIZ-2502 for more details. The store credit now is done to an account (whether billing or financial account) based on the account preference setup on the product store. A new account is created, if not found. While you can specifically mention the account on the return header screen just to make sure that you do the store credit to the account you want.

        The bug I think is still valid. The part of the code at and beyond line 791 OrderReturnServices class can be improved in such a manner that if no billing account is found with -ve balance and if the default store credit on store is billing account than do the credit to billing account associated with particular order for which the refund is made, so that no new billing account is created. If no billing account is found, than simply create one.

        If that sounds like a right approach, let me know.

        Show
        Vikas Mayur added a comment - There have been many changes to the store credit return process, please see OFBIZ-2502 for more details. The store credit now is done to an account (whether billing or financial account) based on the account preference setup on the product store. A new account is created, if not found. While you can specifically mention the account on the return header screen just to make sure that you do the store credit to the account you want. The bug I think is still valid. The part of the code at and beyond line 791 OrderReturnServices class can be improved in such a manner that if no billing account is found with -ve balance and if the default store credit on store is billing account than do the credit to billing account associated with particular order for which the refund is made, so that no new billing account is created. If no billing account is found, than simply create one. If that sounds like a right approach, let me know.
        Hide
        Skip Dever added a comment -

        The supplied patch fixes the problem described in this one selected area (quickReturn). However, I am betting that there are other screens from which you can create returns and they would need to be patched similiarly.

        An alternate method would be to modify the OrderReturnServices.processCreditReturn() to look for an existing BillingAccount for the partyId, but this way is more flexible and allows to create a second billing account in some unknown circumstance.

        Just have to make sure it's done everywhere a credit return is done.

        Show
        Skip Dever added a comment - The supplied patch fixes the problem described in this one selected area (quickReturn). However, I am betting that there are other screens from which you can create returns and they would need to be patched similiarly. An alternate method would be to modify the OrderReturnServices.processCreditReturn() to look for an existing BillingAccount for the partyId, but this way is more flexible and allows to create a second billing account in some unknown circumstance. Just have to make sure it's done everywhere a credit return is done.
        Hide
        Skip Dever added a comment -

        This patch modifies a .bsh script to supply a billingAccountId if one exists in the OrderHeader and then creates a hidden field in the form so the billingAccountId is passed to the createReturnHeader service.

        Show
        Skip Dever added a comment - This patch modifies a .bsh script to supply a billingAccountId if one exists in the OrderHeader and then creates a hidden field in the form so the billingAccountId is passed to the createReturnHeader service.
        Hide
        Jacopo Cappellato added a comment -

        Yes,

        I've noticed this too and I agree that it should be fixed: if the customer has already a billing account, then the refund should be put in that account.

        Show
        Jacopo Cappellato added a comment - Yes, I've noticed this too and I agree that it should be fixed: if the customer has already a billing account, then the refund should be put in that account.

          People

          • Assignee:
            Ashish Vijaywargiya
            Reporter:
            Skip Dever
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development