Одна статья из цикла материалов о практических особенностях перехода с программы 1С:УПП на 1C:ERP.

Автор статьи:

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

Для тех, кто не читал предыдущую статью, расскажу о сути проекта. В 2020-2021 году я участвовал в роли руководителя команды разработчиков Внедренческого центра "Раздолье" в проекте Управление продажами в международной компании на базе "1С:ERP" (ссылка на сайт 1c.ru). Проект был выбран победителем международного конкурса «1С:Проекта года» в номинации «Лучший проект с использованием технологии "Дистанционное внедрение"».

Суть проекта заключалась в переводе Заказчика с 1С:УПП на 1С:ERP. На его примере кратко опишу, какой была организационная структура и какие программы мы использовали при взаимодействии в команде и с пользователями.

Практически весь проект выполнялся удалённо. Многие сотрудники Заказчика, участвующие в проекте, в условиях карантинов и локдаунов были переведены на удалённую работу. Многие сотрудники нашей компании тоже работали удалённо, с командировками в этот период были большие проблемы. Сам Заказчик работает в режиме 24х7 и является одним из крупнейших предприятий в России по производству кофе. На начало проекта в качестве основы корпоративной системы у Заказчика была программа 1С:УПП редакции 1.2 (даже не 1.3). По завершению проекта в 2021-м перешли на ERP 2.5. К слову, когда начинали работу, в 2020-м году, когда 2.5. была ещё в бета-версии, но мы решили прислушаться к рекомендациям "Фирмы 1С" запускать новые проекты на ней, а не на 1С:ERP 2.4.

Рис 1.1 Схема ИТ-архитектуры проекта

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

Одной из задач перехода с УПП на ERP (ЕРП) был перевод интеграции между УПП и системой аналитики QlikView.

Справка

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

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

ВНИМАНИЕ:

! Инструменты перевода с языка SQL на язык 1С и обратно, а также организация процесса подойдут для перевода большинства прямых интеграций с СУБД старого продукта 1С на новый продукт 1С, т.е. технология касается не только частного случая для QlikView, представленного в этой статье, а подойдёт на других проектов с переводом других ПО.

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

Вводная по задаче с QlikView

Интеграция QlikView была реализована ранее с УПП на уровне прямых sql-запросов к СУБД.

Данные передавались в одном направлении из УПП в QlikView:

  • Контрагенты

  • Договоры

  • Заказы

  • Продажи

  • Планы

  • и другие

Требовалось перейти в 1C:ERP (ЕРП):

  • переделать сбор данных, т.е. запросы к источникам, т.к. структура хранения данных между УПП и ERP значительно поменялась;

  • а также доработать ERP (ЕРП) под особенности, затребованные со стороны QlikView и доработанные ранее в УПП.

Интеграция QlikView с УПП проводилась давно (несколько лет назад) и успешно работала, не требуя вмешательства, поэтому всё, что касалось её создания и процесса настройки было успешно стёрто из памяти исполнителей:

  • Интеграционные запросы к УПП были описаны на языке SQL и не имели описания на языке 1С

  • Со стороны Клиента исполнители не помнили технологию реализации задачи (столько лет прошло)

  • Был контакт компании-интегратора со стороны QlikView

  • Срок реализации задачи установлен до конца 1 квартала с момента перехода с УПП на ERP (ЕРП) в начале года (для расчёта KPI и зарплаты менеджеров)

Решение задачи по переводу в ERP (ЕРП)

Шаг 1: Наладка взаимодействия

Со своего опыта: вовлечение 3-го, а именно - сторонней компании, в текущий проект 1С, всегда сопровождается перекладыванием ответственности на друг друга и риском получить проблемы с урегулированием сроков. Поэтому крайне важно сработаться.

Всё, что касалось настройки внутренностей QlikView, находилось в компетенции компании интегратора QlikView. Всё, что касалось УПП и ERP, находилось в нашей компетенции. Первым шагом надо было наладить взаимодействие между нами. После первых переговоров с участием Клиента вышли на ситуацию: интегратор QlikView может выделить ресурсы только в 3-й месяц квартала, когда по сути механизм уже должен сдаваться в эксплуатацию. Поначалу нас как интегратора 1С это не устраивало, были попытки найти другого интегратора QlikView, но в итоге договорились с первым, решили, что успеем.

Работы были поделены на два контура:

  1. Мы - со стороны 1С (понимаем SQL запросы к УПП и трансформируем их в аналоги для ERP)

  2. Они - со стороны QlikView (делают модель связи QlikView с ERP и организуют в QlikView переключение с модели источников УПП на ERP)

Шаг 2: Трансформация SQL-запросов

Составили сводный документ, содержащий список источников данных (около 20 блоков), подтягивающихся из УПП в QlikView:

  • Номенклатурные группы

  • Номенклатура

  • Менеджеры

  • Контрагенты

  • Логистические услуги

  • Заказы

  • Неотгруженные заказы

  • Сетевые скидки

  • ….

  • Продажи

  • Планы

Примечание: QlikView сам забирает данные из Источника, согласно разработанным запросам.

Каждый блок разбили части:

  1. Таблица УПП-SQL-1C – старый текст sql-команд, промаркированный номерами (присвоены краткие уникальные обозначения полям и таблицам) и дополненный описанием полей и таблиц 1С. Примечание: Запросов на языке 1С для сбора данных из УПП для QlikView у Клиента не было или не сохранилось.

  2. Таблица ERP-1C-SQL – текст запроса на языке 1С для ERP с промаркированными данными. Дополнена описанием соответствий и различий по сравнению с Таблицей УПП-SQL-1C (тексты запроса на языке SQL для ERP сопоставленные с полями 1С).

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

ТАБЛИЦА УПП-SQL-1C

На входе дан запрос: что это - непонятно.

SELECT T1._IDRRef, T1._Description, T1._Fld1261, T1._Fld1265, T1._Fld1276RRef, T1._Fld1272, T1._Fld1273, T1._Fld1279RRef FROM dbo._Reference78 T1

Чтобы разобраться, надо транслировать названия таблиц и полей SQL на язык 1С. Для этого воспользуемся замечательной обработкой Крючкова Владимира по конвертации текстов SQL в представление языка 1С (ссылка ниже в приложении). Обработка имеет управляемую форму, поэтому, чтобы её запустить в старом УПП, необходимо изменить режим запуска на "Управляемый". Запустим рабочую базу УПП в режиме управляемого приложения. Для этого у администратора изменим режим запуска на «Управляемое приложение».

После этого открываем обработку конвертации из SQL в 1С через Меню-Файл-Открыть, вставляем в неё текст запроса и жмём [Преобразовать].

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

Делаем описание в виде таблицы:

После выполнения перевода текстов исходных SQL запросов на язык 1С все данные сохраняем в общий документ. Далее анализируем с консультантом: выделили используемые источники данных УПП, пытались понять получаемый результат и сконструировать аналогичные выборки уже на основе источников данных ERP.

ТАБЛИЦА ERP-1C-SQL

На стороне ERP нам нужно было смоделировать запрос 1С с той же структурой и логикой сбора по суммам, количеству и наборам атрибутов объектов, а затем получить его описание текстом SQL.

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

Как видно, запрос в ERP усложнился, из-за того, что требуемые атрибуты контрагентов разделены в ERP по двум справочникам: "Контрагенты" и "Партнеры".

Примечание: Важно, что все запросы SQL получать транслятором нужно именно в рабочей базе. Это нужно чтобы совпадали имена таблиц и реквизитов на уровне СУБД.

Пример:

База-копия, развернутая из архива рабочей базы, изначально имеет совпадающие имена таблиц и полей СУБД. Но если, например, добавляем в хранилище новый реквизит справочника "Договоры" и подтягиваем изменения в обе базы, то реквизит в рамках конфигуратора 1С имеет одинаковое 1С-имя в обоих базах (очевидно), а вот в рамках СУБД получает в соответствие поля с различными именами. В следствие чего запрос SQL, работающий на базе-копии и обращающийся к полям базы-копии в своем тексте, выполниться с ошибкой в рабочей базе, где аналогичный реквизит 1С соответствует полю СУБД с иным именем.

Делаем описание в виде таблицы:

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

Новый запрос SQL для QlikView фиксируем в виде:

SELECT T1._IDRRef, T1._Description, T1._Fld64962, T1._Fld64967, T1._Fld64971RRef, T2._Fld68618, T2._Fld68620, T2._Fld68615RRef FROM dbo._Reference392 T1 LEFT OUTER JOIN dbo._Reference533 T2 ON (T1._Fld64970RRef = T2._IDRRef)

Шаг 3: Запуск новой модели интеграции

Интегратор QlikView на основании предоставленного описания запросов разработал модель связи образа QlikView с ERP. Далее выполнили контрольные заборы данных в QlikView за одинаковый период по старой модели (из УПП) и новой (из ERP). Выполнили сверку количественных и списочных показателей. Выявленные расхождения данных были переданы нам для анализа и пояснений, в итоге:

  • часть различий была устранена за счёт уточнения текстов и фильтров в запросах,

  • по части – были выявлены ошибки учёта как в УПП, так и в ERP, приведшие к расхождениям,

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

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

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

Комментарии (15)


  1. Arimefu
    27.04.2022 08:24

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

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


    1. ERP Автор
      27.04.2022 15:13

      Здесь в конце статьи - про использованные обработки. https://infostart.ru/1c/articles/1639249/


  1. Isiirk
    27.04.2022 09:12

    Почему было принято решение оставить интеграцию через SQL запросы? Решение довольно странное, с моей точки зрения, т.к. QlikView  это аналитика, то возможна не нужна online интеграция, но можно было через 1С сделать универсальное решение. а не привязанное к конкретной БД по именам полей...


    1. Constanine
      27.04.2022 10:18

      Скорее всего, как указано в статье, была задача мигрировать 1 к 1. Переделывать архитектуру при миграции иногда бывает плохой практикой. Может выйти ситуация, когда старое "уже" не работает, а новое "ещё".

      Плюс взаимодействие с другим интегратором, накладывает свои ограничения.


      1. Isiirk
        27.04.2022 10:33

        Сложно судить, не достаточно информации.

        "..Составили сводный документ, содержащий список источников данных (около 20 блоков) ...", но мне кажется это очень маленький объем, чтоб 8 месяцев на это потратить... в худшем случаем можно было сделать прослойку, отражающую данные в другую БД MSSQL, если со стороны QlikView есть ограничения на используемые источники данных, в любом случае решение стало бы универсальным.


  1. Constanine
    27.04.2022 09:17

    А разве прямые SQL запросы к базе 1с не являются нарушением лицензии 1с? Несколько лет назад изучал этот вопрос, и встречался пункт о запрете.


    1. Isiirk
      27.04.2022 09:56

      на диске ИТС есть рекомендация:

      "… для специальных задач интеграции может потребоваться более тесное взаимодействие между 1С:Предприятием и другими программами.
         Для решения таких задач разработана «Технология создания внешних компонент». Данная технология позволяет создавать программы, которые будут динамически подключаться и тесно взаимодействовать с системой 1С:Предприятие, расширяя ее возможности."

      Думаю это наверно был правильный путь в данном случае, а не прямые запросы к БД


      1. Constanine
        27.04.2022 10:12

        Согласен тем более на 8.3 появилось довольно много других возможностей для синхронизаций(web серверы, oData и.т.д.)


        1. Arimefu
          27.04.2022 10:56

          Увы, не всегда они подходят, т.к. имеют серьезные проблемы с производительностью в случае большого объема данных. SQL-запросы намного быстрее.

          Сталкивался с PowerBI, пробовал данные о продажах передавать через OData, но это нереально по времени. В итоге остановились на варианте регламентной выгрузки данных обработкой раз в сутки во внешнюю базу на SQL за несколько последних месяцев, либо по требованию. Зато получился довольно гибкий инструмент, позволяющий сразу запросами внутри 1С сформировать необходимые данные в том виде, в котором они требуются для PowerBI. Минус — задержка в данных в течение дня, но это некритично в моем случае, можно было бы и чаще запускать выгрузку.


          1. Isiirk
            27.04.2022 11:20

            Так как раз задача и не требует online отражения данных, даже если раз в час выгружать, то этого достаточно для анализа и управленческого учета. Вопрос производительности тут вроде не обсуждали, OLTP системы требуют и других подходов


    1. ERP Автор
      27.04.2022 15:43
      +1

      Лицензионное соглашение это важный закон, его нарушать нельзя. Вот ссылка на него https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/?

      Соглашение не запрещает, например, сделать вторую копии базы 1С на СУБД (отрубить её от 1С Сервера, база теперь только на СУБД и к 1С не имеет отношения, работоспособность не нарушает), и с неё считывать данные. Материя тонкая согласен в ней надо понимать и быть осторожным.

      Прикрепленные файлы:


      1. Isiirk
        28.04.2022 02:41

        Создание копии не отменяет того, что база была создана средствами 1С, так что думаю не тот путь


  1. yukon39
    27.04.2022 11:13

    Надеюсь запросы сделали на отдельной RO-копии базы? У нас две рабочие реплики с разными настройками, т.к. OLTP и транзакционные нагрузки требуют разных профилей настроек (даже банальный MAXDOP уже нужен разный).

    Ну и если есть отдельная копия, то можно сделать прокси-базу с подготовленными view-хами, в которых уже использовать понятные имена, и управлять мэппингом полей на уровне СУБД. Кроме того можно «расшивать» всякие непонятности типа полей составного типа.


    1. Isiirk
      27.04.2022 11:23

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


      1. yukon39
        27.04.2022 12:22

        Возможно это его первый опыт с QlickView, мы в свое время тоже изрядно с ним повозились создав по ходу кучу костылей и велосипедов.