Ми використовуємо файли cookies для оптимізації контенту та швидкодії сайту. Продовжуючи відвідування сайту, ви погоджуєтесь на використання файлів cookies.
Слід зробити так, щоб у боксі можна було виконати рознесення платежів за кількома замовленнями, при цьому зберігши вихідний платіж (його суму та реквізити).
Іншими словами.
є платіж на 1000 грн.,
його необхідно прив'язати до
- замовлення 111 на суму 50 грн.,
- замовлення 222 на суму 100 грн.
- залишок суму прийняти без прив'язки до замовлення (850 грн.)
та зберегти вихідні його значення (сума, вхід. номер тощо)
на цю тему вже були запити, які були оцінені в космічну кількість годин
https://crm-onebox.com/ru/support/finances/3343-potribno-v-quotavtomaticheski-raspredelyat-platezhi-klientov-po-protsessamquot/
https://crm-onebox.com/support/finances/2022-raspredelenie-odnogo-platezha-mezhdu-mezhdu-neskolkimi-zakazami-odnogo-i-togo-zhe-postavshchika/
я пропоную варіант реалізації, який на мій погляд набагато менш трудомісткий (але можу помилятися).
Полягає він у тому, щоб позначати вихідний платіж віртуальним та створювати окремі платежі у прив'язці в основному
тобто:
додати у
Слід зробити так, щоб у боксі можна було виконати рознесення платежів за кількома замовленнями, при цьому зберігши вихідний платіж (його суму та реквізити). Іншими словами. є платіж на 1000 грн., його необхідно прив'язати до - замовлення 111 на суму 50 грн., - замовлення 222 на суму 100 грн. - залишок суму прийняти без прив'язки до замовлення (850 грн.) та зберегти вихідні його значення (сума, вхід. номер тощо) на цю тему вже були запити, які були оцінені в космічну кількість годин https://crm-onebox.com/ru/support/finances/3343-potribno-v-quotavtomaticheski-ra... https://crm-onebox.com/support/finances/2022-raspredelenie-odnogo-platezha-mezhd... я пропоную варіант реалізації, який на мій погляд набагато менш трудомісткий (але можу помилятися). Полягає він у тому, щоб позначати вихідний платіж віртуальним та створювати окремі платежі у прив'язці в основному тобто: додати у
Не все так просто, як ви пишете. Як би поділ платежів і так є у редагуванні - і він забирає частину суми. А так розумію що в теорії можна зробити функціонал, що коли ви наприклад платіж на 1000 грн у редагуванні додали розбити ще на 2 по 500 і поставте галочку що платіж віртуальний - зробити загальне налаштування системи, щоб перевірити що якщо платіж розбивають на загальну суму і поставили, що основний стає "віртуальним" - суму основного не зменшувати. Таке підійде? Але ось по батьківській архітектурі - уточніть де і як ви хочете щоб відображалося що саме цей батьківський платіж у іншого? Якийсь банальний висновок десь? чи може й не потрібно?
Не все так просто, як ви пишете.
Як би поділ платежів і так є у редагуванні - і він забирає частину суми.
А так розумію що в теорії можна зробити функціонал, що коли ви наприклад платіж на 1000 грн у редагуванні додали розбити ще на 2 по 500 і поставте галочку що платіж віртуальний - зробити загальне налаштування системи, щоб перевірити що якщо платіж розбивають на загальну суму і поставили, що основний стає "віртуальним" - суму основного не зменшувати. Таке підійде?
Але ось по батьківській архітектурі - уточніть де і як ви хочете щоб відображалося що саме цей батьківський платіж у іншого? Якийсь банальний висновок десь? чи може й не потрібно?
Устименко Ігор OneBox CTO написав: чим вам поточний функціонал рознесення через праву панель масових операцій над процесами чи всередині платежу розподіл - не підійшов?
Найбільш глобальна проблема цього функціоналу - вихідна сума платежу втрачається. Якщо через час спробувати зробити звірку з клієнтом, це зробити буде практично неможливо. І взагалі це створить масу непорозумінь. Дивимося у виписку банку - бачимо платіж в 50000 грн., дивимося в бокс - бачимо 10 платежі на різні суми .... "ФТФ", скаже будь-який бухгалтер або фінансист, який пропрацював хоч трохи в b2b сегменті і буде правий)).
[quote]
Устименко Ігор
OneBox CTO написав:
чим вам поточний функціонал рознесення через праву панель масових операцій над процесами чи всередині платежу розподіл - не підійшов?
[/quote]
Найбільш глобальна проблема цього функціоналу - вихідна сума платежу втрачається.
Якщо через час спробувати зробити звірку з клієнтом, це зробити буде практично неможливо. І взагалі це створить масу непорозумінь.
Дивимося у виписку банку - бачимо платіж в 50000 грн., дивимося в бокс - бачимо 10 платежі на різні суми .... "ФТФ", скаже будь-який бухгалтер або фінансист, який пропрацював хоч трохи в b2b сегменті і буде правий)).
Тиндик Максим Вадимович Адміністратор писав/ла: Але ось по батьківській архітектурі - уточніть де і як ви хочете щоб відображалося що саме цей батьківський платіж у іншого? Якийсь банальний висновок десь? чи може й не потрібно?
так, ось так міг би виглядати платіж, який є частиною основного платежу
Тиндик Максим Вадимович Адміністратор писав/ла: А так розумію що в теорії можна зробити функціонал, що коли ви наприклад платіж на 1000 грн у редагуванні додали розбити ще на 2 по 500 і поставте галочку що платіж віртуальний - зробити загальне налаштування системи, щоб перевірити що якщо платіж розбивають на загальну суму і поставили, що основний стає "віртуальним" - суму основного не зменшувати. Таке підійде?
цілком підійде. власне про це і йдеться але є ще одне, дуже важливе у вихідному платежі (тому, що став "віртуальним" після виконання рознесення по ньому) необхідно відобразити список дочірніх платежів. можна або вивести ось так всі дочірні платежі (+ додати колонку з посиланням на платіж, щоб можна було в нього "провалитися") або вивести список платежів, 1в1 для того, як виводиться в бізнес-процесах (блок інтерфейсу "Платежі") який варіант вибрати – залежить від складності реалізації. мені б, мабуть, перший варіант більше хотілося б бачити.
[quote]
Тиндик Максим Вадимович
Адміністратор писав/ла:
Але ось по батьківській архітектурі - уточніть де і як ви хочете щоб відображалося що саме цей батьківський платіж у іншого? Якийсь банальний висновок десь? чи може й не потрібно?
[/quote]
так, ось так міг би виглядати платіж, який є частиною основного платежу [file]1174[/file]
[quote]
Тиндик Максим Вадимович
Адміністратор писав/ла:
А так розумію що в теорії можна зробити функціонал, що коли ви наприклад платіж на 1000 грн у редагуванні додали розбити ще на 2 по 500 і поставте галочку що платіж віртуальний - зробити загальне налаштування системи, щоб перевірити що якщо платіж розбивають на загальну суму і поставили, що основний стає "віртуальним" - суму основного не зменшувати. Таке підійде?
[/quote]
цілком підійде. власне про це і йдеться
але є ще одне, дуже важливе
у вихідному платежі (тому, що став "віртуальним" після виконання рознесення по ньому) необхідно відобразити список дочірніх платежів. можна або вивести ось так [file]1175[/file] всі дочірні платежі (+ додати колонку з посиланням на платіж, щоб можна було в нього "провалитися")
або вивести список платежів, 1в1 для того, як виводиться в бізнес-процесах [file]1176[/file] (блок інтерфейсу "Платежі")
який варіант вибрати – залежить від складності реалізації. мені б, мабуть, перший варіант більше хотілося б бачити.
Ну тобто формально нам потрібно додати прив'язку платежу до якогось батьківського платежу і це вплине лише на висновок у редагуванні платежів батьківського або дочірніх (посиланнями) + колонку у списку платежів якийсь батьківський. Та й вищеописаний мною алгоритм рознесення. Якщо це все підходить – це можна реалізувати десь за 10 годин.
Ну тобто формально нам потрібно додати прив'язку платежу до якогось батьківського платежу і це вплине лише на висновок у редагуванні платежів батьківського або дочірніх (посиланнями) + колонку у списку платежів якийсь батьківський.
Та й вищеописаний мною алгоритм рознесення.
Якщо це все підходить – це можна реалізувати десь за 10 годин.
Будь ласка, приєднуйтесь до діалогу. Якщо вам є що сказати – будь ласка, напишіть коментар. Для входу потрібний мобільний телефон та смс-код для ідентифікації.
Увійти та написати коментар