350

И собственно, по ДВС в таблице FMIOI создается запись только с регистром 9B

тогда надо использовать либо 200, либо 359 (может быть еще вышли новые профили, кот. позволяют использовать ДВС таким образом при наличии бюджета обязательств)

Несколько раз встречал схему в которой и предоплаты и постоплаты проводились через ТАПы, только с разными кодами ОГК. Только там свои приколы возникают

Да, я тоже видела такое решение, но учитывая все его "приколы" (как Вы деликатно выразились ) я не фанат такого расклада

Все через ОГК не пойдет еще и потому что знаков не хватит. У нас только по авансам 22 кода (разные счета), а еще подотчетники.

Появилась идея использовать "Платежную инструкцию" FM. Попробовал, потестировал, что-то не могу понять какие проводки по ней должны формироваться и как этой настройкой точно можно управлять?
Всего одна настройка - ракурс V_IFMPDCUST

Потом по транзакции FMPO по документу FI можно создать документ, который отъест от FI документа часть суммы.
Только я не могу предположить какие проводки должны возникать (памятные позиции она, к сожалению не создает)

Кто-то использовал эту штуку?

>Все через ОГК не пойдет еще и потому что знаков не хватит.
Вопрос к Delicia - почему Вы не фанат такого решения ? В нашем случае основная проблемы была только в разработке программы , которая аватоматически создавала ТАПы с контролем частичных оплат и предоплат по позиции заказа плюс доработка по статистическому отражению фактур в бюджетах. А чем вам не нравиться такое решение -"все через ТАПы" ?

Но код ОГК - это же 1 символ

Точно, пропахнулся Перепутал с кодом налога. Давно уже финансами не занимался В качестве кодов ОГК использовали буквы и цифры - вроде на всё хватило.

ilu,
а как быть с тем что в УБ операция будет проходить не как платеж а как аванс?
и как этот аванс потом выравнивать?

Про УБ не скажу - сам не занимался, но с точки зрения финансов все выравнивается

извините, что сразу не ответила, вопрос выбора конкретного решения, когда оно кардинально отличается от стандарта, решается конечно в зависимости от задач проекта. Т.е. понятно что хочется компенсировать какие-то недостатки стандарта, но и отрицательных моментов будет достаточно, причем когда ломаешь стандарт, время от времени появляются все новые побочные эффекты, так как при очередных накатах пакетов обновлений или отдельных нот с коррекциями, поведение системы меняется, и разработчики само собой не следят за тем, чтобы эти изменения были совместимы с вашими решениями. Я имею ввиду, что в случае стандартного решения, любой баг или косяк будет исправлен сапом, а вот когда после наката ноты ты видишь, что в каком-то badi или exit-е "вдруг" не пришли на вход нужные тебе данные, потому что саповкие разработчики не обязаны соблюдать всю ту же внутреннюю логику,тьим важно обеспечить результат для стандарта, не важно какими средствами. Т.е. конечно непобедимых проблем нет, просто если решил ломать стандарт - надо быть готовым к постоянному тестированию и доработкам своих разработок после каждого наката пакета или ноты. Если такое решение принимает сам клиент - то ему с этим и жить, конечно.