Money Refund not alowed: "Invalid value: Payment must be a positive amount."

[radioeventos]

Describe the bug

Negative amounts are not allowed on payments made. You cannot write down full or partial refunds of money.

Expected behavior

How save a refund without negative amount?

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to 'Order detail'
2. Apply an discount or free shipping (when a same customer make 2 orders for the same adrees)
3. Go to 'Payments' and try to save the refund
4. See error "Invalid value: Payment must be a positive amount."

Screenshots

If applicable, add screenshots or screen recordings to help explain your problem.

Additional information

• PrestaShop version: 1.7.7
• PHP version: 7.2.34

[hibatallahAouadni]

Hello @radioeventos

You can't add negative value to the payment method. To balance an overdue by the clients, it is recommended to make a credit slip (See the original issue).

So, I close it cause it's not a bug.

Thanks!

[radioeventos]

This point has always been possible. What's more, how do I know at first glance if a customer has received a monetary refund or not, and the amount if it is a partial refund? This is basic accounting, if it is allowed to enter the amount of the payment, it should be possible to enter the amount of the refund.

A payment can be positive or negative. Another thing is that the Total cannot be negative, but partial refunds must be allowed and that these are recorded.
It is a very serious problem for the accounting of a store that the exact accounting balance of a customer cannot be known.

[siky]

This is a very frustrating "feature". If somebody want to use negative amount for payment (eg. refund accounting), he have to modify 3 core file:

src/PrestaShopBundle/Controller/Admin/Sell/Order/OrderController.php (line: 1109)
Add this line to the begin of the addPaymentAction() function:
\OrderPayment::$definition['fields']['amount'] = ['type' => \ObjectModel::TYPE_FLOAT, 'validate' => 'isAnything', 'required' => true];

src/Core/Domain/Order/Payment/Command/AddPaymentCommand.php (line: 173)
Comment/remove this line:
throw new NegativePaymentAmountException('The amount should be greater than 0.');

src/PrestaShopBundle/Form/Admin/Sell/Order/OrderPaymentType.php (line: 111)
Comment/remove this array:
'constraints' => [ ... ]

[pdkey]

Hello @radioeventos

You can't add negative value to the payment method. To balance an overdue by the clients, it is recommended to make a credit slip (See the original issue).

So, I close it cause it's not a bug.

Thanks!

Hi @hibatallahAouadni ,
How can you close this issue if your users do not want this change.

Example - rounding differences in payments of 0.01 €, we used to be able to adjust with -0.01 without any problems. Or overpayments.

How to create an credit slip to this in Prestashop without changing a purchased product?
From an accounting point of view, your change will involve additional personnel costs.

[matks]

I understand you find it very useful to have positive or negative payments but there is more than "is it easy or not to use" when it comes to payments.

AFAIK Product team is actually in the process of getting some law compliance people so that they can tell us what can be done or what cannot be done in order to comply with the law.

The very first thing to do is to verify what is legal and what is not.

After the legal background has been identified, then what the product should do or refuse can be explored.

That being said, remember this is an open source project and it aims to be extensible. If you disagree with PrestaShop built-in logic, you can build/buy a module that overrides these rules.

[pdkey]

hi @matks

thank you very much - Prestashop as an open source project is wonderful.

But in this case the change was as a stone in the regular order processing.

To the legal (basis German law):
We call this payment transaction as voucherless pass-through item.

Case study:
Prestashop and payment modules, such as Klarna create a payment error, due to incorrect rounding differences of 0,01 €. We change this in Presta with -0,01 €. The order value and invoice amount are equal to the payment in Klarna.

Without negative, the entire order must be canceled and the customer must trigger a new order.

This is cumbersome and there is a risk that a customer will not realize a new order.

There are many cases in the daily order processing what make this negative payment value necessary.

Legally, as described above, this is also a legal case. At least here in Germany.

[radioeventos]

Any accounting allows positive and negative amounts. Discounts, without going any further, are a negative amount and this is expressed in the same prestashop. If I make a payment to a customer for a return, there is no way to record said payment in the prestashop accounting. If the order has not been invoiced yet, because until it is sent it is not invoiced, how do I record that payment or that return, whatever you want to call it, in Prestashop? in any way or by hand in the private notes. A botch.
One thing is the credit document and another is the entry in accounting. This existed previously in Prestashop, if it has been removed for monetary reasons so that third parties and Prestashop itself profit from the sale of modules is another thing, but be clear and sincere.

[matks]

This existed previously in Prestashop, if it has been removed for monetary reasons so that third parties and Prestashop itself profit from the sale of modules is another thing, but be clear and sincere.

I have heard this story before. This is wrong, please don't assume bad intentions just because we disagree with you.

You provide good points and good things to think about, please focus on the good ideas you provide and leave the unnecessary ranting aside, following our Code of Conduct.

The topic is on @PrestaShop/product-team table. Many inputs are gathered, some compliance people will be involved because German law is one thing, but PrestaShop aims to be international 😅 . User inputs have been recorded, now let's let the @PrestaShop/product-team do his job.

[radioeventos]

It's easy to get rid of bad thoughts - provide a clear and concise explanation of why a required function is removed and that it is available in any management application or program. Does someone who really uses Prestashop on a daily basis to sell, not as a tester or programmer, get in the way of negative amounts in managing payments? Deleting a function just shows that the programmer does not really put himself in the shoes of the person who uses them or struggles with prestashop on a daily basis.

As long as that clear and objective explanation is not offered, I can think what I want and express it. I have not said at any time that it is not lawful to seek profitability, since for Prestashop it works for everyone and continues to be free at its base, the company behind it must be profitable.

[matks]

I am closing this topic as it's going in the wrong direction.