Добрый вечер!

Пытаюсь организовать что-то похожее на схему согласования предложения по платежам.
Изначально все позиции предложения деблокированы для платежа.

Есть специалисты первый и второй, которые должны ограничить список позиций к оплате в предложении на свое усмотрение.
У первого настроен свой персональный уровень блокирования, например G.

Второй анализирует только те позиции предложения, которые не блокированы первым.
И вот здесь и возникает проблема: запись которая из "зеленой" становится "красной" (в результате применения уровня блокирования G) из предложения не пропадает,
а ей отводится целых две строки, одна из которых с нулевой суммой.

Есть ли какой-нибудь способ удалить из предложения запись с нулевой суммой к оплате?
спасибо за помощь

А Вы не хотели бы попробовать начать блокировать строку не из самого предложения, а до ее попадания туда?
Пусть у первого будет код G, у второго - свой, например, T.
На разных уровнях авторизации пусть они набирают себе свои "кучки" для последующей проверки. Например, через массовое изменение позиций в FBL1N.
И уже потом по факту проверки деблокировать их или не деблокировать (согласно установленному в компании регламенту) к времени X. И далее организовать подготовку предложения по платежам. Вариант второй - не деблокировать, а просто включать все позиции с G и c T в предложение, а из него уже по факту проверки деблокировать и принимать решение об оплате. Каждый по своим позициям.
Все же обычно из самого предложения позиции деблокируют, но не наоборот.

Yozhhhhh, darkduck спасибо за помощь!

Yozhhhhh, проблема в том что это один и тот же набор позиций, который сначала утверждает первый специалист, а уж те, что утверждены первым повторно рассматривает второй.

Если как Вы предлагаете, в предложение изначально попадут позиции с блокировкой G, например.

И первый специалист из этого набора определит те позиции, которые нужно оплатить, то помимо снятия блокировки этому специалисту еще придется указать вручную и расчетный счет, с которого нужно оплатить эту строку.
В принципе ничего страшного, но все настройки ранговой последовательности банков и прочих настроек в части выбора расчетного счета становятся не нужны, так?

Это очень хорошо, что сначала первый, а потом второй. Это означает, что есть определенная последовательность смены кода блокировки.
Пусть первый переводит не на пусто, как предполагалось, а на T (к примеру).
Позиции, получившие T, точно были согласованы первым. Второй рассматривает только их. И деблокирует только их.
Одновременно можно настроить проверки переходов кодов блокировки из состояния в состояние.
Например, тогда схема может быть такой:
1. Начальный код блокировки G (замещение на втором моменте для всех новых позиций).
2. Из G можно только в T (нельзя в деблокировано, проверка на втором моменте).
3. Из T можно в G (вернуть проверяющему №1) или деблокировать для платежа.
4. Из деблокировано можно заблокировать в G (потребуется пройти все уровни авторизации вновь) или в T (первым проверено, реквизиты в порядке, но ждем другой платежный день).


В этом как раз и состоит минус деблокирования из предложения. Все реквизиты приходится пробивать вновь. Куда удобнее иметь все платежные реквизиты сразу в позиции, а АПП настроить так, чтобы деблокированная позиция попадала сразу зеленой. Там даже ничего не придется делать, лишь проверить сумму платежек и сразу приступать к продуктивному прогону. Абсолютно все реквизиты можно указать до предложения АПП. Личное мое мнение - деблокировать позиции удобнее на уровне просмотра ОП, а не из F110.

Ну а для проверяющих обычно кто что делает. По минимуму - настроить варианты FBL1N/FBL5N, расширив их до нужных полей (хоть расчетный счет туда тащите - вот Вам реестр для проверки), либо пишут примитивную Z-оболочку, туда можно и красивых кнопок пульнуть, и все что угодно.

расчетный счет FBL1N не дает изменить

FBL1N дает изменить расчетный счет. Смотря что Вы под ним подразумеваете.
Если собственный счет, то это будет поле "Собственный банк" (HBKID). Да, счет определяется в связке "Собственный банк" + "Ключ счета". Но чаще всего собственные банки нарезают под один конкретный счет.
Если счет контрагента, то это поле "Тип банка партнера".
Абсолютно все реквизиты, важные для платежа, можно изменить в FBL1N.

все получилось. спасибо

... а для эргономики процесса сделать по паре форматов для FBL1N и для FBL5N - для юзера G и для юзера Т. И каждому в инструкцию прописать свой формат.