Yozhhhhh написал:
Планировщик ликвидности работает на основе привязки счетов ГК к статьям ликвидности и анализе цепочки выравнивания документов.
1. Позиции денежных счетов (50, 51, 52 и пр. по необходимости) помечаются в системе как счета, релевантные для учета денежных средств (галка в основной записи счета ГК).
2. Все счета затрат/расхода/выручки/дохода/ТМЦ/контрольные привязываются к статье ликвидности.
3. Дополнительно для каждого счета устанавливается опция, "остановиться" или "пропустить" дальше. Если стоит опция остановки, то система при обнаружении данного счета остановится и отнесет сумму на привязанную к счету ГК статью ликвидности. Это актуально для многих счетов авансов (ОГК) и для некоторых контрольных счетов задолженности, если можно однозначно определить принадлежность к статье (например, 71, 73 счет). Если стоит опция "продолжать", то система будет анализировать цепочку выравнивания документов, пока не доберется до счета с пометкой остановки или до неконтрольного счета (счета затрат, счета дохода и пр.)
4. Если в процессе разворачивания цепочки выравнивания встречается выровненная позиция контрагента, то рассматривается все выравнивание для нее и т.д.
5. Все найденные в процессе анализа цепочки выравнивания позиции делятся пропорционально исходному счету денежных средств согласно его знаку, даже если встретится 1 копейка.
6. Самое важное для Вас: в процессе определения статьи ликвидности можно определять так называемые запросы 1 и 2 уровня. Запросы представляют собой уникальное правило, основанное на значении произвольного поля из найденной позиции. В т.ч. СПП-элемент, операция сетевого графика, работа и пр. (Ваш случай). Например, при обнаружении позиции с непустым СПП можно автоматически относить на статью по инвестиционному виду деятельности. Запросы имеют приоритет и отрабатывают в порядке его понижения. Самое востребованное и универсальное правило, таким образом, задается первым. Потом более слабое и т.д.
Используя описанную логику можно выстраивать довольно гибкие критерии отнесения суммы к той или иной статье ликвидности.
Еще пара слов про 1 и 2 уровень. 1 уровень - это процесс анализа цепочки до первой встретившейся позиции контрагента (чаще всего это 2 область банковской выписки или позиция из F110 с мгновенным созданием документа). 2 уровень - это все остальное, то есть разматывание цепочки выравнивания.
С помощью пользовательских расширений можно задать максимальный уровень анализа цепочки, то есть глубину проваливания. Например, не более 5 документов (чаще всего).
Система автоматически проконтролирует, были ли найдены суммы, которые не смогли быть отнесены ни на одну статью. Они упадут на статью "Не присвоено".
Имеется возможность грузить остатки по каждой статье на произвольную дату, то есть выполнить полноценный процесс миграции.
Расчет фактических позиций производится посредством запуска специальной программы с определенной периодичностью. Если в процессе работы было обнаружено, что часть правил нуждается в уточнении, то можно переопределить их, после чего запустить фактический разбор за указанный период заново.
Это то, что смог написать просто по воспоминаниям, я давно не работал с LP, около 5 лет. Все остальное сможете почитать в курсе по LP или интересными бессонными ночами, настраивая и отлаживая:)
Инструмент не очень востребован в России. У нас широко распространен принцип частичного выравнивания (метод частичной оплаты). Движок LP испытывает серьезные трудности с частичными оплатами, со сторно документов из кассы (CAJO) и со многим другим. Выставлял множество заявок на SAP, диалог был примерно следующий: "А зачем вы даете своим контрагентам платить частично? Пусть платят целиком, это нормальная мировая практика". Становится примерно понятно, с какими проблемами придется столкнуться.
p.s. На Вашем месте я бы использовал PS Cash Management. Его намного быстрее настраивать, в моем случае пришлось незначительно поломать систему, но не факт, что это потребуется делать другим. Там есть пара багов, но суть понятна. Вот как раз он работает только с капексом. Все, что он покажет, будет гарантированно инвестиционными затратами.
Спасибо большое за такой развернутый ответ
будем решать с заказчиком, какой вариант им подойдет больше.