Интеграция ПланФикса и 1С: сказ о техническом и идеологическом подходе

Артём Колисниченко: Сегодня в рубрике «Рассказ от первого лица» Сергей Улаев — руководитель компании «AffContext». Он расскажет о перипетиях интеграции ПланФикса и 1С. Не буду томить долгими вступлениями, а лучше сразу передам ему слово.

Сергей Улаев: Интеграция чего-либо с 1С — это всегда боль. Там что не так сделай, то сразу можно уйти в многочасовые разборы полётов. Ну… либо это у меня был такой печальный опыт. Просто помню, как как-то я нажал не ту кнопку при обновлении, а потом восстанавливал базу из бэкапа. И далее целый год не ставил никаких обновлений, чтобы «от греха подальше» 🙂

Тут у каждого опыт свой. И сейчас хочется рассказать о нашем практическом опыте, где мы на одном проекте сделали двустороннюю интеграцию ПланФикса и 1С. Да так, что всё ещё и работает, как надо 🙂

Вообще, у нас на нашем корпоративном блоге есть хорошая статья «Как самостоятельно написать ТЗ на интеграцию ПланФикса и 1С», на базе которой и была сделана эта работа. Но там описан больше сам идеологический подход к работе, а тут — чуть больше технического описания и преимуществ реализации такой схемы именно в ПланФиксе.

Ниша клиента — производство печного оборудования.

Начнём с общей задачи — нужно создавать в 1С 33 (тридцать-три) документа в разные моменты времени. Вот набор документов в их иерархическом виде:

А вот набор задач в ПланФиксе, которые соответствуют этим документам:

Естественно, что схемы задач и документов — это разные схемы. Там внутри одной задачи может создаваться несколько самых разных документов. И как раз сила ПланФикса воистину открывается в процессе настройки автоматических событий при работе с задачами.

Сразу пропустим сам этап создания грамотного и понятного ТЗ (об этом как раз можно почитать по ссылке, данной ранее) и сразу перейдём к этапу, что код на стороне 1С написан, теперь нужно сделать автоматику внутри ПланФикса. При этом есть некие вводные данные, которые обязательно нужно учитывать:

  1. У клиента в системе уже есть автоматика на создание задач по ручному созданию документов. Это типа задача-напоминалка, чтобы бухгалтер зашла сама в 1С и вручную сделала нужные действия.
  2. У клиента в системе уже есть справочник номенклатур. А это значит, что нужно организовать лаконичную работу именно с этим справочником, а не каким-то новым. И я не смог придумать предложение, которые бы описывало сложности того, когда приходится работать не с нуля, а с имеющимися наработками. Просто знайте — там подводных камней можно накопать «мама-не-горюй».
  3. Внедрение функционала нужно делать поэтапно, чтобы убедиться в корректной логике его работы. Вроде бы должна быть автоматика по созданию документов, но сначала эту автоматику надо будет запускать вручную. И потом уже полностью перейти на авторежим.

Всё эти моменты прекрасно получилось учесть всего за счёт 2-х стандартных функционалов ПланФикса:

  1. Справочники
  2. Автоматические сценарии

Давайте пойдём по порядку, как раз удобно будет читать.

Этап № 1: найти всю текущую автоматику, которая создаёт задачи на ручное создание документов

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

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

По клику картинка отроется в большем размере.

Проходимся по всем таким задачам и запоминаем ссылки на них. Простой и короткий этап, для разогрева вашего внимания на чтение 🙂

Этап № 2: организовать работу с текущей номенклатурной базой

Текущие справочники активно используются в задачах, менять логику работы с ними можно, но это как кинуть палку меж спиц активно едущего велосипеда — можно вообще остановить работу в системе…и получить **** от «велосипедиста». Но при этом нам обязательно надо создавать новые справочники, которые будут содержать объекты для связи с 1С. Вон их тут, целый набор:

Связь между старым и новым получилось сделать за счёт стандартного функционала. Мы добавили в старый справочник номенклатур новое поле типа «Запись справочника», в котором и содержалось новое значение из нового справочника. Но ничего бы не получилось, если бы не возможность в автоматических сценариях обращаться как можно «вглубь» любого справочника, чтобы достать нужные данные для отправки их в 1С. Выглядит это так:

По клику картинка отроется в большем размере.

Здесь мы обратились аж на 3 уровня вглубь справочника, чтобы достать нужное нам значение. В данном случае нам нужен был системный ID объекта для отправки запроса наружу.

Возможность объектам ссылаться друг на друга + возможность достать нужные данные из справочников = успешная реализация сохранения текущей номенклатурной базы при наличии новой. Тут мы не бросаем палку в велосипед, а едем рядом и наблюдаем за происходящим. Круто ж!

Этап № 3: поэтапное внедрение функционала

Вот тут прямо пришлось повозиться, потому что уж мы знаем, что такое «внедрение чего-то нового». Если у человека есть возможность сделать что-то не так — это обязательно будет сделано. И наша задача — разобраться, что и где пошло не так. Поэтому тут пришлось навертеть целую гору автоматических действий, которые подготавливали данные к отправке, но НЕ отправляли их… НО показывали эти данные пользователю. Короче, это выглядело так внутри задач в системе:

По клику картинка отроется в большем размере.

Такие сообщения появлялись в нужные моменты времени (о которых мы, конечно, знали заранее). Это всё сделано с помощью функционала автоматических сценариев. Дальше система говорила пользователю, что именно нужно сделать, чтобы вручную cымитиpoвaть автоотправку данных:

В случае, когда одно действие влекло создание нескольких документов, сообщение было такое:

В деталях задачи у нас были новые поля, которые по клику запускали автоматику на отправку запроса в 1С:

По клику картинка отроется в большем размере.

И потом в задаче получаем информацию о том, какой пришёл ответ от сервера:

Ответ от сервера, конечно, уже настраивается разработчиком 1С, но видим мы его в самой задаче.

Таким образом мы мониторим каждый шаг пользователя и взаимодействия систем, чтобы понять, где какие могут быть ошибки. При этом пользователь сам вручную запускает автоматику по созданию документов и перепроверяет созданные документы. И лишь когда мы окончательно убедимся, что всё 100% работает, как надо, мы уберём действия по ручному запуску отправки запросов. А точнее так — мы добавим новые сценарии, которые будут имитировать ручную имитацию автоматики. Да… запутанно вышло, но так оно и будет.

Ниже представлено видео, где мы изнутри ПланФикса создаём один из документов в 1С.

Всё?

Ну почти…

Описанное выше — лишь односторонняя интеграция, ведь запросы шлются лишь из ПланФикса в 1С. Двусторонней же эту интеграцию делает факт того, что мы из 1С назад в задачу возвращаем ссылку на созданный документ:

По клику картинка отроется в большем размере.

Можно кликнуть по ссылке и вуаааалллля — откроется документ в 1С. На это тоже есть демонстрационное видео, обязательно посмотрите:

Ну теперь вроде всё. Наличие грамотного ТЗ на работу — это хорошо. Но наличие системы, которая позволит сделать поэтапное внедрение такой интеграции — это прямо отлично. Мы прямо кайфанули, когда всё это реализовали. Всё как на ладони и всё предельно прозрачно. Настраивай и собирай как хочешь. ПланФикс — тот ещё лего!

Теперь вы точно знаете, что интеграция ПланФикса и 1С — реализуемая задача. Можете попробовать сами, опираясь на эту статью и на статью с нашего корпоративного блога, это будет вам хорошей практикой. А когда надоест разбираться в технических деталях и построении четкого организационного процесса — вы знаете куда обращаться 😉

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

P.S.S. У вас может возникнуть вопрос, как для 1С выглядит этот новый код по обработке запросов из ПланФикса. Не слетит ли он при очередном обновлении 1С. Тут ответ такой:

«Все изменения сделаны через механизм расширений и не меняют конфигурацию клиента. При последующих обновлениях нужно следить за тем, чтобы расширение оставалось подключенным. Если всё же конфигурация очень сильно обновится (поменяется вторая цифра в номере релиза), то рекомендуется привлекать разработчика для корректной проверки и обновления расширения».


Артём Колисниченко: Спасибо Сергею за очередной интересный рассказ. Завершая рубрику, поделюсь планами на ближайшее будущее относительно ПланФикса и 1С. У нас сейчас на этапе тестирования есть разработка, которая позволит ПланФиксу и 1С в перспективе подружиться. Первый шаг делаем в сторону синхронизации контактов между системами. Новинку планируем выпустить весной, так что обязательно подписывайтесь на наши социальные сети, чтобы ничего не пропустить: Facebook, ВКонтакте, Telegram, Twitter и YouTube-канал.

11 Comments

  1. Аватар

    Круто, Сергей, спасибо.
    1. Было бы интересно узнать трудоемкость в часах для клиента по настройке «ПланФикс».
    2. Кто делал настройки на стороне 1С настройки и программирование, ваша команды или команда Клиента? Если ваша то какие тут трудозатраты в часах если Клиента то возможно тоже вы в курсе о каких затратах идет речью

    1. Аватар

      Не считал в часах конкретные фактические затраты, но интуитивно скажу, что 40% времени и усилий было направлено на ПланФикс (подготовка почвы там), 60% — на написание кода 1С и его тестирование (неоднократное, увы). Всё по части 1С писали мы, клиент лишь порой нам нужные доступы давал и тестовую базу изначально подготовил…и просто был супер адекватный 🙂

      Сейчас со стороны смело бы оценили такое в 100 — 150 часов в сумме

      1. Аватар

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

        А там уже решать каждому своё )

  2. Аватар

    Большое спасибо, очень нужное направление!
    УНФ использовалась коробочная или облачная (fresh)? С Фрешем в принципе можно ли делать такие интеграции? А с Комплексной автоматизацией (тоже Фреш)?

          1. Аватар

            Сергей, мне, к сожалению, не удалось из этого коммента ничего понять 🙁

            Опишу проблему.

            Есть полностью стандартная конфигурация 1С «Управление Небольшой Фирмой», находящаяся в облаке на 1с-фреш (https://1cfresh.com/solutions/sbm)

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

            Сейчас мы еще не выбрали окончательно ни платформу, ни облако. Т.е. если надо «УНФ» поменять на «комплексную» или 1cfresh на какое-то другое 1с-облако — это вполне возможно.

            От чего еще зависит, может или нет получиться обмен?

            1. Аватар

              Ну вот передаю ответ нашего разработчика.
              — — —

              Это зависит целиком и полностью от готовности конкретного облака предоставить ресурс веб-сервера.
              1С:Фреш — это конкретное облако, с ним, с большой вероятностью это не получится. Есть альтернатива — облако 1С: Рарус, с которым, скорее всего получится. Но, в любом случае, нужно запрашивать этот ресурс и либо получать его, либо отказ

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

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

              Но это опять зависит от возможностей, которое предоставляет конкретное облако. 1С:Фреш такое допускает, но в нем любая доработка на стороне 1С проходит процедуру согласования. В 1С:Рарусе можно без проблем и без согласования. Разные облака имеют разную стоимость и разный набор функций.

              — — —
              Надеюсь, я дал вам пищу для размышления )

Добавить комментарий