Центр поддержки пользователей и разработчиков

Стройте эффективные решения на нашей платформе

Методология внедрения

Принципы работы с KPI для достижения максимальной эффективности в управлении

Дальше

Кассовый модуль

Принципы работы кассового модуля и руководство пользования

Дальше

Панель управления

Возможности веб-интерфейсов и инструкции по использованию и настройке аккаунта.

Дальше

Мобильные приложения

Что умеют приложения для iOS и Android и как начать ими пользоваться

Дальше

Установка и настройка

Обновление 03 Дек '15


Требования

Минимальные требования

К кассовому оборудованию

Параметр Значение
ОС Windows XP и выше
Процессор Atom 1Ghz
Память 512MB
Свободное место на диске 40MB для ПО и дополнительно для установки .NET FrameWork 4.0
Подключение Наличие прямого или проксируемого доступа приложению в интернет
Принтер чеков COM/USB при установке в режиме драйвера слушателя чеков (см. таблицу поддерживаемых принтеров)

Поддерживаемые драйверы принтеров чеков

При установке в режиме драйвера слушателя порта принтера нужно учитывать, что POS-система должна работать с принтером напрямую в соответствии с текстовыми протоколами печати чека

Производитель Реализация
ESCPOS Частичная, зависит от формата печатаемого чека. Поддержка только текстовых данных
ATOL Фискальный режим
Штрих Фискальный режим
Меркурий Фискальный режим
Искра Фискальный режим

Поддерживаемые POS-системы

Название Варианты установки
Rkeeper v6, v7 Только драйвер слушателя порта
IIKO v3+ Драйвер слушателя порта или Установка плагина
Frontol 4+ Драйвер слушателя порта или Интеграционные скрипты
1C 7.7+ Драйвер слушателя порта или Интеграционные скрипты
Другие Драйвер слушателя порта или разработка интеграции

Настройка аккаунта

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

После регистрации в меню "Настройки" выберите в блоке "Магазин" пункт "Общая информация"

Конфигурация магазина

Здесь нужно заполнить основную информацию о вашем предприятии

Конфигурация Торговых Точек

После сохранения данных о магазине в том же блоке нужно перейти в пункт "Торговые точки"


Здесь заполняется список адресов торговых точек вашего предприятия. Нажав кнопку "Добавить" вы сможете добавить ещё один адрес торговой точки



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

Конфигурация устройств

После добавления хотя бы одной Торговой Точки нужно добавить устройство - это конечный аккаунт для приложения на кассе торговой точки.


Добавление происходит похожим на Торговые Точки образом



Для настройки достаточно выбрать привязку к Торговой Точке, где работает Касса и назвать её для удобства дальнейшей идетификации


Установка

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

Установка с интеграцией в POS-систему

В разделе Требования обозначен список POS-систем с которыми возможна интеграция

Для данного вида установки вам так же нужно зерегистрировать аккаунт и скачать дистрибутив для интеграции

Далее руководствоваться разделом Интеграция, в котором описаны принцип и методы интеграции.

Установка в режиме драйвера слушателя порта

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



После удачного определения экран приложения сменится на рабочий.


Конец документа

COM-Интерфейс

Последнее обновление: 01 Окт '16


Интеграция возможна на платформах MS Windows (Начиная с XP и выше)

Для начала интеграции достаточно скачать дистрибутив и установить его на кассу или станцию разработки

Данный дистрибутив устанавливает Кассовый Модуль в режиме интеграции через COM-интерфейсы (не подходит для решений драйвера слушателя порта принтера).

Поддержка интеграции для POS-систем

POS-система Ссылки на файлы/документацию
IIKO Plugin
v3.5
v3.9
v4.2.1172
v4.2.+
v4.3+
v4.4+
Frontol Интеграция
v4
v5
1C 7.7 Драйвер слушателя порта или Интеграция
1C 8.0+ Драйвер слушателя порта или Интеграция
Другие Драйвер слушателя порта или индивидуальная интеграция

Примеры кода для POS-систем

1C 7.7

ГМ = CreateObject(“Giftoman.ChequeApi”);
ГМ.<Название метода>( Параметры );

1C 8+

ГМ = Новый COMОбъект(“Giftoman.ChequeApi”);
ГМ.<Название метода>( Параметры );

Frontol 4+

var gmObject = new ActiveXObject(“Giftoman.ChequeApi”);
gmObject.<Название метода>( Параметры );

Начало покупки

Метод предназначен для начала оформления покупки по новому чеку.

PurchaseOpen ( [ total, cashier ]);

name type description
total DOUBLE (Опционально) Итоговая сумма чека (за вычетом скидки)
(Опционально, если нужен расчёт суммы по PurchaseAddItem())
cashier(60) BSTR (Опционально) ФИО или другое текстовое обозначение продавца

Exceptions

Значение Описание
COMException Не обнаружена директория обмена

Пример

Открытие чека с итоговой суммой 300 рублей .Кассир "Иванова И.И."

 GM.PurchaseOpen( 300.00, "Иванова И.И." );         

Добавление позиции в покупку

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

PurchaseAddItem( name, count, total, [, category, seller, extId] );

Параметры.

name type description
name BSTR(200) Название товарной позиции
count DOUBLE Количество
total DOUBLE Итоговая сумма (за вычетом скидки) по товарной позиции (priceDiscounted * count)
category BSTR(200) (Опционально) Строка категории (группы) товара
Можно передавать несколько категорий, разделяя их '&&'
seller BSTR(64) (Опционально) Строка имени продавца по позиции (по умолчанию продавец берётся из PurchaseOpen())
extId BSTR(48) (Опционально) Внешний идентификатор товара (из номенклатуры ТС)

Пример

Добавление товарных позиций

GM.PurchaseOpen( 300.00,"Иванова И.И." ); // Открываем покупку
GM.PurchaseAddItem('Пакет-майка',1,5.0); // Регистрируем позицию "Пакет-майка", количество 1, общая стоимость 5.0
GM.PurchaseAddItem('Огурцы зелёные',3,295,'Овощи'); // Регистрируем позицию "Огурцы зелёные", количество 3, общая стоимость 295 в категории "Овощи"
GM.PurchaseClose();  // Закрываем покупку            

Добавление атрибута к покупке

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

PurchaseAddAttr(name, value);

Параметры

name type description
name BSTR (20) Название атрибута
withcard (value: 0,1) - использование карты лояльности
discount (value: double) - скидка на покупку
bonus_sp (value: double) - использование бонусных баллов
procspd (value: int) - время обработки чека, сек.
paytype/[cash,card,visa,master, e.t.c.] (value: double) - разбиение суммы по платежам или указание типа платежа.
возможно использовать свои названия под разработку доп. KPI.
value BSTR (10) значение атрибута (Все значения передаются в виде строки, в том числе и числовые типа скидок и флагов)

Пример

Добавление товарных позиций

GM.PurchaseOpen( 300.00,"Иванова И.И.");
GM.PurchaseAddItem('Пакет-майка',1,5.0);
GM.PurchaseAddAttr('withcard','1'); // Обозначаем, что покупка проходит с картой лояльности Клиента
GM.PurchaseAddAttr('paytype/cash','200'); // Была проведена покупка за 200р наличными
GM.PurchaseAddAttr('discount','100'); // Определяем скидку на данную покупку
GM.PurchaseClose();              

Завершение покупки

Только при закрытии покупки система ставит её в очередь отправки в облако.

PurchaseClose([extId])

Параметры

name type description
extId BSTR (40) (Опциональный) Идентификатор чека внутри торговой системы для возможности сквозной идентификации на стороне облака.

Начало возврата

Метод предназначен для начала процедуры возврата.

RefundOpen ([total, extId ]);

name type description
total DOUBLE (Опционально) Сумма возврата
(Опционально, если будут указаны возвращаемые позиции)
extId BSTR(40) (Опционально) Идентификатор чека в торговой системе
(При обработке чека в облаке будет связано с начальной покупкой)

Exceptions

Значение Описание
COMException Не обнаружена директория обмена

Пример

Открытие чека с итоговой суммой 300 рублей .Кассир "Иванова И.И."

 GM.RefundOpen( 300 ); //Возврат суммы чека в 300 рублей
 GM.RefundClose(); // отправка данных              

Добавление позиции в возврат

В случае, если проводится неполный возврат чека (выделенные позиции).

RefundAddItem( name, count, total [, category, seller] );

Параметры.

name type description
name BSTR(200) Название товарной позиции
count DOUBLE Количество возвращаемых позиций
total DOUBLE Итоговая сумма возврата
category BSTR(200)
Категория возвращаемого товара (Опциональный параметр)
Можно передавать несколько категорий, разделяя их '&&'
seller BSTR(64)
Продавец возвращаемого товара (Опциональный параметр)

Пример

Возврат товарных позиций

GM.RefundOpen( 300.00,"12309283445" ); // Начинаем возврат
GM.RefundAddItem('Огурцы зелёные',3,295, "Овощи СТМ", "Иванов Иван Иванович"); // Регистрируем позицию возврата "Огурцы зелёные", количество 3, общая стоимость 295
GM.RefundClose();  // Закрываем возврат            

Закрытие возврата

Отправка данных в облако.

RefundClose()

Параметры отсутствуют


Установка даты-времени покупки/возврата

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

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

Время должно быть преобразовано к UTC-0

SetDateTime(BSTR datetime);

Параметры

name type description
datetime BSTR (14) Строковый формат даты-времени (yyyyMMddHHmmss) (20160515120159) - UTC-0 время на машине момента регистрации события

Пример

Установка даты-времени покупки

GM.PurchaseOpen( 300.00,"Иванова И.И.");
GM.SetDateTime('20160515120159'); // Устанавливаем время 12:01:59 от 15-го мая 2016-го года
GM.PurchaseClose();              

Общая установка продавца

Данный метод используется для отдельной установки ФИО продавца (как для продажи, так и возврата)

SetCashier(BSTR cashier);

Параметры

name type description
cashier BSTR (14) ФИО продавца

Пример

Установка продавца в чек

GM.PurchaseOpen( 300.00,"Иванова И.И.");
GM.SetCashier('Грозный Иван Васильевич'); 
GM.PurchaseClose();              

Service API

Последнее обновление: 24 Окт '16

Сервисное API предназначено для прямой интеграции Server-Server или Application-Server.
API поддерживает JRPC 2.0-протокол вызова методов.
Для работы небходимо знать ключ <authkey> "устройства" с которым можно обращаться по URI: https://api.giftoman.ru/s/<authkey>

Протокол обмена данными

Запрос представляет собой JSON-сериализованный объект отправляемый с помощью POST-метода в виде RAW_POST_DATA

                      {
                        "jsonrpc":"2.0",
                        "id": "[Свободно-генерируемый идентификатор запроса]"
                        "method": "[Название вызываемого метода]",
                        "params":  [объект или массив аргументов вызываемого метода]
                       }
                    }

Ответ так же является JSON-сериализованным объектом

                      {
                        "jsonrpc":"2.0",
                        "id":"[Идентификатор запроса на который дан ответ]"
                        "result":[Любой тип данных - объект, массив, значение]
                      }

или отрицательный

                      {
                        "jsonrpc":"2.0",
                        "id":"[Идентификатор запроса на который дан ответ]"
                        "error": {
                        "code":"[Код ошибки]",
                        "message":"[Человекочитаемое пояснение ошибки]"
                        }
                      }

Регистрация продажи/возврата

Запрос позволяет как оформить продажу, так и возврат

purchaseRegister( token, amount, cart );

Параметры.

name type description
token string(32) Локальный идентификатор клиента, если таковой отсутствует передавать 'guest'
amount DOUBLE Если >0, то сумма чека, если <0, то сумма возврата
cart object Объект расширяемых (опциональных) параметров чека:
- discount (double) : Скидка по чеку
- ts (UNIX UTC0 timestamp) : Точное время чека
- cashier (string(200)) : Имя продавца
- positions (array) : [ Товарные позиции в чеке {
-- name (string(200)) : Название товара
-- count (double) : Кол-во товара
-- total (double) : Сумма по позиции
-- category (string(200)) : Название категории товара (Можно передать несколько категорий в строке, разделяя '&&')
},..
]
- attributes (array) : [ Массив свободных атрибутов чека (карты лояльности, платёжные системы и т.п.) {
-- name (string(10)) : Название атрибута (английские мнемоники),
-- value (double) : Значение атрибута
},..
]

Параметры ответа

result: { "amount" : Зарегистрированная сумма, "id": Идентификатор чека, "ts": Время регистрации}

Установка планового значения

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

Планы устанавливаются на ту Торговую точку, где зарегистрировано данное устройство.

planSet( metric, plan, year, month, day );

Параметры.

name type description
metric string(40) Мнемоника, либо прямой идентификатор правила:
- income : Выручка
- average : Средний чек
- count : Кол-во продаж
- category : Выручка по СТМ
- complexity : Комлексность чека по кол-ву товаров
- p/<идентификатор показателя> - прямой идентификатор показателя
plan DOUBLE Если >=0, то установка планового значения = plan, если <0, то удаление
year int Год
month (необязательный) int Месяц, если не указан или = -1, то выставляется план на год
day (необязательный) int День, если не указан или = -1, то выставляется план на месяц, иначе - на день

Параметры ответа

result: { "addressId" : ИД торговой точки, "metric": Идентификатор показателя, "plan": Установленный план, "year": Год, "month" : Месяц, "day": День}

Публикация плана

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

planPublish( auto );

Параметры.

name type description
auto boolean - true - Использовать сервисную аналитику распределения по периодам.
- false - Не использовать аналитику (равномерное распределение по нижним периодам)

Параметры ответа

result: { "addressId" : ИД торговой точки, "auto": Автоматическое распределение}

Management API

Management API предназначено для автоматизации партнёрских схем интеграции, когда партнёр сам обслуживает своих клиентов и парк их устройств.
API поддерживает JRPC 2.0-протокол вызова методов по аналогии с Service API.
Для работы небходимо знать ключ <authkey> Административного устройства с которым можно обращаться по URI: https://api.giftoman.ru/m/<authkey>


Добавление/Обновление аккаунта

Запрос позволяет зарегистрировать нового клиента и получить идентификатор магазина для дальнейшей работы с ним

setAccount( email, name, inn, phone, params );

Параметры запроса.

name type description
email string(100) Электронная почта, являющаяся первичным идентификатором в системе
name string(200) Название компании
phone string(12) Телефон. Возможные форматы:
+79223332233 - с ведущим плюсом или без,
89223332233 - будет преобразовано к Российскому коду,
8(922)333-22-33 - скобки, тире и пробелы так же принимаются
inn string(12) ИНН организации
params object Объект расширяемых (опциональных) параметров записи: {
- head (string(100)) : ФИО руководителя
- bank (string(100)) : Название банка
- kpp (string) : КПП
- okpo (string) : ОКПО
- bik (string) : БИК
- corr_account (string) : К/С
- postal_address (string) : Почтовый адрес
- legal_address (string) : Юридический адрес
- legal_name (string) : Юридическое название
- location (array) : { Уточнение локации аккаунта
-- country (string(100)) : Название страны по КЛАДР
-- city (string(100)) : Название города по КЛАДР
}

Параметры ответа

result: { "acc_id" : Идентификатор клиента }

Добавление/Обновление устройства

Запрос позволяет зарегистрировать нового клиента и получить идентификатор магазина для дальнейшей работы с ним

setCashbox( acc_id, location, id);

Параметры запроса.

name type description
acc_id uint Идентификатор клиента, полученный из Management API.setAccount()
location object Объект локации: {
- country (string(60)): Название страны по КЛАДР
- city (string(60)): Название города по КЛАДР
- street (string(100)): Название улицы по КЛАДР
- house (string(20)): Дом, включая корпуса, литеры и т.п. (например 10/1а) }
id string(100) Внешний (партнёрский) идентификатор конкретного устройства для создания уникальных устройств по адресу

Параметры ответа

result: { "id" : Идентификатор устройства, "auth_key": Ключ устройства для работы с Service API }

Установка планового значения

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

Планы устанавливаются на ту Торговую точку, где зарегистрировано данное устройство.

storePlanSet(store_ext_id, metric, plan, year, month, day );

Параметры.

name type description
store_ext_id string(20) Внешний идентификатор (на стороне Торговой системы или бэкофиса клиента)
metric string(40) Мнемоника, либо прямой идентификатор правила:
- income : Выручка
- average : Средний чек
- count : Кол-во продаж
- category : Выручка по СТМ
- complexity : Комлексность чека по кол-ву товаров
- p/<идентификатор показателя> - прямой идентификатор показателя
plan DOUBLE Если >=0, то установка планового значения = plan, если <0, то удаление
year int Год
month (необязательный) int Месяц, если не указан или = -1, то выставляется план на год
day (необязательный) int День, если не указан или = -1, то выставляется план на месяц, иначе - на день

Параметры ответа

result: { "addressId" : ИД торговой точки, "metric": Идентификатор показателя, "plan": Установленный план, "year": Год, "month" : Месяц, "day": День}

Публикация плана торговой точки

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

storePlanPublish(store_ext_id, auto );

Параметры.

name type description
store_ext_id string(20) Внешний идентификатор (на стороне Торговой системы или бэкофиса клиента)
auto boolean - true - Использовать сервисную аналитику распределения по периодам.
- false - Не использовать аналитику (равномерное распределение по нижним периодам)

Параметры ответа

result: { "addressId" : ИД торговой точки, "auto": Автоматическое распределение}

SDK для платформ

Последнее обновление: 17 Дек '15


Android SDK v0.1.0

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

Скачать пакет можно здесь https://partner.giftoman.ru/files/android.sdk.v0.1.0.zip

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


Примеры интеграции с платформами

Последнее обновление: 15 Май '16


Интеграция с 1С 8.0+

Программа 1С в процедурах взаимодействия с торговым оборудованием передаёт информацию о своих операциях в кассовый модуль Гифтоман, установленный на этом же персональном компьютере. Данные передаются путем подключения внешней библиотеки (COM-сервера) и вызова её методов.
Для корректной интеграции система должна передавать данные ТОЛЬКО в местах её неотменяемой пользователем регистрации.

Для случая 1С 7.7 используется аналогичная схема интеграции, отличающаяся методом создания COM-объекта Драйвер_Гифтоман = CreateObject(“Giftoman.ChequeApi”); и другими названиями объектов документа чека

Подключение компоненты

Подключение компоненты может проводиться как в момент инициализации окружения 1С, так и непосредственно в цикле продажи. Мы рекомендуем организовать отдельную общую процедуру для того, чтобы облегчить работу в случае потери соединения с COM-сервером.

Процедура Подключить_Гифтоман() Экспорт
        
        Попытка
                        Драйвер_Гифтоман = Новый COMОбъект("Giftoman.ChequeApi");
                        ОбщегоНазначения.ЗапишемЛогДополнительный(ПараметрыСеанса.ТекущийПользователь, "ок");
                        Прервать;
        Исключение
                        ОписаниеОшибки1 = "Не зарегистрирована библиотека Гифтоман. Обратитесь в службу технической поддержки Гифтоман.";
                        ОписаниеОшибки2 = ОписаниеОшибки();
                        Сообщение = ОписаниеОшибки1 + Символы.ПС + ОписаниеОшибки2;
        КонецПопытки;

КонецПроцедуры

Обработчик регистрации продажи

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

ИтоговаяСуммаЧека = 0;
ИтоговаяСкидкаЧека = 0;
ИтоговаяСуммаЧека = ФР.Quantity * Товар.Итог("Сумма");
ИтоговаяСкидкаЧека = Товар.Итог("СкидкаСумма");

Если ВидОперации = Перечисления.ВидыОперацийЧекККМ.Продажа Или ВидОперации = Перечисления.ВидыОперацийЧекККМ.ПродажаСертификатов Или ВидОперации = Перечисления.ВидыОперацийЧекККМ.Депозит Тогда
   // Прямая продажа
Иначе
    // Подготовка данных для проведения "возврата"
    ИтоговаяСуммаЧека = - ИтоговаяСуммаЧека;
    ИтоговаяСкидкаЧека = - ИтоговаяСкидкаЧека;
КонецЕсли;

После вывода чека на печать шлём данные в модуль Гифтоман

Если ИтоговаяСуммаЧека Тогда // Только в случае ненулевого чека
    
    Подключить_Гифтоман();
    ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "Начало чека. Объект Гифтоман " + ?(Драйвер_Гифтоман <> Неопределено, "определен", "не определен") + ", сумма " + ИтоговаяСуммаЧека + ", скидка " + ИтоговаяСкидкаЧека + ", Опт " + Опт); // Лог
    Если Драйвер_Гифтоман <> Неопределено Тогда

         Попытка
               ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "Вызов PurchaseOpen");
               Драйвер_Гифтоман_Ответ = Драйвер_Гифтоман.PurchaseOpen(ИтоговаяСуммаЧека /* Сумма чека за вычетом скидки */,  "Розница" /* Продавец */);
               ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "ок"); // Лог

               Для Каждого СтрокаТовара Из Товар Цикл
                        НаименованиеПозиции = СтрокаТовара.Номенклатура.Код1С + "; " + СтрокаТовара.Номенклатура;
                        Драйвер_Гифтоман.PurchaseAddItem(НаименованиеПозиции, СтрокаТовара.Количество, СтрокаТовара.Сумма, "");
               КонецЦикла;

               ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "Вызов PurchaseClose"); // Лог
               Драйвер_Гифтоман.PurchaseClose(); // Закрытие чека и отправка данных в Гифтоман
               ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "ок"); // Лог
               Прервать;
         Исключение // Обработка в случае потери связи с COM-сервером
               Сообщение = ОписаниеОшибки();
               ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "Вызвано Исключение: " + Сообщение);
               Подключить_Гифтоман();
         КонецПопытки;
		 
    КонецЕсли;
    ОбщегоНазначения.ЗапишемЛогДополнительный(Кассир, "Конец чека."); // Лог
КонецЕсли;

Интеграция с IIKO

Для интеграции с IIKO достаточно установить готовый плагин под соответствующую версию IIKO. Плагин запускается автоматически при старте IIKO

Плагины

v3.5
v3.9
v4.2.1172
v4.2.+
v4.3+
v4.4+

Установка до версии iiko 4.3

Для установки на главную кассу скопируйте содержимое архива плагина в папку:

  • C:\Program Files\iikoRMS\Front.Net\Plugins\ - для Windows XP / POS Ready 2009
  • C:\Program Files (x86)\iikoRMS\Front.Net\Plugins\ - для Windows 7 / POS Ready 7 / 8

Установка начиная с версии iiko 4.3

Для установки на главную кассу скопируйте файл плагина Giftoman.IIKO.plugin.dll в папки (подпапку iikoWaiter необходимо создать вручную):

  • C:\Program Files\iikoRMS\Front.Net\Plugins\Giftoman - для Windows XP / POS Ready 2009
  • C:\Program Files (x86)\iikoRMS\Front.Net\Plugins\Giftoman - для Windows 7 / POS Ready 7 / 8

  • Действует правило: одна подпапка - один плагин.


    Интеграция с Frontol

    Интеграция с Frontol 4 производится через сценарий обработки продаж, настраиваемый в административной части Frontol

    Сценарии

    для v4
    для v5

    Установка для версии 4

    В экране "Скидки и сценарии" добавить сценарий для v4


    Далее открыть подменю “Скидки и сценарии” \ “Объекты” и добавить “Объект скидки”


    Указать в “Объекте скидки” созданный сценарий “Отправка данных в Гифтоман” и нажать ОК

    Конец документа.

    Методология

    Обновление 26 Дек '15


    Введение

    За основу примеров мы берём успешные внедрения в бизнесах различного уровня, построенных на активных продажах: розничная торговля, быстрое питание, рестораны, сфера услуг e.t.c.

    Наш инструмент является частью автоматизации бизнес-процессов предприятия и как всякая автоматизация направлен в первую очередь на уменьшение издержек и увеличение эффективности работы сотрудников

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

    Основная идея: эффективное использование нашего инструмента как информационного канала внутри предприятия.

    Ценность канала будет тем выше, чем адекватней передаваемый сигнал управления (KPI), поэтому все примеры методов сводятся к выбору: какой именно показатель станет задачей и мотивацией для ваших сотрудников.

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

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

    Общие положения

    Для всех вариантов KPI характерны три стимула: Социальный, Премиальный и Штрафной.

    Социальный стимул

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

    Такой вариант подходит предприятиям с низкой ротацией кадров и как следствие высокой их ценой.

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

    Премиальный стимул

    Премирование за выполнение KPI одна из самых распространённых и рабочих схем. Она же одна из самых неустойчивых перед человеческим фактором. Со стороны работодателя премия не должна быть эмоциональным фактором: только тщательный расчёт "делаешь больше - получаешь больше"

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

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

    Штрафной стимул

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

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

    Некоторые KPI поддерживают дополнительные возможности автоматизации: Автоматический прогноз, Автоматическая коррекция плана и Автоматическое планирование

    Автоматический прогноз

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

    Прогноз выручки = ( Выручка за пройденное время работы / Пройденное время работы ) * Оставшееся время работы

    Автоматическая коррекция плана

    Если торговая точка недовыполнила план "вчера", то на "сегодня" он будет автоматически скорректирован по формуле

    Коррекция на текущий день = Суммарное недовыполнение на текущий день / Количество оставшихся дней в календарном месяце.

    Система не превысит определённый лимит коррекции (по умолчанию это 20% от суммарной), чтобы сохранить достижимость и стимулироавть Продавца следовать заданной цели.

    Автоматическое планирование

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

    Мы учитываем несколько факторов в этом алгоритме :

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

    KPI: Общая выручка Автоматический прогноз Автоматическая коррекция Автоматическое планирование

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

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

    В качестве основных KPI предлагается выделять План по выручке на день и План по выручке на месяц - это основа для оперативного понимания ситуации как со стороны Продавца, так и Управляющего.

    Применимость

    Подходит абсолютно всем предприятиям как самая простая постановка задачи. Лучший вариант для предприятий, работающих на активное привлечение покупателей.

    Расчёт плановых значений

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

    План на следующий месяц = Среднемесячная выручка за 3 прошлых месяца * 110%

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


    KPI: Выручка в группе товаров Автоматический прогноз Автоматическая коррекция

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

    Применимость

    Данный метод подходит для предприятий, которые

    • Активно адаптируются под потребности рынка
    • Имеют широкий ассортимент и разделение его на ходовой и вторичный
    • Имеют ответственность перед поставщиками определённых товаров
    • Регулярно проводят акции по целевым товарам

    Расчёт плановых значений

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

    План на следующий месяц = План по общей выручке * Доля %

    Драйвер роста: когда выделенная группа товаров косвенно усиливает продажи остальных товаров:
    В таком варианте идея расчёта этого KPI практически не отличается от плана общей выручки

    План на следующий месяц = Среднемесячная выручка по группе товаров за последние 3 месяца * 110%


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

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

    Применимость

    Данный метод подходит для

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

    Расчёт плановых значений для ключевых товаров

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

    В таком случае рассчитывается порог премирования за день. Формульная основа:

    Порог премирования за день = Среднемесячное количество продаж товара за 3 месяца * 110% / 30

    Расчёт плановых значений для сопутствующих товаров

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


    Метод: переход с почасовой на сдельную оплату труда

    Есть ряд случаев, где на первое место выходит оптимизация оплаты труда: Честная сделка с Продавцом, когда вместо фиксированной оплаты труда предлагается смешанная схема фиксированная ставка + премиальная часть

    Применимость

    В первую очередь для

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

    Расчёты

    В общем случае рекомендуется брать фиксированную часть от 50% до 70% средней ставки. Далее идeт Сдельная часть и Премиальная часть.

    Сдельная часть = Средняя ставка - Фиксированная часть

    Сдельная часть рассчитывается по порогу достижения плана выбранного KPI

    Для KPI Общая выручка, Выручка в группе товаров

    Интервал сдельной части = [ 80% * Установленный план по KPI, 100% * Установленный план по KPI ]

    Для KPI Количество проданных в группе товаров

    Порог сдельной части на день = Среднемесячное количество продаваемых товаров за последние 3 мес * 110% / 30

    Тут же рассчитывается премия за проданную единицу товара не выше порога дневной сделки

    Премия за проданную единицу товара ниже порога дневной сделки = Сдельная часть / Среднемесячное кол-во продаваемых товаров за последние 3 мес

    При перевыполнении плановых значений назначается мотивирующая премия

    Премия выше порога дневной сделки = Премия за проданную единицу товара ниже порога дневной сделки * 150%


    Кассовый модуль

    Обновление 17 Янв '16


    Принцип работы

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

    Минимальные требования для работы

    Параметр Значение
    Операционная система Windows XP (SP1-SP3, PosReady 2007, PosReady 2009), Windows 7, Windows 8
    CPU 1 Ghz ARM
    RAM 512MB
    .NET Framework 4.0
    Наличие доступа в Интернет на кассе Да (проксируемый или маршрут до шлюза)
    Дополнительно Административный доступ при установке приложения

    Версия для скачивания доступна в двух вариантах: для интеграции через COM-интерфейсы
    и для версии слушателя драйвера порта

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

    Экран меню и навигация

    При первом нажатии на иконку модуля возникнет сервисный экран

    Элементы навигации

    С помощью следующих элементов навигации можно открывать нужные интерфейсы:


    1. Открытие сервисного экрана
    2. Открытие экрана KPI
    3. Открытие экрана общих показателей
    4. Сворачивание экрана обратно в иконку


    Экран KPI

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

    Блок KPI


    Вид блока KPI строится на основе нескольких параметров:

    1. Период KPI - Для какого периода считается KPI (Может быть Дневной, Недельный, Месячный, Годовой)
    2. Название KPI - Смысловое название KPI
    3. Плановое значение - цель достижения KPI, может отсутствовать
    4. Прогресс выполнения плана - Шкала достижения цели (планового значения), в случае отстутствия планового значения так же выключается
    5. Прогноз - Автоматический прогноз выполнения KPI (Работает для KPI на основе выручки)
    6. Факт - фактическое (достигнутое на момент просмотра) значение по KPI
    7. Разница/Выполнение - вычисляемое значение между Планом и Фактом


    Экран общих планов

    ---


    Панель управления

    Обновление 20 Дек '15


    Начало работы

    ---


    Мобильное приложение

    Обновление 20 Дек '15


    Начало работы

    ---