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