Перед новым годом мы публикуем обновлённые планы по разработке УПД. Уже можно свободно обмениваться УПД, в том числе и через веб версию Диадока. Подробнее — на картинке:
Перед новым годом мы публикуем обновлённые планы по разработке УПД. Уже можно свободно обмениваться УПД, в том числе и через веб версию Диадока. Подробнее — на картинке:
Когда можно будет создавать УПД?
есть сроки?
В Диадоке не планируется поддержка новых форматов актов и накладных.
Мы рекомендуем использовать формат УПД (ММВ-7-15/155@) в качестве формата для первичных документов, он уже работает в роуминге.
здравствуйте.
Я правильно понял Ваше утверждение: документы, законодательно утвержденные как формализованные ДИАДОКом таковыми не рассматриваются и обрабатываются как неформализованные? (т.е. никак не обрабатываются)
В случае роуминга, насколько я понимаю, контроль формализованных документов лежит на первом операторе ЭДО - том, кто принял документ от пользователя. Принимающий оператор ЭДО вправе рассчитывать, что этот контроль уже проведен. Получается, передавая через роуминг другим оператором ЭДО эти документы ДИАДОК... поступает не совсем корректно: документы формализованные, но контроль не прошли.
Если форматы утверждённые Приказами N ММВ-7-10/551@ и N ММВ-7-10/552@ являются единственными возможными для отправителя или получателя, то их можно отправить с типами "Накладная" и "Акт" (выбор типа доступен при отправке при загрузке документа в веб версии). В API эти типы называются Torg12Documents и AcceptanceCertificates. Для этих документов вручную можно указать метаданные для возможности автоматической обработки такого документа. Подробнее про "полуформализованные" типы документов вы можете узнать у техподдержки.
Технология роуминга не накладывает обязательств на операторов ЭДО проверять контент отправляемого документа.
Повторюсь, что мы предлагаем обмениваться первичными документами в формате более свежего приказа ММВ-7-15/155@.
т.е. первичный документ без оператора (дружить чужие ИС, вместо одного API к своему оператору?), а счф к нему - через оператора?
но озвучил реалии с которыми сталкивался и есть до сих пор
(компания А реализовала поддержку накладной только по 551 приказу, а счф в УПД)
>Достаточно настроить “Прямой обмен с контрагентом”
Вы почему-то забываете, что есть не только 1С, если эта терминология взята оттуда.
И "просто так" взять и настроить не всегда получается у компаний
2) Для прямого обмена, 1с на другом конце вовсе не обязательна, если не нужен автоматический ввод. Счета, например, можно смело слать на почту. Кстати, как Вы их сейчас выставляете, если не секрет? Что касается сложности в настройке 1с, то и есть другие способы организации прямого обмена.
2) Наличие оператора ЭДО позволяет иметь третью сторону в документообороте с контрагентом. Это может быть полезным в случае конфликтов. Однако, вы верно заметили, что ФНС требует наличие оператора только в случае передачи ЭСФ.
2) Яндекс.Почта разве не может быть третьим?
Что касается наличия независимой третьей стороны - уже складывается судебная практика, когда суд обращается к оператору за подтверждением факта передачи документа, наличия и подлинности электронных подписей, датой и временем подписания документа сторонами. Маловероятно, что сервис электронной почты возьмет на себя такую роль.
Вопрос был про “Документы в кастомных форматах”.
Такие документы, как известно, можно просто подписать КЭП и передать.
Оператор ЭСФ в этом случае превращается просто в транспорт.
Учитывая то, что КЭП может быть выдана не принадлежащим оператору удостоверяющим центром, роль оператора в суде стремится к нулю -
подтверждать подлинность подписи в суде будет УЦ выдавший ЭП.
Остается подтверждение факта передачи и хранение документов.
Яндекс.Почта думаете с этим не справится?
Мы не можем утверждать, что почтовые сервисы смогут предоставить юридически значимое подтверждение факта отправки письма.
Формат передачи документа следует выбирать исходя из целей этого обмена. Условиями юридической значимости документа, как известно, являются договорённости с контрагентом и 63-ФЗ.