Error when fiscalizing a return check

[quote] Farkhshatov Rodion wrote: From today I get an error: "An error has occurred. Validation error The amount of payments cannot be less than the amount of the check" [/quote] This error is thrown by the Checkbox API [quote] Farkhshatov Rodion wrote: Have you changed something? [/quote] Not Probably the checks on their side have been finalized in the Checkbox - you can check this point with their technical support

I clarified that they changed the validation, and it is necessary that the amount be transmitted. I tried to make a payment in the process, but the error is the same and occurs due to the fact that the payment is outgoing. With incoming it turns out, but this is the process of returning payment. Can you add a setting so that the process amount is transmitted as the payment amount when the return check is made?

can you just fix the basic return logic without modification? Outgoing payment does not generate a return receipt

Without rework, I can only make a minor improvement if you are a user of a paid cloud plan. But since you have a box (purchased by AS IS) - we have no obligation to perform any improvements for free (this is not a mistake on our part, but innovations from a third-party service).

[quote] Tyndyk Maxim Vadimovich OneBox production wrote: [quote] Farkhshatov Rodion wrote: Can you add a setting so that the process amount is transmitted as the payment amount when the return check is made? [/quote] Yes, we can - such a revision will take 1 hour. Bill? [/quote] Willing to pay half.

[quote] Farkhshatov Rodion wrote: Can you add a setting so that the process amount is transmitted as the payment amount when the return check is made? [/quote] This is a Wishlist / improvement, because this is a departure from the basic logic of the return operation (when the return implies a chargeback). And this option is more suitable for me, and I am ready to share the cost of revision with Alexander. Submit an invoice. And the fact that the basic function of a return check with an outgoing payment in the process does not work for you is an unfinished integration. You have integration. There have been changes in it, integration does not work for clients. Are you going to make changes in this case? But how is it an improvement? If Nova Poshta now changes something in the API, and the integrations fall off, do you also plan to upgrade it? And since the fiscalization of the return check passes with the incoming payment, the amount is still transferred, and the problem arises when the payment is outgoing. It turns out that you did not initially foresee this, and the validation at that time did not produce an error. Why doesn't it work with outgoing payment? Do you transfer the amount with a minus?

[quote] Farkhshatov Rodion wrote: This is a Wishlist / improvement, because this is a departure from the basic logic of the return operation (when the return implies a chargeback). And this option is more suitable for me, and I am ready to share the cost of revision with Alexander. Submit an invoice. [/quote] I'll arrange for you to be billed. [quote] Farkhshatov Rodion wrote: And the fact that the basic function of a return check with an outgoing payment in the process does not work for you is an unfinished integration. [/quote] I remind you that you purchased the boxed version of the product (as it is at the time of purchase) - initially there was no such integration at all. The integration was done exactly as required by the API at the time of its implementation. [quote] Farkhshatov Rodion wrote: You have integration. There have been changes in it, integration does not work for clients. Are you going to make changes in this case? But how is it an improvement? [/quote] We will make changes and update our paid cloud clients - their tariff implies small improvements, etc. Your vision now is equivalent to the fact that I can take a car bought 4 years ago and come to an official dealer and demand free tuning of my car, because I once bought it from them, they are now obliged to me all my life. As far as I know, we only owe you the correction of errors on our part. And changes in a third-party service are not our fault. [quote] Farkhshatov Rodion wrote: If Nova Poshta now changes something in the API, and the integrations fall off, do you also plan to upgrade it? [/quote] If they change something on their side, while breaking the current integration work, there will be 2 solutions: 1. We are making changes and updating cloud clients, because their paid plans imply such support. 2. For users of boxed versions - revision (at least get New Post to make 2 api options, or pay for revision instead of you) If this is a new functionality that someone needs - this is a refinement / improvement depending on the complexity / time / tariff of the client. [quote] Farkhshatov Rodion wrote: And since the fiscalization of the return check passes with the incoming payment, the amount is still transferred, and the problem arises when the payment is outgoing. It turns out that you did not initially foresee this, and the validation at that time did not produce an error. Why doesn't it work with outgoing payment? Do you transfer the amount with a minus? [/quote] We should not have provided for something that was not indicated in the terms of reference or documentation of the service with which the integration is being done. For that matter, and you claim that we should have done your integration differently - justify this with the terms of reference for integration, as well as the service documentation https://dev-api.checkbox.in.ua/api/redoc#operation/create_receipt_api_v1_receipts_sell_post - where exactly it is indicated about the payment transfer format - at least it is indicated there that the value can take the integer data format - and these are values \u200b\u200bfrom −2 147 483 648 to 2 147 483 647. And without indicating that in the documentation, we consider it logical that incoming payments is a positive amount, and outgoing (returning amount) is a negative amount.

[quote] Tyndyk Maxim Vadimovich OneBox production wrote: We will make changes and update our paid cloud clients - their tariff implies small improvements, etc. Your vision now is equivalent to the fact that I can take a car bought 4 years ago and come to an official dealer and demand free tuning of my car, because I once bought it from them, they are now obliged to me all my life. As far as I know, we only owe you the correction of errors on our part. And changes in a third-party service are not our fault. [/quote] You are talking about tuning (this is a refinement / improvement), but the fact that some kind of integration falls off is a repair. I bought software with integration, for example, Nova Poshta. After a while, the integration stopped working. And I, as a client, should not worry about the reason, be it an API update or something else. I need to have an always working integration that I paid for. It's like the Chrome browser will change something, and on iPhones it will stop opening. Apple won't tell you to pay extra for us to make changes. For this, there are updates that are regulated by you too, aren't they? [quote] Tyndyk Maxim Vadimovich OneBox production wrote: For that matter, and you claim that we should have done your integration differently - justify this with the terms of reference for the integration, as well as the service documentation https://dev-api.checkbox.in.ua/api/redoc#operation/create_receipt_api_v1_receipt. .. - where exactly it is indicated about the payment transfer format - at least it indicates that the value can take the integer data format - and these are values \u200b\u200bfrom −2 147 483 648 to 2 147 483 647. And without indicating that in the documentation, we consider it logical, that incoming payments are a positive amount, and outgoing (amount returned) is a negative amount. [/quote] The API specifies the payment type RETURN http://joxi.ru/KAg5e35IN95EVm, i.e. you indicate that this is a return and at the same time transfer the minus amount. And the return of a minus is like 2 times a minus, i.e. eventually +. It's only in your box that you have minuses on outgoing payments, other systems do not understand this. It is logical that a positive amount is transmitted and it is separately reported that this is a return.

[file]9252[/file]

[file]9253[/file]

[quote] Farkhshatov Rodion wrote: You are talking about tuning (this is a refinement / improvement), but the fact that some kind of integration falls off is a repair. [/quote] I can bring a bunch of other analogies - the essence does not change. [quote] I bought software with integration, for example, Nova Poshta. After a while, the integration stopped working. And I, as a client, should not worry about the reason, be it an API update or something else. I need to have an always working integration that I paid for. [/quote] You bought the software "as is" - you got it. I don't think you have a legal basis for us to owe you anything other than fixing bugs on our end (changes to how a third party API works is not a product bug). If you think otherwise, it is your right to turn to the management, possibly with a court claim, and decide there who owes you what in this case. [quote] It's like the Chrome browser will change something, and on iPhones it will stop opening. Apple won't tell you to pay extra for us to make changes. For this, there are updates that are regulated by you too, aren't they? [/quote] Our support and updates are regulated in cloud rates, which are updated and supported. [quote] Farkhshatov Rodion wrote: The API specifies the payment type RETURN http://joxi.ru/KAg5e35IN95EVm, i.e. you indicate that this is a return and at the same time transfer the minus amount. And the return of a minus is like 2 times a minus, i.e. eventually +. It's only in your box that you have minuses on outgoing payments, other systems do not understand this. It is logical that a positive amount is transmitted and it is separately reported that this is a return. [/quote] According to the receipt creation documentation at the time of integration (including in your case) https://dev-api.checkbox.in.ua/api/redoc#operation/create_receipt_api_v1_receipts_sell_post there are no payment types you specified (screenshot in the application). To indicate that something should work differently for you, please be so kind as to justify this with a technical task, an agreement, or any other documents that will agree on the specific logic of the integration in your box. I appreciated the improvement of your boxed version, or I can offer you the option of switching to a paid cloud plan - and then we will support such moments in the form of improvements at our expense. If you are not satisfied with any of these options - this is your right. [file]9254[/file]

Since I am ready to pay half for improvements, the question is: will it be implemented on the MVP version

[quote] Grabovsky Alexander wrote: Since I am ready to pay half for improvements, the question is: will it be implemented on the MVP version [/quote] If you pay for revision - it will be implemented on your version of the product (in this case, MVP) and updated for you immediately after it is completed

[quote] Tyndyk Maxim Vadimovich OneBox production wrote: [quote] Grabovsky Alexander wrote: Since I am ready to pay half for improvements, the question is: will it be implemented on the MVP version [/quote] If you pay for revision - it will be implemented on your version of the product (in this case, MVP) and updated for you immediately after it is completed [/quote] Rodion pays. I give him half. I don't know what version it is

[quote] Grabovsky Alexander wrote: Rodion pays. [/quote] The invoice was posted yesterday. [quote] Grabovsky Alexander wrote: I don't know what version it is [/quote] Same MVP - both projects will be updated.

The bill is paid. I'm updating it: The total amount of the process is transferred to the amount of the fiscal receipt. A positive number. Return type. The presence of a payment in the process is not required.

[quote] Farkhshatov Rodion wrote: The total amount of the process is transferred to the amount of the fiscal receipt. A positive number. Return type. The presence of a payment in the process is not required. [/quote] I'm thinking, based on the comment https://crm-onebox.com/ru/ajax/download/9253/ - there will be no problems if, for example, the sales receipt was for 2 payments, and the return will be for 1? Maybe it would be better to take into account only incoming payments in action - and it turns out to transfer the same check, but with isReturn as they say - and already in the process you can add incoming payments, and after them outgoing ones (to go to 0) ?

I do not see a problem, the refund is made in one payment after the fact, one is transferred. But the essence of the revision is the opposite, so that the return check is fiscalized without any payments, as it was before the change in validation. We carry out a refund in the main process (order), and to fiscalize the refund, a subprocess is created, a product is added, and the Fiscal refund button is pressed. No payments. It needs to be exactly like that. Just transfer the amount of the process to the payment amount.

Improved the setting "When returning, send a payment for the amount of the process (regardless of the presence of payments)" When creating a return check and setting a new setting - instead of process payments, 1 payment will be transferred for the process amount in the base currency with the type and name according to the action settings

[quote] Tyndyk Maxim Vadimovich OneBox production wrote: Improved the setting "When returning, send a payment for the amount of the process (regardless of the presence of payments)" When creating a return check and setting a new setting - instead of process payments, 1 payment will be transferred for the process amount in the base currency with the type and name according to the action settings [/quote] Does not work https://drive.google.com/file/d/1BVY4D-dTtVaz6ifHNl8XqRwiBnmPbA67/view?usp=sharing

+