доопрацювання дії "Сформувати очікуваний платіж" (Брати клієнта очікуваного платежу з доп.поля замість поля "клієнт процесу")

[quote] Перегіняк Олександр писав/ла: Для цього необхідно додати до таблиці очікуваних платежів поле, в якому зберігатиметься id контакту очікуваного платежу [/quote] Яка мета цього? (Для розуміння масштабів рефакторингу)

[quote] Тиндик Максим Вадимович Адміністратор писав/ла: Яка мета цього? (Для розуміння масштабів рефакторингу) [/quote] зрештою дані з факту платежу, який буде прив'язаний до процесу через очікуваний повинні завантажитися в картку контакту. якщо контакту в очікуваному платежі немає і ми його завжди братимемо з процесу, то буде виходити занадто заплутаний і нелогічний процес пошуку контакту, в який слід довантажити дані... та й не логічно формувати очікуваний платіж на клієнта процесу, якщо за клієнта платить третя особа.

[quote] Перегіняк Олександр писав/ла: в кінцевому підсумку дані з факту платежу, який буде прив'язаний до процесу через очікуваний повинні завантажитися в картку контакту. якщо контакту в очікуваному платежі немає і ми його завжди братимемо з процесу, то виходитиме занадто заплутаний і нелогічний процес пошуку контакту, в який слід довантажити дані... [/quote] Це милиця, і дуже заплутана. Навіщо шукати в процесі контакт в дод.поле і мити це в очікуваний платіж заради 1 проекту, якщо можна в кінцевій точці запису даних - зробити налаштування щоб не контакту процесу очікуваного платежу записувати поля, а контакту з доп.поля процесу очікуваного платежу - і вийти більш очевидно. [quote] Перегіняк Олександр писав/ла: та й не логічно формувати очікуваний платіж на клієнта процесу, якщо за клієнта платить третя особа. [/quote] Кожен має свою логіку залежно від потреб. Мені не логічно створювати очікуваний платіж на одного клієнта на замовлення іншого клієнта.

[quote] Тиндик Максим Вадимович Адміністратор писав/ла: Кожен має свою логіку залежно від потреб. Мені не логічно створювати очікуваний платіж на одного клієнта на замовлення іншого клієнта. [/quote] так, ще момент. надалі передбачалося з урахуванням даної доопрацювання реалізувати такий функционал: взяти код ЄДРПОУ платника платежу, знайти за цим кодом контакт у боксі, отримати список усіх очікуваних платежів цього контакту та "сплатити" всі знайдені очікувані платежі даним фактичним патежем (основний платіж позначається віртуальним, а на кожен очікуваний створюється реальний субплатіж). Мені здається, що якщо очікуваний платеж не матиме свого контакту, то виконати такий пошук буде досить проблематично - весь час потрібно буде "заглядати" в процеси, шукати в яких процесах контакт платежу є платником, отримувати список очікуваних платежів з них і потім їх " гасити". Хоча як знати... може справді простіше "зашити" цю логіку в одній дії замість того, щоб правити існуючу логіку системи. Хоча в той же час можливість задавати того, від кого реально повинні надійти гроші окремо від клієнта процесу, дуже приваблива, бо значно розширить можливості боксу і додасть точності у використанні календаря надходжень д/с (звісно, це актуально далеко не для всіх користувачів системи). Разом ... якщо ви вважаєте, що запитана доопрацювання суперечить або не цікава плану розвитку боксу, то можете її відхилити. у такому разі я піду іншим шляхом.