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

Самый распространенный на сегодня коммерческий продукт, разработанный на платформе - lsFusion ERP. Это решение для управления розничной и оптовой торговлей, которое используют ⅔ крупных торговых сетей Беларуси, и активно начинают внедрять в России и Узбекистане.

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

Логика подбора в документах

В крупных торговых системах ежедневно генерируются тысячи документов, которые имеют в составе спецификацию, т.е. перечень включенных в документ товарных позиций с рядом характеристик. К ним относятся заказы, накладные, прайс-листы, таможенные декларации, акты списаний, расхождений и т.п. Для каждой позиции указывают, как минимум, количество и цену товаров. Остальные данные определяются типом документа и особенностями бизнес-процессов. Часть таких документов может формироваться автоматически, на основании, скажем, импортированных данных или документов, однако при любом уровне автоматизации избежать ручного ввода “с нуля” невозможно.

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

Рассмотрим, как работает подбор в lsFusion ERP на примере заказа поставщику.

При формировании заказа сотрудник должен предусмотреть следующее:

  • включить в заказ только те позиции, которые возит этот поставщик

  • заказать только те позиции, которые составляют ассортимент магазина

  • верно определить количество для заказа

В lsFusion после заполнения параметров заказа пользователь переходит на вкладку "Подбор" и составляет спецификацию.

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

  2. Следующим кликом пользователь оставляет на форме только те товары поставщика, которые продаются в магазине, куда заказывают товар. Для этого на форму выведен фильтр по ассортименту магазина.

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

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

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

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

Как функционал подбора в документах реализуется средствами платформы подробно описано в статье “Строим интерфейс по вводу документов через подбор”.

Логика прайс-листов

В предыдущем разделе упоминалось, что при подборе позиций документа пользователь располагает достаточным объемом данных для принятия решения, в том числе информацией о цене товара. Система отображает для каждого товара на конкретном складе именно то значение цены, которое действует в текущий или установленный пользователем момент времени. При этом на момент времени можно получить действующие значения различных видов цен: закупочная цена у поставщика, учетная цена на складе, оптовая или розничная и т.д. Один из инструментов, с помощью которого реализовано отслеживание изменения цен во времени в lsFusion ERP — это логика прайс-листов. 

Прайс-лист — это документ, который фиксирует значение одного или нескольких видов цен на товарные позиции на одном или нескольких складах на установленный период времени.

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

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

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

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

Как функционал работы с прайсами реализуется средствами платформы подробно описано в статье “Управление параметрами в бизнес-приложениях по аналогии с системой контроля версий”.

Логика ассортиментных матриц

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

В lsFusion ERP ассортимент магазина составляет совокупность ассортиментных матриц товарных категорий. Логика управления ассортиментными матрицами опирается на принцип стандартизации разновидностей полочных пространств торговой сети и правил их заполнения.

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

Ассортиментная матрица в lsFusion ERP содержит список товаров определенной товарной категории, ранжированных по  уровню популярности. По каждой товарной категории определяют количество вариантов полочных пространств, которое используется во всей торговой сети. Каждая полка соответствует уровню ассортиментной матрицы, а количество наименований, которое можно на ней выставить — это глубина уровня.  Товарные позиции в матрице ранжируются от самых ходовых к менее покупаемым и распределяются по уровням (полкам) по следующему алгоритму: самые популярные позиции размещаются на самой маленькой полке и их количество соответствует глубине этой полки, на следующую полку (уровень) к самым популярным наименованиям добавляются менее популярные. Так в ассортимент добавляются позиции на каждом следующем уровне. Количество наименований на самой большой полке равно количеству товаров в ассортиментной матрице.

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

В каждом магазине торговой сети используется свой набор полочных пространств, исходя из этого  каждому магазину, или формату магазинов, назначается уровень ассортиментной матрицы, соответствующий используемым полкам.  Например, если у нас есть минимаркет, супермаркет и гипермаркет, в которых соответственно используются полки на 4, 8 и 12 наименований, то ассортиментная матрица будет иметь 3 уровня: А, B и С, каждый с глубиной 4 позиций. Минимаркету будет назначен уровень ассортимента А (4 наименования), супермаркету - В (А+B=8 наименований), а гипермаркету - С (А+В+С=12 наименований).

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

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

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

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

Автогенерация документов

Стандартная схема поступления товаров выглядит так: контрагенты согласовывают заказ на товар, поставщик выполняет заказ, а покупатель получает товар. На практике даже в такой схеме есть ряд нюансов, которые влияют на оформление бизнес-процессов в учетной системе. Во-первых, заказанные товары могут поступать частями, или наоборот, если с поставщиком действуют долгосрочные соглашения, в одну поставку могут быть включены несколько заказов, например, с нескольких магазинов торговой сети. Фактическая отгрузка/поступление товара и возникновение финансовых обязательств (или права собственности) могут быть существенно разнесены во времени. Из-за этого при оформлении поступления/выписки товара одним документом “накладная” возникает расхождение в данных. На текущий момент времени управляющий бизнесом не может знать наверняка, все ли оформленные в системе товары поступили или отгружены.

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

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

Конечно, в описанной схеме оппоненты сразу увидят основной "недостаток": создание двух документов в одном из наиболее регулярных процессов для торговых сетей, когда документы приходят вместе с товаром и временная разбежка отсутствует. Это дополнительное время, недовольство персонала, больше вероятность ошибки и т.д. На первый взгляд объективные возражения, но не совсем.

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

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

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

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

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

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

Заключение

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

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

 

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


  1. itmind
    06.06.2023 12:54

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

    1С это платформа, на которой можно написать любую логику ( и такую как вы описали)

    GUI как будто из начала 2000х, интерфейс перегружен, элементы не выровнены.


    1. weissruss Автор
      06.06.2023 12:54
      +3

      1С это платформа, на которой можно написать любую логику ( и такую как вы описали)

      И на SQL можно написать шахматы. Вопрос только в том, насколько это быстро и легко. В lsFusion такие интерфейсы делаются достаточно легко (в статье есть ссылки на соответствующие статьи с описанием как это делается). В 1С же это делается гораздо сложнее (а некоторые вещи вообще невозможны). Мы более подробно проблемы 1С описывали в статье Почему не 1С ?.

      GUI как будто из начала 2000х, интерфейс перегружен, элементы не выровнены.

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


      1. itmind
        06.06.2023 12:54

        Я вам указал на то, что вы в статье сравниваете платформу 1с с конкретной конфигурацией Is Fusion ERP, что не корректно. Должны сравнивать с конфигурацией 1с, например с УТ или ЕРП.

        В 1с ERP интерфейс выглядит более современно и менее перегружен. При этом все, что нужно для отражения хозяйственной операции, имеется.


        1. weissruss Автор
          06.06.2023 12:54

          Я вам указал на то, что вы в статье сравниваете платформу 1с с конкретной конфигурацией Is Fusion ERP, что не корректно. Должны сравнивать с конфигурацией 1с, например с УТ или ЕРП.

          В этой статье как раз описывается не столько продукт, сколько подходы для решения типовых задач (например, ввода документа). И сравнение идет по сути с подходами по вводу документов в 1С. А они в общем-то в 1С похожи, что в УТ, что в ERP.

          В 1с ERP интерфейс выглядит более современно и менее перегружен. При этом все, что нужно для отражения хозяйственной операции, имеется.

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

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


  1. mixsture
    06.06.2023 12:54

    А как тут с пользовательской кастомизацией? Вот списки, например — в 1с в них много колонок и пользователь может выбрать используемые, скрыть остальные (или поменять их порядок, вытащив нужные в начало) и даже добавить свои поля (с ограничением — только вложенные поля от уже существующих). Причем для всего этого участие программиста не нужно.


    1. weissruss Автор
      06.06.2023 12:54

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


      1. mixsture
        06.06.2023 12:54

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


        Но 1с, когда перешла на управляемые формы, добавила еще пользовательской кастомизации: в частности "и даже добавить свои поля (с ограничением — только вложенные поля от уже существующих)".
        Если придумать необходимость на ваших картинках — то это будет "Отправитель.ИНН" — поле Отправитель уже есть в списке, а пользователю нужно сразу видеть его инн. Может ли пользователь сам добавить это поле или только программист?


  1. mixsture
    06.06.2023 12:54

    Приведенные в статье примеры демонстрируют, как разработанная на платформе бизнес-логика сокращает время выполнения операций пользователем

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


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


    1. weissruss Автор
      06.06.2023 12:54

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

      Сравнивали со среднестатистическими бизнес-приложениями на рынке. В частности, с 1С. И да, это субъективно.

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

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


  1. weissruss Автор
    06.06.2023 12:54

    del