Исходная ситуация
В компанию «Имплекс» обратилась организация, которая занимается продажей оборудования и техники для промышленности и сферы строительства.
Компания приняла решение мигрировать с платформы «1С:Управление торговлей» версии 11.5 на «1С:Комплексная автоматизация 2.0». Задача выглядела вполне стандартной — разработчик предусмотрел для этого соответствующие инструменты. Однако трудность состояла в том, что процесс миграции растянут во времени, а деятельность предприятия за это время никуда не исчезает: операции продолжаются и их необходимо отражать в системе. Старая база непрерывно наполняется свежими данными, прекратить этот поток невозможно — это немедленно обернётся финансовыми и репутационными потерями. При этом переход откладывать тоже нельзя.
Задача, которую поставил перед нами клиент, звучала так:
Пока все отделы компании окончательно не перешли на КА, необходимо поддерживать постоянный поток документации оперативного учёта между базами УТ и КА, в том числе объекты с нестандартными метаданными.
Как мы выполняли работу
- Мы проанализировали всю нормативно-справочную информацию и документооборот в действующей базе, отобрали объекты, реально нужные для переноса, и составили предварительную схему соответствия данных между двумя системами.
- На основе полученной схемы написали правила обмена данными под платформу КД 2.1 — как для доработанных объектов, так и для полностью нестандартных. Клиент изначально хотел получить правила на КД 3.0, но этот вариант пришлось отклонить: разработка оказалась бы слишком дорогой и трудоёмкой. Кроме того, обе базы на время переходного периода оставались без изменений и обновлений, а это как раз соответствует условиям работы с конвертацией версии 2.1.
- Стандартными средствами перенесли остатки из базы УТ в КА по состоянию на конец прошлого года, скопировали все настройки.
- В базе УТ мы настроили план обмена, отслеживающий только актуальные документы текущего года вместе со всеми привязанными справочниками и документами. Дополнительно создали регламентное задание: оно выгружает по установленному графику зарегистрированные документы в файл согласно написанным правилам и передаёт его в КА через веб-сервис. Экспериментально подобрали оптимальный интервал синхронизации — он составил 15 минут.
- В базе КА развернули и опубликовали веб-сервис, принимающий входящий файл. После загрузки данных сервис отправляет подтверждение обратно в УТ. Она фиксирует успешный результат и снимает обработанные объекты с регистрации.
- Чтобы документы, поступавшие из УТ, проводились в правильной последовательности — ведь они, как правило, образуют взаимосвязанные цепочки — в базе КА создали отдельный регистр сведений. Он накапливает очередь загруженных документов, ожидающих проведения. К этому регистру привязали регламентное задание, которое планомерно обрабатывает весь список. Оптимальный интервал его запуска — от получаса до одного часа.
На схеме этот шаг выглядит так:
В завершение мы привели базу КА в полностью рабочее состояние: проверили корректность настроек, сверили остатки, убедились в том, что данные загружены полностью, и протестировали процедуру закрытия месяца.
Обнаруженная проблема и её решение
В ходе отладки обмена мы столкнулись с неожиданным сбоем. Схема работы УТ выглядела так: система формирует перечень документов, отправляет их в КА и ждёт подтверждения. Получив ответ, она удаляет эти документы из списка регистрации. Проблема возникала в следующей ситуации: если какой-либо документ редактировали именно в тот момент, когда он уже был отправлен, система снова его регистрировала. Но сразу после получения ответа от КА он удалялся — вместе с остальными, поскольку удаление шло по объектам. В итоге обновлённая версия документа в КА так и не попадала. Изменения просто терялись.
Мы нашли следующий выход: вместо того, чтобы удалять документы по объектам, делать это по номеру отправленного сообщения, который фиксируется в плане обмена.
Механизм работает так: документ появляется в регистрационном реестре без присвоенного номера сообщения. Этот номер назначается только тогда, когда система считывает отправляемые объекты. Если документ, которому уже присвоен номер, снова регистрируется — например, из-за правок — номер автоматически обнуляется, и документ возвращается в исходное состояние очереди. Именно поэтому функция удаления по номеру сообщения решила проблему: повторно зарегистрированный документ лишается номера и не удаляется при первой обработке. Он снова уходит в КА с актуальными данными, и только после успешной загрузки покидает список регистрации.
Что получил клиент
Организация плавно заменила конфигурацию, не прерывая ни на день текущую работу в системе и не жертвуя привычным ритмом бизнеса.
