Разработка правил обмена данными 1С

Когда нужны собственные правила обмена данными

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

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

Например, необходимо:

• передавать собственные реквизиты, добавленные в конфигурацию;
• включить в обмен собственный справочник или документ;
• сопоставить разные структуры справочников двух систем;
• преобразовать значения при передаче;
• изменить правило поиска существующего объекта;
• исключить создание дублей при загрузке;
• передавать только часть объектов по заданному условию;
• заполнять реквизит приёмника на основании нескольких данных источника;
• по-разному обрабатывать один объект в зависимости от его вида или состояния;
• адаптировать существующий обмен после доработки одной из конфигураций.

Чем правила обмена отличаются от настройки типовой синхронизации

Чем правила обмена отличаются от полноценной интеграции

Правила обмена отвечают прежде всего за преобразование данных:

какой объект источника → в какой объект приёмника → с какими реквизитами и по каким условиям.

Полноценная интеграция может дополнительно включать:

• проектирование API;
• HTTP- или web-сервисы;
• авторизацию;
• очереди сообщений;
• таймауты;
• повторные попытки;
• мониторинг;
• webhook;
• защиту сетевого взаимодействия;
• версионирование интерфейса.

Если задача заключается в создании всего канала взаимодействия между 1С и внешней системой, используется настройка интеграции 1С с другими системами.

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

Сначала анализируем существующий обмен

Перед изменением правил необходимо понять, как обмен работает сейчас.

Проверяем:

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

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

Правило начинается с точного соответствия объектов

До программирования фиксируем, какой объект одной системы соответствует объекту другой.

Например:

• справочник источника → справочник приёмника;
• документ источника → документ другого типа;
• справочник → регистр сведений;
• несколько объектов источника → один объект приёмника;
• один объект → разные объекты в зависимости от его вида.

После определения объектов составляется соответствие их реквизитов и табличных частей.

Это позволяет отделить простое копирование значения от ситуаций, где необходима отдельная логика преобразования.

Соответствие реквизитов фиксируем отдельно

После сопоставления объектов определяем, какие реквизиты источника соответствуют реквизитам приёмника.

Для каждого значимого поля необходимо понять:

• откуда берётся исходное значение;
• в какой реквизит оно записывается;
• совпадают ли типы данных;
• нужно ли преобразование;
• обязательно ли поле;
• что означает пустое значение;
• можно ли изменять уже существующее значение приёмника.

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

Одинаково названные реквизиты не всегда означают одинаковый смысл

Совпадение названия поля в двух конфигурациях ещё не гарантирует, что данные можно переносить напрямую.

Например, реквизит «Статус» в одной системе может описывать состояние заказа, а в другой — состояние согласования документа.

Перед сопоставлением необходимо учитывать:

• назначение реквизита;
• тип значения;
• допустимые варианты;
• момент заполнения;
• влияние на дальнейшую бизнес-логику.

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

Преобразование значений

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

Например:

• один статус источника соответствует другому статусу приёмника;
• код заменяется ссылкой на объект справочника;
• строковое значение преобразуется в перечисление;
• дата приводится к требуемому формату;
• несколько полей объединяются в один реквизит;
• одно исходное значение разделяется на несколько реквизитов;
• значение вычисляется по согласованному алгоритму.

Такие преобразования должны быть явно описаны и проверяемы на контрольных примерах.

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

Справочные значения требуют отдельного сопоставления

Во многих случаях поле содержит не текст, а ссылку на справочник или перечисление.

Например:

• организация;
• контрагент;
• склад;
• подразделение;
• договор;
• номенклатура;
• единица измерения;
• вид цены;
• статья движения денежных средств;
• статус или перечисление.

Значение «Основной склад» нельзя просто записать как строку в ссылочный реквизит. Сначала необходимо определить соответствующий объект в базе-приёмнике.

Для таких полей отдельно задаётся правило поиска или таблица соответствий.

Правило поиска существующего объекта

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

Для поиска могут использоваться:

• GUID;
• внешний идентификатор;
• артикул;
• штрихкод;
• ИНН и КПП;
• номер документа внешней системы;
• код;
• таблица соответствий;
• комбинация нескольких реквизитов.

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

Что делать, если объект не найден

Поведение определяется отдельно для каждого типа данных.

Универсальное правило «не найдено — создать новый объект» обычно небезопасно для сложных справочников.

Несколько найденных объектов — отдельная ошибка сопоставления

Если правило поиска вернуло более одного возможного объекта, нельзя случайно выбирать первый.

Такая ситуация может означать:

• дубли в базе;
• слишком слабый ключ поиска;
• неполные данные источника;
• разную бизнес-сущность при одинаковом наименовании;
• необходимость дополнительного условия.

До исправления причины такой объект желательно исключить из автоматической обработки и явно зафиксировать проблему.

Создание нового объекта требует заполнения обязательных данных

Если правило разрешает создавать новый объект, одного идентификатора может быть недостаточно.

Нужно определить:

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

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

Обновление существующего объекта требует отдельного правила

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

Для каждого изменяемого поля определяем:

• имеет ли источник право изменять этот реквизит;
• нужно ли обновлять значение при каждом обмене;
• следует ли сохранять локальное значение приёмника;
• что делать, если значение источника пустое;
• нужно ли сравнивать новое и существующее значение перед записью.

Например, внешняя система может быть источником артикула и маркетингового описания номенклатуры, но не должна изменять ставку НДС, вид номенклатуры или другие реквизиты, которые ведутся непосредственно в 1С.

Пустое значение тоже имеет смысл

При обмене необходимо различать как минимум несколько ситуаций:

• источник не передал реквизит вообще;
• источник передал пустое значение;
• источник явно требует очистить существующее значение;
• поле необязательно и должно остаться без изменений.

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

Поэтому для значимых реквизитов заранее фиксируем семантику пустого значения и поведение при обновлении существующего объекта.

Условия отправки объектов

Не каждый объект источника обязательно должен участвовать в обмене.

Правило может учитывать, например:

• организацию;
• вид документа;
• статус;
• дату;
• подразделение;
• склад;
• вид номенклатуры;
• признак активности;
• другой согласованный реквизит или условие.

Например, во внешнюю систему могут передаваться только действующие товары определённого вида либо только проведённые документы после установленной даты.

Условия должны быть сформулированы однозначно, чтобы пользователь понимал, почему один объект был передан, а другой — нет.

Условия загрузки данных в систему-приёмник

Отбор на стороне источника и проверка на стороне приёмника решают разные задачи.

Даже если сообщение было отправлено, приёмник может дополнительно проверять:

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

Если условие не выполнено, результат должен быть понятным: объект пропущен, сообщение отклонено либо требуется ручная обработка.

Молчаливое игнорирование ошибки усложняет контроль обмена и может создавать расхождения между системами.

Табличные части требуют собственного сопоставления

Для документов и некоторых справочников недостаточно сопоставить только реквизиты шапки.

Необходимо отдельно определить правила для строк табличной части:

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

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

Создание документа отличается от обновления документа

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

Проведение документов не следует включать без проверки

Создать документ в 1С и успешно провести его — разные операции.

При проведении конфигурация может:

• проверять обязательные данные;
• формировать движения регистров;
• контролировать остатки;
• рассчитывать суммы;
• проверять доступность периода;
• выполнять собственную бизнес-логику.

Поэтому режим обработки согласуется заранее:

• создать документ непроведённым;
• провести после проверки пользователем;
• проводить автоматически, если контрольные сценарии подтверждают корректность;
• не проводить документы определённого типа или состояния.

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

Обратное направление обмена может требовать другого правила

Если данные передаются в обе стороны, обратное преобразование не всегда является зеркальным отражением прямого.

Например:

• заказ создаётся во внешней системе и загружается в 1С;
• обратно из 1С передаётся только статус заказа;
• номенклатура создаётся в 1С и выгружается наружу;
• внешняя система возвращает только собственный идентификатор объекта.

Для каждого направления отдельно определяем:

• состав объектов;
• состав реквизитов;
• источник данных;
• правила преобразования;
• условия отправки;
• обработку повторов.

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

Удаление объекта требует отдельного сценария

Удаление данных в одной системе не должно автоматически означать физическое удаление соответствующего объекта в другой.

Для каждого типа данных необходимо определить, что делать, если объект больше не используется или помечен на удаление.

Возможные варианты:

• не передавать удаление вообще;
• установить признак неактивности;
• пометить объект на удаление;
• изменить статус;
• скрыть объект из дальнейшей выгрузки;
• передать отдельное событие об удалении;
• оставить решение пользователю.

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

Изменение ключевого реквизита не должно создавать новый объект

Если объект сопоставляется по изменяемому реквизиту, после его изменения система может перестать находить ранее созданное соответствие.

Например, могут измениться:

• артикул;
• код;
• наименование;
• номер внешней карточки;
• другой используемый для поиска реквизит.

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

Если постоянного идентификатора нет, необходимо заранее определить, как будет обрабатываться изменение ключа.

Конфликт изменений между системами

Если один и тот же реквизит может изменяться в обеих системах, простого сопоставления недостаточно.

Нужно определить правило приоритета.

Например:

• всегда принимать значение из 1С;
• всегда принимать значение внешней системы;
• использовать последнее изменение;
• не изменять поле автоматически при конфликте;
• передавать ситуацию пользователю;
• разделить ответственность по отдельным реквизитам.

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

Тогда обмен не пытается постоянно перезаписывать одно и то же значение в обе стороны.

Значения по умолчанию должны быть осознанными

Если источник не содержит обязательного для приёмника реквизита, иногда используется значение по умолчанию.

Например:

• определённый склад;
• организация;
• вид операции;
• единица измерения;
• статья;
• статус;
• другой обязательный параметр.

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

Также нужно определить, применяется ли значение по умолчанию всегда или только при отсутствии исходного значения.

Проверка входящих данных до записи

До создания или изменения объекта полезно проверить, что входящие данные соответствуют требованиям принимающей системы.

Проверки могут включать:

• наличие обязательных реквизитов;
• корректность типа значения;
• допустимый диапазон;
• существование связанных объектов;
• допустимость статуса;
• уникальность внешнего идентификатора;
• соответствие бизнес-условиям.

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

Ошибка одного объекта не всегда должна останавливать весь пакет

При массовом обмене необходимо определить поведение при ошибке одного элемента.

В любом случае ошибочный объект должен быть идентифицируемым, чтобы его можно было исправить и повторно обработать отдельно.

Повторная загрузка должна быть предсказуемой

После исправления ошибки пользователь или регламентный механизм может повторно отправить тот же объект.

Правило должно заранее определять результат такого повтора.

Необходимо понимать:

• как найти ранее созданный объект;
• какие данные обновить;
• какие локальные изменения сохранить;
• как обработать уже созданные строки;
• что считать успешным повтором;
• когда повтор необходимо отклонить.

Ошибки обмена должны быть понятны пользователю

Сообщение «Ошибка преобразования данных» редко помогает найти причину проблемы.

Для диагностики желательно фиксировать:

• какой объект обрабатывался;
• его внешний идентификатор;
• какое правило выполнялось;
• какой реквизит вызвал проблему;
• какое значение было получено;
• что ожидала принимающая система.

Например, вместо общего сообщения полезнее получить результат вида:

«Заказ 45821: не найдено соответствие склада с внешним кодом MSK-03».

Такую ошибку можно локализовать и исправить без повторного анализа всего обмена.

Журнал обмена нужен для сопровождения правил

После запуска важно иметь возможность ответить на вопросы:

• передавался ли конкретный объект;
• когда выполнялся обмен;
• был ли объект создан или обновлён;
• возникла ли ошибка;
• выполнялась ли повторная обработка;
• какое соответствие использовалось.

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

Не требуется сохранять абсолютно всё содержимое каждого сообщения, если для диагностики достаточно идентификаторов, результата и текста ошибки.

Производительность правил обмена имеет значение

Корректное преобразование данных должно оставаться приемлемым по скорости при реальном объёме информационной базы.

На производительность могут влиять:

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

Правило, которое быстро работает на десяти тестовых объектах, необходимо отдельно проверять на объёме, близком к рабочему.

Не следует выполнять одинаковый поиск для каждой строки заново

Если в одном пакете многократно используются одни и те же связанные данные, повторный поиск может создавать ненужную нагрузку.

Например, сотни строк документов могут ссылаться на:

• один и тот же склад;
• одну организацию;
• повторяющиеся единицы измерения;
• одни и те же виды цен;
• небольшой набор контрагентов.

В подходящих случаях соответствия можно получать заранее или повторно использовать уже найденный результат в рамках обработки пакета.

Конкретный способ зависит от архитектуры существующего обмена и объёма данных.

Правила должны учитывать порядок передачи связанных объектов

Документ или справочник может ссылаться на данные, которые ещё не существуют в принимающей системе.

Например, заказ может использовать:

• контрагента;
• договор;
• склад;
• номенклатуру;
• характеристики;
• единицы измерения.

Если зависимый объект поступил раньше основного, правило должно иметь определённое поведение:

• создать необходимый объект;
• отложить обработку;
• зафиксировать ошибку;
• использовать заранее согласованное соответствие.

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

Изменение структуры конфигурации может потребовать корректировки правил

После обновления или доработки одной из участвующих систем могут измениться:

• состав реквизитов;
• типы данных;
• структура табличных частей;
• перечисления;
• обязательность заполнения;
• логика проведения документов;
• назначение отдельных объектов.

Если правило обращается к изменённой структуре, необходимо проверить, продолжает ли старое соответствие отражать актуальный бизнес-смысл.

Особенно важно это для собственных правил, которые были разработаны под конкретные версии и доработки конфигураций.

После обновления проверяем не только отсутствие технической ошибки

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

Поэтому контроль после обновления включает проверку:

• создания нового объекта;
• обновления существующего объекта;
• поиска соответствий;
• преобразования ключевых реквизитов;
• табличных частей;
• повторной передачи;
• ошибочных данных;
• обратного направления, если оно используется.

Если обновляется доработанная конфигурация, дополнительно может потребоваться обновление доработанной конфигурации 1С с проверкой собственных механизмов обмена.

Тестировать правила лучше на копии или отдельном контуре

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

Для тестирования желательно подготовить:

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

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

Контрольные примеры формируются до массового запуска

Для каждого существенного правила полезно иметь небольшой набор объектов, по которым заранее известен ожидаемый результат.

Например:

• новый элемент справочника;
• существующий элемент;
• объект с изменённым реквизитом;
• объект без соответствия;
• объект с пустым значением;
• документ с несколькими строками;
• повтор ранее загруженного документа;
• ошибочный объект.

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

Так можно проверить именно логику правила, а не ограничиваться фактом отсутствия сообщения об ошибке.

Отдельно проверяем массовый сценарий

После проверки отдельных примеров необходимо убедиться, что правило корректно работает на реальном количестве объектов.

Массовая проверка помогает обнаружить:

• неожиданные дубли;
• редкие варианты данных;
• незаполненные реквизиты;
• ошибки сопоставления;
• неприемлемое время обработки;
• накопление большого числа ошибок;
• зависимость результата от порядка объектов.

Необязательно сразу запускать обмен на всей исторической базе. Объём можно увеличивать постепенно после проверки предыдущей выборки.

Первоначальная загрузка и регулярный обмен могут использовать разные условия

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

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

Разовая миграция и постоянный обмен — разные задачи

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

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

Исторические данные требуют отдельного решения

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

До разработки определяем:

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

Передача всей истории «на всякий случай» увеличивает объём проверки и может перенести во вторую систему устаревшие или ошибочные данные.

Изменение правила не должно неожиданно переобработать старые данные

После корректировки алгоритма необходимо понимать, к каким объектам применяется новая версия правила.

Возможны разные сценарии:

• новое правило действует только для новых изменений;
• необходимо повторно передать отдельные объекты;
• нужно переобработать данные начиная с определённой даты;
• требуется полная повторная выгрузка согласованного набора;
• исторические объекты должны остаться без изменений.

Массовый повтор старых данных после изменения правила выполняется только тогда, когда это действительно требуется.

Версию правил полезно связывать с изменением требований

Если логика обмена развивается, важно понимать, почему конкретное преобразование было добавлено или изменено.

Для существенных изменений полезно фиксировать:

• какое требование изменилось;
• какие объекты затронуты;
• какие реквизиты изменились;
• нужно ли повторно передавать старые данные;
• какие контрольные примеры проверены;
• с какого момента применяется новое правило.

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

Документируем нестандартную логику

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

Для нестандартных преобразований желательно описать:

• исходный объект;
• объект приёмника;
• условие выполнения;
• правило поиска;
• преобразование значений;
• поведение при отсутствии соответствия;
• ожидаемый результат;
• контрольный пример.

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

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

Не каждую ошибку нужно исправлять программным правилом

Иногда причина проблемы находится не в конвертации, а в исходных данных или организации процесса.

Например:

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

В такой ситуации сложный программный алгоритм может только скрыть проблему.

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

Ручные исключения должны быть контролируемыми

Иногда для отдельных объектов действительно требуется особое соответствие.

Например:

• один старый код соответствует новому объекту;
• несколько исторических значений объединяются в одно;
• для конкретной организации используется отдельное правило;
• ошибочное значение источника временно заменяется корректным.

Такие исключения лучше хранить и описывать так, чтобы их можно было:

• найти;
• проверить;
• изменить;
• удалить после потери актуальности.

Изменения лучше внедрять ограниченным объёмом

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

Последовательность может быть такой:

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

Перед рабочим запуском нужна сверка результата

После тестовой передачи необходимо проверить не только количество обработанных объектов.

Сверяем:

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

Для финансово или операционно значимых данных дополнительно согласуется предметная сверка с ответственным пользователем.

Как проходит разработка правил обмена

Что не входит автоматически

Разработка правил обмена сама по себе автоматически не включает:

• создание полноценного API для внешней системы;
• разработку внешнего сайта, CRM, WMS или другой системы;
• полное перепроектирование существующей интеграции;
• исправление всех дублей и ошибок накопленных данных;
• ручное сопоставление тысяч неоднозначных объектов;
• миграцию всей исторической базы без согласованного объёма;
• изменение бизнес-процессов заказчика;
• исправление всех ранее существовавших доработок конфигурации;
• настройку сетевой инфраструктуры, VPN и внешних серверов;
• круглосуточный мониторинг обмена;
• сопровождение стороннего API без отдельного соглашения.

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

Когда вместо изменения правил лучше исправить исходные данные

Программная доработка не всегда является оптимальным решением.

Сначала имеет смысл исправить исходные данные, если проблема возникает из-за:

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

Иначе новое правило может лишь автоматически переносить существующие ошибки из одной системы в другую.

Когда требуется полноценная переработка обмена

Иногда локальной корректировки правил недостаточно.

Это возможно, если:

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

В такой ситуации сначала оценивается, что выгоднее: продолжать усложнять старые правила или перейти к отдельной интеграции 1С с другой системой.

Стоимость разработки правил обмена

5 000 ₽ за час работы специалиста.

Цена означает стоимость часа работы, а не фиксированную стоимость любой доработки обмена.

Трудоёмкость зависит от:

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

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

Что потребуется для первичной оценки

Для предварительного анализа желательно сообщить:

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

Для первичной оценки особенно полезен конкретный пример:

«В источнике заполнено так → сейчас в приёмнике получается так → требуется получить такой результат».

Связанные задачи

В зависимости от причины проблемы могут потребоваться другие услуги:

• настройка типовой синхронизации 1С — если собственная логика не требуется и достаточно правильно настроить штатный обмен;
• настройка интеграции 1С с другими системами — если требуется спроектировать не только преобразование данных, но и сам канал взаимодействия;
• обновление доработанной конфигурации 1С — если обмен необходимо проверить и адаптировать в рамках обновления изменённой конфигурации.

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

Частые вопросы о разработке правил обмена данными 1С