Проблема с транзакцией J3RCALK. Перечитала документацию, вроде по документации должно работать как мне надо. Не работает. Не понимаю
В TF123 по кредитору стоит только ZUONR. По каждому кредитору обычно один договор. В рамках этого договора несколько счетов-фактур. К одной счет-фактуре созданы несколько оплат, на общую сумму=сумме по счет-фактуре. Во всех оплатах прописаны ссылки на эту счет-фактуру.
Запускаю транз-с параметром Требуется ссылка на счет, один счет-несколько платежей, сортировка по дате проводки.
В результате система выдает все операции (все счета-фактуры и оплаты) сгруппированные по ZUONR, и абсолютно не смотрит на ссылку на счет!
В результате - Нет операций для выравнивания.
Те она считает, что есть операции для выравнивания только тогда, когда все суммы дадут нулевое сальдо по кредитору и zuonr.
Читаю документацию к проге, там явно написано, что после группировки по TF123, она должна сгруппировать по ссылке.

Я не права? Прога должна учитывать ссылку на счет, и считать сальдо по ссылке на счет и выравнивать?
Система EHP6.0

В стандартной системе в ситуации: один договор (ДОГ1), к нему две фактуры, к ним по два платежа на каждую фактуру и с установленным количеством повторов в программе (PA_QURUN) = 2 и отбором позиций только с заполненным присвоением, тр. J3RCALK выравнивает правильно
У вас в фактуре и платежах ZUONR заполнен?
Или у вас не такой пример?

ZUONR заполнено во всех документах.
Только пример не такой. У вас в примере обе фактуры закрываются оплатами в ноль.
А у меня
Одна фактура закрывается, а вторая фактура еще совсем не оплачена.
СчетФ1 -2000 р
Оплата1 - 1800 р
Оплата2 - 200 р
В оплате1 и оплате2 - ссылки прописаны на СчетФ1
--------------
СчетФ2 - 1800 р
Все документы по одному договору, те ZUONR везде одно и тоже.

Про количество повторов в проге посмотрю. Спасибо! Может в этом дело.

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

Я как раз очень предполагала, что стандарт ждать не будет нулевого сальдо по ZUONR))))
Спасибо! Мне и нужно было подтверждение как работает стандарт.

Plank, а подскажите, вы какую опцию "Правила выравнивания" запускали (Один счет и Один платеж, Несколько счетов и платежей и тд)? У вас создался отдельный документ выравнивания на каждую группу (счет и оплаты) 1*225 и 1*226.
Я ставлю опцию "Один счет и один платеж" - нет позиций. Все документы счетов и оплат один к одному.
Ставлю "Один счет несколько оплат" - тоже нет позиций.
Ставлю "Несколько счетов и несколько оплат" - тогда выравнивает, НО одним документом выравнивания.
В ОИ к проге про эти опции ни слова.

После установки 617SP4, в котором есть нота 1979049 - J_3RCALD(K): credit memos, у меня перестал работать тот пример, который я показывал в постах выше.
Советую проверить, стоит ли у вас нота 1979049, может в ней дело.
Я откатил ноту, и старый пример заработал.

Спасибо большое!

а если не откатить ноту 1979049, а установить J_3RFCALD(K): multiple partial clearings are not processed?
нота 1979049 в пререквизитах 2024297

Нота вышла 30.05.2014, соответственно я ее не проверял. Наверное, она решит проблему, нужно попробовать.

Недавно сталкивались с такой же проблемой.
У нас на автоматическом выравнивании по ночам посажено как J3RCALK, так и J3RCALD.
В этом плане у них одинаковый глюк: система НЕ хочет выравнивать фактуру и документы по REBZG к ней, если REBZG заполнен во всех позициях.
То есть:
фактура 100, первое частичное на 40 и еще одно на 60, но без REBZG - работать будет.

А вот такое:
фактура 100, частичное с rebzg 40, частичное с rebzg 60 - работать не будет.

Это вообще очень мило и забавно)))

Ноты не проверяли, поискали решение на периферии. А именно: если вдуматься, то второй документ с REBZG, выводящий всю кучку в 0, появиться БЕЗ выравнивания всей кучи не должен был. Проверьте у себя в опциях галку "Учесть ссылку на счет-фактуру". А еще никогда не подавайте в выравнивание конкретные номера документов, есть риск упустить частичное (в системе позволительно даже при включенной галке "Учесть ссылку на СФ" подать только фактуру; в этом случае частичные в выравнивание не идут и с удовольствием висят и мозолят глаза).

Еще ситуация: поздняя регистрация документа. Дело в том, что CALK и CALD проверяют BUDAT в "кандидатах" на выравнивание по условию <= отчетная дата. Таким образом, если у вас уже есть более позднее частичное выравнивание, но потом кто-то притараканил документ с более ранней датой проводки, то рождается частичное выравнивание с более ранней датой, позднее частичное будет при этом отсечено по проверке budat. В результате зависает нулевая куча, которая не хочет выравниваться автоматом, только руками.

Побороть это можно enhancement где-нибудь в подпрограмме add_item.

В корне не согласна, что второй документ с REBZG появиться без выравнивания всей кучи не должен был. Должен и второй документ быть с REBZG - если вы используете ТП, как мы используем на проекте. Соответственно остаток фактуры тоже будет оплачен через ТП.
А что нужно проверить в опциях в данной галке? Она стоит-об этом написано в моем сообщении.
Ну про конкретные документы, это я думаю и так всем понятно

Галина, да, общеизвестный факт, что F110 при прогоне ТП на остаток от фактуры (выводящий строго в 0) сам не выравнивает всю кучу (кт 60 и несколько дт 60). В разное время я выходил из такой ситуации по-разному. Например, почему бы Вам не подать на F110 при последнем платеже саму фактуру? Программа платежей автоматически определит все имеющиеся частичные оплаты и уменьшит сумму платежного поручения, а потом выровняет всю кучу. Это приемлемо? Или Вы вообще все строго через ТП и ТАПы платите? Если приемлемо, то проблема решена.

А причем здесь F110 и выравнивание при прогоне F110?
Я и не ожидаю выравнивания при прогоне F110. И мой вопрос был совсем не про F110.
Платим все строго через ТП и ТАП.

Я не хочу казаться циничным, но результат от попытки сделать энхансмент в тушке программы J_3RCALK/J_3RCALD (неважно где - в основной тушке или в инклюде при ней) может тебя немного расстроить

Это же центровая прога, компонент SAP-FIN (( Проблем бы не было, если бы можно было энхансмент приткнуть.