Параллельный контур при переходе с SAP на 1С: что сверять и когда выключать старую систему

Переход с SAP на 1С почти всегда обсуждают как проект разработки: объём доработок, сроки, бюджет. А ломается он обычно не на разработке, а в момент переключения — когда обе системы уже работают, данные начинают расходиться, и никто не может сказать, чьи цифры правильные.

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

Почему нельзя просто переключиться

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

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

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

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

Кто мастер данных

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

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

Рабочая схема одна: ввод идёт только в одну систему, вторая получает данные обменом. Дальше вопрос в направлении.

Если ведущей делают 1С — пользователи сразу работают в новой системе, а SAP получает данные и остаётся для отчётности и сверки. Это правильный порядок: люди осваивают интерфейс, а ошибки видны сразу.

Если ведущим оставляют SAP, а 1С наполняют обменом — вы проверяете корректность переноса, но не проверяете главное: сможет ли компания работать в новой системе. Такой контур стоит держать недолго, как техническую проверку миграции, а не как режим эксплуатации.

Что переносить через обмен, а что нет

Соблазн — синхронизировать всё. Это ошибка: чем шире обмен, тем больше точек отказа и тем дольше вы его отлаживаете вместо того, чтобы проверять бизнес-процессы.

Через обмен разумно гнать то, что нужно для сверки итогов: движения по остаткам, взаиморасчёты, ключевые документы реализации и поступления. То, что не влияет на итоги — служебные пометки, вложения, история согласований — переносить не нужно, это шум.

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

Механика на стороне 1С

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

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

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

Идентификаторы. У каждого объекта, пришедшего извне, должен храниться ключ системы-источника. Не в комментарии, а в реквизите. Без этого при расхождении вы не сможете сопоставить документ в 1С с документом в SAP иначе как глазами по сумме и дате.

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

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

Что сверять на самом деле

Сверять всё построчно бессмысленно: объём такой, что отчёт никто не читает, а расхождения тонут в шуме.

Работает трёхуровневая схема.

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

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

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

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

Какие расхождения нормальны

Ноль расхождений в первые недели не бывает, и ожидать его — значит запланировать провал.

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

Такие расхождения нужно не устранять, а описать и объяснить. Заведите список известных расхождений с причиной по каждому. Сверка должна отчитываться о том, что не попало в этот список, — иначе команда через неделю перестаёт читать отчёт, потому что там всегда что-то есть.

Настоящие проблемы выглядят иначе: расхождение растёт со временем, появляется в новом разрезе, не объясняется ни одной известной причиной.

Когда выключать SAP

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

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

Важная деталь: отключать нужно поэтапно. Сначала прекращается запись в старую систему, она остаётся доступной на чтение. И только потом, когда прошло достаточно времени и все убедились, что обращаться к ней не приходится, останавливается сам контур.

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

Сколько это стоит

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

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

Итог

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

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

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

Николай Мазур, MZR Digital.