finalization of the functionality for "spreading" a payment across several processes
you need to make it possible to post payments for several orders in the box, while retaining the original payment (its amount and details).
In other words.
there is a payment for 1000 hryvnia,
it needs to be tied to
- order 111 for the amount of UAH 50,
- order 222 for the amount of 100 UAH.
- accept the rest of the amount without reference to the order (850 UAH)
and keep its original values (amount, input. number, etc.)
there have already been requests on this topic that have been estimated at a cosmic number of hours
https://crm-onebox.com/ru/support/finances/3343-potribno-v-quotavtomaticheski-ra...
https://crm-onebox.com/support/finances/2022-raspredelenie-odnogo-platezha-mezhd...
I propose an implementation option that, in my opinion, is much less labor-intensive (but I could be wrong).
It consists in marking the original payment as virtual and creating separate payments in the lin
Original question is available on version: ru
In other words.
there is a payment for 1000 hryvnia,
it needs to be tied to
- order 111 for the amount of UAH 50,
- order 222 for the amount of 100 UAH.
- accept the rest of the amount without reference to the order (850 UAH)
and keep its original values (amount, input. number, etc.)
there have already been requests on this topic that have been estimated at a cosmic number of hours
https://crm-onebox.com/ru/support/finances/3343-potribno-v-quotavtomaticheski-ra...
https://crm-onebox.com/support/finances/2022-raspredelenie-odnogo-platezha-mezhd...
I propose an implementation option that, in my opinion, is much less labor-intensive (but I could be wrong).
It consists in marking the original payment as virtual and creating separate payments in the lin
Answers:
what do you think about the current functionality of spreading through the right panel of mass operations on processes or inside the payment distribution - did not fit?
26.11.2020, 17:34
Original comment available on version: ru
Not everything is as simple as you write.
As if the division of payments is already in editing - and it takes away part of the amount.
And so I understand that in theory it is possible to make a functional, that when, for example, a payment for 1000 UAH in editing was added to split it into 2 more by 500 and check the box that the payment is virtual - make a general system setup to check that if the payment is divided into a total amount and set that the main becomes "virtual" - do not reduce the amount of the main. Will this fit?
But according to the parent architecture - specify where and how you want to display that this particular payment is the parent of another? Any banal conclusion somewhere? or maybe not needed?
As if the division of payments is already in editing - and it takes away part of the amount.
And so I understand that in theory it is possible to make a functional, that when, for example, a payment for 1000 UAH in editing was added to split it into 2 more by 500 and check the box that the payment is virtual - make a general system setup to check that if the payment is divided into a total amount and set that the main becomes "virtual" - do not reduce the amount of the main. Will this fit?
But according to the parent architecture - specify where and how you want to display that this particular payment is the parent of another? Any banal conclusion somewhere? or maybe not needed?
26.11.2020, 17:37
Original comment available on version: ru
Ustimenko Igor
OneBox CTO wrote:
what do you think about the current functionality of spreading through the right panel of mass operations on processes or inside the payment distribution - did not fit?
The most global problem of this functionality is that the original payment amount is lost.
If after a while you try to make a reconciliation with the client, then it will be almost impossible to do this. And in general, it will create a lot of misunderstandings.
We look at the bank statement - we see a payment of 50,000 UAH, we look at the box - we see 10 payments for different amounts .... "ftf", any accountant or financier who has worked at least a little in the b2b segment will say and will be right)) .
26.11.2020, 17:57
Original comment available on version: ru
Tyndyk Maxim Vadimovich
Administrator wrote:
But according to the parent architecture - specify where and how you want to display that this particular payment is the parent of another? Any banal conclusion somewhere? or maybe not needed?
yes, this is how a payment that is part of the main payment could look like
Tyndyk Maxim Vadimovich
Administrator wrote:
And so I understand that in theory it is possible to make a functional, that when, for example, a payment for 1000 UAH in editing was added to split it into 2 more by 500 and check the box that the payment is virtual - make a general system setup to check that if the payment is divided into a total amount and set that the main becomes "virtual" - do not reduce the amount of the main. Will this fit?
quite suitable. actually this is what we are talking about
but there is one more very important
in the original payment (the one that became "virtual" after posting on it), you need to display a list of child payments. you can either display all child payments like this (+ add a column with a link to the payment so that you can "fail" into it)
or display a list of payments, 1v1 with the way it is displayed in business processes (interface block "Payments")
which option to choose depends on the complexity of the implementation. I would probably prefer the first option.
26.11.2020, 18:18
Original comment available on version: ru
Well, that is, formally, we need to add a payment link to some parent payment, and this will only affect the output in editing payments of the parent or child (by links) + the column in the list of payments which parent.
Well, the diversity algorithm I described above.
If all this fits, it can be implemented somewhere in 10 hours.
Well, the diversity algorithm I described above.
If all this fits, it can be implemented somewhere in 10 hours.
27.11.2020, 09:02
Original comment available on version: ru
Please join the conversation. If you have something to say - please write a comment. You will need a mobile phone and an SMS code for identification to enter.
Log in and comment
Copyright © OneBox 2024
