Коллеги, привет!
Сижу тут, медитирую вот по какому вопросу - возможно ли стандартными средствами реализовать схему исчисления входного НДС при закупках через логистику, когда база для исчисления этого НДС является отдельной от цены заказа/инвойса величиной? Например, закупаем мы лом радиоактивных металлов. Поскольку это спецсырье, предположим государство установило на него твердую цену = 100 рублей/кг, и требует от этой величины исчислять все налоги и не более чем в такой оценке включать в себестоимость. Нам же гад-поставщик выставляет в инвойсе цену = 120 руб/кг, но свой исходящий НДС считает от 100 рублей базовой цены. Как сделать так, чтобы при MIRO на нашей стороне инвойс зашел в полной сумме (от цены 120), а НДС посчитался от базовой суммы (от цены 100)?

Вот такая задачка, кто что думает?

Всем привет!
Отвечу на свой вопрос, вариантов тут два:
1. Вариант, требующий наличия точной суммы нормативного НДС во входящем инвойсе:
- Запускаем МИРО, заполняем заполняем заголовок, указываем сумму в поле "Сумма" (по условию задачи должна включать стоимость нетто+величину нормативного НДС), указываем код НДС, НЕ ставим галочку "Расчет налога", УКАЗЫВАЕМ сумму налога из входящей фактуры ручками в поле "Сумма налога". В табличной части ставим ссылку на заказ и позицию, нажимаем "Моделирование", если все сделано правильно, то должна получиться сальдированная модель вида:
Кт поставщика - сумма из поля"Сумма"
Дт запас/затраты - сумма позиции заказа из табличной части
Дт НДС - то, что ввели ручками в поле "Сумма налога"

Благодарность @Yozhhhhh за ценную подсказку для этого варианта.

2. Вариант, требующий знания базы исчисления нормативного НДС и немного колдовства:
- Запускаем МИРО, заполняем заполняем заголовок, указываем сумму в поле "Сумма" (по условию задачи может включать что угодно), указываем код НДС с требуемым процентом, СТАВИМ галочку "Расчет налога", НЕ УКАЗЫВАЕМ сумму налога из входящей фактуры ручками в поле "Сумма налога" даже если она у нас есть. В табличной части на вкладке "Заказ на поставку" ставим ссылку на заказ и позицию, на вкладке "Счет" делаем Дт нормативная база НДС - Кр нетто-стоимость позиции по заказу на поставку И СТАВИМ КОД НДС В КАЖДОЙ ПОЗИЦИИ (тут важно не накосячить со счетами, Дт-Кт должен в идеале обернуться по тому счету, который определяется из заказа/группы материала, в зависимости от того, что за тип позиции в заказе и как настроена деривация счета, если это невозможно в случае запаса, например, то надо создавать поправочные затратные счета), нажимаем "Моделирование", если все сделано правильно, то должна получиться сальдированная модель вида:
Кт поставщика - сумма из поля"Сумма"
Дт запас/затраты - сумма позиции заказа из табличной части со вкладки "Заказ на поставку"
Кт запас/затраты - сумма кредитовой позиции из табличной части со вкладки "Счет" (минус стоимость позиции заказа)
Дт запас/затраты - сумма дебетовой позиции из табличной части со вкладки "Счет" (плюс нормативная база НДС)
Дт НДС - сумма НДС, которая просчиталась от нормативной базы.
Дт запас/затраты - разница между НДС, который бы посчитался без этого шаманства и НДС, который по факту посчитался с шаманством, относится на затраты.

Этот вариант я уже сам придумал Если не нравятся лишние обороты и настройка БЕ разрешает красное сторно, можно запилить соот. замещение через момент 3 транзакции OBBH.

Но третий вариант ты, как я полагаю, все равно решил проигнорировать)
В моем понимании он проще был (по нашим внутренним обсуждениям).
А именно на вкладке "Счет" обойтись без шаманства как раз, а просто вбить две поправочных позиции на сумму нормативной базы по конкретному тупенькому счету Z* (образно). Одна с плюсом, одна с минусом. Во всех позициях, кроме нормативной с плюсом, использовать декоративный код налога (без ндс). В нормативной с плюсом использовать актуальный код налога. Этот вариант мне все равно кажется более выигрышным по ряду причин:
1. Структура документа проще (всего две поправочных позиции вместо миллиона, если разные строки заказа будут давать проводки на разные счета учета ТМЦ/Услуг).
2. Потребуется отключение галки "Только автоматические проводки", которые по-хорошему всегда стоят в BSX, WRX.
3. Чехарда между складскими отчетами и отчетами из финансов.
4. Для замещения красного сторно очевидная и простая предпосылка: нам известен счет и нам известна сторона проводки (ставим в кредит). В случае с твоим подходом у нас две балансировочные + строка отклонения. И уже как минимум ломать голову, чтобы реализовать логику замещения. Если будут разношерстные строки с разными счетами учета, то все умножаем на N по принципу декартова произведения. Что проще заместить: строку из миро с балансировочным счетом в кредите без пользовательской подпрограммы или с использованием подпрограммы, в которой необходимо будет придумывать движок с расчетом общей стоимости по балансировке, выбором позиций. И это при отсутствии третьего момента из миро, то есть на втором не будет информации обо всех строках. То есть с ассайном всего, что было ранее. То есть с дикой рекурсивностью и падением производительности.