Можно ли разделить почтовый сбор по разным истцам, если его рассчитывать с помощью YSCAL в RUTAX?
При двух истцах формируются два вида /GIS, но база для почтового сбора получается одна на общую сумму /GIS. А так как почтовый сбор непропорциональный, то при двух истцах считается неправильно. Если базу разделить на уровне вида оплаты, то RUTAX этого не видит. Какие есть варианты решения этой проблемы?

Зачем YSCAL?
Есть же T7RUG9 и RUFEE, стандартное правило RUI2 по 80-му классу обработки.

Спасибо Вам большое за подсказку! У нас реализация через yscal плавно преползла из 4.0. Кто-то когда-то сделал именно так. А про T7RUG9 и RUFEE я и не знала. И откуда все это можно узнать?
Буду пробовать...

как говорит bot, для это надо иметь геморрой и седые волосы )

Эх, не все так просто...
Что-то мне RUFEE ничего не возвращает. Как правильно заполнить T7RUG9?
Способ платежа имеет значение? Я выбрала S-почтовый перевод.
Код региона- это регион истца?
Вид оплаты - какой?
Занесла для примера только процент.
В правиле RUI2 написала обработку для значения 3 80-го класса , кот. присвоила виду оплаты базы почт. сбора ZBPS. В обработке делаю AMT=RUFEE в надежде получить сумму почт. сбора рассчитанную по T7RUG9. Но увы, получаю 0.
Что еще нужно?

а вот и я с сединой и геморроем =)
вид оплаты почтового сбора
способ платежа имеет большое значение
код региона получателя!

Ничего не получается!
У нас схема RU00. Алименты считаются функцией RU295. В результате имеем 2 вида /GIS-алименты по двум истцам и два вида ZBPS - соответсвующие базы почтового сбора. Вид почтового сбора - /PST.
В T7RUG9 создана запись с видом оплаты /PST c процентом и способом платежа S-почтовый перевод.
Для ZBPS создана обработка в RUI2.
Чем вызывать RUI2? Если через PIT, то RUFEE ничего не дает. Попробовала через RU295 - она вообще проверку AMT?0 для ZBPS не проходит.
Чего еще не хватает???!!!

pit-ом вызывать.
а у вас база почтового сбора со всеми теми же сплитами что и алименты? это имеет значение.
и зачем вы отделяете базу почтового сбора от суммы алиментов?

Не знаю, зачем отделяю. Было так до меня...
Ну ладно, даже если не отделяю: присвоила эту обработку виду /GIS через 80 класс. В правиле пишу
AMT*-1
AMT= RUFEE
WGTYP=/PST
ADDWT *
получаю /PST c AMT=0
Чувствую, что не так надо. Иначе зачем в T7RUG9 указывать вид оплаты. Но как надо? Не знаю...

там важно чтобы в t7ruG9 :
способ платежа
Регион и страна
совпадали с информацией о получателе. 0296 или t7ru1b или LFB*
Кроме того если в способ платежа помечен как почтовый (в T042z) то регион важен если платеж через банк то тогда соответствующа галка в 042 должна быть но регион в G9 д.б. пустым.

Результата пока нет....
В упомянутых табличках вроде все занесено. Способ платежа везде S, код страны и региона везде стоит. Наверное это еще не все...
А где-нибудь есть информация о том где, что и как правильно настроить для расчета почтового сбора? Может нота какая-нибудь?
Или кто-то может описать порядок настроек?

попробуйте развернуть лог для этой операции.
Там когда в правило заходите (в логе) есть еще один + 2-й уровень лога
Там должна появится строчка типа: сумма % сумма
- если % 0 то проблама со шкалов в g9
- если это строчки даже нет то операция не нашла соответствующей настройки в таблице g9 вообще.

для первого случая в шкале поставьте только % а остальное удалите. Ежели заработает то тогда шкала может быть типа такой:
300,00 0,00 0,06 0,00 6,50
1.000,00 0,00 0,04 18,00
5.000,00 0,00 0,02 46,00
0,00 0,00 0,01 126,00

А вот во втором случае лучше в дебагире понять чего система пытается в таблице найти и откуда какие регионы и страны берутся.

После длительного прерыва продолжаю мучаться с почтовым сбором...
Теперь выдает ошибку "нет записи в таблице LFBK для аргумента (код получателя)". Получатели у меня прописаны в 296 инфотипе и в таблице T7RU1B. А таблицу LFBK я вообще найти не могу. Что это такое и что с этим делать?

Вопрос снят. Оказывается получателю-кредитору нужно было прописать банковские данные. Непонятно почему - ведь платеж почтой...

значит не стояла галка для поля XPGIR в таблице T042Z для текущего способа платежа.
Дебаг показал, что сначала проверяется наличие банковских реквизитов, если их нет, то система смотрит на поле XPGIR. Если галки нет, то и не заходит в ветку, где определяется вид оплаты для сбора для способа платежа в таблице T7RUG9.

Хотя обсуждения давно прекратились, но решила написать, т.к. сами только мучились, а вести банковские реквизиты для получателя-почты не считаем красивым. Думаю, пригодится=)