Кэшконтроль - SET Prisma или POS Intellect ? : СКУД и видеонаблюдение

да. + на одной кассе то синхронно, то убегает

внесу свои 5 копеек

1. рассинхронизация - надо посмотреть передаются ли в сообщение необязательные поля протокола обмена (поставить логгер на порт)
=============================
из доков: Последние семь полей необходимо заполнить датой и временем происхождения события. Если не указать дату, то будет подставлена текущая дата сервера принимающего события. Тоже произойдет со временем.
=============================
и если этого нет - допиливать протокол, если есть - пинать разработчиков призмы - все должно быть синхронно (по крайней мере у нас не жалуются на время)

2. не сталкивался (отчеты не смотрел, но и никто не жаловался пока)

3. номер чека - обязательный параметр протокола обмена - его передает касса - надо попытаться понять откуда она его берет

4. изменение кол-ва - отдельное событие и не должно быть связано со сканированием весового товара - скорее всего ошибка в описании протокола в программе (если конечно не некий скрытый смысл разработчиков связки)

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

Доброго дня !
Уж лето минуло и осень наступила. Мораль такова
1.Рассинхрон победили скриптом от призмы
2.Отчет по дисконтным картам. Если после применения дисконтной карты была оплата по кредитке, система считает что номер кредитки это номер дисконтной карты

Это я сдуру так решил, все гораздо интереснее. Карты клиентов УКМ принципиально не передает в призму. Точнее принципиально не желают допилить. И второе - дисконтные карты идут, но не передается тип карты - то ли это кредитка толи дисконт - в итоге в отчете все в перемешку.

3.Номера чеков. Призма ведет некую свою нумерацию, несовпадающую с номерами на кассе.
С номером все прояснилось это номер ТРН, он есть везде :)

4.Весовой товар - каждое сканирование призма считает несанкционированным изменением количества товара
С этим похоже ничего не сделать. Опять же по словам С+.


Вопрос - неужто никому не нужны карты клиентов в призме ?

Мне нужны.
А нельзя посмотреть что там lua-скриптах и их поправить?

Да если б так просто, давно б разобрались и поправили.
При использовании карты клиента не возникает событие.

У тебя уже есть призма, или собираетесь ставить ?

Уже есть, и собираемся ставить...

не могу личных сообщений писать - надо бы скоординировать работу с с+ :), как связаться то...

Если не хотите обсуждать это здесь, можете обсудить это в jabber-конференции форума.
Нас там немного, обстановка почти интимная.

Суть
1.Почему не разделяются дисконты и кредитки
ответ С+ :
"Насчет отчета по дисконтным картам:
Возможно, данный отчет в призме использует поле Cardtype, которое по техническим требованием было необязательно к заполнению и мы его оставляем пустым. Это всего лишь предположение.
УКМ4 при отправке события с кодом 31 "Продажа по кредитной Карте" - в поле CardNumber посылает номер БАНКОВСКОЙ карты.
А при отправке события с кодом 35 " Продажа по дисконтной Карте" в поле CardNumber посылается номер ДИСКОНТНОЙ карты. Только так.
И если ПРИЗМА в данном отчете неправильно трактует код команды + CardNumber, то вопрос необходимо задавать именно в "призму"."


По описанию, да, реально Cardtype необязателен, но и CardNumber - необязателен, и логично если уж пересылаешь CardNumber, будь добр и Cardtype. Но наверно не всем логично :)


Далее вопрос номер два
Хочу видеть номера карт клиентов, пусть как дисконты, реально в призме мало отчетов, пусть идут как дисконты, лишь бы иметь возможность фильтрануться по номеру карты
ответ С+

"Думаю, что надо написать письмо в Кристалл, с требованием расширить протокол взаимодействия с Призмой с целью обеспечения передачи следующей информации из кассовой программы:
- номер дисконтной карты
- номер клубной карты
- номер кредитной карты (замаскированный)
при условии, что в одном чеке могут примениться несколько карт и разных типов и несколько карт одинаковых типов.
Затем Кристалл выпустит новую версию Призмы, сообщит нам (и другим клиентам) новую структуру протокола. Соответственно, мы внесем изменения в протокол и, после обновления версии УКМ и Призмы, все начнет работать по новому протоколу.
Другого пути я не вижу. Логика, по-моему, простая – есть Призма, ее функционал сейчас не позволяет отслеживать все эти события в произвольной комбинации. Соответственно, клиент и обращается к разработчику Призмы, а мы, уж, ведомое звено…"


Вопрос знатокам - на сколько это растянется ? :). С учетом того что ни С+ ни кристаллу это не нужно.

3. м.б. и есть своя нумерация, однако и стандартная по кассе должна быть - по крайней мере в протоколе это обязательные поля

4. не совсем понятно какая здесь связь c весовым товаром (если только не идет подмена в программе)
- есть событие
6 Добавление товара в чек - Основное событие, говорящее о том, что какой-либо товар добавлен в чек, причем способ добавления (сканирование, ввод по коду и т.д.) не важен
и событие
12 Изменение количества товара - Происходит в момент, когда кассир изменяет количество обрабатываемого товара.

посмотри есть ли у тебя в призме событие добавление в чек (6) на весовой товар