Предложения по улучшению функционала GameKeeper

[Hendehog]

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


Предложения:
1) Добавить возможность завершать тарификации на кассе которые были открыты на контроллере.
2) Добавить возможность обнулять карты клиент по одной или массово (с указанием интервала номеров например) , или по заданным параметрам, например "Обнулить все карты с балансом менее < x " .
Очень много клиентов не гасят свой минус, и все карты приходится обнулять через SQL.
3) Добавить возможность при создании товаров в зонах, работать массово с товарами.
Предположим я завел игротеку, завел в ней 50 видом мягких игрушек, завел их в папку Мягкие игрушки, и мне приходится Статус (Активен - Не активен) ,и Категорию на каждый товар выставлять вручную. Можно было бы и кнопку массового выделения сделать, было бы очень удобно.
4) Добавить возможность создавать контроллер для проверки баланс в реальном времени(онлайн режим) , способ реализации я Сергею уже предлагал.
Можно сделать просто, человек вошел в зону, покатался 15 минут в ней подъехал к контроллеру проверки баланса, провел картой (система посмотрела когда он вошел, система посмотрела когда провели картой, система посмотрела период и стоимость минуты и простой математической формулой все посчитала и вывела циферки на экран , для этого в БД даже ничего нового UCS по сути делать ничего и не надо, просто запрос , и возможность выставлять режим назовем например "Тарификация Проверка Баланса" .
5) Добавить возможность авторизации на кассе без магнитной карты по Коду и Паролю , да- да ( По типу RK-7 ), на самом деле очень важная функция, часто когда подключишься удаленно на кассу , в программу без участия кассира не войти , не совсем это удобно.
6) Исправить баг версии 3,25, если выставить Минимальный баланс входа, то технический персонал не пускает если на карте нету этого баланса.
7) Добавить возможность сохранения всех настроек GKeditor , (По типу как в маршрутизаторах) , если вдруг, что произошло, выбрал нужный save и он все настройки восстановил, очень полезная штука, предусмотрительная я бы сказал =)
8) Добавить отчетность по кассовым операциям (возможно я что-то не знаю) , но я нигде не видел отчета По Х и З - отчетам.
В R-keeper это называется кассовый протокол, здесь подобного ничего нету .
9) Предлагаю доделать до ума механизм приостановки тарификации , сейчас в версии 3,25 можно выставить время за которое клиент должен погасить минус, это круто конечно, но многие клиенты не гасят свои минуса и уходят а карта продолжает уходить в огромный минус и ее приходится обнулять а таких карт много.
Было бы неплохо сделать возможность замораживать минусовой баланс, клиент выходит у него недостаточно очков , заморозили баланс и все.
Придет в следующий раз покататься , ему придется его погасить , при этом сумму с него потребуют реальную и вменяемую а не та огромная сумма, что в нынешнем раскладе накапает за время его отсутствия.

[sibgaba]

Все это хорошо, и наверное очень востребовано для вашего объекта. Но...

Мы сделали (и обслуживаем) 4 разных РЦ на GK (от 200 до 50 контроллеров в каждом).
Ни одна из описанных вами доработок там не нужна.
А некоторые, на мой взгляд, даже вредны, в тех реалиях в которых работают эти объекты...

Ну т.е. если оно там будет реализовано, то пусть будет. А что то (например, авторизацию по коду с клавиатуры) я бы и вообще отключил!

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

[Hendehog]

Все это хорошо, и наверное очень востребовано для вашего объекта. Но...

Мы сделали (и обслуживаем) 4 разных РЦ на GK (от 200 до 50 контроллеров в каждом).
Ни одна из описанных вами доработок там не нужна.
А некоторые, на мой взгляд, даже вредны, в тех реалиях в которых работают эти объекты...

Ну т.е. если оно там будет реализовано, то пусть будет. А что то (например, авторизацию по коду с клавиатуры) я бы и вообще отключил!

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


Если бы по пунктам написал, что не так, тогда бы можно было о чем-то говорить.
Вот вы обслуживаете много торговых центров , неужели вы не сталкивались с ручным обнулением минусовых карт?
Ну хотя бы так для примера?
Неужели клиент не имеет право посмотреть сколько у него денег осталось во время катания на ледовом катке?
Неужели нормально, что при недостатке средств для выхода карты уходят в огромнейшие минуса?
Все эти пункты ни из головы придуманы. А из реалий.
Количество ТЦ это вообще не показатель.
Может у вас там одни автоматы игровые стоят, тк для этого конечно никаких апгрейдов не надо.
Та же онлайн тарификация судя по этому форуму как минимум еще одному человеку нужна была.

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

[sibgaba]

Да не кипятитесь вы так...
Для меня GK - это средство для автоматизации Игровых центров. Это те самые игровые аппараты о которых вы и говорите, плюс аттракционы (берется плата за вход).

Для задач по автоматизации катков и тому подобное используем Абонемент-Менеджер. Он гораздо лучше заточен под те задачи о которых говорите Вы.
По пунктам:


1) Добавить возможность завершать тарификации на кассе которые были открыты на контроллере.
В Абонементе это делается элементарно и более того, доступ к этой функции определяется правами юзера.


2) Добавить возможность обнулять карты клиент по одной или массово
На выходе, в зависимости от настроек, турникет либо не выпустит гостя, либо выпустит и администратор должен будет списать образовавшийся долг на убытки либо оставить минус за гостем. И это гораздо правильнее чем обнуление через SQL запрос, т.к. все остается в отчетах, понятно с кого спрашивать и видно сколько нам не доплатили (если уже списали на убытки) и видно сколько нам должны (если есть долги не списанные).


3) Добавить возможность при создании товаров в зонах, работать массово с товарами.
На вскидку не помню есть ли это в Абонементе, но особых проблем с ведением списка товаров там не было. А призотеки в детских игровых центах делаем на Кипере.


4) Добавить возможность создавать контроллер для проверки баланс в реальном времени(онлайн режим)
Инфокиоск в Абонементе. Там тебе и баланс, и оставшееся время и перечень всех внесений/потрат...


5) Добавить возможность авторизации на кассе без магнитной карты по Коду и Паролю
В Абонементе вход в программу через логин/пароль.
Ручная авторизация "как в RK7" мне лично не нравится тем что персонал может подсмотреть админский пароль, воспользоваться этим, а потом доказывай что ты не верблюд. Случаи уже были и отмазаться удалось только при помощи видеонаблюдения.


6) Исправить баг версии 3,25, если выставить Минимальный баланс входа,
В Абонементе, для сотрудников заводятся спец тарифы и все...


7) Добавить возможность сохранения всех настроек GKeditor
Не совсем понял о каких настройках идет речь. Но в любом случае они либо в файле хранятся, либо в реестре. Бекапить одно и другое труда не составит...


9) Предлагаю доделать до ума механизм приостановки тарификации
Там (в Абонементе) функционала по этой теме - чуть больше чем дофига...



Критика должна быть конструктивной.
Разобранной по полочкам и пунктам.Это плохо потому что ..., я думаю Это не нужно потому-что ...
Итого. Я понимаю что наверное не вы определяли какое ПО использовать для автоматизации и наверное из за описанных проблем ваши объекты не пойдут на замену ПО, но эта ошибка вряд ли может служить весомым поводом (для UCS) что бы загонять функционал Абнемента в GK...

[Hendehog]

Да не кипятитесь вы так...
Для меня GK - это средство для автоматизации Игровых центров. Это те самые игровые аппараты о которых вы и говорите, плюс аттракционы (берется плата за вход).

Для задач по автоматизации катков и тому подобное используем Абонемент-Менеджер. Он гораздо лучше заточен под те задачи о которых говорите Вы.
По пунктам:


В Абонементе это делается элементарно и более того, доступ к этой функции определяется правами юзера.


На выходе, в зависимости от настроек, турникет либо не выпустит гостя, либо выпустит и администратор должен будет списать образовавшийся долг на убытки либо оставить минус за гостем. И это гораздо правильнее чем обнуление через SQL запрос, т.к. все остается в отчетах, понятно с кого спрашивать и видно сколько нам не доплатили (если уже списали на убытки) и видно сколько нам должны (если есть долги не списанные).


На вскидку не помню есть ли это в Абонементе, но особых проблем с ведением списка товаров там не было. А призотеки в детских игровых центах делаем на Кипере.


Инфокиоск в Абонементе. Там тебе и баланс, и оставшееся время и перечень всех внесений/потрат...


В Абонементе вход в программу через логин/пароль.
Ручная авторизация "как в RK7" мне лично не нравится тем что персонал может подсмотреть админский пароль, воспользоваться этим, а потом доказывай что ты не верблюд. Случаи уже были и отмазаться удалось только при помощи видеонаблюдения.


В Абонементе, для сотрудников заводятся спец тарифы и все...


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


Там (в Абонементе) функционала по этой теме - чуть больше чем дофига...



Итого. Я понимаю что наверное не вы определяли какое ПО использовать для автоматизации и наверное из за описанных проблем ваши объекты не пойдут на замену ПО, но эта ошибка вряд ли может служить весомым поводом (для UCS) что бы загонять функционал Абнемента в GK...

Я спокоен как удав:)Просто объяснил, что критика без объяснений мне непонятна.
1.Какими правами юзера? UCS сообщает, что закрытие тарификации на кассе возможно только если эта тарификация на кассе была открыта.
Если вы про абонемент который активируется непосредственно с кассы , на том же Ледовом Катке такой вариант не подойдет, вы просто не стояли за кассой в выходные дни.
2.На выходе турникет не выпустит гостя, и в новой версии он даст ему в течении заданного установленного времени погасить долг заморозив на это заданное время тарификацию. Если гость долг не гасит, тарификация продолжается до бесконечности.
А я говорю, что нужно просто замораживать тарификацию, и продолжать ее потом нет смысла , и плодить огромные минуса.
3.Проблем то там нету, мои предложения состоян не в исправлении багов а в улучшении программы, чтобы сделать ее удобнее для конечно пользователя. Вот я недавно забивал около 180 позиций, на каждой ставить галку Активен, и Категорию это очень неудобно, а вот если бы я смог массово для нужной папки одним кликом это сделать, сэкономил бы кучу времени.
4.Интересно, в какое место внутри Ледового Катка вы поставите инфокиоск и как быстро его вам сломают?
Контроллер мы в борт примастырили, и то напряжно провода прятать, там же люди на коньках ходят.
А Инфокиоск...
5.Я думаю сам человек должен сугубо лично решать юзать ему карту или логин с паролем?:)
А, по поводу безопасности , я же написал для каких целей я это вижу например.
6. О каких спецтарифах вы говорите? У нас у сотрудников у всех спецтариф по нулевой цене.
Разговор о том, что Минимальный баланс входа действует на любые тарифы.
И UCS про этот баг знают!
7. О всех настройках Эдитора.
9. http://abonement.ucs.ru/ вы об этом?

А вот с последним не согласен , то, что UCS мягко говоря пофигу , это я в курсе )
Но система GameKeeper , если включает в себя функциональные возможности тарифицируемого доступа , значит предусматривалась не только, чтобы жетоны бросать:)ИМХО.
Спасибо за развернутую критику.

[sibgaba]

1.Какими правами юзера? UCS сообщает, что закрытие тарификации на кассе возможно только если эта тарификация на кассе была открыта.
В Абонементе


Если вы про абонемент который активируется непосредственно с кассы , на том же Ледовом Катке такой вариант не подойдет, вы просто не стояли за кассой в выходные дни.
Тарификация по проданному абонементу начинается автоматически при проходе через турникет (это я опять про ПО Абонемент Менеджер)


2.На выходе турникет не выпустит гостя,
Все что я говорил - это про Абонемент Менеджер!


4.Интересно, в какое место внутри Ледового Катка вы поставите инфокиоск и как быстро его вам сломают?
Над бортом.
Антивандальные киоски (аналогичные киоскам по приему платежей в переходе на улице) прекрасно это выдержат.
Да, согласен, цена будет другая, но и уровень сервиса для гостя на порядок выше.


6. О каких спецтарифах вы говорите?
О спец тарифах в ПО Абонемент-Менеджер


9. http://abonement.ucs.ru/ вы об этом?
В точичности!!!


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

[Hendehog]

В Абонементе


Тарификация по проданному абонементу начинается автоматически при проходе через турникет (это я опять про ПО Абонемент Менеджер)


Все что я говорил - это про Абонемент Менеджер!


Над бортом.
Антивандальные киоски (аналогичные киоскам по приему платежей в переходе на улице) прекрасно это выдержат.
Да, согласен, цена будет другая, но и уровень сервиса для гостя на порядок выше.


О спец тарифах в ПО Абонемент-Менеджер


В точичности!!!


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

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

[olegash]

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


Предложения:
1) Добавить возможность завершать тарификации на кассе которые были открыты на контроллере.
2) Добавить возможность обнулять карты клиент по одной или массово (с указанием интервала номеров например) , или по заданным параметрам, например "Обнулить все карты с балансом менее < x " .
Очень много клиентов не гасят свой минус, и все карты приходится обнулять через SQL.
3) Добавить возможность при создании товаров в зонах, работать массово с товарами.
Предположим я завел игротеку, завел в ней 50 видом мягких игрушек, завел их в папку Мягкие игрушки, и мне приходится Статус (Активен - Не активен) ,и Категорию на каждый товар выставлять вручную. Можно было бы и кнопку массового выделения сделать, было бы очень удобно.
4) Добавить возможность создавать контроллер для проверки баланс в реальном времени(онлайн режим) , способ реализации я Сергею уже предлагал.
Можно сделать просто, человек вошел в зону, покатался 15 минут в ней подъехал к контроллеру проверки баланса, провел картой (система посмотрела когда он вошел, система посмотрела когда провели картой, система посмотрела период и стоимость минуты и простой математической формулой все посчитала и вывела циферки на экран , для этого в БД даже ничего нового UCS по сути делать ничего и не надо, просто запрос , и возможность выставлять режим назовем например "Тарификация Проверка Баланса" .
5) Добавить возможность авторизации на кассе без магнитной карты по Коду и Паролю , да- да ( По типу RK-7 ), на самом деле очень важная функция, часто когда подключишься удаленно на кассу , в программу без участия кассира не войти , не совсем это удобно.
6) Исправить баг версии 3,25, если выставить Минимальный баланс входа, то технический персонал не пускает если на карте нету этого баланса.
7) Добавить возможность сохранения всех настроек GKeditor , (По типу как в маршрутизаторах) , если вдруг, что произошло, выбрал нужный save и он все настройки восстановил, очень полезная штука, предусмотрительная я бы сказал =)
8) Добавить отчетность по кассовым операциям (возможно я что-то не знаю) , но я нигде не видел отчета По Х и З - отчетам.
В R-keeper это называется кассовый протокол, здесь подобного ничего нету .
9) Предлагаю доделать до ума механизм приостановки тарификации , сейчас в версии 3,25 можно выставить время за которое клиент должен погасить минус, это круто конечно, но многие клиенты не гасят свои минуса и уходят а карта продолжает уходить в огромный минус и ее приходится обнулять а таких карт много.
Было бы неплохо сделать возможность замораживать минусовой баланс, клиент выходит у него недостаточно очков , заморозили баланс и все.
Придет в следующий раз покататься , ему придется его погасить , при этом сумму с него потребуют реальную и вменяемую а не та огромная сумма, что в нынешнем раскладе накапает за время его отсутствия.+1
10. Сделать "сгорание" бонусов через определенное время.



Итого. Я понимаю что наверное не вы определяли какое ПО использовать для автоматизации и наверное из за описанных проблем ваши объекты не пойдут на замену ПО, но эта ошибка вряд ли может служить весомым поводом (для UCS) что бы загонять функционал Абнемента в GK...Вы предлагаете заменить GK Абонементом? Тогда уж эти 2 программы надо слить в одну. Ибо услуги ИЦ постоянно расширяются и получается, что одной программой не обойтись. Не сильно знаком с Абонементом, но подозреваю, что им нельзя полностью заменить GK на, например 100 ИА.
Очень жаль, что уважаемые старожилы этого форума всегда защищают софт UCS - типа там все правильно и красиво и ничего большего не надо, а, если вам (и клиентам) что то надо большего, так это бизнес у вас не правильный. Переделывайте его под продукты UCS. В корне не соглашусь с таким подходом. С одной стороны можно понять. В UCS достаточно стабильно работает только базовый функционал - шаг в сторону куча глюков. Да и настраивать\поддерживать примитивную программу легче. Но это не значит, что это не нужно бизнесу.
ПыСы. Тема поднята правильная, но имхо бесполезная. Не будет UCS прислушиваться к хотелкам простых смертных.

---------- Добавлено в 19:59 ---------- Предыдущее сообщение было размещено в 19:24 ----------


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

---------- Добавлено в 20:00 ---------- Предыдущее сообщение было размещено в 19:59 ----------


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


4) Добавить возможность создавать контроллер для проверки баланс в реальном времени(онлайн режим)



Инфокиоск в Абонементе. Там тебе и баланс, и оставшееся время и перечень всех внесений/потрат...Так это и в GK есть, но цена непомерная. Нужен более простой вариант со считывателем.

---------- Добавлено в 20:04 ---------- Предыдущее сообщение было размещено в 20:00 ----------


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


4) Добавить возможность создавать контроллер для проверки баланс в реальном времени(онлайн режим)



Инфокиоск в Абонементе. Там тебе и баланс, и оставшееся время и перечень всех внесений/потрат...Так это и в GK есть, но цена непомерная. Нужен более простой вариант со считывателем.


7) Добавить возможность сохранения всех настроек GKeditor , (По типу как в маршрутизаторах) , если вдруг, что произошло, выбрал нужный save и он все настройки восстановил, очень полезная штука, предусмотрительная я бы сказал =)Если я правильно понимаю, что вы хотите, то бэкап MSSQL базы+скрипт очистки базы. Как в роутере навряд ли получится уж очень много связей.

[SH]

Очень жаль, что уважаемые старожилы этого форума всегда защищают софт UCS - типа там все правильно и красиво и ничего большего не надо
Это неправда. Критики тут навалом. Но и обоснованно критиковать чужую критику мы тоже любим.


Тема поднята правильная, но имхо бесполезная. Не будет UCS прислушиваться к хотелкам простых смертных.
Правда, но не совсем. Помимо того, что тут полно "непростых" смертных, здесь еще и непосредственные представители UCS есть. Поэтому, внятно аргументированная тема имеет шанс быть перемещенной на трекер. И я считаю, здесь обсудить полезно, ибо это позволит донести очищенную от шелухи и заблуждений информацию.

Так что - чем пытаться обвинить, что никому ничего не надо, попробуйте вначале своих коллег убедить в своей правоте. Иначе UCS никогда не убедить.

[olegash]

здесь еще и непосредственные представители UCS есть.Ну представители, естественно обвинят "в глубоком не понимании процессов..." на этом все закончится. Как уже писали на этом форуме "толку от техподдержки GK ноль" (не совсем так, конечно, иногда реально помогают, ну так как по другому, если тех. документации практически нет). Вопросы задаваемые на трекере UCS зачастую остаются без ответов (многие параметры настройки никак не документированы, некоторые ответы техподдержки о работе тех или иных функций противоречат друг другу). Новый серьезный функционал добавлять вряд ли будут, ибо велика вероятность получить кучу глюков (тот же мин. баланс входа правильно не работает). Т. е. создается впечатление, что легче как с RK6 - написать новую программу, а старую объявить "пробой пера". И сначала продумать все бизнес-процессы, требующиеся ИЦ (с возможностью масштабируемости и добавления нового функционала), а потом закодить все это, а не наоборот. Не хочу грубить, но кодеров в UCS по всей видимости много, а вот программистов очень мало.

---------- Добавлено в 20:45 ---------- Предыдущее сообщение было размещено в 20:40 ----------


здесь еще и непосредственные представители UCS есть.Ну представители, естественно обвинят "в глубоком не понимании процессов..." на этом все закончится. Как уже писали на этом форуме "толку от техподдержки GK ноль" (не совсем так, конечно, иногда реально помогают, ну так как по другому, если тех. документации практически нет). Вопросы задаваемые на трекере UCS зачастую остаются без ответов (многие параметры настройки никак не документированы, некоторые ответы техподдержки о работе тех или иных функций противоречат друг другу). Новый серьезный функционал добавлять вряд ли будут, ибо велика вероятность получить кучу глюков (тот же мин. баланс входа правильно не работает). Т. е. создается впечатление, что легче как с RK6 - написать новую программу, а старую объявить "пробой пера". И сначала продумать все бизнес-процессы, требующиеся ИЦ (с возможностью масштабируемости и добавления нового функционала), а потом закодить все это, а не наоборот. Не хочу грубить, но кодеров в UCS по всей видимости много, а вот программистов очень мало.


Это неправдаПравда-правда :) Но это я думаю разговор для другой темы....

[NeiroN]

Идея полностью переписать этот Game Keeper не покидает меня, но я ограничиваюсь лишь нужными мне приложениями.
Хотите забивать кучу товаров по категориям - прямо из экселевского файла?
Без проблем - можно написать стороннюю программу, раз они не хотят.
Может ваш штатный админ напишет? Там не нужно никаких суперпознаний в программировании - обычная работа с базой данных. Анализируешь входные данные и отправляешь кучу запросов.

Я к примеру сделал программу для восстановления магнитной полосы на картах - через записывающий MSR206 девайс. Ввел номер, провел картой, готово.

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

UPDATE [gkArcade].[gk].[GK_CARDS] SET [Bonus] = 0 WHERE DATEADD(day,90,[CardLastUse]) < GETDATE()
Если картой не пользоваться 90 дней - бонусы сгорают.

[olegash]

11. Возможность удаленной заливки прошивок на ZB контроллеры и ТД. Без программатора.
12. Сохранять настройки (Адрес, канал, PAN ID) при перепрошивке.

[sibgaba]

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

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

Хорошо если кассир вспомнит про сгорание через 90 дней и сможет "на пальцах" объяснить гостю что к чему. Но кассир этого не сделает, а особенно в случае когда внесений бонусных было много и часть из них уже просрочена...

[Hendehog]

Респект за знание структуры БД и SQL, но...

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

Хорошо если кассир вспомнит про сгорание через 90 дней и сможет "на пальцах" объяснить гостю что к чему. Но кассир этого не сделает, а особенно в случае когда внесений бонусных было много и часть из них уже просрочена...

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

[NeiroN]

да с этими отчетами вообще бида - UCS для чего то придумали две таблицы с транзакциями. Люди знающие SQL при желании смогут все это организовать. Если бы не лень я бы даже написал вам его - там надо использовать курсор.

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

[NeiroN]

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

Первая для получения значения бита из переменной с областью значений байта (254...0):

CREATE FUNCTION [gk].[GetBit] (@val int,@bit int) RETURNS bit AS
BEGIN
DECLARE @out bit = 0
DECLARE @i int = 7
WHILE @i >= 0 BEGIN
IF(@val >= POWER(2,@i)) BEGIN
SET @val -= POWER(2,@i)
IF(@i = @bit)BEGIN SET @out = 1 END
END
SET @i -= 1
END
RETURN @out
END

И вторая сама проверка периода, возвращает число совпавших интервалов в данном периоде - ноль если нет совпадений. Если периоды составлены из не пересекающихся временнных интервалов то будет возвращать 1 если период действителен.


CREATE FUNCTION [gk].[CheckPeriod] (@period int) RETURNS int AS
BEGIN
DECLARE @TIME int = DATEPART(HOUR, GETDATE())*60 + DATEPART(MINUTE, GETDATE())
DECLARE @out int = (SELECT count(*)
FROM [gkArcade].[gk].[PERIODDETAILS]
WHERE ([PERIOD] = @period)AND([STATUS] = 3)AND(IIF(([STARTTIME]<= @TIME)AND([ENDTIME] >= @TIME),32*gk.GetBit([DATEFLAGS],5),0)+
IIF((gk.Getbit([DAYSOFWEEK],DATEPART(weekday,GETDATE())) = 1),gk.GetBit([DATEFLAGS],0),0)+
IIF(([STARTDATE]<=GETDATE())AND([ENDDATE]>=GETDATE()),16*gk.GetBit([DATEFLAGS],4),0)+
IIF((DATEADD(year,YEAR(GETDATE())-YEAR([STARTDATE]),[STARTDATE])<=GETDATE())AND(DATEADD(year,YEAR(GETDATE())-YEAR([ENDDATE]),[ENDDATE])>=GETDATE())AND(gk.GetBit([DATEFLAGS],3)=1),8*gk.GetBit([DATEFLAGS],3)+4*gk.GetBit([DATEFLAGS],2)+2*gk.GetBit([DATEFLAGS],1),0)+
IIF((DAY([STARTDATE])<=DAY(GETDATE()))AND(DAY([ENDDATE])>=DAY(GETDATE()))AND(gk.GetBit([DATEFLAGS],3) = 0)AND(gk.GetBit([DATEFLAGS],4) = 0),6*gk.GetBit([DATEFLAGS],1)*gk.GetBit([DATEFLAGS],2),0) = [DATEFLAGS] ))
RETURN @out
END

Пример:
SELECT * FROM [gkArcade].[gk].[GK_BONUSES] WHERE [gkArcade].[gk].CheckPeriod([PERIOD])>0
Покажет ВСЕ действующие по времени бунусы.

И код обнуляющий бонусы с транзакциями - через курсор
Считается что ид 2 у пользователя админ - транзакции от его имени

DECLARE @CARD int
DECLARE @Level int
DECLARE @Bonus money
DECLARE upd CURSOR READ_ONLY FOR
SELECT [CARD],[Bonus],[Level] FROM [gkArcade].[gk].[GK_CARDS]
WHERE DATEADD(day,90,[CardLastUse]) < GETDATE() --карты не активные 90
OPEN upd
FETCH NEXT FROM upd INTO @CARD,@Bonus,@Level
WHILE (@@FETCH_STATUS <> -1) BEGIN --Операция "Списание бонусов" ид 850
INSERT INTO [gkArcade].[gk].[TRANSACTS] ([DATE],[ACCOUNT],[EMPLOYEE],[ACTIVITY],[VALUE1],[UNIT1],[VALUE2],[UNIT2],[QUANT],[CREATOR],[CREATORADDR],[CREATORDATE],[CARD],[DEAL],[CheckItem])
VALUES(GETDATE(),@CARD,2,850,1,401,@BONUS,401,1,1, 1,GETDATE(),@CARD,NULL,0)
INSERT INTO [gkArcade].[gk].[GK_TRANSACTS]([DATE],[ACTIVITY],[CARD],[ACCOUNT_TYPE],[VALUE],[QUANT],[CREATOR],[CREATORADDR],[DEAL],[CHECK_ITEM],[EMPLOYEE],[LEVEL],[ARCADE],[GUID],[TRANSACT_GUID])
VALUES(GETDATE(),850,@CARD,2,-@BONUS,0,1,1,NULL,0,2,@Level,1,newid(),newid())
-- обнуляем бонус
UPDATE [gkArcade].[gk].[GK_CARDS] SET [Bonus] = 0 WHERE [Card]=@CARD
FETCH NEXT FROM upd INTO @CARD,@Bonus,@Level
END
CLOSE upd

Надеюсь данный код поможет вам реализовать вашу бизнеслогику не входящую в функционал Game Keeper

[Hendehog]

Собрал воедино и отправил в UCS , все предложения.
Ответили как ни странно.


Выделю главное​, без воды.

Александр.

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

Некоторые комментарии в пожеланиям ниже.

Предложения:
1) Добавить возможность завершать тарификации на кассе которые были открыты
на контроллере.
2) Добавить возможность обнулять карты клиента по одной или массово (с
указанием интервала номеров например) , или по заданным параметрам, например
"Обнулить все карты с балансом менее < x " .
Очень много клиентов не гасят свой минус, и все карты приходится обнулять
через SQL.

Ответ UCS
Обнуление карт реализовано не будет. Предварительно принцип планируется
следующим. Незакрытие тарификации будут автоматически закрываться в конце
дня со списанием средств за полное время тарификации. Если баланс карт при
этом будет уходить в минус, то разница
Будет храниться отдельно для возможности получения отчёта по этим данным.

8) Добавить отчетность по кассовым операциям (возможно я что-то не знаю) ,
но я нигде не видел отчета По Х и З - отчетам.
В R-keeper это называется кассовый протокол, здесь подобного ничего нету .

Ответ UCS
Планируется добавить в версии 3.27. Но следует учитывать, что принципы
работы R-Keeper и Game-Keeper разные. Не все, что логично для одной системы
логично для другой.

9) Предлагаю доделать до ума механизм приостановки тарификации , сейчас в
версии 3,25 можно выставить время за которое клиент должен погасить минус,
это круто конечно, но многие клиенты не гасят свои минуса и уходят а карта
продолжает уходить в огромный минус и ее приходится обнулять а таких карт
много.
Было бы неплохо сделать возможность замораживать минусовой баланс, клиент
выходит у него недостаточно очков , заморозили баланс и все.
Придет в следующий раз покататься , ему придется его погасить , при этом
сумму с него потребуют реальную и вменяемую а не та огромная сумма, что в
нынешнем раскладе накапает за время его отсутствия.
10) Добавить возможность сгорания бонусов через определенное время
(опционально)

Ответ UCS
В планах сделать время жизни бонусов.

11)Возможность удаленной заливки прошивок на ZB контроллеры и ТД. Без
программатора.
Ответ UCS
В разработке сейчас.

12)Сохранять настройки (Адрес, канал, PAN ID) при перепрошивке.
13)Расширить работу с зонами - на каждую зону , сделать возможность
настраивать свое приветствие, и свои настройки (Игровой зал)

Ответ UCS
Пока не планируется.

14) Расширить возможности бонусной системы - разделение по зонам ,
разделение по уровням
15) Добавить возможность в GknetMonitor видеть версию прошивки контроллера
16) Добавить возможность скидок в ту же бонусную систему ( как в 6 Кипере по
аналогу)

Ответ UCS
Game-Keeper не скидочная система. "Скидки" реализуются управлением тарифами.

18) Добавить возможность админам, самим создавать валюты и называть их как им угодно
Сейчас существует Наличные,Кредитные Карты, Пластиковые карты - неудобно кассирам!!!
Ну и само собой, задавать куда будет новая валюта отбиваться в Кредит или в Наличные.

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

[NeiroN]

Еще в "Редакторе" ,как и писали, неплохо бы групповое управление ценами(RULES) - чтобы можно было скопировать с других уровней, изминив цену на число или процент, задав определенный временной период. Я вначале мучался вручную(в редакторе) - потом начал писать на SQL запросы для этого. А как быть другим? Думаю там должно быть групповое управление и кнопки "Копировать", "Вставить" - вобщем чтобы удобно было...

[Hendehog]

Еще в "Редакторе" ,как и писали, неплохо бы групповое управление ценами(RULES) - чтобы можно было скопировать с других уровней, изминив цену на число или процент, задав определенный временной период. Я вначале мучался вручную(в редакторе) - потом начал писать на SQL запросы для этого. А как быть другим? Думаю там должно быть групповое управление и кнопки "Копировать", "Вставить" - вобщем чтобы удобно было...

Написал и об этом =)

[NeiroN]

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

Для этого есть решение - в базе сделать триггер, который будет при пополнении баланса начислять бонус. Как связать бонусы с уровнем? Можно воспользоваться полем "Код", оно доступно прямо в редакторе и есть почти у всех основных объектов. Поле код у уровня должно при этом быть частью поля код у бонуса: "L01" у уровня и "L01_b01" у бонуса для этого уровня. В запросе мы заведем переменную,в которую будем получать содержимое поля код у уровня и использовать его в фильтре при выборе бонусов. Чтобы бонусы работали в альтернативном режиме - их надо отключить изменяя статус на "Неактивен"

USE [gkArcade]
GO

CREATE TRIGGER [gk].[GK_TRANSACT_TRIGGER]
ON [gk].[GK_TRANSACTS]
AFTER INSERT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DECLARE @ACT int = (SELECT [ACTIVITY] FROM inserted)
DECLARE @TYPE int = (SELECT [ACCOUNT_TYPE] FROM inserted)
DECLARE @CARD int = (SELECT [CARD] FROM inserted)
DECLARE @Level int = (SELECT [Level] FROM [gk].[GK_CARDS] WHERE [Card] = @CARD)
-- Insert statements for trigger here
IF (@ACT >= 901 AND @ACT <= 919)AND @TYPE = 31 BEGIN --пополнение баланса
DECLARE @VALID smalldatetime = (SELECT [ValidFor] FROM [gk].[GK_CARDS_EX] WHERE [Card] = @CARD)
DECLARE @maxdays int = 1 --число дней от дня рождения. в итоге: день до, день рождения, день после (+/- 1 день)
DECLARE @BONUS money
DECLARE @PAY money = (SELECT [VALUE] FROM inserted)
DECLARE @LC varchar(10) = (SELECT [CODE] FROM [gk].LEVELS WHERE [LEVEL]=@Level) --получаем код уровня
DECLARE @BIRTH int = --количество людей по данной карте у которых день рождения
(SELECT count(*) FROM [gk].[GK_CARDS_CHILDS] --найдем всех детей
WHERE ABS(DATEDIFF(day,GETDATE(),DATEADD(year,YEAR(GETDA TE())-YEAR([Birthday]),[Birthday]))) <= @maxdays
AND [CARD] = @CARD) +
(SELECT count(*) FROM [gkArcade].[gk].[GK_CARDS_EX] --и владельца
WHERE ABS(DATEDIFF(day,GETDATE(),DATEADD(year,YEAR(GETDA TE())-YEAR([Birthday]),[Birthday]))) <= @maxdays
AND [CARD] = @CARD)
IF @BIRTH = 0 BEGIN -- если ни у кого нет дня рождения сегодня
SET @BONUS = (SELECT MAX(CASE WHEN [RELATIVE] = 0 THEN [VALUE] WHEN [RELATIVE] = 1 THEN @PAY*[VALUE] END) FROM [gk].[GK_BONUSES]
WHERE [STATUS] = 2 AND [KIND] = 1 AND (@PAY >= [LOW] AND @PAY <= [HIGH]) AND [CODE] LIKE @LC+'%' AND [gkArcade].[gk].CheckPeriod([PERIOD]) > 0)
END ELSE BEGIN -- если есть то даем максимально возможный бонус
SET @BONUS = (SELECT MAX(CASE WHEN [RELATIVE] = 0 THEN [VALUE] WHEN [RELATIVE] = 1 THEN @PAY*[VALUE] END) FROM [gk].[GK_BONUSES]
WHERE [STATUS] = 2 AND [KIND] = 1 AND (@PAY >= [LOW] AND @PAY <= [HIGH]) AND ([CODE] LIKE @LC+'bir%' OR [CODE] LIKE @LC+'%') AND [gkArcade].[gk].CheckPeriod([PERIOD]) > 0)
END
IF @BONUS > 0 BEGIN -- если Бонус положен то даем его
DECLARE @Employee int = (SELECT [EMPLOYEE] FROM inserted)
DECLARE @Creator int = (SELECT [CREATOR] FROM inserted)
DECLARE @Deal int = (SELECT [DEAL] FROM inserted)
DECLARE @CheckItem int = (SELECT [CHECK_ITEM] FROM inserted)
DECLARE @TGUID uniqueidentifier = (SELECT [TRANSACT_GUID] FROM inserted)
-- создаем транзакции
INSERT INTO [gk].[TRANSACTS] ([DATE],[ACCOUNT],[EMPLOYEE],[ACTIVITY],[VALUE1],[UNIT1],[VALUE2],[UNIT2],[QUANT],[CREATOR],[CREATORADDR],[CREATORDATE],[CARD],[DEAL],[CheckItem])
VALUES(GETDATE(),@CARD,@Employee,411,1,401,@BONUS, 1,1,@Creator,1,GETDATE(),@CARD,@Deal,@CheckItem+1)
INSERT INTO [gk].[GK_TRANSACTS]([DATE],[ACTIVITY],[CARD],[ACCOUNT_TYPE],[VALUE],[QUANT],[CREATOR],[CREATORADDR],[DEAL],[CHECK_ITEM],[EMPLOYEE],[LEVEL],[ARCADE],[GUID],[TRANSACT_GUID])
VALUES(GETDATE(),411,@CARD,@TYPE,@BONUS,0,@Creator ,1,@Deal,@CheckItem+1,@Employee,@Level,1,newid(),@ TGUID)
-- заачисляем бонус
UPDATE [gk].[GK_CARDS] SET [Bonus] += @BONUS WHERE [Card]=@CARD
END
END
END

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

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

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