magento / community-features

Magento Features Development is an Initiative to Allows Community Memebers Join to Development of Magento Features
46 stars 18 forks source link

Suggestion: Change "adjustment refund" and "adjustment fee" #27

Open magento-engcom-team opened 6 years ago

magento-engcom-team commented 6 years ago

For credit memo, the terms "adjustment refund" and "adjustment fee" are confusing. They are neither proper accounting terms nor do they make sense. And the impetus to get terms right is because the actions are irreversible and it is easy to make mistakes if terms don't make sense.

Let me state my case.

"Adjustment Refund" Any figure entered here is added to the refund total. There are hardly any case which you need to refund a customer more than what he paid for. And the term isn't intuitive at all to tell you what it does is to add the amount to the refund total. Further, to do a partial refund, it makes sense that you are finding a field that says "adjustment to refund", and the closest you have is "Adjustment Refund", which sounds like what you want to do here except it doesn't -- it adds the amount to the refund total.

"Adjustment Fee" Any figure entered here is subtracted to the refund total. This is actually how you would do a partial refund. However, very few people will understand what is the meaning of an adjustment fee. A partial refund is a partial refund. You would say "I got a partial refund". You wont say "I got a full refund but charged an adjustment fee" -- which is exactly what the box really mean. Because nobody will understand the latter statement, nobody will understand this term "adjustment fee".

The solution is simple.

Provide a box that says "refund" and populate it with the default full product price. Then the admin can choose to refund less than the product price or more than the product price (which I state is rare but yes we may want to allow that to happen).

Then finally, the last line should be "Total amount to refund" instead of "subtotal". And this should be javascript binded to change according to the amounts entered.

Exactly because the process is 1) Very important because you are dealing with money, 2) Irreversible and 3) Error prone at present, therefore it is important to change it and improve with the above recommended features.

Preconditions

Magento version 2.1.8

Steps to reproduce

Attempt a refund

Expected result

Refunding makes sense.

Actual result

Refunding doesn't make sense.

Original Report: https://github.com/magento/magento2/issues/9053 by @calvintwr

aeu commented 6 years ago

100% agree with this ticket. As he says, the phrases "Adjustment Refund" and "Adjustment Fee" are not actual accounting terms, nor do they make any sense.

bardkalbakk commented 6 years ago

I just want to emphasize the importance of this request. Just had a chat with a client about this particular case and handling of online refund, which the name implies is an online refund through the VISA network and irreversible.

Exactly because the process is 1) Very important because you are dealing with money, 2) Irreversible and 3) Error prone at present, therefore it is important to change it and improve with the above recommended features.

erfanimani commented 4 years ago

I agree to make this happen. Although the existence of this ticket is documentation in and of itself (it's the top result for searching about the refund terms).

robbertstevens commented 4 years ago

The fact that this ticket is 3 years old, shows how much they care about fixing important issues.

snez commented 4 months ago

The only correct use case for adjustment fees and adjustment refunds, is when you would like to change the live refund amount based on a previous customer balance. In Adobe Commerce, this is what is called a "Store Credit", but the same concept does not exist in Magento 2 Open Source.

A store credit or customer balance is treated like a payment method and can be used to offset the final refund to the customer.

At the same time, it could also be used during invoicing of the order to offset the collected payment.

An example use case is for example, a customer buying a subscription using Stripe, and then subsequently downgrading their subscription plan. Stripe will adjust the customer balance, and use that to offset future subscription payments. We still want those future payments to be invoiced in full in Magento, but the invoice would need a customer balance adjustment, which was used to partially pay for that invoice.

I propose that both the adjustment fee and adjustment refund fields are combined into a single "Customer Balance" field, which can be used both during invoicing, as well as during credit memos, to offset the live payment or live refund amount.

In the case of invoicing, a negative value would mean that the customer balance is reduced, because it has been used to partially pay for the invoice.

In the case of a refund, a positive value would mean that the customer balance has increased, because the refund went into the customer's balance rather than back to their card.