image

Добрый день


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

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

Основной предмет данной статьи — механизм трансформации первичных данных о продажах в учетные документы ERP-системы. Статья максимально абстрагируется от конкретных систем, реализующих описанные техники, но используемая терминология частично заимствована у open source ERP-системы OpenPapyrus (там же описанные подходы реализованы и превосходно работают на протяжении многих лет).

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

Требования


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

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

Модель учета розничных продаж OpenPapyrus

Теперь к делу


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

Общее описание


Если рассматривать процесс в общем, то механизм трансформации данных может быть описан следующим образом:

  1. Первичные данные о продажах поступают в ERP-систему от подсистемы управления кассовыми терминалами (point-of-sale).
  2. Входящие данные о чеках обычно сгруппированы в кассовые сессии (смены). Если нет (такие случаю крайне редки), то мы должны искусственно сгруппировать их.
  3. Кассовые сессии группируются в суперсессии, о которых подробнее будет рассказано ниже.
  4. Следующая фаза — консолидация данных кассовых чеков в агрегаторе. Опять же, подробнее он описан ниже.
  5. Завершающая фаза: превращение консолидированных данных о продажах в учетные документы, модифицирующие балансовые параметры предприятия (товарные остатки, бухгалтерские проводки и т.д.).

Кассовые чеки


Собственно, первичные данные розничных продаж, проходящих через point-of-sale, представлены кассовыми чеками. Здесь публика вполне подготовленная потому я не вижу смысла углубляться в особенности структуры кассовых чеков и прочие технические нюансы, тем более, что это выходит за пределы предмета статьи.

Перечислю существенные, в контексте статьи, особенности кассовых чеков:

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

Кассовые сессии


Группирующий объект, объединяющий выборку кассовых чеков за какой-либо период времени. В российской практике почти (но не абсолютно) всегда кассовая сессия совпадает с так называемым Z-отчетом (или сменным) кассы.

Кассовые сессии имеют следующие важные свойства:

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

Кассовые суперсессии


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

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

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

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

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

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

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

Агрегатор


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

Агрегатор — последний эшелон препроцессинга первичных данных о продажах перед окончательным списанием.

Вполне ожидаемым будет вопрос: зачем вообще выделять агрегатор в качестве отдельного компонента модели учета розничных продаж? Не проще ли сгруппировать все в transient-объекте и пустить на «съедение» модулю списания. Увы, нет. Агрегатор является persistent-объектом и выполняет важную функцию в управлении учетным дефицитом и при списании производства (упомянутого выше).

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

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

Документы списания


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

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

Документы розничной продажи


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

Документы возвратов


Дополнение к предыдущему классу, отражающее возвраты через кассы.

Итоговый суммовой документ кассовой сессии


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

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

  • Учетный дефицит
  • Тривиальные проблемы округления (которые, впрочем, можно элиминировать и иными способами)

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

Документы списания производства


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

Документы автоматической компенсации дефицита


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

Заключение


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

  • Масштабируемость: модель применима для розничной торговли любого масштаба — от одиночного магазина до сетей из любого количества магазинов.
  • Универсальность: эта модель работает в разных сегментах бизнеса. Автоматизацию розницы и автоматизацию ресторанов я упоминал, добавлю к этому превосходную адаптированность модели для аптечного бизнеса (там есть ряд нюансов, сильно отличающих этот сегмент о обычной розницы) и, как не странно, beauty-услуги и фитнес-клубы.
  • Управляемость и обратимость: процессы трансформации данных в описанной модели, являясь максимально автоматическими, позволяют в тоже время проконтролировать каждый из этапов.
  • Эффективность: соображения, приведенные в статье, обеспечивают компактное хранение данных и высокую скорость их обработки. Для больших предприятий это — весомый фактор.

Спасибо за внимание.
Поделиться с друзьями
-->

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


  1. Pointman
    22.05.2017 12:03

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


  1. DTL
    22.05.2017 12:03

    Интересная статья. Спасибо! А не планируете развивать проект OpenPapyrus под Linux? Мне кажется, что это было бы вполне логично: коммерческая версия — на Windows-платформе, а OpenPapyrus — на Linux.


  1. antonsobolev
    22.05.2017 12:05

    Планируем, но пока только стратегически. То есть, совершенно ясно, что на Linux надо портироваться, но по-факту даже не приступили еще.