WEB-интерфейсы как механизм сбора и контроля данных в розничной сети. Инструменты и наработки

В докладе будет две части.

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

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

 

Кейс по автоматизации сети магазинов с помощью веб-интерфейса. Начальные условия и проблемы заказчика

 

 

К нам обратилась сеть магазинов японской кухни – у них есть собственные магазины, и они предоставляют возможность открыть магазин по франшизе.

Это сеть географически распределенная, владельцы предпочитают работать не в крупных городах, а на отшибе, им так проще – сеть работает в 10 регионах в 35 городах, у них около 70 собственных магазинов.

В этом проекте принимали участие только собственные магазины сети, франшизеров мы не автоматизировали.

 

 

Какие проблемы были у заказчика, зачем им это все понадобилось?

• Так как это общепит, розничная сеть, у них скапливается колоссальный объем наличных денежных средств. Эти денежные средства географически распределены, контролировать их сложно. Плюс недобросовестное поведение персонала: кражи, всякие утаивания, пересорт по различным видам платежей (наличка/ безналичка). Этими денежными средствами достаточно сложно распоряжаться, потому что помимо аутсорсинговой инкассации, у заказчика есть собственная инкассация, которая туда-сюда возит эти деньги. На старте проекта в каждый момент времени понять, где, в каком количестве и какие денежные средства хранятся, было практически невозможно.

• Часть из этих наличных средств может в определенные моменты времени переходить в подотчетные наличные средства – если розничной точке нужно срочно закупить какие-то продукты, надо что-то отремонтировать, они могут это сделать за наличку. На это им нужно выделять деньги, и эти средства тоже нужно отслеживать. Это довольно сложно.

• Третья проблема, которая стояла, – контроль привлекаемого персонала. Руководство компании всегда хотело, чтобы велась максимально «белая» деятельность. Но если вы находитесь в Санкт-Петербурге, а у вас торговая точка где-нибудь в Дагестане, к вам часто могут прилетать штрафы. К примеру, управляющий рестораном нанял дополнительный персонал, потому что существующий не справлялся. Но оказалось, что у людей просрочена регистрация, нет разрешения на работу. А вы узнаете об этом, когда уже выписали штраф, и его надо оплатить. Естественно, руководство это не устраивало, они хотели видеть в реальном времени, что где происходит, где какие люди работают.

• Последняя задача, которая следовала из этого всего, – очень длительное формирование бюджетов. У них очень крупный контрольно-аналитический отдел, где экономисты считали все эти бюджеты – четкий БДР, четкий БДДС. Но формирование бюджетов проходило стадию контроля, т.е. там было огромное количество контролёров, у которых столы были забиты чеками от инкассаторов. В итоге формирование этих бюджетов в среднем составляло 4 месяца. Конечно, руководители жаловались, что к тому времени, когда бюджеты сформированы, они уже фактически не нужны, и то, что произошло 4 месяца назад, никоим образом не помогает принимать управленческие решения. Поэтому нужно было каким-то образом собирать все данные в одном месте, чтобы оптимизировать и ускорить процесс бюджетирования.

 

Почему выбрали веб-интерфейс, а не просто 1С

 

 

Какие были еще проблемы и почему выбрали именно веб-интерфейс, а не просто установку 1С?

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

• У кого-то есть интернет, у кого-то его нет, у кого-то мобильный интернет. Надежных средств связи тоже не было, поэтому оснастить всех нормальным клиентом 1С не представлялось возможным.

• Кроме того, управляющие магазинов были людьми без подготовки – они не были специализированным управленческим персоналом. Поэтому владельцы компании не хотели, чтобы их низкоквалифицированный персонал вообще знал о существовании 1С.

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

По этим причинам было принято решение все делать на веб-интерфейсе.

 

Инфраструктура до и после проекта

 

 

Как у них выглядела инфраструктура в самом начале:

• Бухгалтерия велась в БП плюс БИТ.Финанс.

• Управленческая база – тоже в БП + БИТ.Финанс.

• Весь зарплатный учет велся в коммерческом ЗУП.

• А вся операционная деятельность – в R-Keeper. Наверняка, вы видели в ресторанах экраны с кнопочками, где оформляют заказ – на них чаще всего установлена программа R-Keeper, это очень распространенное программное обеспечение, которое работает на MS SQL.

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

На момент старта единственное, что у них было налажено, – это обмен данными между бухгалтерской и управленческой частью. Там по регламенту с помощью конвертации данных выгружались безналичные платежи. А наличка вообще никак не учитывалась.

 

 

В конце проекта все это пришлось слить в управленческую базу:

• наладили обмен с R-Keeper и с корп. порталом Битрикс;

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

• и еще мы добавили обмен с кадровой базой.

Основная часть, которая нас интересует по сегодняшней тематике, – это веб-интерфейс, который мы добавили.

• Сам веб-интерфейс был реализован на UMI.CMS, но это практически ни на что не влияет, вместо него может быть выбран любой другой программный продукт – Битрикс, какая-нибудь самописная система, Laravel, YII, все, что угодно.

• Сайт, на котором это постится, никаких данных в себе не хранит – все запросы идут напрямую в 1С.

• Единственная дополнительная полезная функция сайта – он кэширует некоторые запросы к базе. Обычно это типы справочников, которые практически никогда не меняются, типы статей затрат. Чтобы лишний раз базу 1С не беспокоить этими запросами, там реализован свой кэш.

А для файлов, чтобы не доставлять их в базу 1С, было реализовано хранилище Selectel – отдельный контейнер. Так как там никаких персональных данных не хранилось, было принято решение, что мы не будем хранить их у себя, тем более что никаких ресурсов под это не было. А в облаке Selectel приятно сделано: можно без программирования настроить, чтобы старые данные за определенный период автоматически удалялись. Поэтому решили все отчетные материалы туда складировать.

 

Кабинет пользователя. Подсистема учета денежных средств

 

 

Покажу, как все выглядит со стороны пользователя-сотрудника.

Еще раз повторю: есть примерно 70 магазинов, и у каждого магазина свой управляющий. Кроме этого, есть еще региональные директоры в каждом регионе, которые тем или иным образом следят за этими подотчетными магазинами.

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

По сути, это система сбора отчетности. Когда закрывается кассовая смена, обычно это происходит в 11 часов вечера, они обязаны в течение определенного времени заполнить ряд отчетов о том, как они отработали, кто у них работал и т.д. Чуть позже все это покажу.

При нажатии кнопки «Отправить» все данные сразу попадают в 1С.

 

 

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

• добавить отчет,

• посмотреть отправленные отчеты,

• посмотреть данные за период.

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

 

 

Здесь показан отчет, который нужно заполнять каждый день.

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

Здесь можно ввести данные:

• по выручке;

• по инкассации – сколько была исходящая инкассация, в некоторых случаях у них может быть входящая инкассация, если недостаточно налички.

 

 

• если в течение дня были наличные расходы, то пользователь открывает меню, выбирает из 1С статьи затрат (кстати, именно эти данные кэшируются на стороне UMI), заполняет форму, что потрачено.

 

 

• и еще у пользователей есть возможность прикрепить определенные файлики, где есть подтверждение затрат по чекам.

Дальше нажимаем «Отправить», все это падает в 1С.

Как это выглядит на стороне БИТ.Финанс

 

 

Так выглядит БИТ.Финанс.

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

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

 

 

Управление системой происходит исключительно на стороне 1С. В UMI.CMS есть своя админка, но единственное, что там настраивается, – это адрес подключения к базе данных 1С.

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

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

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

 

 

После отправки данных можно посмотреть список отчетов с фильтрами по магазинам:

• региональные директоры видят данные только по магазинам своего региона;

• центральный офис видит все данные;

• а управляющие магазином видят данные только по своему магазину.

 

 

Можно просмотреть сами отчеты, чтобы убедиться, что все данные правильные.

Если окажется, что отправили что-то неправильно, отредактировать они это не могут, но могут отправить заявку на редактирование отчета (на картинке этого не видно). После этого у контролера в 1С автоматически создается задача со ссылкой на этот документ. И контролер уже определяет, нужно что-то исправлять или не нужно, почему была допущена ошибка.

 

 

Если нужно посмотреть данные за период, можно построить отчет движения денежных средств, аналогичный 1С, где показано:

• какая была выручка,

• какие расходы,

• какая инкассация,

• сколько дней прошло после инкассации – обычно руководители хотят это видеть.

 

 

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

Система заработала, мы ее запустили. Было много споров, что ресурсов очень мало, сервер работал уже на пределе, было занято 95% оперативной памяти. Мы долго обсуждали, можно ли все 70 торговых точек запускать в эту систему, чтобы они все делали отчеты.

Но как оказалось, работа с этими отчетами практически ни на что не повлияла, все магазины заканчивают работу примерно в одно и то же время – это 11 часов вечера. Дальше у них есть определенное регламентное время, когда они могут делать эти отчёты. И хотя все отчеты отправляются приблизительно в одно и то же время, никакой нагрузки на базу никто не заметил, почти ничего не поменялось.

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

 

Подсистема рабочего времени сотрудников

 

 

Какое-то время в компании привыкали пользоваться новой системой – в ней на тот момент работала только подсистема учета денежных средств.

Но потом нам сказали, раз все работает в таком виде, давайте решать вторую проблему – рабочее время сотрудников.

Для этого появилась аналогичная форма. Много про нее рассказывать не буду. Здесь интеграция уже ведется не с управленческой базой на БИТ.Финансе, а с ЗУП.

Опять-таки ежедневно вы заполняете некую форму, где показано, какие именно сотрудники у вас работали.

 

 

Сотрудников можно выбрать их из списка. Список формируется «на лету» в зависимости от штатной расстановки на текущую дату: видно, кто у вас работает, кто не работает. Если у вас появился внештатный сотрудник, его сюда также можно добавить.

 

 

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

Можно приложить подтверждающие документы, ведомость, где человек расписался, что обработал.

Опять-таки – нажимаем кнопку «Отправить отчет», и в 1С создается нужный документ. Эта подсистема тоже заработала, все стало здорово.

После того, как мы наладили обмен с ЗУП, эти данные стали поступать в управленческую базу. А это значит для формирования бюджетов у нас уже был ФОТ – а это уже солидная основа, без которой раньше нельзя было построить БДР.

 

Подсистема контроля подотчетных средств

 

 

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

 

 

Из списка он может выбрать возможные статьи расходов.

 

 

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

 

 

Также можно посмотреть отчеты, что и сколько за конкретный период заказано, сколько заявок одобрено, сколько израсходовано по каждой статье расходов.

Эта подсистема тоже заработала, все были очень довольны

 

Подсистема ввода показателей счетчиков

 

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

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

 

Подсистема регистрации нарушений

 

 

Следующая подсистема – контроль нарушений – очень интересная. Она появилась самой последней.

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

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

И дальше уже контролер просматривает этот документ и принимает «арбитражное» решение: если объяснительная нормально написана, он может не оштрафовать, а если это очевидное нарушение, то он выставляет штраф.

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

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

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

Я был немножко в шоке, когда увидел этот бесконечный список протоколов нарушений: нарушение гигиены, разговоры во время готовки, невыполнение задачи в Битриксе…Это тотальный контроль всего, что происходит в каждой торговой точке.

Эта система тоже заработала и до сих пор работает.

 

Какие проблемы удалось решить

 

 

Чего нам удалось добиться по окончании этого проекта?

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

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

• Через какое-то время, довольно продолжительное, мы оформили систему формирования бюджетов. Нам удалось достичь следующего.

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

  • Естественно, этого было недостаточно, было большое количество операций, которые невозможно автоматизировать, потому что такая сеть – это обычно огромное количество различных юридических лиц и индивидуальных предпринимателей, которые обмениваются операциями, и экономистам нужно какое-то время, чтобы уточнить все непонятные операции и уже руками проставить нужную аналитику во всех документах. Это занимало примерно 5-6 дней, и уже через неделю эти бюджеты рассылались как белые. В них уже были проставлены все статьи доходов и расходов, по ним можно было посчитать прибыль по каждой торговой точке. В итоге сроки формирования бюджетов сократились с 4 месяцев до 7 дней, а это уже вполне нормальный период, когда можно что-то планировать, принимать какие-то управленческие решения.

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

• Дополнительно удалось реализовать систему контроля и учета нарушений.

 

Чем закончился проект

 

Система очень быстро стартовала – мы постоянно добавляли в нее новые подсистемы, и все это сливалось в базу 1С.

Если посмотреть, какие задачи ставились, и как они были решены, то это, уверен, Epic Win (эпическая победа). Потому что для общепита в принципе сформировать какой-нибудь бюджет сложно. Мы с этой задачей обращались в более крупные сетевые компании, но они все нам говорили, что даже не будут рассматривать такую проблему. Поэтому наши результаты – это здорово, на 5+.

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

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

В принципе все задачи, которые ставились, на стороне 1С были несложными. Мы их оценивали, говорили, что это абсолютно реально, мы понимаем, как это делать. Но перенос всей этой деятельности на сторону веб-интерфейса получался так: сама задача отнимает 10%, а действия по переносу всей этой деятельности на сторону web – еще 90%. Мы, как разработчики, не совсем понимали, зачем это вообще нам надо. И в итоге нам бюджет не согласовывали.

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

Почему я привел в качестве примера этот проект? Потому что он не только показывает, как все может быть здорово, когда задачи поставлены и решены. Но и с точки зрения стратегического планирования: сейчас у заказчика есть достаточно объемная система, в которую вложены деньги, и ее дальнейшее развитие приводит к тому, что нужно думать, надо ли вкладывать такие бешеные деньги. Грубо говоря, даже если они сейчас закупят ноутбуки во все свои торговые точки, это выйдет даже дешевле, чем развивать систему с таким навороченным интерфейсом.

 

Вторая франшиза в той же базе

 

Еще один момент, который нам удалось решить: в определенный момент наша система из системы, которая обслуживает одну франшизу, превратилась в систему, которая обслуживает две франшизы. Там была такая ситуация: в конце 2017 года активно развивалась франчайзинговая сеть бьюти-салонов «Пилки». Наш клиент решил, что это перспективно, и открыл у себя вторую франшизу, помимо суши.

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

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

 

Предыстория появления универсального расширения для создания веб-интерфейса

 

На этом первую часть доклада я закончу и расскажу немножко о другом.

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

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

В бюджетной сфере не так – там, когда заключаются контракты на реализацию веб-интерфейса или интеграцию, есть контракт, в котором написано, что, условно, на какую-нибудь интеграцию с веб-интерфейсом выделено 500 человек-часов. Приходит заказчик, ты его спрашиваешь, что надо делать, предлагаешь составить какое-то промежуточное техническое задание. А тебе говорят, что пока сами не знают, что нужно делать, что есть огромное количество отделов со своими мелкими задачами, и есть какой-то свой портал, написанный неважно на чем. То есть никакого общего видения, что должно получиться в конце, как вы должны работать, кто будет потребителем, у заказчика нет, все задачи появляются спонтанно.

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

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

• определенный список справочников и перечислений,

• набор каких-то элементов этих справочников с определенными отборами,

• документы определенных видов с определенными отборами,

• данные, которые выбраны каким-то определенным запросом.

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

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

 

Расширение БРОМ – что это такое

 

 

Так у нас родилась библиотека, которую мы назвали БРОМ.

Об этом продукте есть статья на Инфостарте.

 

 

А еще в интернете можно найти специальную страницу, где можно посмотреть, что эта штука умеет.

Если вкратце, суть в следующем:

• в 1С устанавливаем расширение, в котором есть веб-сервисы, отвечающие по SOAP.

• На стороне клиента подключаете клиентскую библиотеку – это может быть либо приложение .Net Core, которое можно запихнуть в ASP, либо скрипт на PHP, либо на Python.

 

 

Код вызова клиента практически идентичен – создается объект БромКлиент, где указывается адрес вашего развернутого сервиса.

 

 

Этого клиента достаточно, чтобы, например:

• получить необходимые элементы из выборок – мы можем получать ссылку на нужную нам группу справочника;

• можете вызывать произвольные процедуры и функции из модуля менеджера справочника – при этом в библиотеке есть свой сериализатор, и, если вы передаете данные в каком-то виде, вам не нужно париться и во что-то их оборачивать, он автоматически сериализует нужные типы (это могут быть ТаблицыЗначений, ДеревьяЗначений, ДвоичныеДанные);

• можете сформировать выборки, указать для них условия, упорядочить и дальше уже как-то с ними работать;

• если у вас есть какие-то ссылочные данные, вы можете через ссылку обращаться к внутреннему контексту.

 

 

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

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

 

 

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

Если вам нужно вызвать функцию глобального контекста, к примеру, «ЧислоПрописью», вы ее просто вызываете как метод клиента, передаете сюда параметры в естественном виде, она возвращает результат.

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

 

 

У продукта есть достаточно подробная документация по каждому клиенту.

А если какого-то клиента нет, например, вам нужна Java, вы можете за счет документации по SOAP написать свой клиент для Java.

Здесь задокументирован пример SOAP-запроса и SOAP-ответа.

 

 

Кроме того, мы сняли несколько уроков, где наша сотрудница рассказывает, как установить и работать с этой библиотекой.

Соответственно, если вам нужно наладить связь с бэкендом и потом это все вывести, можно этой штукой пользоваться, она у нас предоставляется по лицензии MIT.

 

Вопросы

 

Непонятно, где заканчивается 1С и начинается не-1С? Что у вас используется, кроме 1С?

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

В клиентской части сайта (я имею в виду тот обработчик, который будет отвечать за бэкенд сайта, который генерит страницу) устанавливается клиент БРОМ (либо на .NET Core, либо на PHP, либо на Python). Дальше в нем прописывается строка подключения, и вы уже по указанному выше синтаксису обращаетесь к базе через веб-сервис, который запросом забирает из 1С все, что вам нужно. Синтаксис кода очень похож на то, что пишется в 1С.

Вы упоминали корпоративный портал Битрикс. Каким образом он использовался – параллельно для других целей?

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

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

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Web-клиенты для 1С".