Как мы перенесли 20 лет учёта из 1С 1999 года

Мы давно работаем с дилером Bosch в Кыргызстане: сделали им сайт, кучу инструментов внутренней автоматизации, но никак не доходили до одной из самых важных тем. До 1С.

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

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

Исходная точка

Внутри той самой базы на ноутбуке — вся история компании: 86 тысяч документов, 2,6 миллиона записей, каждый товар и каждый клиент с 2006 года.

Задач было три:

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

Перед тем как делать что-либо, мы провели небольшой ресёрч. Всё, что для этого понадобилось, — точная конфигурация системы: клиент прислал скрин окна «О программе», и этого было достаточно.

Если задались вопросом, что из этого можно понять, — на самом деле многое. «1С:Предприятие 7.7 для SQL», релиз 7.70.021. Конфигурация — типовая «Торговля и Склад» с адаптацией под Кыргызстан от локального вендора. И главное — формат базы: файлы DBF и CDX, то есть обычные таблицы данных и индексы к ним, лежащие в папке на диске. Этот момент ещё сыграет свою роль.

Почему «в лоб» не получалось

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

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

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

И вишенка: проверить полноту такого переноса нечем. У штатного пути нет инструмента сверки «всё ли доехало» — расхождения всплывали бы по мере работы, через месяцы. А если тащить в новую базу историю документов, есть и содержательная ловушка: перепроведение пересчитало бы себестоимость по другой учётной политике, и исторические цифры разошлись бы с тем, что было в 7.7.

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

Мы пошли другим путём.

Ход конём: разобрать базу напрямую

Помните формат базы — папку с файлами DBF? База старой 1С это, по сути, обычная папка: таблицы данных лежат в ней файлами, которые открываются напрямую, без самой 1С. У 1С есть и штатный архив данных, как резервная копия он даже правильнее ручного копирования папки, но читается только самой 1С: таблицы внутри упакованы в служебный вид. А нам нужно было ровно обратное — разобрать данные без участия 1С. Поэтому мы взяли не архив, а копию папки целиком: оба способа верные, просто для разных задач. Такая копия содержит всю базу до последнего байта, включая внутренний словарь структуры, по которому мы восстановили человеческие названия всех таблиц и полей. Снимается за несколько минут и не требует каких-то навыков.

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

Итак, у нас архив: 271 файл во внутреннем формате 1С 7.7. Дальше в дело вступил ИИ. Формат этих файлов это наследие девяностых, и писать инструменты для его разбора вручную под одну-единственную задачу было бы нерентабельно: недели инженерной работы ради кода, который нужен один раз. С помощью ИИ точечные инструменты под конкретно эту базу — чтение устаревшего формата, выгрузка в современную открытую базу данных, автоматическая проверка результата — были созданы за часы. Мы, конечно, ожидали, что ИИ справится, но то, что он без подсказок правильно распарсил всё, что было в базе, стало приятной неожиданностью.

Здесь нам повезло со сценарием использования: клиент вёл в 1С только учёт, по сути базовый функционал, — и никакие особенности региональной кастомизации не выстрелили нам в ногу. Хотя, честно говоря, нашему методу это было безразлично. Доработанная конфигурация — главный враг штатного переноса: правила перехода написаны под типовую систему и о самописных объектах ничего не знают. Но наша выгрузка читает структуру базы напрямую и переносит все таблицы одинаково — хоть типовые, хоть доработанные. Так «доработанная 1С», которая пугает внедренцев, для нас просто не была фактором.

Результат: все справочники, все документы, все движения товара за двадцать лет — 2,65 миллиона записей в открытом MySQL-формате, с которым умеет работать любой современный инструмент — включая ИИ. С такой базой можно просто разговаривать: задавать бизнес-вопросы обычным языком, нужен только проект с правилами. Мы так и сделали и отдали владельцу — то, что двадцать лет было интуицией, подкрепилось цифрами, а кое-где и расширилось. И важная деталь: пересборка всей выгрузки из архива занимает меньше минуты. Если бы в процессе что-то пошло не так, мы в любой момент могли начать заново.

Доверяй, но проверяй

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

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

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

Переезд налегке

Дальше — решение, которое сэкономило больше всего времени и денег: не тащить в новую систему всю историю.

В новую 1С поехали только справочники — товары, клиенты, склады — и остатки на дату перехода. Они ложатся на типовые объекты новой системы без всяких доработок. А вся двадцатилетняя история осталась в выгрузке — проверенной, открытой, доступной в любой момент. Новая система стартует чистой и быстрой, при этом ни один документ прошлого не потерян. Для «справочники плюс остатки» штатный механизм переноса и вовсе избыточен: загрузка из табличного документа делает то же самое проще и полностью под нашим контролем.

Целевой системой стала «1С:Управление торговлей 8 для Кыргызстана» — на собственном Linux-сервере клиента, с публикацией через веб-сервер: менеджеры работают через браузер, а сайт забирает остатки автоматически.

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

День переключения

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

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

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

Осталось подружить с новой 1С сайт. Способов два. Первый — штатный обмен по расписанию: 1С сама раз в 15–30 минут выгружает на сайт остатки и цены. Второй — прямой API: 1С публикуется как сервис, и сайт запрашивает остатки в реальном времени, в момент показа страницы. Второй звучит солиднее, но у него есть цена: каждый запрос сайта занимает клиентскую лицензию, сама 1С становится рантайм-зависимостью сайта — ушла на бэкап или обновление, и сайт остался без остатков, — а торговую базу пришлось бы публиковать наружу со всеми вытекающими вопросами безопасности.

Мы выбрали первый. Для витрины интернет-магазина реальное время не нужно: покупатель не заметит запаздывания в 15–30 минут, а обмен по расписанию закрывает задачу бесплатно и надёжно — 1С сама отправляет данные, открывать её наружу не нужно, и даже если она выключена, сайт просто живёт с последними полученными остатками. Прямой API оправдан, когда сайт должен резервировать товар в момент заказа, — не наш случай. Платить за ёмкость, которая не нужна, мы в этом проекте уже один раз отказались — когда не стали покупать серверную лицензию. Та же логика.

Что получил бизнес

• Современную 1С на собственном сервере — вместо ноутбука, который был единственной точкой отказа.
• Менеджеры работают в системе одновременно, из любого магазина или склада.
• Интернет-магазин получает остатки автоматически, ручные выгрузки ушли в прошлое.
• Вся история за двадцать лет сохранена и сверена до байта — и впервые стала доступна для аналитики: в старой системе задать вопрос «а как менялись продажи за десять лет» было практически невозможно.
• Вся история заняла чуть больше двух недель — от старта до релиза, включая переговоры с вендорами и настройку сайта. Против минимум 4 недель по оценке профильных внедренцев.

Если у вас похожая история — старая 1С, ручные выгрузки на сайт и страх что-то потерять при переезде, — расскажите нам про неё. Посмотрим на вашу базу и честно скажем, какой путь будет дешевле и безопаснее.