1c edi что это

Обновлено: 07.07.2024

1С:Сеть является EDI-сервисом компании 1С, встроенным в программные продукты 1С и представляет собой попытку решения дилеммы EDI: легкость подключения выгода от эксплуатации. Идея сервиса 1С:Сеть состоит в том, чтобы встроив подключение к EDI в каждую коробку 1С, и создав специального EDI-провайдера дать малым организациям возможность полноценного использования преимуществ EDI, как средства прямого обмена между информационными системами, обмена который невозможен при подключении к EDI через Интернет-браузер

Содержание

История и дилемма EDI

Элитный EDI 1960-х и 1970-х

Интернет и EDI в 1990-е

И сегодня компании по-прежнему вынуждены выбирать между дорогостоящим проектом подключения своих информационных систем к EDI и неэффективной работой через браузер с ручным или полуручным переносом данных между EDI и информационной системой.

Итак, крупные компании, располагающие достаточными средствами, подключают свои информационные системы к EDI и получают ощутимый рост эффективности, а их малые партнёры, не готовые потратить средства на интеграцию своей информационной системы с EDI, работают через браузер, смирившись с неоправданным ростом издержек по сравнению с практически бесплатным e-mail. Примечательно, что, поскольку малых компаний значительно больше, чем крупных, то именно от них EDI-провайдеры получают основной доход, и, значит, именно они оплачивают содержание EDI-инфраструктуры для всей отрасли.

Справедливости ради следует отметить, что существуют компании, получающие заказы лишь изредка и не использующие комплексные корпоративные информационные системы. Для них web-EDI является идеально подходящим решением, позволяющим сбалансировать интересы малого поставщика и крупного покупателя [1] [2] .

Идея «1С:Сеть»

Создатели сервиса 1С:Сеть сделали попытку решить дилемму EDI в духе Win-win для отдельно взятого региона бывшего СССР, пользуясь распространенностью программных продуктов 1С. 1С:Сеть был создан, как специальный EDI-сервис, подключение к которому встроено в стандартные конфигурации 1С:Предприятие. Таким образом, покупатель 1С получал подключение к 1С:Сеть, интегрированное в ИС, прямо «из коробки». Дилемма доступность-эффективность EDI для пользователей 1С, казалось бы, переставала существовать, а, благодаря умеренной цене программных продуктов 1С, эффективный EDI, интегрированный в информационную систему, становился доступен компаниям любого размера. Для фирм, использующих иные информационные системы, 1С:Сеть предоставил те же средства подключения, что и другие EDI-провайдеры.

Недостатки «1С:Сеть»

Альтернативные способы решения проблемы

Коннекторы к ИС

Производители «тяжёлых» ERP, такие как SAP или Oracle поставляют, как и 1С, средства связи с EDI в составе своих систем, что сокращает время (но не бюджет) подключения к EDI крупных компаний. Конечно, на российской территории благодаря распространённости 1С наличие даже встраиваемых объектов для подключения к EDI, поддерживаемых самой 1С, выглядит привлекательно.

Сервисно-ориентированная архитектура, Enterprise Service Bus

Подключение к EDI может быть осуществлено в рамках интеграции нескольких информационных систем одного предприятия или родственных предприятий. Современные способы такого объединения базируются на идеях Сервисно-ориентированной архитектуры и обязательно предусматривают наличие сервиса обмена данными между системами, одним из воплощений которого является Enterprise Service Bus (ESB). В ESB часто входят готовые модули связи с EDI, что даёт возможность подключить к EDI все связанные с ESB ИС, среди которых могут быть и ИС малых компаний, входящих в союз, получающих, таким образом, EDI вместе с подключением к ESB, как результат интеграционного проекта.

Можно подключить к EDI ИС, расположенную в организации, а можно поступить и наоборот: разместить подключённую к EDI информационную систему прямо в Интернет у специального провайдера и дать к ней доступ через веб-браузер всем сотрудникам организации.

Обычная реализация этой модели такова: компания-провайдер создаёт у себя на сервере простую в эксплуатации информационную систему, приспособленную для одновременного использования множеством организаций, и за абонементную плату предоставляет к ней доступ. Такой способ распространения программного обеспечения называют ПО «по-запросу» или Software On Demand, Software as a Service (SaaS). Так, например, если бы 1C предоставляла облегчённые версий самой системы 1С:Предприятие со встроенным EDI через Интернет за разумную абонентскую плату, то малые компании могли бы позволить себе эксплуатацию ИС со встроенным EDI, что, видимо, послужило бы окончательным решением проблемы их подключения к EDI.

Литература

Фото Бориса Мальцева. Клерк.Ру

“Система - больше, чем просто совокупность ее элементов”; “Несколько разработчиков - это еще не команда разработки”. Расскажу, как мы прочувствовали эти очевидные утверждения на своей шкуре.

Наша команда разрабатывает модуль интеграции EDI для 1С.

Изначально обработка должна была выполнять 4 действия:

Проблемы предметной области

Почти в каждом IT-проекте встречаются совершенно очевидные предположения, которые разбиваются о суровую реальность. Мне очень нравится пример с именами.

Чем же нас порадовал российский EDI?

Проблемы кода

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

За плечами у нас были франчи, ИТ-отделы компаний разных масштабов, фриланс. Каждый работал в одиночку, как это обычно и бывает с 1С-никами.

Когда-то стройный код стал обрастать костылями. Методы - непонятными параметрами, о назначении которых мы стали забывать. Тексты запросов становились все запутаннее, они собирались динамически в зависимости от десятков условий, закопанных где-то глубоко. Отладка усложнялась, а количество багов стало плавно, но уверенно расти. Как и их сложность: порой одна ошибка обходилась нам в несколько человекочасов только на ее локализацию. А исправление иногда только усложняло исходный алгоритм.

Общее владение кодом падало.

Параллельно мы развивали версию для конфигураций на управляемых формах. Ее код мы частично скопировали из обработки на ОФ, но дальше развивали независимо. Изменения базовой функциональности (например, работы с API сервиса) приходилось вручную переносить из одной обработки в другую и адаптировать.

Кроме того, у нас иногда появлялись клиенты с полностью самописными конфигурациями. Адаптировать модуль под такие разработки было тяжело: один из разработчиков полностью уходил в эту задачу на 2-3 для, потом еще в течение недели (или больше) занимались отладкой получившегося Франкенштейна. Последующее обновление обработки становилось неоправданно тяжелым. А развитие продукта, естественно, буксовало из-за этого.

В общем, мы столкнулись с тем, с чем ранее не имели дела: с разработкой тиражного продукта (и со всей ответственностью, вытекающей из этого), а также с необходимостью работы в команде.

Средства командной разработки от 1С нам не подошли. “Хранилище Конфигурации” решает другую задачу: оно в буквальном смысле хранит конфигурацию. И все. Ветвление и объединение веток, режим “blame” и возможность построчного комментирования кода отсутствуют. Да, в последних версиях 8.3 разработчики платформы дали возможность разложить конфигурации на исходники в виде текстовых файлов, которые уже можно хранить в современных системах контроля версий. И скомпилировать конфигурацию из этих исходников, разумеется. Нас эти возможности очень радуют, но воспользоваться мы ими не можем. Причина проста - нам приходится поддерживать версию для 8.2.

Итого, мы имели около 85 тысяч строк кода в 2 разных обработках, длинные запутанные методы, проблемы с объединением наработок. Тяжелее всего было объединять изменения двух разработчиков в рамках одной функции.

Как выживать?

Я не открою здесь Америку, многое давным-давно описано в учебниках ООП. Можно почитать Фаулера. Но 1С8 - не совсем ООП, и мы долгое время писали по принципу “лишь бы работало” (и работало, конечно, до поры до времени).

Технические решения

Рефакторинг - наше все

В продуктах подобного масштаба читабельность и структурированность кода становится не эстетическим удовольствием перфекциониста, а необходимым условием выживания проекта вообще. Лучше потратить лишний час на структурирование и подбор говорящих за себя имен методов/переменных, чем заставить своего коллегу потом убить 2 дня на поиск ошибки, оторвав его от текущих задач на развитие.

А еще в сложном, запутанном коде часто водятся баги. Прозрачный и лаконичный код они почему-то не любят.

Например, встречаются такие нагромождения:

<170 строк чего-то>

<250 строк чего-то>

КонецЕсли" (несколько экранов спустя).

Если ДальшеДелатьНечего Тогда

И жить стало легче.

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

Рефакторинг проводим время от времени, без какого-либо плана, по настроению. А настроение обычно возникает на фоне необходимости добавления какой-либо фичи, затрагивающей запутанные участки кода.

Чем меньше кода, тем лучше

Не в ущерб читабельности, здесь важно вовремя остановиться. Одинаковые или просто похожие куски кода мы стали объединять в новые методы или в циклы. Это типичный прием рефакторинга, но мы пошли чуть дальше.

Мы начали избавляться от функциональности, от которой в принципе можно было избавиться (имелась альтернатива). Это было довольно болезненно: взять и выбросить десятки тысяч строк кода, написанных когда-то совместными усилиями. Скрежет наших зубов раздавался по всему этажу. Самые значимые примеры:

Полтора года назад у нас было 2 обработки и 85 000 строк кода в сумме. Сейчас одна обработка и 70 000 строк кода. Разумеется, эти полтора года мы не только уничтожали код, но и писали много нового.

Декомпозиция методов

Это тоже часть рефакторинга, но о ней я расскажу чуть подробнее.

Чем меньше разных действий выполняет метод, тем он читабельнее. Например, если в одной процедуре/функции встречается чтение файла с FTP и заполнение какого-либо документа, логичнее разбить его на два разных метода. Методу, который парсит XML, незачем знать, как устроена текущая конфигурация. Еще есть управляемые формы, где интерактивные действия недоступны на сервере.

Это аналог старых добрых классов в ООП и немного закос под mvc.

Мы стали делить длинные портянки кода на логические блоки, и средний размер одного метода упал с 40 до 30 строк кода. Стало гораздо проще объединять код разных веток перед релизом. Вероятность конфликтов свелась к минимуму, а их разрешение упростилось в разы.

Да, у нас еще остаются портянки строк на 300. Придет время - и их по возможности раскидаем.

Автоматизированное тестирование

Мы внедрили 2 системы тестов: сценарные тесты и юнит-тесты на основе xUnitFor1c. Каждый коммит в системе контроля версий подхватывается скриптом и автоматически отправляется на тестирование в нескольких типовых конфигурациях 1С. Релиз не выпускаем до тех пор, пока все тесты не позеленеют, и пока тестировщики не скажут "ок", разумеется. (Да, у нас есть тестировщики, нет, они не программисты).

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

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

Стараемся придерживаться такого правила: если в релизной версии более 1-2 раз регистрируются ошибки, возникающие в одном и том же методе, то покрываем этот метод тестами. Чаще всего сначала его приходится потрошить и расчленять подвергать рефакторингу.

Система контроля версий

Изначально использовали SVN с клиентом от Tortoise. Использовали его для блокировки предрелизной версии в момент заливки изменений и для хранения истории коммитов и релизов.

Затем на коленке собрали собственную систему контроля версий на 1С. Выглядит примерно так:

Автотесты интегрированы с этой системой и зеленеют/краснеют прямо на коммитах. Столбец с зелеными кружками и заголовком “U” - юнит-тесты. Столбец правее с заголовком “F” - интеграционные тесты.

Иногда встречаются такие цепочки коммитов:

Сюда же встроен V8Reader с возможностью сравнить 2 произвольных коммита без открытия конфигуратора. Получается очень удобно.

Здесь же автоматизированы действия при выпуске релиза: формирование RSS, закрытие задач в трекере, расчет контрольной суммы файла и т.д.

Почитав статьи про современные системы контроля версий (раз, два), захотели перейти на связку Git+Precommit1c с компиляцией обработки из исходников. Увы, в платформе 8.x есть не очевидная особенность: при сохранении файла внешней обработки некоторые формы (не управляемые) хаотично перекодируются, выдавая совершенно другой файл, даже если вы просто пробел в коде добавили. Мы пытались как-то обмануть платформу, чтобы можно было объединять изменения разных веток и компилировать исходники обратно во внешнюю обработку. В конце концов пришлось смириться с реальностью и оставить эти попытки. Однако используем Git+Precommit1c для “ленивого” Code Review: каждый участник команды получает уведомления о новых коммитах и может оставить комментарии к любой строке изменившегося кода. В precommit1c внесли изменения:

Но делает это более корректно:

Работа в нестандартных конфигурациях

Периодически возникавшая необходимость адаптировать модуль под нетиповую конфигурацию очередного крупного клиента заставила нас задуматься о каком-то инструменте, который позволит выполнять эту работу хотя бы с минимальными усилиями. Мы же программисты, самые ленивые люди в мире. Тем более что для 7.7 такой инструмент уже был готов: у нашего основного разработчика на этой платформе черный пояс по магии.

Изначально модуль 8.х разрабатывался на УТ 10.3. Весь код был пронизан конструкциями вида Заказ = Реализация.Сделка, например.

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

Был период, когда мы целенаправленно брали вне очереди задачи на настройку модуля в самописных конфигурациях и смотрели, в какие участки кода приходится вносить правки. Начинали с простого: с замены конструкций “Заказ = Реализация.Сделка” на функции-обертки: “Заказ = ПолучитьЗаказ (Реализация)”. В итоге получился довольно мощный инструмент, основная идея которого, надеюсь, будет понятна. Большую часть описания конфигураций удалось оформить декларативно (макеты, тексты запросов, без кода).

Получилось примерно так:

(Данные запросы разбираются на части и собираются заново в нужном виде. И не говорите, что СКД для этого не предназначена. Знаю, согласен.)

Эти вещи позволили нам легко выполнять 90% работы по кастомизации обработки.

После этого провели боевой тест на полностью самописной конфигурации, вот фрагмент метаданных для наглядности :

Модуль взлетел быстро, большую часть изменений удалось вынести “сбоку”, что дает возможность с минимальной болью обновляться в будущем.

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

И еще один побочный эффект от проделанной работы: стало гораздо проще влить в модуль логику работы с 3 основными конфигурациями на управляемых формах.

Организационные решения

Code Review

Очень простой и мощный инструмент. При масштабных изменениях в коде автор кидает клич, желающие изучают diff и дают свои замечания.

Практический эффект: на этом этапе мы действительно иногда находим ошибки в коде, неоптимальные действия, нечитабельные места. Психологический эффект: зная, что твой код будет придирчиво изучать коллега, стараешься писать как можно качественнее и яснее. Плюс повышаем общее владение кодом: напомню, это 70 000 строк.

Пример “ленивого” Code Review:

“Митинги” (Daily Scrum meeting)

Это часть технологии “SCRUM”. Каждый день в 15:45 встаем возле доски и двигаем листочки с задачами, рассказывая друг другу, что сделали и что собираемся делать. Это здорово помогает быть в курсе того, куда вообще двигается продукт, и заодно позволяет избегать проблем с объединением кода.

Циклы разработки

Набираем задач на ближайшую неделю
Разрабатываем и тестируем в своих ветках
Проводим Code Review всех крупных изменений
Сливаем в предрелизную ветку, она же версия для тестирования
Тестировщики говорят свое "фи", исправляем баги
Когда тестировщики говорят "ок", готовим описание релиза для rss, выпускаем релиз (обычно это 2-3 недели от начала итерации, бывает и больше).
Критичные баги в случае их появления лечим в промежуточных релизах, дублируя фикс в предрелизную ветку.

Работа с багами

Критичные/блокирующие баги исправляются везде и всегда в первую очередь. А мелкие, позволяющие продолжить работу, обычно копятся. Психологически очень тяжело заставить себя потратить час на исправление одной ошибки из известных 46, чтобы их осталось 45.

Однажды мы ввели “день багов”. Это один день в неделю, когда все, преодолев собственное сопротивление, откладывают в сторону все новые фичи и занимаются исключительно исправлением таких вот мелких ошибок. Сейчас их осталось 13, это самые редкие или неуловимые.

Подбор задач из очереди

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

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

При работе фрилансом я сталкивался с тем, что клиент настаивал на придуманном им неоптимальном способе решения задачи. Если не удавалось его переубедить, в действие вступал простой алгоритм:

Зато у нас сформировалось собственное видение стратегии развития модуля. Именно стратегии, а не беспорядочного исполнения желаний. И при отборе задач в очередную итерацию мы определяем их по таким критериям:

Что сейчас?

Не скажу, что год-два назад мы прямо ощущали какой-то большой дискомфорт. Нет, мы занимались разработкой в привычном для 1С-ника режиме (ну, вы понимаете, в каком именно). Более того, казалось, что по-другому и не бывает. Это как с курением: пока куришь, не понимаешь что что-то не так. Понимаешь только тогда, когда уже бросил.

Сейчас нам стало гораздо спокойнее выпускать новые релизы. Легче объединять код. Легче его поддерживать, мы больше не боимся через год-два полностью погрязнуть в разборе багов. Мы развиваем модуль по своей стратегии, и нам это нравится. Получаем удовольствие от красиво написанного кода и морщимся, наткнувшись на свои же костыли многомесячной давности. Продолжаем набивать шишки и расти. Наверное, так и выглядит командная разработка в других средах за пределами 1С.

Опубликован очередной релиз стандартной библиотеки электронных документов 1С:БЭД 1.8, в котором анонсированы новые возможности для обмена электронными документами в среде «1С:Предприятие».

Сервис 1С:EDI включен в стандартную библиотеку электронных документов

В описании свежего релиза 1С:БЭД говорится, что в библиотеку добавлена новая подсистема для интеграции с сервисом 1С:EDI в ознакомительных целях. 1С:EDI в данном случае – это сервис, который входит в состав комплексного продукта 1С:Бизнес-сеть и предназначен для формирования, согласования и отслеживания выполнения заказов посредством обмена электронными документами.

В качестве ключевого преимущества 1С:EDI обозначается то, что пользователи смогут отказаться от ручного ввода данных, создавая учетные документы в 1С на основании полученных электронных. Обновленная версия 1С:БЭД 1.8 включает отдельное рабочее место «Текущие дела EDI», которое становится доступным после подключения конфигурации к сервису 1С:Бизнес-сеть.

Текущие дела EDI в 1С:БЭД 1.8

На данный момент 1С:EDI доступен почти во всех относительно свежих релизах тиражных конфигураций:

1C:Управление холдингом 8
1С:ERP Управление Холдингом 8, начиная с версии 3.0.2.1
1С:ERP Управление предприятием 2, начиная с версии 2.4.5
1С: Бухгалтерия 8, начиная с версии 3.0.42
1С:Комплексная автоматизация 8, начиная с версии 2.4.5
1С:Розница 8, начиная с версии 2.2.8
1C:Управление нашей фирмой 8, начиная с версии 1.6.15
1С:Управление торговлей 8, начиная с версии 11.4.5

В целом, данное решение должно помочь быстрее освоиться в 1С-ЭДО, что особенно актуально на фоне того, что по работе с данным сервисом не так много обучающих материалов, а сам по себе 1С-ЭДО содержит в себе массу неочевидных для пользователя функциональных решений.

Механизм советов будет доступен пользователям сервиса, начиная с 1С:БЭД 1.7.2. Подробное описание данной функциональности доступно на сайте 1С-ЭДО.

Что еще нового появится в работе с электронными документами

Кроме 1С:EDI и улучшенной справки, обновленная стандартная «Библиотека электронных документов 1.8» содержит еще несколько новых возможностей:

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

Также при наличии в конфигурации Библиотеки регламентированной отчетности поддержана возможность выгрузки для ФНС документов вида «Акт о расхождениях», «Соглашение об изменении стоимости», «Акт на передачу прав».

Модуль 1C:EDI для обмена документами с торговыми сетями

31 мая 2021 фирма 1С выпустила информационное письмо №28360 о выпуске ознакомительной версия продукта "Модуль 1C:EDI" для работы c сервисом 1С:EDI.

Что представляет собой сервис 1С:EDI? Аббревиатура EDI (Electronic Data Interchange) в переводе с английского язіка обозначает электронный обмен информацией. По сути, это процесс конвертации и обмена данными между организациями. Наиболее востребованным данный сервис будет в компаниях, где в текущей работе задействован большой поток документов. Например, в ретейле, где торговые сети просят поставщиков обмениваться с ними данными по EDI. На уровне законодательства у нас пока нет такого стандарта, но очень часто ритейлеры жестко ставят вопрос о его обязательном использовании.

Данный сервис поможет избежать ошибок, которые возникают при ручном вводе информации, и сократит время обработки документов. Включить его в свою работу смогут компании, которые подключились к Docrobot (E-COM) и используют электронные документы стандарта EDI. Docrobot (E-COM) – это облачный провайдер, который обеспечивает связь между торговой сетью и ее поставщиками, а также между торговой сетью и логистическими компаниями.

С помощью "Модуля 1C:EDI" можно проследить всю цепочку документов по каждому заказу в компании. Сотрудники смогут увидеть, на какой стадии обработки находится заказ и что нужно сделать с ним дальше. Сейчас в модуле реализована строгая последовательность: «Заказ → Ответ на заказ → Уведомление об отгрузке → Уведомление о приемке → УПД».

Интеграция модуля 1С:EDI

"Модуль 1C: EDI" работает с 1С:ERP 2.5 и 2.4, с программой 1С:Комплексная автоматизация в версии 2.5, а также конфигурациями 1С:Управление торговле» редакций 10.3 и 11, 1С:Бухгалтерия версии 3, 1С:УНФ и 1С:УПП 1.3.

"Модуль 1C:EDI" работает в качестве подключаемого расширения для конфигураций платформы 1С:Предприятие версии 8.3 и для приложений, работающих в сервисе 1С:Фреш.

Как внешняя обработка 1C:EDI работает с платформой 1С:Предприятие версии 8.2 при включении режима совместимости.

Читайте также: