Настоящей статьей мы продолжаем цикл о технических особенностях перехода из программы 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% реализовывался удаленно, без посещения заказчика.
О задаче переноса остатков и параллельной работе пользователей в двух системах
Речь пойдет об особенности организации двух последовательно идущих этапов проекта: «Переносе начальных остатков из УПП в ЕРП» и «Начале работы пользователей в новой системе ЕРП и отказа от УПП».Большинство из нас знает, что в самом распространенном случае после переноса остатков в начале января пользователи короткое время параллельно работают и в старой, и в новой системах, а не сразу в новой. Многие взяли за правило не рубить канаты сразу, чтобы:
- в течение некоторого стартового периода иметь возможность откатиться в старую базу в случае неудачного запуска новой базы, например, из-за технических проблем;
- постепенно переключить интеграции с другими системами со старой на новую базу;
- откорректировать предыдущий период в старой базе при подготовке отчетности и правке остатков в новой;
- и т.п.
Чрезвычайная ситуация со сроками
А вот с этапом начала работы в новой системе возникла чрезвычайная ситуация: не успевали к январю «ну ни как, хоть ножом режь»…. Проявилась она заблаговременно, за 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 Бета-версия без официального релиза (для котят), но рекомендованная для входа в проект
Полученный файл залили в 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:
- программисты получили минимизированный список объектов, который был одобрен пользователями;
- определили ответственных за каждый объект УПП и его образ в ЕРП со стороны пользователей заказчика.
Шаг № 2: Выбор схемы переноса, подготовка набора инструментов и организация работы
На время параллельной работы в 2-х системах сначала рассматривали разработку стандартной схемы синхронизации 2-х баз (2 плана обмена + пакеты правил), но от неё было решено отказаться по нескольким причинам:- нам требовался только односторонний обмен из УПП в ЕРП,
- синхронизации работает согласно регистрации изменений и не тянет по умолчанию объекты по ссылке,
- трудно установить произвольные фильтры на выгрузки,
- трудно совместить работу нескольких программистов в рамках 1СКД2 над одним и тем же экземпляром правил, которые включали бы и перенос остатков и будущий обмен (правила надо было бы делить на 2 экземпляра).
План обмена создали, но только на стороне УПП, определили его состав согласно таблице статистики (из шага 1 см. выше) создали 1 узел для регистрации изменений.
Для выгрузки из УПП использовали обработку с опцией выбора узла обмена и с возможностью установки произвольных фильтров (что позволяло выгружать данные зарегистрированные на узле плана обмена, а также выполнять выгрузки данных за период и точечные догрузки). Выгрузка больших пакетов выполнялась по COM с очисткой регистрации на узле обмена выгруженных данных. В обработке прописали все нужные настройки по умолчанию для облегчения регулярных запусков. Запускали каждый день вечером.
Конвертации делить между разработчиками не стали, работа 2-ух программистов (красный остатки, синий обмен) велась в одной базе 1СКД2 над одним и тем же экземпляром правил.
Отмечу, в разработке очень помогла одна публикация коллег.
Объекты переносили из УПП длительный период. Важно было сохранить нумерацию. Ручное создание новых номеров в ЕРП было по многим типам запрещено. Также проработали нумерацию, чтобы где-то разделить префиксом, и в общем случае прописать продолжение нумерации объектов по закона УПП (в ЕРП убрать префиксы ЕРП 0000-, повторив работу нумерации УПП).
Пользователи проводили выверку данных объектов и ручную корректировку, и чтобы защитить их труд, т.е. уже проверенные и дозаполненные объекты от изменений ежедневного обмена, разработали расширение позволяющее пользователю точечно закрыть нужный документ от изменения обменом. Также в этом расширении можно было администратору указывать закрытые от обмена периоды и типы метаданных – это нужно было после закрытия месяца в ЕРП (запретить изменения данных месяца).
Итоги по шагу № 2
- Мы начали учет в ЕРП с января успешным переносом остатков. Регулярным обменом сняли нагрузку с пользователей по дублированию информации в обеих базах. Пользователи продолжали работать в УПП и проводили сверку своих объектов в ЕРП (частично дозаполняли данные, проверяли печатные формы, отчеты и тем самым учились понимать, как трансформировалась их система, адаптировались к интерфейсу). Финансисты проводили закрытия месяца, выявляя и принимая глобальные цифры, например, различия методик по себестоимости.
- Программисты подтянули хвосты по интеграциям и спокойно их подключили.
- Системные администраторы с нашей помощью и c помощью известной команды по подбору оборудования для 1С апгрейдили оборудование до нужной мощности.
Переход с 1С: УПП на 1C:ERP: перенос остатков и затянувшееся начало работы в ERP
Настоящей статьей мы продолжаем цикл о технических особенностях перехода из программы 1С:УПП на 1C:ERP. Автор статьи: Дмитрий Малышев - разработчик 1С с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3,...
habr.com