Торговая система «Супермаг Плюс» регистрирует транзакции, совершаемые с товаром. Ей важно как, куда, когда товар двигается, остатки товара в местах хранения и доступность их для розничной торговли. К документам (в том числе электронным) СМ+ имеет весьма опосредованное отношение и документооборотом не занимается.
При поступлении товара.
Что делает СМ+? Регистрирует фактическое поступление товара (не документов) по составу, количеству, ценам, маркам (прочим наносимым на товарную упаковку и отслеживаемым признакам). Информация о факте получается путем инструментального снятия с товара информации (штрих-кодов, КИЗов, ФСМ, ветеринарной маркировки и пр.) или путем получения этой информации из внешнего документа (в том числе и по ЭДО) и доверии к этой информации. Факт приемки по всем перечисленным параметрам сравнивается в информацией из электронного документа (документов) (УПД, ИУПД, УКД, ИУКД и пр.). Цель сличения – убедиться, что электронное документирование выполнено полностью и соответствует факту. С самим документом, как с таковым, СМ+ не работает. Он работает только с некоторой информацией из документа. Интересна только информация для выполнения выше названной задачи. Эту информацию СМ+ получает от системы ЭДО. Этой системой может быть софт ЭДО-провайдера, 1С или какой-то специализированный софт типа Директума.
В ответ в систему ЭДО СМ+ после сличения отдает информацию о решении пользователя при приемке товара. Решение соответствует тем трем вариантам, которые названы в 820 Приказе ФНС. Товар принят полностью, товар принят с расхождениями, товар не принят и экспедитор отправлен с товаром обратно. Акцентирую внимание, что решение касается товара, а не документа. СМ+ не дает точного приказа подписать или отклонить УПД, он лишь сообщает, свое решение о смене собственника на товар. Как этот факт оформить, что подписать, что отклонить, решается уже на уровне системы ЭДО.
Если товар принят с расхождениями, то в адрес системы ЭДО отсылается спецификация с фактическими данными приемки.
См+ «не задумывается», как в случае расхождений система ЭДО передаст данные о фактической спецификации Поставщику. Будь то документ с КНД или какой-то произвольный документ, Будь то форма, содержащая факт, или форма, содержащая разницу факта и документа. Это все решается на уровне системы ЭДО.
Хотя СМ+ в данном случае указывает , какой вариант документирования расхождений ожидается покупателем (ИУПД или УКД). На этом основании, в том числе, система ЭДО принимает решения подписать – не подписать титул покупателя.
Есть возможность принимать данные от системы ЭДО в форме , предусмотренной 820 приказом. А отдавать информацию о решении тоже в форме, предусмотренной приказом (титул покупателя). Но при этом смысл и назначение этих артефактов не меняется. Это только информация, а не сами электронные документы.
Реализация принципа единой точки управления процессом выполняется следующим образом. Считается, что точкой управления процессом является рабочее место приемщика в СМ+. По замыслу, система ЭДО должна работать , как бот, тупо подписывающий (отклоняющий) все, что шлет ему СМ+ . По замыслу, пользователь к системе ЭДО не подходит. Он делегирует право подписи роботу. Это базовый сценарий. Ручное вмешательство на стороне системы ЭДО нужно только в случае инцидента. Это альтернативный нехороший сценарий.
См+ не хранит приходящие, как положено по закону для юридически значимых документов. Хранятся только факты их получения и нужная информация из УПД.
При отгрузке.
Процесс зеркален. СМ+ формирует данные для создания на стороне системы ЭДО некоего УПД. Можно назвать это заявкой (требованием) на формирования УПД (ИУПД, УКД) , подписание титула продавца, отправку файла получателю через каналы ЭДО. При отгрузке на стороне СМ+ файл по форме, предусмотренной приказом 820, не формируется. Формируется похожий файл.
Как и в случае приемки, сценарий предполагает, что точка управления и пользователь регулярно находится в интерфейсе СМ+. На стороне системы только работает бот, создающий и подписывающий документы. Пользователь обращается в систему ЭДО только в случае инцидента (например, выпал USB ключ из разъема или лицензия на Крипто-Про закончилась).
Для процессов приемки и отгрузки дополнительной задачей является адресация УПД в конкретный магазин или склад. Штатно УПД не содержит нужных логистических данных. Их по договоренности между абонентами нужно добавлять в штатный УПД, чтобы УПД маршрутизировался в нужный магазин. Практика показала, что надёжным идентификатором места отправки (получения) служит GLN места хранения.
Из описанного выше замысла вытекают возможности и невозможности.
Невозможно.
1. СМ+ не хранить ЮЗД, как положено по закону (подписи, квитанции..).
2. СМ+ не подписывает электронной подписью ничего.
3. См+ при формировании ЮЗД не обладает некоторыми необходимыми для этого данными, поскольку не работает с сервисами справочника организаций и предпринимателей, КЛАДРами.. Т.е. сами эти данные в СМ+ есть. Но они могут содержать мелкие неточности, которые существенны для ЭДО. Например, СМ+ имеет ИНН и КПП организации (подразделения), но может содержать наименование организации, отличное на одну букву от того, что содержится в федеральном справочнике. В документообороте это может создать проблему.
Возможно.
1. Расширить логику обработки на стороне СМ+. Например, чтобы СМ+ участвовал в логике обработки документа, а не только товара. Например, См+ будет давать команду «Подпиши документ», а не как сейчас - «Документируй приемку с расхождениями».
2. Протокол обмена. Сейчас это XML файлы. Можно обсуждать web-сервис, API, json….