Продолжаем рассказывать об изменениях в формате электронных документов (УПД, счета-фактуры, отгрузочных документов) согласно 820 приказу ФНС и поддержке этих изменений в Диадоке.
Сравнение старого и нового форматов
В предыдущей статье мы рассказали об изменениях в новом формате по приказу 820, а теперь подготовили сравнение со старым форматов по приказу 155.
Переход на новый формат
В первую очередь, 2 главные даты:
- 2 февраля 2019 года вступил в силу 820 приказ ФНС, который определяет формат счета-фактуры и других первичных документов.
- 1 января 2020 года выставление электронного счета-фактуры и УПД возможно только в новом формате.
В период со 2 февраля по 31 декабря документы можно выставлять и в старом, и в новом форматах.
Как будет происходить переход
В апреле 2019 года будет реализована поддержка нового формата в API Диадока и отправка готового документа в веб-интерфейсе. О последующих планах мы сообщим дополнительно.
Изменения в API
Формат изменился значительно, поэтому не все текущие методы API смогут его поддержать.
Для генерации документов в новом формате необходимо будет использовать универсальные методы GenerateSenderTitleXml и GenerateRecipientTitleXml. Методы GenerateUniversalTransferDocumentXmlForSeller и GenerateUniversalTransferDocumentXmlForBuyer продолжат работать только со старым форматом, новый формат не поддержат.
Для парсинга документов в новом формате будут разработаны новые универсальные методы, которые помимо УПД поддержат работу со всеми типами документов. Текущий метод парсинга ParseUniversalTransferDocumentSellerTitleXml можно будет использовать только для старого формата. Новый метод парсинга появится в конце марта. О том, как с ним работать, расскажем отдельно.
Если вы в интеграционных решениях используете генерацию и парсинг УПД, то для работы с новым форматом вам следует перейти на универсальные методы GenerateSenderTitleXml, GenerateRecipientTitleXml и новый метод парсинга.
На отправку и патчинг изменения формата не повлияли. Для нового формата можно будет использовать текущие методы отправки (PostMessage и PostMessagePatch) и патчинга (PrepareDocumentToSign). Отправлять УПД следует используя структуру DocumentAttachment.
Неточности нового формата
В титуле покупателя для подписанта указывается Статус, и в зависимости от значения Статуса прописываются основания полномочия (доверия) (атрибут ОснПолн).
В новом формате значения Статусов изменились:
- 3 — работник иной уполномоченной организации,
- 4 — уполномоченное физическое лицо, в том числе индивидуальный предприниматель,
- 5 — работник организации — покупателя,
- 6 — работник организации — составителя файла обмена информации покупателя, если составитель файла обмена информации покупателя не является покупателем. Правила заполнения Оснований полномочий остались без изменений и поэтому противоречат значениям статуса.
Как указано в формате:
- Для Статус=1 или Статус=2 или Статус=3 указываются «Должностные обязанности» по умолчанию или иные основания полномочий (доверия).
- Для Статус=4 указываются основания полномочий (доверия).
Как должно быть и как правильно трактовать:
- Для Статус=5 или Статус=6 или Статус=3 указываются «Должностные обязанности» по умолчанию или иные основания полномочий (доверия).
- Для Статус=4 указываются основания полномочий (доверия)
Все решения Диадока уже поддерживают работу с документами в новом формате.
Вот интересно, означает ли изменение названия файла что на товары, подлежащие маркировке, нужно выставлять отдельный комплект ТСД (наличие в одном СФ маркируемых и немаркируемых товаров не допускается)?
спасибо, поправим опечатку!
В один документ можно включать маркируемые и немаркируемые товары.
в один документ нельзя включать маркируемые и прослеживаемые товары, т.к. в этом случае невозможно назвать файл документа корректно.
"R_T - префикс, принимающий значение ON_NSCHFDOPPR в общем случае или значение ON_NSCHFDOPPRXXXX (где XXXX формируется в случае, если законодательством Российской Федерации предусмотрено использование настоящего формата в целях контроля за движением товара; принимает значение "PROS" - для товаров, подлежащих прослеживаемости; "MARK" - для товаров, подлежащих маркировке);"
без каких-либо уточнений, кому отправляется документ
Присоединяюсь к вопросам.
Я правильно понимаю, что новый формат будет зашит в саму компоненту(dll) и сама обработка 1С сильно не поменяется как и не поменяется API компоненты 1С? Хотелось бы, хотя бы, примерно узнать месяц выхода версии для 1С с полной поддержкой нового формата. Октябрь? Ноябрь?
Компонента уже поддерживает 820 формат. Изменения в API компоненты можно посмотреть в инструкции — http://1c-docs.diadoc.ru/ru/latest/History/release_info/5_27_0.html
Модуль Диадока 1С поменяется из-за смены API компоненты. Поэтому не достаточно обновить dll.
Модули Диадока для 1С поддержат новый формат в несколько этапов. В августе будет реализован прием документов без обработки новых полей формата, связанных с маркировкой, прослеживаемыми товарами, федеральным казначейством и товарами на муниципальные нужды. Полная поддержка формата появится к концу 2019 года, назвать месяц выхода сейчас не могу.
Август позади, новости по приему документов не видел. Релиз модуля Диадок для 1С отодвигается?
С каким модулем работает ваша организация?
В модуле должна появиться кнопка "Скачать обновление". Подробнее про нее можно посмотреть в инструкции https://wiki.diadoc.ru/pages/viewpage.action?pageId=12877935.
Воспользуйтесь кнопкой "Скачать обновление", чтобы скачать эту версию. Подробнее про нее можно посмотреть в инструкции https://wiki.diadoc.ru/pages/viewpage.action?pageId=12877977
Из статья "Изменения в счете-фактуре с 19 июля 2019 года" на официальном сайте федеральной налоговой службы.
Где вы увидели что с новым форматом можно тянуть до 1 января 2020? Прошу указать ссылку на статью в том же ресурсе
Обратите внимание на пункт 2 Пркиаза ФНС РФ от 19.12.2018 № ММВ-7-15/820 "Об утверждении формата счета-фактуры, формата представления документа об отгрузке товаров (выполнении работ), передаче имущественных прав (документа об оказании услуг), включающего в себя счет-фактуру, и формата представления документа об отгрузке товаров (выполнении работ), передаче имущественных прав (документа об оказании услуг) в электронной форме".
Там написано, что Приказ ФНС от 24.03.2016 № ММВ-7-15/155 (действующий пркиаз для составления счетов-фактур и первичных документов) утратит силу 1 января 2020 года.
Сроков от налоговой по публикации нового формата пока нет.
Не могли бы вы пояснить следующий момент: в новом формате УПД теги СтТовУчНал и СтТовУчНалВсего стали необязательными, то есть вместо стоимости товаров может приходить "-" в тегах ДефСтТовУчНал и ДефСтТовУчНалВсего соответственно.
Откуда при этому получить сумму поставки товаров? Эта информация будет приходить в УКД?
Если вы получили документ без нужных данных, вы можете запросить уточнение и ожидать от клиента корректировку (УКД) с необходимыми данными. Обращаю Ваше внимание, что не указывать эти данные могут только определенные КА (налоговые агенты), КА работающие со счетами-фактурами на аванс. В общем случае, эти данные должны быть заполнены.
Транспортную накладную можно передать в формате xml Диадок. Отправка и получение этого документа поддержаны в нашем API. Если вы готовы принять участие в пилотах по запуску транспортной накладной - обратитесь в техподдержку https://www.diadoc.ru/support.
Также вы можете отправлять транспортную накладную как неформализованный документ, с помощью API или в веб-интерфейсе.
Не могли бы Вы уточнить, какой именно "формат XML" для Транспортной накладной Вы имели в виду?
Насколько я знаю, формат и регламенты для этого вида документа на сегодняшний день не утверждены (в отличие от железнодорожной транспортной накладной).
Или Вы хотите использовать собственный формат?
Транспортную накладную (далее —ТрН) необходимо передавать нам в электронном виде через систему ЭДО.
•Отправлять желательно формализованный документ — файл с расширением XML. Так как Ваш оператор предоставляет ТрН в формате XML, Вы сможете создать ТрН прямо в своем кабинете ЭДО.
1.Создайте ТрН в ЭДО.
2.Подпишите ее и отправьте нам.
3.На портале, на странице генерации штрихкодов поставки, привяжите ТрН к своему поступлению.
4.Сразу по завершении разгрузки Вашей поставки транспортная накладная будет подписана нами в ЭДО.
На текущий момент в Диадоке реализована возможность обмена транспортной накладной в формате xml через API. Если вы хотите поучаствовать в пилоте, напишите повторный запрос на https://www.diadoc.ru/support, оставьте свои контакты и ИНН организации.
Вероятно, ваше обращение было до момента реализации функциональности, поэтому вы получили такой ответ от техподдержки.
/Файл/Документ/СвСчФакт/СвПрод
/Файл/Документ/СвСчФакт/ГрузОт
/Файл/Документ/СвСчФакт/ГрузПолуч
/Файл/Документ/СвСчФакт/СвПокуп
То есть формат допускает их множественность в одном электронном документе.
Коллеги, вопрос: каким образом система Диадок будет визуализировать и, возможно, маршрутизировать документы в которых указаны несколько разных продавцов, покупателей, грузоотправителей, грузополучателей? Какова цель ФНС для такой модификации формата (относительно старого приказа 155) ?
При доставке документа до получателя мы не смотрим на СвПрод и СвПокуп. В формате есть отдельные элементы ИдОтпр и ИдПол, которые обозначают отправителя и получателя, они не могут быть множественными, т.е. отправитель и получатель документа всегда определяются однозначно.
Такая модификация формата случилась для того, чтобы можно было формировать и отправлять сводные счета-фактуры. Примеров конкретных кейсов, как с этим работать, у нас пока нет.
Понимаю, что вопрос не совсем по адресу, но у вас ведь более плотный контакт с разработчиками форматов...
В Приказе 820 у КодВидТов тоже написано 'При отсутствии значения ставится знак "-" (дефис) (визуализируется как прочерк)'.
При этом формат элемента "T(=10)" и ФЛК знак "-" (дефис) не пропускает (по длине).
Прокомментируете?
Дело в том, что требования к стоимости товара с налогом и без - продиктованы новым форматом. https://normativ.kontur.ru/document?moduleId=1&documentId=328588&rangeId=291672
Нельзя указывать отрицательные значения в электронных документах. Возможно, следует иначе оформлять возвраты.
1. Модуль Стандарт УФ - с версии 5.36.01 и выше
2. Модуль Стандарт ОФ - с версии 5.32.01 и выше
3. Модуль Про - с версии 3.2.0 и выше
4. Модуль 7.7 - версия 2.10.01
Для работы в формате 820-го В модуле Про - кроме обновления модуля, нужно ли делать какие либо доработки в ПМ?
1. В ПолучитьТаблицуИспользуемыхВидовДокументов нужно поменять “utd” → “utd820”
2. В ПодготовитьЭлектронныйДокумент добавить условие ВРЕГ(ТипКонтента_XDTO) = ВРЕГ("Utd820SellerContent")
3. Изменить в пользовательском режиме: В настройках → Сервисные функции → Сопоставление видов пакетов и документов → Обновить типы документов API → Сопоставить виды документов
Предполагаю, что Контур запрашивал ФНС по этой коллизии. Прошу поделиться ответом ФНС и/или видением Контура по формированию документа со множественным СвТд (разные страны происхождения в одном СведТов).
Дробить строку на несколько не вариант - суммы расползутся.
Сейчас действительно есть несоответствие в 820 формате, так как элемент СвТД множественный, КодПроисх множественный. А элемент КрНаимСтрПр, о котором идет речь – не множественный. Предложение о приведении к единообразию в части этих элементов будет внесено в рамках доработок форматов.
Обратите, пожалуйста, внимание, что согласно Письма ФНС от 01.02.2022 № ЕА-4-26/1125@ «О порядке формирования в счетах-фактурах информации о подлежащих прослеживаемости товарах при их реализации в составе наборов (комплектов)», https://normativ.kontur.ru/document?moduleId=8&documentId=422784 строгие требования по заполнению УПД/СЧФ относительно товаров, подлежащих прослеживаемости предъявляются к графам 11, 12, 12а, 13. Их нужно заполнять обязательно по входящему в комплект прослеживаемому товару.
- Регистрационный номер декларации на товары или регистрационный номер партии товара, подлежащего прослеживаемости (гр. 11)
- Количественная единица измерения товара, используемая в целях осуществления прослеживаемости (гр. 12, 12а)
- Количество товара, подлежащего прослеживаемости, в количественной единице измерения товара, используемой в целях осуществления прослеживаемости (гр. 13)
Несоблюдение требований по реквизитному составу формы счета-фактуры (УПД) повлечет недействительность документа.
Для целей прослеживаемости обязательными к заполнению в УПД/СЧФ (помимо основных обязательных реквизитов) являются графы 11-13, а графы 10-10а - не являются обязательными.
Например, вот такой ответ по поводу заполнения строк 10, 10а дает представитель ФНС на официальном форуме:
«Страна происхождения – графа, неверное заполнение которой, а также при отсутствии данных не влечет отказа в вычете НДС. Также никаких последствий с точки зрения законодательства о национальной системе прослеживаемости товаров». https://forum.nalog.ru/index.php?showtopic=804139&page=6
В случае если товар состоит из нескольких элементов, произведенных в разных странах, допускается указание в качестве страны происхождения наименование союза нескольких государств. В таком случае графа 10 не заполняется (прочерк), а в графе 10а нужно указать наименование союза стран. Например, «ЕС» или «Европейский союз». Об этом сказано в пункте 1 письма Минфина от 10.02.2012 № 03-07-09/06 https://normativ.kontur.ru/document?moduleId=8&documentId=194371.
Также страну происхождения можно не указывать, если товар ввезен с территории стран, входящих в ЕАЭС, даже если товары произведены за его пределами. Такая позиция изложена в Письме Минфина России от 23.08.2017 № 03-07-13/1/53878. https://normativ.kontur.ru/document?moduleId=8&documentId=300013
И обсуждаем формирование электронного документа. К чему тут старое письмо про незаполнение графы 10 при происхождении из ЕС? Согласно утверждённому Приказом ММВ-7-15/820@ формату для товаров из EC должен указываться КодПроис='980'.
Что касается письма 03-07-13/1/53878 - во-первых, оно само по себе является весьма спорным (и есть более свежее письмо от 19 августа 2021 г. N ЕА-4-15/11700@, предусматривающее определение страны происхождения по прочим документам и даже по маркировке на товаре), а во-вторых, касается только товаров, происходящих с территории государств, не являющихся государствами - членами ЕАЭС. Т.е. для товаров, произведённых в ЕАЭС (вне России) даже такой отмазки нет. А Налоговый кодекс (ст.169), Постановление 1137 и утверждённый приказом 820@ формат требуют указания страны происхождения для товаров, страной происхождения не является РФ, без каких-либо исключений.
При заполнении КодПроисх, в атрибуте «КрНаимСтрПр» указываем только одну страну происхождения одного товара из комплекта (обычно первого).
Для целей прослеживаемости обязательными к заполнению в УПД/СЧФ (помимо основных обязательных реквизитов) являются графы 11-13, а графы 10-10а (код, краткое наименование) - не являются обязательными.
Не понял, зачем Вы написали второй абзац в последнем ответе. Может быть именно для целей прослеживаемости код и краткое наименование страны и не нужны, но нормативные акты (НК, ПП1137 и формат из Приказа 820@) требуют их указания в СФ для не-российского товара => для ПТ (поскольку прослеживается только импортный товар).