Настоящей статьей мы продолжаем цикл о технических особенностях перехода из программы 1С:УПП на 1C:ERP. Автор статьи: Дмитрий Малышев - разработчик 1С с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3, технологический руководитель корпоративных проектов внедрения решений 1С Внедренческого центра «Раздолье». Сертификат «1С:Эксперт по технологическим вопросам». Участвовал в 30-ти проектах внедрения 1С:УПП и 1C:ERP.

Введение

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

Заказчик является крупнейшим предприятием пищевой отрасли. До начала проекта у заказчика было УПП 1.2 (даже не 1.3). В 2021-м перешли на ERP 2.4. В целом по проекту делали переход с УПП + ДО с большим количеством внешних интеграций. Переходили на связку ERP + ЗУП + ДО. Начали с августа 2020 года.

Порекомендовали ИТ-специалистам заказчика пройти курсы 1С. В ноябре, после обучения, специалисты присоединились к проекту (кто не потянул - уволился). Учет проектных задач велся в информационной системе «Канбан» и Google.Docs, использовали встраиваемую справку в ERP, информационную систему поддержки, встроенную прямо в ERP, стандартное хранилище 1С. В обязательном порядке проводили еженедельные планерки с фиксацией задач и прогресса.

Стандартный перенос из УПП в ERP пришлось переделать. Перенос остатков делали в январе. До апреля учет вели в двух системах в УПП и в ERP, обменивались оперативными документами и НСИ по правилам обмена (чтобы снять нагрузку с работающих пользователей т.к. они все-таки бизнесом занимаются и не являются каторжниками).

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

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

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

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

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

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

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

Начало работы в новой системе

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

Но, как описано во введении, на проекте за пару месяцев до запуска выявились критичные факторы:

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

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

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

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

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

Если 2-3 недели? - Да, пожалуйста. - А 2-3 месяца? - Категорически - нет!

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

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

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

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

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

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

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

• ЗА – большой вес объекта, т.е. большое число созданных объектов данного типа за период ИЛИ большое число строк в объекте ИЛИ отметка ответственного консультанта или ключевого пользователя об обязательности переноса данного типа объектов,

• ПРОТИВ – малое количество объектов данного типа или сложность создания правил для обмена объекта.

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

• ПОЛНЫЙ (программист должен проработать перенос максимально возможного количества реквизитов объекта);

• ЧАСТИЧНЫЙ (перенос ключевых реквизитов объекта - Номер, Дата, Код, Наименование, Организация - остальное заполнялось пользователем вручную);

• ВРУЧНУЮ (объект УПП полностью заводился пользователем вручную в ЕРП).

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

ИТОГИ по Шагу № 1:

• программисты получили минимизированный список объектов, который был одобрен пользователями;

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

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

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

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

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

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

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

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

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

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

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

Отмечу, в разработке очень помогла одна публикация коллег.

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

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

Итоги по шагу № 2

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

• Программисты подтянули хвосты по интеграциям и спокойно их подключили.

• Системные администраторы с нашей помощью и c помощью известной команды по подбору оборудования для 1С апгрейдили оборудование до нужной мощности.

Отказ от УПП произошел без стресса 1 апреля. Я это называю "на лайте". ))) Далее в течение нескольких месяцев шел процесс постепенного уменьшения поддержки со стороны нашей компании и вывод ИТ-отдела заказчика на самостоятельную поддержку своей системы ЕРП. К августу мы практически не участвовали в процессах закрытия и сопровождения.