Бэк-офис — достаточно широкое понятие: в зависимости от заказчика это может быть, как система управления товародвижением, так и система управления предприятием (ERP). В большинстве случаев речь идёт именно о товародвижении — основной системе магазина, отвечающей за закупку товаров, ценообразование, ведение остатков.
Даже «коробочные» версии бэк-офиса различаются
Понятие типового, «коробочного» бэк-офиса размыто. У средних и больших магазинов его в принципе не существует: чаще всего российские ритейлеры работают с продуктами компаний SAP, «1С», Oracle, Domino, Gestori. Но практика наших проектов показывает, что даже в этом случае системы магазинов друг от друга отличаются. Два ритейлера могут пользоваться одним и тем же «коробочным» продуктом, но он будет доработан и настроен индивидуально, в зависимости от специфики бизнеса.
Кассовая система должна получать справочники товаров, цен, налогов, дополнительных данных о товарах, информацию о кассирах, маркетинговых акциях и сроках их действия. И отдавать в бэк-офис результаты работы: как минимум, чеки продаж и возвратов, товарную ленту. Но это только в базе, реально же касса получает много другой информации. На один товар может быть установлено несколько цен — это часто делают продавцы табачной продукции: сроки начала и окончания действия цен, а также признаки, что делать кассам с товарами по их истечению. Достаточно часто товары группируются по свойствам, причём группы кардинально отличаются в одном и том же сегменте ритейла. Например, лыжные ботинки могут у одного магазина находиться в группе «обувь», а у второго — в «активных видах спорта». Другой пример: товар может иметь признак штучного или весового, а весовой — признак ввода количества только с помощью прикассовых весов и запрет указывать массу вручную.
Из кассового софта в систему товародвижения уходят не только чеки продажи и возвратов. Дополнительно мы можем передавать удалённые позиции в чеке и причину их удаления (ошибка ввода, отказ от покупки), применённые скидки и метод их расчета (акция на кассе или ручное назначение скидки), KPI продавцов или признаки, что чек является оплаченным интернет-заказом. Многие сети привязывают продажи товара на кассе к конкретному продавцу-консультанту, таким образом учитывается личная продажа. Все эти детали в том или ином виде будут уникальны для бизнеса конкретного заказчика, поэтому каждый раз интеграция «коробочной» кассовой программы и «коробочного» бэк-офиса уникальны.
Как осуществляется интеграция
Технически интеграцию можно осуществить несколькими способами.
Файловый обмен: самый быстрый и простой способ интеграции. Из бэк-офиса формируются файлы товаров и других справочников, кассовая программа забирает их к себе, обрабатывает, начинает работать с этой информацией. По итогам процесса кассовый софт формирует файлы с результатами продаж. Этот способ распространён у многих российских ритейлеров. Но в последнее время мы делаем интеграции со многими системами посредством web-сервисов. Например, «Профи-Т» может через веб-сервис выгрузить все результаты продаж в SAP POS DM.
Интеграция на уровне баз данных (БД). Сервера кассовой программы, работающей на инфраструктуре Microsoft SQL, можно интегрировать с базами данных бэк-офиса. Либо кассовый софт забирает из внешней БД информацию о товарах и отдаёт данные о чеках. Либо внешняя система базу кассового ПО заполняет необходимой для работы информацией.
При интеграции нужно учитывать специфику бизнеса. Небольшому магазину вполне достаточно использовать штатные инструменты интеграции в бэк-офисе, которые позволят системе отдавать данные для работы кассовой программы. А вот сети продуктовых магазинов приходится учитывать при интеграции массу дополнительных факторов, например, специфику работы с Единой государственной автоматизированной информационной системой ( ЕГАИС ). В ней есть такое понятие, как минимальная розничная цена товара, алкогольной продукции. К ней невозможно применять скидки, снизить цену ниже стоимости, установленной госорганами. Или специфику продажи табачной продукции: в этом сегменте указывают МРЦ — максимальную розничную цену, выше которой продавать нельзя. Кроме того, на такой товар нельзя давать скидки.
При интеграции всегда необходимо формализовать и согласовать требования к работе систем: как, что и с чем будет работать. Я рекомендую относиться с осторожностью, когда говорят: «У нас типовая система, давайте сделаем интеграцию — это очень быстро». Обычно это влечёт за собой сплошную головную боль, а весь проект приведёт к увеличению сроков реализации и принесёт только отрицательный опыт. Потому что из-за отсутствия подробных требований в процессе работы появятся неучтённые сюрпризы.
Ещё сложнее интегрироваться с нетиповыми системами. На российском рынке до сих пор ряд ритейлеров в качестве товароучётной системы используют специфическое зарубежное ПО или разработанный под заказ софт, у которого есть только определённые инструменты интеграции. Обычно такие решения не могут похвастаться гибкостью и поддержкой разработчика. В этом случае много времени тратится на выяснение подробностей существующих форматов данных. Тем более, что на процесс накладывает отпечаток российское законодательство. Тот же 54-ФЗ существенно изменил требования к формату фискальных данных, что потребовало дополнительных данных от товароучётной системы. Большинство российских разработчиков это понимают, но многие разработчики систем часто не обращают внимания на такие специфические, но обязательные требования.
Если вас заинтересовала возможность интеграции бэк-офиса с кассовой программой или вы хотите узнать подробнее о возможностях «Профи-Т», свяжитесь со специалистами «Пилота». Они проконсультируют вас и помогут самостоятельно протестировать «Профи-Т».
