Добрый день!

Прошу прощения, если неправильные термины на русском, система ECC6 на англ, работаю в основном на французском, а задача для Англии.

Задача вот какая: бизнес получает фактуру к оплате от таможни на входящий НДС (на импорт товаров в страну). В фактуре только непосредственно НДС, ничего другого. Бизнес-юзеры просят, чтобы в FB60 или где-то еще можно было ввести такую фактуру без налоговой базы (BSET-FWBAS = 0). При этом хотят, чтобы отчет RFUMSV00 показывал тоже ноль в колонке "База налога" и саму сумму НДС в колонке Deduct.Input Tax. Имеет ли смысл задача? Если да – то как устроить код налога и налоговый счёт ГК, чтобы FB60 не блокировал нулевую налоговую базу ошибкой FF747?

Заранее благодарю!

Рискну не согласиться. Разумеется, если мы не говорим про подлом, так как там можно сделать все.
В FB60 базой для налога может служить только позиция по счету главной книги, одна или несколько.
А позиция с нулевой суммой быть не может. Нулевая база означала бы нулевую сумму проводки.

Я писал про расчет, но в равной степени можно то же самое сказать про ручной ввод.
68 или 19 тут не суть. Дальше в зависимости от налоговой категории.
- имеет налоговую категорию > или <: потребует ввод базы или расчет на основе введенной суммы. Если базу не указывать (ноль), то будет игнорировать и ждать указания ненулевой базы (не наш вариант) или расчета. Рассчитать базу он сможет только на основе непустого dmbtr (пусть он для простоты). Но любой непустой dmbtr даст ненулевую базу (снова не наш вариант). Пустой dmbtr же попросту будет проигнорирован и позиция будет исключена.
- имеет НЕналоговую категорию. В этом случае будет приравнен к обычному счету ГК, интерпретироваться будет не как налог, а сам как база. Дальше в зависимости от кода налога и галки расчета или введенной суммы даст сам налог или не даст, что снова уже неактуально, так как база будет ненулевой.

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

Поэтому в первом приближении это мне видится как deadlock и манипулировать тут надо не с проводкой, а с отображением в самом BSET (при этом BSEG оставлять в покое). Ну и смотреть, как себя поведут всякие дальнейшие отчеты.

Минуточку, будьте добры помедленнее, я записываю. (C)

Подскажите пожалуйста где ломать конкретно для FB60?

Именно отображение в BSET и интересует. Потому что надо чтобы RFUMSV00 для такой линии отображал BSET-HWBAS нулевой а BSET-HWSTE с суммой VAT из инвойса от её величества таможни aka HMRC. Печалька в том что согласно тому же HMRC НОЛЬ должен быть в боксе импорта и сумма налога - в соответствующем боксе VAT декларации. И в данный момент бухи манипулируют декларацию руками, а хотят вводить фактуру так чтобы потом не манипулировать декларацию.

Я так понимаю надо ломать, тем более что я еще спросил тоже самое у $AP $upport который выкатил 11ю ноту.

I checked with my team again internally. If you use transaction FB01/FB60 or other posting transaction, and you fill the Tax code in a line item, Base amount is mandatory to be filled or is automatically calculated. RFUMSV00 reads table BSET, BSET line has been generated when a Tax code is available in a G/L account line, and Base amount is derived. - if you use special transaction FB41, you can post directly Tax account without filling tax code, but in this case no entry in BSET have been generated, so document is not visible in RFUMSV00.
There is no other options in standard. You may refer to note 11 and request for this functionality. then our developers can consider it based on similar request from other customers.

Ну здесь примерно то же и написано. База потребует расчета.
В противном случае типа пишите хотелку, а они сядут за бутылочкой и обсудят, как вам грамотнее отказать

Да FB60 ломать не надо. Bseg ломать точно не надо. Вообще ничего до сохранения проводки в таблицах не ломать.
Если бы дело разворачивалось в России и речь шла о старом добром НДС, а не новом хановском, я бы при активном REGINV пакете (сохранение в журнале) в 1030 - 1050 BTE поковырял бы очень крутую badi, которая сохраняет данные в журнале счетов. Журнал с недавних пор необязательный, но в системе сам по себе журнал в старом НДС несет сокровенный смысл - имеется примат журнала над разворотом книги на коленке. Таким образом, в бадихе сохранения в журнале я бы обновил все поля, какие захочу. И база там тоже есть. С вероятность 97% именно это мое значение нулевой базы и пошло бы в нужный мне басгруно в 8, 9 разделах + UMSV также должна сработать.

Но раз задача для Англии, то пакеты русской локализации там вряд ли есть и посему вопрос возникает такой... а нет ли у вас чего-то похожего на наш журнал фактур?

Ну а если и нет, то решение-то найдется всегда. Просто оно будет более или менее элегантным. В 1030 можно запустить функцию отложенного обновления BSET. Все по документу в этот момент уже будет известно.

База это сапёрный термин. В UK-VAT Бокс 7.

Давайте ОЧЕНЬ Упростим. Мы импортёр в Англию. У нас два типа фактуры к оплате.
1. Фактура от поставщика. ИМПОРТНЫЙ Товар – 100 GBP, налог 0. Тут всё хорошо, 100 в бокс 7. Ноль в бокс 4.
2. Фактура от «поставщика» HMRC. Товар 0, Налог на фактуру 1 -20 GBP. Из неё НОЛЬ в бокс 7 и 20GBP в бокс 4.
Фактур типа 1 – несколько сотен в месяц, с ними всё хорошо. Фактур от HMRC – как обычно 4-5 в месяц, суммируют VAT на все импорты поза-поза-прошлой недели. Из них ничего в бокс 7, всё в бокс 4. Если вы работали с импортом, вам этот ритм знаком.

Вполне возможно что проблемы нет и Вы правы. Последние 14-15 лет декларации бухи делали вручную. Т.е. FB60 c 0% и плевали на эту САПёрную базу. Просто правили то что даёт RFUMSV00 для фактуры второго типа. Фактур tax-only мало, ну что там мудрствовать а САПе, когда можно в декларации написать правильно.

Однако теперь нам, как и многим другим, надо делать декларацию через аппробированный софт в рамках MTD
https://en.wikipedia.org/wiki/Making_Tax_Digital
https://www.gov.uk/guidance/find-softwa ... al-for-vat

и теперь в ERP всё «должно быть правильно».

Ибо лицензированный HMRC софт от САПа (отдельно купили, в облачке, а как жэж) править базу не может. Ошибкой считает такую правку.

Повторюсь, Вполне возможно что проблемы нет и Вы правы. Но вот как мне это всё объяснить бухам?

Ну я тут специально паузу взял, поскольку мне известно, что darkduck имеет хороший и обширный опыт с UK и что постарается решить проблему методологически.
Если бы этот путь у меня во всяком случае зашел в тупик, то я не вижу никаких последствий от того, чтобы поправить сумму базы в первичной системе в BSET.
А сделать это можно несколькими способами.
1. Поправить сразу после проводки с отложенным обновлением (четкая предпосылка = код налога, его использовать только для таких операций).
2. Поправить несколько проводок сразу ночным заданием (отработает мгновенно, индексировать по введенным за интервал С ... ПО документам, только для них проверить строки в BSET по заданному коду налога и обновить). Минус - day to day, если сегодня проведут и сразу запустят на формирование декларацию. Тогда либо сокращать интервал запуска, либо рассмотреть другой пункт.
3. Править BSET вообще при запуске RFUMS проги (найти где расшириться). Поскольку до нее все равно ошибка нигде не выстрелит. Расшириться в самый ранний момент, переписать значения. Прога продолжает работу, а если и не продолжает, то следующий запуск уже будет на обновленных данных автоматически.
4. Вообще BSET не обновлять, а изменять данные динамически в самой проге. То есть расширяться перед записей итоговых данных в UMSV. И на лету подменять значение базы по собранным кодам налога (см. выше - не использовать его для других целей, только для этой). BSET остается жить своей жизнью. Прогоны в UMSV своей.

Огромное спасибо коллеги darkduck и Yozhhhhh.

Однозначно специальный код налога и может даже счет ГК. Но и подмена BSET пока не исключена, потому что игнорировать базу не могут. Пока что конс SLH ACR спорят с бухами о том, что фактура 2 из моего примера, это может вовсе и не фактура. Я в сторонке постою.