Итак, вводные данные. У заказчика база на 1С 7.7 Торговля и склад. База доработанная, используется распределенная информационная база. Общее количество пользователей — около 100. Есть свой ит-отдел. К нам обратились в сентябре с задачей запуститься 1 января следующего года. Необходимо установить новый программный продукт и сделать перенос данных — остатки на начало периода и документы за последние два месяца.

Как обычно мы выполняем подобные внедрения:
1.Устанавливаем программные продукты и лицензии.
2.Проводим обучение пользователей (или хотя бы ключевых лиц организации)
3.Совместно с ответственными лицами сравниваем функционал старой и новой версии, определяемся, что и как будет работать в новой версии (возможно потребуются доработки и если да, то какие)
4.Готовим базу для переноса
5.Переносим остатки на начало периода.
6.Переносим документы за требуемый период (но чаще стараемся убедить заказчика, чтобы документы не переносить, а закончить период в старой базе, а с нового периода начинать работать в новой базе. во избежание ошибок, работа с нового периода в старой базе блокируется, тогда мы получаем новую легкую базу, без ненужного «хлама» в виде уже неиспользуемой номенклатуры и контрагентов с которыми прекращено взаимодействие).

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

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

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

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

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

Протестировали механизм на сервере заказчика — подключение прошло успешно (правда подключается через раз, но если подключилось работает стабильно), данные получает, скорость получения данных приемлемая.

Начинаем писать механизм переноса заново. Чтобы опять же закончить быстрее (хоть сроки уже все просрочены), берем базу со справочниками и остатками, но без документов и догружаем документы в нее. Однако остатки и обороты снова не сходятся. Анализ базы выявил, что из-за переноса данных с помощью правил обмена создалось куча записей разных регистров, создались дубли и проч. В общем привести базу в соответствие никак уже не выйдет.

Исходя из этого принято принципиальное решение делать перенос по ОЛЕ заново. Смотрим каждый документ в семерке, каждый справочник сами ищем соответствие данных, добавляем недостающие реквизиты справочники. Добавили Индивидуальный номер каждого объекта, чтобы не создавались дубли при повторных переносах (к этому моменту в базе и бизнес процессах заказчика разобрались пожалуй лучше самого заказчика, даже настройки параметров учета делали сами исходя из настроек семерки, хоть это и неправильно — клиент сам должен сделать настройки так как это ему нужно).

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

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

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