Что необходимо сделать, чтобы в счет-фактуре клиенту исходящий налог не уменьшал позицию выручки по кредиту, а создавал новую позицию по дебету 90?
Сейчас, это выглядит так:
Д60 1 180
К90.01 1 000
K68 180

А надо:
Д60 1 180
К90.01 1 180
K68 180
Д90.03 180

или:
Д60 1 180
К90.01 1 000
К90.01 180
K68 180
Д90.03 180

В налоговой схеме примерно так:

Исх.НДС (РФ) MWS 18,000
Исх.НДС/ДебетВыравн ZUD 100,000-
Исх.НДС/КредитВыравн ZUK 100,000

В настройках счетов:
MWS 68.1
ZUD 90.3
ZUK 90.1 - одинаковый со счетом выручки (ну либо отдельный, как нравится).

Урра! Все ровненько работает. Однако, долго бы до этого я своими собственными ковыряниями добиралась бы. Спасибо.

А ведь можно просто почитать документацию к AddOn...

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

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

Еще что-то там вроде SAPF180 делает. Может кто подскажет?

Что-то я совсем не поняла - а причем здесь SAPF180?
Не - у нас не будет в одной счет-фактуре позиций с разными БС.

Ну тогда замещение.. или OpenFI. Это точно работает.

Тогда еще вопрос - а какое событие для этого лучше использовать? (Имеется ввиду OpenFI)

Хорошо работает 1025. Видел и на 1120 вроде.

А мне еще необходимо, чтобы для счетов выручки и налогов было обязательным поле Бизнес-Сфера (статус поля)
При попытке запостить документ с-ма ругается, что позиции необходимо откорректировать.
При этом если для заполнение их БС использовать событие 1025, то вообще на этот момент мы до него не доходим.
Я использовала событие 1020. В этом случае позиции с БС, но когда они проверялись на уровне строки, БС тогда в них не было еще. А инф-я об ошибке осталась. В результате, все равно надо заходить в эти несчастные позиции. Более ранне как мне кажется событие 1011 - проверка строки, однако для соответсвующиго модуля интерфейс не позволяет изменения i_bseg, после вызова функции с-ма не импортирует i_bseg

Для версии 5.0 и выше не рекомендую делать через OpenFI. Лучше через BadI AC_DOCUMENT

В событиях до 1025 документ еще не смоделирован - бесполезно пытаться пропихнуть БСф в позиции, которых еще не существует. Лучше сделать это после моделирования на событии 1025 (1120, как говорит DiaRom) или BadI AC_DOCUMENT. При этом, естественно, обязательность полей придется снять. Но "обязательность" полей можно обеспечить на уровне того, когда событие/BadI будет запускаться, или проверками на более поздних событиях OpenFI.

С-ма 4.6С. А где можно что-нибудь про BadI почитать? - ничего не знаю...