finalization of the functionality of posting actual payments through expected payments

Business Requirement if necessary, I will detail this TOR for individual tasks according to the blocks of the TOR please evaluate TK block by block You need to make sure that incoming payments that do not contain a link to a process are automatically linked to processes through existing pending payments. The selection of a suitable payment must be carried out according to a number of conditions, for example - according to the client of the expected payment (selection of the client through the fields and contact details) - according to the amount of the expected payment - by date of expected payment and also make it so that large payments are spread into several small ones according to the available expected ones and data from the received actual payment is recorded in the card of the paying client for its enrichment and more accurate selection in the future To implement this scenario, you need 1. finalize the functionality of expected payments. Namely, in the action "Generate the expected payment" add the field "Take the client of the expected payment from the additional field instead of the field "process client". When filling in this field, the client of the expected payment will enter the contact that was specified in the corresponding additional field of the process. To do this it is necessary to add a field to the table of expected payments, which will store the contact id of the expected payment 2. modify the action of importing payments from privat24 in such a way that you can specify in which additional payment field to write this or that value of the statement field [file]2157[/file] 3. finalize the action "Allocate payments to processes based on expected payments" so that 3.1.the selection of a suitable payment was carried out on the basis of the fulfillment of a number of conditions, in particular: - by contact fields from the expected payment and details from the actual payment - by date of expected payment and date of actual payment - by the amount of the expected payment and the amount of the actual payment 3.2. there was a distribution of the actual payment for as many payments as the amount of the actual payment is enough to cover the existing expected payments. this functionality works only if it was possible to find the expected payments for the contact from the actual payment and none of the other linking conditions worked. In this case, the main payment is marked as virtual, and for each expected payment, a separate payment fact is created equal to the amount of the expected payment (the payment fact amount is calculated using the following algorithm: take the client's expected payments, sort them by payment date in ascending order, take the amount of the first expected payment, compare with the actual amount. payment, if the amount of the expected payment is less, then create a payment fact for the amount of the expected one, and transfer the difference to the next expected payment and perform a similar comparison until the condition is met that the amount of the expected payment is greater than the balance of the actual one, in this case, create a payment for the balance of the actual payment. 3.3. there was an automatic addition of contact data from the expected payment with data from the linked fact. payment Tasks for improvement 1. improve the functionality of expected payments - in the action "Generate expected payment" add the field "Take the client of the expected payment from the additional field instead of the field "process client". process field To do this, you need to add a field to the table of expected payments that will store the contact id of the expected payment 2. modify the action of importing payments from Privat24 "Privat24 Autoclient Statement of Accounts" so that you can specify in which additional field of the payment to write one or another value of the statement field [file]2157[/file] 3. finalize the action "Distribute payments among processes based on expected payments" in such a way that you can set the rules for selecting payments based on the fulfillment of a number of conditions, in particular: - by contact fields from the expected payment and details from the actual payment - by date of expected payment and date of actual payment. - by the amount of the expected payment and the amount of the actual payment for this, add to the action: table consisting of the following comparison columns - field of the expected payment. Composition of the field: Fields legal. contact details, ext. contact fields (get the list of fields from here [file]2158[/file] (action "Privat24 Autoclient Account Statement")) + payment amount + payment date + account/account + currency - "deviation" field. The value from this field is used to enter the error on the date of payment and the amount of payment (similar to what has already been implemented) - comparison condition. List of fields from "greater than, less than, equal to, not equal to, greater than or equal to, less than or equal to, no value" - actual payment field. List of extras payment fields and system fields: payment date, payment amount, account/account, currency - Checkbox "Required". If set, then the condition is considered mandatory when comparing *condition AND" 4. modify the action "Distribute payments among processes based on expected payments" so that the action automatically distributes large payments to several processes and at the same time the main payment is saved for this add to action: - check the box "Automatically create subpayments in accordance with the expected if several expected payments were found according to the configured selection conditions" - the "method" field, consisting of the options "pay off earlier (FIFO)" and "pay off later (LIFO) first" when this checkbox is enabled must happen 1. the actual payment that is being processed is marked as virtual 2. If in the "method" field "repay the earliest (FIFO)" is selected, then sort the expected by creation date in ascending order, otherwise, if "repay the later (LIFO) first", then sort "Descending" 3. as many subpayments are created as the amount of the original payment is enough to cover the existing pending payments (take into account the sorting from paragraph 2.) 4. Subpayments are linked to the original payment. The "virtual" mark is not installed on them. Data from the original payment is copied to sub-payments, such as: payment date, account, currency, rate, payment category, type and client 5. finalize the action "Distribute payments among processes based on expected payments" so that data from payments is written to the contact card for automatic filling with data To do this, check the box "Improve the action "Distribute payments among processes based on expected payments" in such a way that" if this checkbox is enabled, then if it was possible to find the expected payment based on the mandatory search criteria, then you need to write the values of the payment fields specified as the criteria for selecting a client into the corresponding fields of the client of their expected payment, to which the actual payment was linked layout https://www.figma.com/file/8rgRpCkKzcagoBkYO5biUU/Untitled?node-id=1%3A9