День добрый специалисты. Возникла задачка, не могу определить с чего начать.
Есть несколько магазинов (разные хозяева) и разные базы
Они хотят, что бы у них появилась общая накопительная карта. То есть приходят к одному, покупают, на карту подает бонусов допустим 10. Далее приходят к следующем и у того тоже падает бонус, допустим 20. Итого 30 Бонусов. Приходит этот покупатель к третьему и покупает у него товар на бонусы.
как отследить, что бы все знали кому возмещать потерянные деньги.В общем нужен такой вот учет. Кто чем может подскажите пожалуйста.
Есть несколько магазинов (разные хозяева) и разные базы
Они хотят, что бы у них появилась общая накопительная карта. То есть приходят к одному, покупают, на карту подает бонусов допустим 10. Далее приходят к следующем и у того тоже падает бонус, допустим 20. Итого 30 Бонусов. Приходит этот покупатель к третьему и покупает у него товар на бонусы.
как отследить, что бы все знали кому возмещать потерянные деньги.В общем нужен такой вот учет. Кто чем может подскажите пожалуйста.
По теме из базы знаний
- Обработка обмена между 1С: Розница 1.0 и Frontol с учётом скидок и накоплений
- Корректировка скидок по дисконтным картам. УТ 10.3
- Перенос остатков по дисконтным картам (картам лояльности) в УТ 11
- Поиск накопительной карты по телефону
- Функционал скидок в программе 1С:ЕRP. Дисконтные карты лояльности и отчеты анализа предоставленных скидок
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Viktor_vc, Вопрос общий, поэтому и ответ будет общим. Я бы написал небольшую конфигурацию по ведению учета по данным картам, одна ИБ на всех (с прямым доступом, или через РИБ - это уже частности внедрения) и в ней бы хранил информацию по данным картам (Держатели, баланс карты, покупки, начисления и т.п.) ну и к этой ИБ уже обращаться из Розницы при продаже товара (вносить информацию о предоставленных скидках, поступивших бонусах) ну и там уже можно будет строить отчеты о том, кто, кому и сколько должен. Либо, вместо конфигурации, можно создать какой-то веб-сервис, туда-же еще и л/кабинет держателя карты прикрепить. Суть одна - нужна некая общая ИС, к которой будут подключены все торговые точки участвующие в проекте.
(1) по идее получается некий процессинг, в идеале онлайн процессинг (иначе как отслеживать остатки бонусов).
т.е. идея такая - в бд только номера карт, данные по транзакциям хранятся на внешнем сервисе (как вариант - процессинг от штриха либо в инете простейший процессинг на пхп). далее при накоплении - списании бонусов данные берутся/пишутся на внешний процессинг например в виде от кого пришло , у кого списалось сумма карта. все остальное просто.
Если нужен бюджетный вариант - можно реализовать через xml сумматор и регламентное задание.
т.е. идея такая - в бд только номера карт, данные по транзакциям хранятся на внешнем сервисе (как вариант - процессинг от штриха либо в инете простейший процессинг на пхп). далее при накоплении - списании бонусов данные берутся/пишутся на внешний процессинг например в виде от кого пришло , у кого списалось сумма карта. все остальное просто.
Если нужен бюджетный вариант - можно реализовать через xml сумматор и регламентное задание.
я бы сделал так:
1. регистр накопления - "движения бонусов"(измерение - штрихкод карты, ресурс-сумма), регистратор - новый созданный документ "начисление-списание бонусов"
2. подписки на события(чек ккм или реализация при записи), которые создают документ "начисление-списание" и движения расход или приход в зависимости от вида документа, так же предусмотривая пометку удаления и отмену проведения (эти основные реквизиты должны у документа источника и подчиненного совпадать)
3. если конфигурации идентичны-тогда замутил бы что-нибудь с РИБом- создал бы план обмена, с этим регистром и регистратором, но здесь вопрос сложный, такого еще не мутил ни разу не знаю даже как это могло бы выглядить
1. регистр накопления - "движения бонусов"(измерение - штрихкод карты, ресурс-сумма), регистратор - новый созданный документ "начисление-списание бонусов"
2. подписки на события(чек ккм или реализация при записи), которые создают документ "начисление-списание" и движения расход или приход в зависимости от вида документа, так же предусмотривая пометку удаления и отмену проведения (эти основные реквизиты должны у документа источника и подчиненного совпадать)
3. если конфигурации идентичны-тогда замутил бы что-нибудь с РИБом- создал бы план обмена, с этим регистром и регистратором, но здесь вопрос сложный, такого еще не мутил ни разу не знаю даже как это могло бы выглядить
Был опыт реализации подобной системы. В центре стояла небольшая конфигурация, которая посредством веб сервиса "общалась" с магазинами. По запросу из магазина отдавались данные у кого сколько баллов и принимались данные о списаниях.
От себя добавлю - обязательно продумайте все до мельчайших деталей. Тут ключевой момент - оперативность обновления данных в центре чтобы, например, не списали бонусы 2 раза.
Ну и обязательно с бухгалтерами все обсудите.
От себя добавлю - обязательно продумайте все до мельчайших деталей. Тут ключевой момент - оперативность обновления данных в центре чтобы, например, не списали бонусы 2 раза.
Ну и обязательно с бухгалтерами все обсудите.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот