Переход с 1С: УПП на 1C: ERP (1С:ЕРП): Перенос остатков и затянувшееся начало работы в ЕРП

Не буду детально расписывать как проходил проект перевода Заказчика с УПП на ЕРП.

Немного введу в курс дела по проекту: Заказчик является крупнейшим предприятием пищевой отрасли. До начала проекта у Заказчика было УПП 1.2 (даже не 1.3) в 2021-м перешли на ERP 2.4. В целом по проекту делали переход с УПП + ДО с большим количеством внешних интеграций. Переходили на связку ERP + ЗУП + ДО. Начали с августа 2020 года. Порекомендовали ИТ-специалистам заказчика пройти курсы 1С. В ноябре, после обучения, специалисты присоединились к проекту (кто не потянул — уволился). Учет проектных задач в информационной системе «Канбан» и Google Doc, использовали встраиваемую справку в ERP, информационную систему Поддержки, встроенную прямо в ERP, Стандартное хранилище 1С. В обязательном порядке проводили еженедельные планерки с фиксацией задач и прогресса. Стандартный перенос из УПП в ERP пришлось переделать. Перенос остатков делали в январе. До апреля учет вели в двух системах в УПП и в ERP обменивались оперативными документами и НСИ по правилам обмена (чтобы снять нагрузку с работающих пользователей т.к. они все-таки бизнесом занимаются и не являются каторжникамиJ). За время учета в двух системах адаптировали интеграции и нестандартные подсистемы УПП, модифицировали железо и инфраструктуру серверов, настраивали права доступа, адаптировали мышление пользователей к проверкам данных и закрытию в ERP и ЗУП (не было обрубания канатов на 01.01). Гладко перешли с системы на систему без привязки к началу года. (Кому нужно обращайтесь, внедряли и УПП и ЕРП, понимаем и там и там).

В условиях пандемии Проект на 98% реализовывался удаленно, без посещения Заказчика.

Расскажу о задаче переноса остатков и параллельной работе пользователей в двух системах.

Речь пойдет об особенности организации двух последовательно идущих этапов проекта: «Перенос начальных остатков из УПП в ЕРП» и «Начало работы пользователей в новой системе ЕРП и отказа от УПП».

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

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

На этом проекте с этапом «Переноса остатков» всё складывалось близко к стандартному сценарию (шли тестовые переносы и выверки, планировался итоговый перенос в январе и расчет на небольшие догрузки исправлений). И это не смотря на то, что переходили с «перепиленной» вдоль и поперёк УПП 1.2 (даже не УПП 1.3, а 1.2) с серьезными отличиями логики учета УПП, допиленной силами заказчика, от логики зашитой в типовые правила переноса остатков из УПП в ЕРП по большинству блоков (Продажи и Покупки, НМА и ОС, Оплаты, Складской учет количества и др.) Свет в конце туннеля к январю всё же был виден. Про сам процесс переноса остатков кратко опишу в отдельной главе «Перенос … «, ниже.

А вот с этапом «Начала работы в новой системе…» возникла чрезвычайная ситуация — что не успевали к январю «ну ни как, хоть ножом режь»… Проявилась она заблаговременно (за 2 месяца до январского запуска) в ходе составления и обсуждения на планерках, так называемой, Таблицы переключения {Блок, Ответственный, Дата переключений с УПП на ЕРП, Мероприятия для переключения, Проблемы} выявили критичные моменты, такие как:

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

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

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

По факту нам нужно было переносить данные из Источника УПП 1.2 (сами типовые правила изначально для УПП 1.3) в Приемник Бета версию ЕРП 2.5 (еще не было официального релиза, но был получен «сверху» совет, входить в проект именно на 2.5 и вероятно правила переноса не адаптировались самой фирмой 1С) поэтому типовые правила потребовалось дорабатывать.

Входные параметры проекта, предопределили необходимость адаптации/доработки типовых правил переноса под другие условия:

Источник «перепиленная» УПП 1.2 (даже не УПП 1.3) с отклонениями/нарушениями типовой логики учета 1С.

Приемник ЕРП 2.5 Бета-версия без официального релиза (для котят), но рекомендованная для входа в проект.

Сами исходные правила переноса из УПП в ЕРП мы забрали из типовой обработки «Выгрузка данных. epf» открыв её в конфигураторе и сохранив текст макета в текстовый файл с расширением XML.

Полученный файл залили в 1С:Конвертация данных 2 (далее 1СКД2), затем выгрузили файлы со структурами метаданных Источника и Приемника и также залили их в 1СКД2 (Обработками получения структур метаданных MD82Exp. epf, MD83Exp. epf).

Глобальные различия типовых правил и структур реальных баз сразу убирали через меню 1СКД2 — Сервис — Проверка. Остальное локально дорабатывали почти по каждому блоку. Я уже акцентировал ваше внимание в разделе «Введение» на том, что логика учета в УПП Заказчика значительно не совпадала с логикой, заложенной для сбора остатков в типовом переносе и многие правила адаптировались.

В дальнейшем саму выгрузку из УПП делали по доработанным правилами с помощью стандартной обработки «V8Exchan82.epf», а загрузку в ЕРП обработкой «V8Exchan83.epf». Они более известны по наименованию «Универсальный обмен данными XML.epf» и находятся в составе как УПП так и ЕРП.

Примечание: Замечу что типовые правила 1С были не без сюрпризов, например, осуществлялся перенос ставки НДС 0% в ставку Без НДС, может из-за того, что работали с Бета 2.5.

В итоге несмотря на специфические для перехода с УПП на ЕРП базы Источника и Приемника (УПП 1.2 и бета ЕРП 2.5) сам этап ввода начальных остатков прошел по стандартной схеме:

Были подготовлены и одобрены списки необходимых срезов остатков и НСИ для переноса из УПП.

Написаны правила переноса. Смоделированы и выверены с ключевыми ответственными лицами Заказчика результаты тестовых переносов между Источником и Приемником.

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

Для примера, на параллельно идущем проекте нашей компании, люди последние две трети января просто параллельно «вколачивали» данные и в УПП, и в ЕРП, а в феврале перешли на работу только в ЕРП. Это привычная практика и мы изначально предполагали сделать ровно также, но…
Но как описано во введении на проекте за пару месяцев до запуска выявились критичные факторы:

Невозможность в срок подготовить все интеграции с ЕРП (70% объема интеграций модифицировали И Т Заказчика, 30% мы как интегратор).

Неготовность серверного ландшафта для работы в ЕРП нужного количества онлайн-пользователей (хотя на этапе запуска необходимые серверные мощности нам обещали).

Именно эти проблемы не позволили применить привычную схему перехода.
Ситуация сложилась критическая для всего проекта…

Выход был найден. Было принято решение по удлинению периода параллельной работы в двух системах с января, до нескольких месяцев. Пользователи и все интеграции должны работать с УПП, но учет в ЕРП должен начаться с января нового года (остатки + ввод оперативных данных). Это давало проектной команде необходимое время для подтягивания отстающих задач.

Обычно, «крайними» на этапе параллельного учета в двух системах становятся пользователи. Но в данном случае для этого не хватало ресурсов — сама компания была коммерческой с рыночными зарплатами и оптимизированным штатом сотрудников, которые были максимально загружены основной работой, и поэтому работать в двух системах ни физически, ни морально длительный период не могли…

Если 2−3 недели? — «Да, пожалуйста»,

А 2−3 месяца?! — «Категорически — Нет!».

Им надо было помочь, а нам экстренно в течение месяца разработать регулярную подкачку НСИ и оперативной информации из УПП 1.2 в ЕРП 2.5.

Все, кто занимался обменами, представляют, что организация нового обмена данными это объемная комплексная задача для группы специалистов. Выдернуть на неё дополнительные ресурсы перед январём очень сложно, а надо сделать работающий вариант. Тут выполнялся пошаговый поиск решений с упрощением, чтобы сэкономить время и трудозатраты. Для этого нам надо было минимизировать список того, что требуется перегружать из УПП и выбрать максимально простой способ передачи данных в ЕРП. При этом надо гарантировать, чтобы перегружались как новые данные выбранные за период так и точечно изменяемые пользователями.

Шаг № 1: Определение данных для переноса

Чтобы ограничить список перегружаемых из УПП объектов мы собрали статистику за прошлый квартал и свели её в таблицу. Обработки по сбору статистики были найдены и скачаны с Инфостарта, они по сути делятся на нескольких видов: сбор данных по журналу регистрации, сбор данных по метаданным в 1С, сбор данных по таблицам SQL — но не каждая подойдет, т.к. какие-то работают неприемлемо долго на объемных базах, какие-то не имеют нужных отборов, например за период или выдают плохое представление результатов (в общем нашли, скачали, допилили).

Лучше остальных подошла обработка сбора статистики по Журналу регистрации, в ней мы добавили вывод ответственных за объект, чтобы знать ФИО кого со стороны пользователей Заказчика назначить ответственным за сверку данных объекта между УПП И ЕРП (разобрали по контролёрам).

Рис. Статистика по Журналу регистрации (в исходном виде скачанная с Инфостарта)

В таблице статистики члены команды и ключевые пользователи проголосовали за объекты переносимые из УПП в ЕРП согласно критериям:

• ЗА — Большой вес объекта, т. е. большое число созданных объектов данного типа за период ИЛИ большое число строк в объекте ИЛИ отметка ответственного консультанта или ключевого пользователя об обязательности переноса данного типа объектов
• ПРОТИВ — Малое количество объектов данного типа или сложность создания правил для обмена объекта.

По самим объектам перенос указывался:

• ПОЛНЫЙ — программист должен проработать перенос максимально возможного количества реквизитов объекта)
• ЧАСТИЧНЫЙ — перенос ключевых реквизитов объекта (Номер, Дата, Код, Наименование, Организация), остальное заполнялось пользователем вручную
• ВРУЧНУЮ — объект УПП полностью заводился пользователем вручную в ЕРП

Также в таблице статистики напротив каждого объекта УПП консультантами были указаны его образы в ЕРП. Связи были не только 1 в 1, а несколько типов объектов УПП в один и тот же тип объекта ЕРП, или 1 тип объекта УПП в несколько типов объектов ЕРП. Основную сложность вызвали Взаиморасчеты со сверками, Оплаты по разным видам операций, Перенос производства.

Итоги по Шагу № 1:

• Программисты получили минимизированный список объектов, который был одобрен пользователями.
• Определили ответственных за каждый объект УПП и его образ в ЕРП со стороны пользователей Заказчика.

Шаг № 2: Выбор схемы переноса, подготовка набора инструментов и организация работы

На время параллельной работы в двух системах сначала рассматривали разработку стандартной схемы синхронизации двух баз (2 плана обмена + пакеты правил), но от неё было решено отказаться по нескольким причинам:

Нам требовался только односторонний обмен из УПП в ЕРП.

Синхронизации работает согласно регистрации изменений и не тянет по умолчанию объекты по ссылке.

Трудно установить произвольные фильтры на выгрузки.

Трудно совместить работу нескольких программистов в рамках 1СКД2 над одним и тем же экземпляром правил, которые включали бы и перенос остатков и будущий обмен (правила надо было бы делить на 2 экземпляра).

Конвертации делить между разработчиками не стали, работа 2-ух программистов (красный остатки, синий обмен) велась в одной базе 1СКД2 над одним и тем же экземпляром правил.

В разработке очень помогла публикация Перенос данных из УПП 1.3 в ERP 2 (ЕРП 2) / УТ 11 / КА 2 (infostart.ru)

Объекты переносили из УПП длительный период — важным было сохранить нумерацию. Ручное создание новых номеров в ЕРП было по многим типам запрещено. Также проработали нумерацию, чтобы где-то разделить префиксом, и в общем случае прописать продолжение нумерации объектов по законам УПП (в ЕРП убрать префиксы ЕРП 0000- повторив работу нумерации УПП).

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

Итоги по Шагу № 2:

• Мы начали учет в ЕРП с января успешным переносом остатков, регулярным обменом сняли нагрузку с пользователей по дублированию информации в обеих базах. Пользователи продолжали работать в УПП, и проводили сверку своих объектов в ЕРП (частично дозаполняли данные и проверяли печатные формы и отчеты), тем самым учились понимать как трансформировалась их система (адаптировались к интерфейсу). Финансисты проводили закрытия месяца, выявляя и принимая глобальные цифры, например различия методик по себестоимости.
• Программисты подтянули хвосты по интеграциям и спокойно их подключили.
• Системные администраторы с нашей помощью и помощью команды www.gilev.ru апгрейдили оборудование до нужной мощности

Отказ от УПП прошёл без стресса 1 апреля. Я это называю — «на лайте».)))

Далее в течение нескольких месяцев шёл процесс постепенного уменьшение поддержки со стороны нашей компании и вывод ИТ-отдела Заказчика на самостоятельную поддержку своей системы ЕРП. К августу мы практически не участвовали в процессах закрытия и сопровождения.

P. S. Поддержка была реализована через систему заявок и сервер взаимодействия в самой ЕРП (об этом расширении и других расширениях используемых на проекте расскажем в следующей статье)

Вот другие статьи по внедрению ERP:

• Переход с 1С:УПП на 1C:ERP (1С:ЕРП): Переделываем интеграции, использующие SQL запросы к СУБД (на примере УПП -> QlikView -> ERP)
• Переход с 1С:УПП на 1C:ERP (1С:ЕРП): Подсистема поддержки пользователей в 1С:ERP
• Переход с 1С:УПП на 1C:ERP (1С:ЕРП): Задача переноса печатных форм в сжатые сроки. Конструктор печати
• Переход с 1С:УПП на 1C:ERP. Переезд пользователей с сохранением прежних прав