4. Электронный документооборот — контроль за содержимым EDI и EDO сообщений.

О чем будем говорить сегодня?

Немного разгрузился, сдав очередной экзамен по 1С и решил предпраздничный день завершить немного расслабившись 🙂 Что дает замечательную возможность написать еще одну статью по СЭД. Тем более, что тема легко пришла на ум, вспомнив один из последних споров с прежним директором по ИТ — кто виноват — провайдер или партнер по СЭД?

Цель проекта внедрения СЭД.

Цель внедрения СЭД можно сформулировать по разному, я сторонник следующего подхода:

  1. Упрощение бизнес-процесса по взаимодействию с партнерами компании.
  2. Автоматизация согласования заказов.
  3. Автоматизация передачи юридически значимых электронных документов.
  4. Отказ от бумажной технологии.

Проблема.

И так в игре участвует три стороны: покупатель, поставщик и провайдер СЭД.

Пусть вы максимально упростили процесс согласования документов, теперь его надо автоматизировать.

При этом схема обмена данными выглядит так:
Схема СЭД
А теперь проблема — нужно контролировать данные, передаваемые в сообщениях, если этого не делать — будет беда.

Очевидно, что ставя как цель автоматизацию процесса, мы стремимся отказаться от контроля силами сотрудника и захотим, чтобы это было автоматически по утвержденным нами правилам.

Кто отвечает за устранение этой проблемы?

И вот мы приходим к главному вопросу, сегодняшней статьи — кто же отвечает за этот контроль?

Как мы уже знаем — провайдер представляет нам сервис передачи данных, в соответствии с текущими стандартами электронных сообщений. Задача уже поставщика и покупателя интегрироваться с этим сервисом (как и за какие деньги это другой вопрос и не относится к текущей статье). Из схемы мы видим, что у обоих есть интерфейсы взаимодействия с сервисом, результатом работы с этими интерфейсами будут пакеты данных, отправляемых через сервис. В этих пакетах будет в общем случае перечень SKU, цены по каждому SKU, количество, сумма, НДС (который может быть как включенным в сумму, так и нет) и т.д.

Обмениваясь такими пакетами поставщик и покупатель приходят к общему знаменателю. после чего и происходит согласование поставки. Но какие данные поставщик и покупатель заложил в эти пакеты — это все цело их вопрос, а не вопрос провайдера!

Так делаем важный вывод: прежде чем начать внедрение СЭД у себя, именно вы и ваши партнеры должны прийти к соглашению какая информация и по каким правилам закладывается в эти пакеты. Если вы работаете в розничной сети (крупной сети), то у вас есть возможность диктовать ваши правила вашим партнерам в этом вопросе и тогда именно вам формулировать эти правила. И ОБЯЗАТЕЛЬНО включать эти правила в ДС, который вы будете заключать с партнерами относительно СЭД, и обязательно включать в Техническое Задание по интеграции с СЭД, которе вы будете писать для провайдера СЭД.

Запомните — провайдер понятия не имеет, как именно нужно проверять данные, передаваемые в электронных сообщения, он предоставляет лишь сервис их передачи! Именно вам нужно прописывать эти правила, а ваши партнеры должны их согласовать и если в пакете будет ошибка, то это не проблема провайдера, а проблема интеграции КИС вашей или вашего партнера с сервисом СЭД и вам или вашему партнеру отвечать за ошибки в этом, в зависимости на чьей стороне был сгенерирован пакет с неправильными данными! 

Я сам с этим при запуске столкнулся, но как я не пытался владельцу проекта (ИТ-нику кстати) объяснить этот момент — он был глух, возможно по тому, что это уже был боевой запуск и проще было обвинить провайдера, чем поставщика нашей компании в неправильно проведенной интеграции.

Так что доносите эту информацию до владельца проекта на этапе только его планирования и обязательно включайте данные моменты в ДС по СЭД, заключаемые с партнерами вашей компании.

Добавить комментарий