Всем привет.
Вкратце о проблеме. Компания использует автоматическое выравнивание J3RCALD, запускается из-под Z-оболочки, внутри которой последовательно выполняется submit с увеличением отчетной даты на +1 день по всему открытому периоду. У отчетной даты PA_STIDA смысл такой, что все документы (даже частичного платежа - вообще все) выбираются по условию BUDAT <= PA_STIDA (это стандарт).

Предположим, с прошлого месяца есть аванс Кт 62А на 100 руб. Открытый период - сентябрь 2014.
15.09 (CPUDT) в системе отражается задолженность Дт 62 на 60 руб. Дата проводки 10.09. В ночь с 15.09 на 16.09 программа автовыравнивания создает частичный платеж Дт 62А Кт 62 на 60 руб c BUDAT = 10.09.
28.09 (CPUDT) в связи с поздним получением документов или по другой причине в системе проводится еще задолженность по этому же договору на 80 руб. BUDAT = 05.09.

В результате запуска J3RCALD (когда отчетная дата достигнет 05.09) система видит аванс на 100 руб. и задолженность от 05.09 на 80 руб. Частичный платеж от 10.09 она увидеть не может из-за ограничения по BUDAT внутри программы. Создается документ частичного платежа на 80 руб.

Таким образом, в системе существует теперь аванс 100 руб. и два частичных платежа к позиции аванса на общую сумму 140 руб. Аванс перерасходован, знак сменился на недопустимый (ушли в плюс). В результате все последующие выравнивания выполняться (по данному дебитору и договору) вообще не могут: система пытается выровнять данный аванс, но это невозможно (сумма частичных платежей необоснованно превышает сумму аванса).

Требование компании - выравнивать не в конце месяца, а в режиме онлайн, каждую ночь. Итеративный submit используем, потому что дата проводки на экране селекции одна, выравнивать всю кучу документов за месяц одной датой неправомерно (фактура выравнивается с авансом той же датой, что и дата проводки фактуры).

p.s. Я мог бы спокойно подтянуть все частичные платежи через пользовательское расширение, за это отвечает таблица it_rebzg. Заполнить ее искусственно не проблема. Но тогда (конкретно в этом примере) позиция частичного платежа от 10.09 должна будет иметь дату выравнивания 05.09 (потому что в тот момент будет отрабатывать итерация с PA_STIDA = 05.09 и такой же датой проводки). А позиция не должна иметь дату выравнивания раньше, чем дата проводки. Это даже не каприз, а здравый смысл))) Подменить дату проводки у всего выравнивания на более позднюю (10.09) тоже неверно. Потому что зачет фактуры от 05.09 должен быть выполнен именно этой датой проводки.

В этой ситуации мне оставалось только на 940 событии добавить проверку "неперерасхода" общей суммы аванса с учетом существующих частичных оплат. То есть по еррору упадет выравнивание, но хотя бы не будет перерасхода.

У кого-то были подобные решения на проектах? Как удавалось разрешить ситуацию? Или, возможно, кто-то что-то посоветует.
Спасибо!

Автовыравнивание умеет делать несколько выравниваний для разных фактур подряд для одного аванса (см. тут viewtopic.php?f=5&t=85674). Соответственно, запускаете автовыравнивание при закрытии периода, когда все документы уже введены в систему и в замещении меняете дату проводки документа выравнивания на дату проводки выравниваемой фактуры.
Если нужно, добавить сортировку позиций фактур по дате проводки в пользовательском расширении.

Plank, в этом все и дело. Предпосылка - компания хочет, чтобы выравнивалось все сразу же, а не в конце периода. У нас при проводке второй области выписки применяется выравнивание с остатком с использованием авизо. Каждый день в системе не должно быть неразнесенки. Если бы можно было в конце периода, то я так бы и поступил - заменял дату проводки на самую позднюю.

Сортировка по дате проводки, кажется, есть прямо на селекции, сейчас так и работает, просто не видит позицию с бОльшей датой проводки.

Наверное, если выравнивать он-лайн, то подобные проблемы неизбежны...?

Тут или умный или красивый. Если онлайн, то неизбежны проблемы с задним числом.
Я бы добавил автоматическое сторно частичных выравниваниий, если проводится новое частичное выравнивание с меньшей датой.
При проводке частичного выравнивания добавил бы запуск FBRA и FB08 в отложенном обновлении.

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

Plank, как считаете, выдерживает ли критику такую подход?

В связи с этим стал вдруг резко непонятен опыт других компаний. Да, большинство, судя по всему, выравнивает в конце периода. Как в таком случае выполняется выравнивание второй области по выписке? И как идет интерпретация входящего платежа на предмет того, что это именно аванс? У нас сейчас очень топорно, даже стыдно говорить: есть задолженность - не аванс, нет задолженности - аванс. А наличие задолженности - вещь хрупкая. К примеру, клиент позвонил и возмутился, откуда у него штраф или пени возникли. Или страховка какая-нибудь. В процессе выяснения оказывается, что ошибочно начислено. Начисление сторнируется, а вторая область - нет (по закрытым периодам стараемся выписку не рвать). Выходит, то, что было проведено как гашение задолженности вообще-то должно было быть авансом. Ну и т.д.

"можно ли авансы и задолженность выравнивать последним числом?"
Если нет требований по оперативному отслеживанию состояния расчетов на основе бухгалтерских данных (это реализовано другими средствами), то можно делать зачет и при закрытии периода, НДС отчетность сформируется верно.

Нормальная практика, пришли деньги и есть задолженность - закрываем, нет задолженности или есть остаток платежа - делаем аванс. Даже если аванс сделали утром, а вечером появилась задолженность, то ничего страшного, что в один день пройдет аванс, задолженность и зачет. Суммы НДС прокрутятся по книгам (аванс в книге продаж, реализация в книге продаж, зачет в книге покупок и все это одним днем). Зато риски минимальны.

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

Выход из этой ситуации различный, в зависимости от принципов работы вашей бухгалтерии (или возможностей по их изменению).
1. Все платежи учитываем на счете расчетов, там же реализация. В конце месяца понимаем состояние расчетов и делаем аванс, если по счету расчетов кредитовое сальдо. Начисляем НДС с авансов.
Недостаток: счет-фактура на аванс должен быть выставлен в течении 5 дней. Тут можно выкрутится и сказать, что в течении месяца нет достоверных данных о состоянии расчетов, так что понять, где аванс, а где оплата сложно, поэтому авансы выявляются по итогам периода.
Другой недостаток: покупатель может потребовать счет-фактуру на перечисленный вам аванс, для возмещения НДС в перечисленного вам аванса у себя. Тогда ему нужно выставить счет-фактуру в течение 5 дней. Хотя, опять же, можно договорится на конец месяца.
2. Выявлять авансы по итогам пятидневки. Тут и счета-фактуры вовремя выставляем, и есть 5 дней на фиксацию состояния расчетов.
3. Что касается 2 области БВ, то ее не нужно трогать. Если нужно сделать аванс, перенесите сумму со счета расчетов, на счет авансов, начислите НДС. Я встречал такие схемы превращения оплаты в аванс.

К сожалению, ваш вопрос относится к категории "Кто виноват?" и "Что делать?". Да, будут возникать ситуации, когда нужно что-то сделать задним числом, и переделать последующие операции. Если бы все было так просто, консалтинг не стоил бы так дорого...

P.S.
На будущее, предлагаю воздержаться от личных обращений "Plank, как считаете". Я тут не один...

Спасибо за ответ!