Постоплата в SAP, миф или реальность
Очень давно хотел написать про свое отношение к процессу платежей в SAP. Делал разные схемы по платежам, в основном сводились они к тому, что на определенном этапе согласования заявки на платеж (каким бы документом она не была в реализуемом решении) все сводилось к генерации или ручному созданию ТАП. Про ТП вообще вспоминать не хочется из-за фокусов с FM.
Случилось так, что получилось попробовать постоплатную схему в действии. Лучше бы не пробовал, сложности буквально со всем: с реестром платежей, с процессом согласования, и главное с АПП (F110).
Про АПП и особенно про механизм работы объединения платежей, без которого постоплатная схема не “взлетит” хочется рассказать отдельно.
Основные правила по работе объединения программы платежей отражены в ноте 305414 - F110: Unintelligible grouping of documents
Основной смысл в том, что позиции не попадут в одну группу, если при прогоне предложения АПП для их открытых позиций не будут сформированы индентичные структуры ZHLG1 с учетом критериев группирования.
Также вскользь упоминается о многострадальной настройке в способе платежа T042E-XEIPO “Платеж по каждой помеченной позиции”
Теперь получаем логичный вопрос, если у нас 50% аванс а остальное пост. оплата всего на 1200.
Мы провели начисление
| Дебет | 19.01 [Предварительный НДС] | 200 ₽ |
| Дебет | 35.00 [Затраты по аренде] | 1 000 ₽ |
| Кредит | 60.01 [Продавец ] | 1 200 ₽ |
Выравняли ранее выданный аванс с начислением на 600 рублей
| Дебет | 60.01 [Продавец ] | 600 ₽ |
| Кредит | 60.02 [Продавец ] | 600 ₽ |
В итоге если выравнивали частичным платежом получем две открытые позиции.
И вот тут начинается самое интересное, если в результате объединения частичное выравнивание и начисление попадут в разные группы мы просто заплатим аванс еще раз.
Позиция выравнивания заблокируется как позиция с дебетовым сальдо а начисление уйдет в оплату.
Бывают ситуации, когда в позицию выравнивания замещением или просто из-за ошибки передаются данные, которые не дают объединять начисление и частичное выравнивание по полям структуры ZHLG1. В случае, если это делает сам SAP то их первая линия твердо уверена, что индикатор T042E-XEIPO не учитывает частичные выравнивания.
Вот если добраться до 2 линии поддержки там люди уже понимают, что признак T042E-XEIPO делит именно платежные позиции. Да он выключает критерии группирования, но при этом частичные выравнивания попадут в одну группу с начислением. Не важно был ли это частичный аванс или корректировка начисления на минус.
То есть если было 2 начисления, одно из них с частичным выранванием, итого 3 открытых позиции, группы в итоге будет 2 а не три.
Так как признак T042E-XEIPO на обработку частичных платежей со сссылкой на счет и корректировок на уменьшение не влияет и если у вас позиции попадают в разные группы, то виноват не способ платежа а какой-то из оставшихся алгоритмов группирования.