finalization of the action "Generate the expected payment" (Take the client of the expected payment from the additional field instead of the "process client" field

[quote] Pereginyak Alexander wrote: To do this, you need to add a field to the table of expected payments, which will store the contact id of the expected payment [/quote] What is the purpose of this? (to understand the scope of refactoring)

[quote] Tyndyk Maxim Vadimovich Administrator wrote: What is the purpose of this? (to understand the scope of refactoring) [/quote] eventually, the data from the payment fact, which will be linked to the process through the expected one, should be loaded into the contact card. if there is no contact in the expected payment and we will always take it from the process, then we will get too confusing and illogical process of finding a contact into which data should be loaded ... and it is not logical to form the expected payment for the client of the process if a third party pays for the client.

[quote] Pereginyak Alexander wrote: eventually, the data from the payment fact, which will be linked to the process through the expected one, should be loaded into the contact card. if there is no contact in the expected payment and we will always take it from the process, then we will get too confusing and illogical process of finding a contact into which data should be loaded ... [/quote] It's a crutch, and a very confusing one. Why look for a contact in an additional field in the process and hack it into the expected payment for the sake of 1 project, if it is possible at the end point of data recording - make a setting so that not the contact of the expected payment process writes fields, but the contact from the additional field of the expected payment process - and you get more obvious. [quote] Pereginyak Alexander wrote: and it is not logical to form the expected payment for the client of the process if a third party pays for the client. [/quote] Everyone has their own logic depending on the needs. It doesn't make sense for me to create an expected payment for one customer in another customer's order.

[quote] Tyndyk Maxim Vadimovich Administrator wrote: Everyone has their own logic depending on the needs. It doesn't make sense for me to create an expected payment for one customer in another customer's order. [/quote] yes, one more moment. In the future, it was supposed to implement the following functionality on the basis of this revision: take the EDRPOU code of the payer of the payment, find the contact in the box using this code, get a list of all the expected payments of this contact and "pay" all the expected payments found with this actual payment (the main payment is marked virtual, and for each expected payment a real subpayment is created). It seems to me that if the expected payment does not have its own contact, then it will be quite problematic to perform such a search - all the time you will need to "look" into the processes, look in which processes the payment contact is the payer, get a list of expected payments from them and then them " put out." Although, who knows ... it might really be easier to "sew" this logic in one action, instead of editing the existing system logic. Although, at the same time, the ability to set the person from whom the money should actually be received separately from the client of the process is very tempting, because it will significantly expand the possibilities of boxing and add accuracy in using the income calendar (of course, this is far from being true for all users of the system) total... if you think that the requested revision is contrary to or not interesting to the boxing development plan, then you can reject it. in that case, I'll go the other way.