Настройка автоматического обмена данными при миграции с 1С:УТ на 1С:КА

Исходная ситуация

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

Компания приняла решение мигрировать с платформы «1С:Управление торговлей» версии 11.5 на «1С:Комплексная автоматизация 2.0». Задача выглядела вполне стандартной — разработчик предусмотрел для этого соответствующие инструменты. Однако трудность состояла в том, что процесс миграции растянут во времени, а деятельность предприятия за это время никуда не исчезает: операции продолжаются и их необходимо отражать в системе. Старая база непрерывно наполняется свежими данными, прекратить этот поток невозможно — это немедленно обернётся финансовыми и репутационными потерями. При этом переход откладывать тоже нельзя.

Задача, которую поставил перед нами клиент, звучала так:

Пока все отделы компании окончательно не перешли на КА, необходимо поддерживать постоянный поток документации оперативного учёта между базами УТ и КА, в том числе объекты с нестандартными метаданными.

Как мы выполняли работу

1. Мы проанализировали всю нормативно-справочную информацию и документооборот в действующей базе, отобрали объекты, реально нужные для переноса, и составили предварительную схему соответствия данных между двумя системами.
2. На основе полученной схемы написали правила обмена данными под платформу КД 2.1 — как для доработанных объектов, так и для полностью нестандартных. Клиент изначально хотел получить правила на КД 3.0, но этот вариант пришлось отклонить: разработка оказалась бы слишком дорогой и трудоёмкой. Кроме того, обе базы на время переходного периода оставались без изменений и обновлений, а это как раз соответствует условиям работы с конвертацией версии 2.1.
3. Стандартными средствами перенесли остатки из базы УТ в КА по состоянию на конец прошлого года, скопировали все настройки.

• В базе УТ мы настроили план обмена, отслеживающий только актуальные документы текущего года вместе со всеми привязанными справочниками и документами. Дополнительно создали регламентное задание: оно выгружает по установленному графику зарегистрированные документы в файл согласно написанным правилам и передаёт его в КА через веб-сервис. Экспериментально подобрали оптимальный интервал синхронизации — он составил 15 минут.
• В базе КА развернули и опубликовали веб-сервис, принимающий входящий файл. После загрузки данных сервис отправляет подтверждение обратно в УТ. Она фиксирует успешный результат и снимает обработанные объекты с регистрации.
• Чтобы документы, поступавшие из УТ, проводились в правильной последовательности — ведь они, как правило, образуют взаимосвязанные цепочки — в базе КА создали отдельный регистр сведений. Он накапливает очередь загруженных документов, ожидающих проведения. К этому регистру привязали регламентное задание, которое планомерно обрабатывает весь список. Оптимальный интервал его запуска — от получаса до одного часа.

На схеме этот шаг выглядит так:

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

Обнаруженная проблема и её решение

В ходе отладки обмена мы столкнулись с неожиданным сбоем. Схема работы УТ выглядела так: система формирует перечень документов, отправляет их в КА и ждёт подтверждения. Получив ответ, она удаляет эти документы из списка регистрации. Проблема возникала в следующей ситуации: если какой-либо документ редактировали именно в тот момент, когда он уже был отправлен, система снова его регистрировала. Но сразу после получения ответа от КА он удалялся — вместе с остальными, поскольку удаление шло по объектам. В итоге обновлённая версия документа в КА так и не попадала. Изменения просто терялись.

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

Механизм работает так: документ появляется в регистрационном реестре без присвоенного номера сообщения. Этот номер назначается только тогда, когда система считывает отправляемые объекты. Если документ, которому уже присвоен номер, снова регистрируется — например, из-за правок — номер автоматически обнуляется, и документ возвращается в исходное состояние очереди. Именно поэтому функция удаления по номеру сообщения решила проблему: повторно зарегистрированный документ лишается номера и не удаляется при первой обработке. Он снова уходит в КА с актуальными данными, и только после успешной загрузки покидает список регистрации.

Что получил клиент

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