Переход с УПП на ЕРП с сохранением документов. Способы, проблемы, варианты решений

Много лет я трудился разработчиком на платформе 1С, то есть всегда был техническим специалистом. Для меня естественным и понятным в докладе является рассказ как раз о технических проблемах, например, как решить проблему производительности обмена или как методически мы переносим такой-то вид документа. Или какие мы придумали таблицы кэша, чтобы ускорить работу.

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

Перенос документов. В чем необходимость?

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

Организация проекта перехода

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

Патовая ситуация в организациях, работающих без выходных

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

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

Управление ожиданиями

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

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

Насчет истории продаж рекомендуем переписать алгоритмы на использование данных, которые создаются документом Ввод остатков с видом операции “История продаж”.

Вторая проблема с ожиданиями заказчиков, которая очень часто встречается, это когда говорят, что назначена дата перехода на новую конфигурацию 1С и эта дата примерно через 20-30 дней.

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

Сроки проекта и их указание в договоре

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

Ранее уже сказал, что по проекту перехода всегда подразумевается двусторонняя работа сотрудников заказчика и подрядчика. И в этом случае крайне сложно фиксировать сроки. Как бы мы не старались фиксировать в договоре, что работы выполняются в две итерации - тестовый перенос и рабочий перенос. Что все замечания после выполнения тестового переноса нужно передавать один раз полным исчерпывающим списком. Но все равно заказчики говорят, что не могут продвинуться дальше в проверке, пока не будут исправлены найденные замечания. И проект растягивается на много итераций.

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

Плавный переход

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

• настроить универсальный обмен данными EnterpriseData
• использовать правила конвертации данных формата КД 2, создать план обмена и инструмент для автоматического запуска выгрузок данных
• самописное решение, в том числе с использованием прямых SQL-запросов

Обсудим подробнее плюсы и минусы каждого способа

ED

1. Должен быть достаточно свежий релиз УПП.
2. План обмена и сама технология уже есть в конфигурациях.
3. Неполный объем переносимой информации
4. Высокие требования к заполнению данных (в xsd-схеме многие поля отмечены обязательными, хотя в документах УПП они обязательными не являются. Выгрузка падает из-за незаполненных полей)
5. Очень много придется дорабатывать “напильником” под свои потребности
6. Удобство отладки (все алгоритмы находятся в общем модуле)
7. Еще не все разработчики квалифицированно работают с КД 3 (на первом этапе будут обучаться технологии, а это потери времени)

КД 2

В продаже на Инфостарте есть решения, которые не просто поддерживают максимально широкий перечень видов объектов, но и проверены на проектах перехода у сотен компаний. Смотрите ТОП продаж Инфостарта

1. Несложно найти разработчика на доработку правил конвертации КД 2
2. Универсальность - враг производительности
3. И в целом - выгрузка данных в формате КД 2 - это много запросов в цикле. Сама по себе технология не очень производительная
4. Перенос документов с правилами конвертации хорошо работает, пока мы не приходим к границам возможностей по производительности данного формата обмена. При увеличении объема данных для переноса выгрузки и загрузки могут занимать недели времени, что совершенно не позволит в адекватные сроки выполнить задачу.

В таком случае нужна разработка решения через другие форматы технологий обмена, с соответствующим увеличением бюджета проекта

Свое решение

1. Можно сделать событийную интеграцию (выгрузка объекта сразу из подписки на запись объекта или при создании новой версии объекта в истории данных)
2. Разработка длительная и сложная
3. Прямые SQL-запросы тоже мало кто умеет писать

Методические сложности переноса документов из УПП в ЕРП

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

Почему это так сложно?

“... УТ 11 делали марсиане”

Эпиграф имеет отношение к вопросу, т.к., как известно, ЕРП сделана как развитие конфигурации УТ 11. УТ 11 на несколько лет раньше была выпущена в продажу, а далее на ее основе были разработаны подсистемы ЕРП.

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

Разумеется, конфигурация ЕРП хоть и более жестко требовательна к вводу данных и не дает такой гибкости при заполнении документов, как УПП, но имеет очень обширный функционал. И в конечном счете для любой операции из УПП можно найти способ ее ввода в ЕРП даже с сохранением тех же движений по регистру бухгалтерии.
Проблема только в том, что процесс этот длительный и тем более сложный, чем больше данных вводится.
Учитывая “любовь” бухгалтеров отражать операции хозяйственной деятельности в УПП с помощью документа Операция, следует иметь в виду, что такие документы в ЕРП хоть и создают движения по регистру бухгалтерии, но совершенно игнорируются при закрытии месяца. Так как при закрытии алгоритмы опираются на данные регистров накопления.
Мы встречались с пожеланием главного бухгалтера на проекте, где заказчик хотел перенести все документы за всю историю работы в УПП в базу ЕРП, перенести документы Операция в корректные подходящие документы отражения операций хозяйственной деятельности в ЕРП. Но автоматизированного и универсального способа решения такой задачи нам на данный момент неизвестно. На проектах при возникновении таких ситуаций либо заказчик, либо подрядчик обычно такие документы вводят в ЕРП вручную.

Хочется подытожить, что чем больше в УПП создавалось “хитрых” операций, чем больше нарушений методики учета в УПП допускалось пользователями, тем больше возникнет трудностей при переносе оборотов за период в базу ЕРП.