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

Заканчивается поддержка 1С:УПП

В соответствии с решением, принятым на Большом партнёрском семинаре 27-28 февраля 2021 г, фирма «1С» объявляет о том, что предполагает завершение поддержки конфигурации УПП через 5 лет — весной 2026 года. Подтверждение этого намерения и точный срок окончания поддержки, как сообщалось ранее, будут объявлены не менее чем за 3 года до завершения поддержки конфигурации 1С:УПП, то есть ориентировочно весной 2023 года.

По срокам поддержки локализованных для других стран версий конфигурации УПП решения не приняты, о планах прекращения их поддержки будет объявлено не менее чем за 3 года до вступления такого решения в силу.

Фирма «1С» рекомендует пользователям и партнерам не откладывать переход с 1С:УПП на более современные решения фирмы «1С» на последние годы поддержки конфигурации 1С:УПП, т. к. найти ресурсы на внедрение 1С:ERP в 2024-2026 годах может оказаться сложнее, чем в 2021-2023 годах. Кроме того, пользователи, осуществляющие переход с 1С:УПП на современные ERP-решения фирмы «1С» в ближайшие 2 года, получат дополнительные преимущества по акции «Аналитика и Академия ERP».

Подробнее здесь https://consulting.1c.ru/news/107035.html

Введение

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

Немного введу в курс дела по проекту: Заказчик является крупнейшим предприятием пищевой отрасли. До начала проекта у Заказчика было УПП 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С\Enterprise20\2_5_7_193\AddFiles\Переходы с других конфигураций\УПП_КА1»

Рис. Папка с релизом ЕРП

В этой папке в файле «Руководство по переходу с УПП 1.3 и КА 1.1.htm» содержится подробное описание того что и как нужно выполнить

Рис. Первая страница типовой инструкции переноса остатков

По факту нам нужно было переносить данные из Источника УПП 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 - Сервис – Проверка. Остальное локально дорабатывали почти по каждому блоку. Я уже акцентировал ваше внимание в разделе «Введение» на том, что логика учета в УПП Заказчика значительно не совпадала с логикой, заложенной для сбора остатков в типовом переносе и многие правила адаптировались.

Рис. 1СКД2, Загруженные типовые правила

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

Рис. Все обработки можно найти в папке с релизом 1СКД2

Примечание: Замечу что типовые правила 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 экземпляра).

В итоге упростили схему обмена, таким образом:

План обмена создали, но только на стороне УПП, определили его состав согласно таблице статистики (из шага 1 см. выше) создали 1 узел для регистрации изменений.

Для выгрузки из УПП использовали обработку “Универсальный обмен данными XML.epf” с опцией выбора узла обмена и с возможностью установки произвольных фильтров (что позволяло выгружать данные зарегистрированные на узле плана обмена, а также выполнять выгрузки данных за период и точечные догрузки). Выгрузка больших пакетов выполнялась по COM с очисткой регистрации на узле обмена выгруженных данных.  В обработке прописали все нужные настройки по умолчанию для облегчения регулярных запусков. Запускали каждый день вечером.

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