Обмен логами. : УКМ-4

Цель: Хотелось бы выявить наиболее стабильную версию УКМ4. И соотвественно обменяться опытом.

В связи с чем предложение обменяться логами касс, которые проработали более месяца в режиме обычной эксплуатации в
магазине. Интересуют версии УКМ 4.44 и выше, буду очень рад если это будет версия 4.45. Соответсвенно, хотелось бы
начать с себя, но у меня версия 4.42 sp4, логи которой выложу когда буду на работе.

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

Итак достаточно следующего:
- Версия УКМ
- Лог файл за месяц.
- Указать нужен ли анализ и ответ по ошибкам.

Логи с кассы можно получить

Версия 44 сп 1
log.rar

Кстати, специально посмотрела. У меня в магазинах, которые на 44-ой версии нет ни одной проблемы с разрушенными чеками. Время работы на 44-ой - с лета.
Насколько я помню, результатом твоих "любимых" ошибок является разрушение чека.

Спасибо за логи.

Что интересно:
1) Ошибки персонала. Много ошибок товар не найден. Наверно это проблема всех сетей магазинов, когда товар лежит в магазине, а вот на кассе его не присутвует. Причин конечно для этого множество, и все они в области бек офиса. Так же множество затупов кассиров, типа цены товара вместо штрих кода.(для меня много это более одного раза в сутки ;) )

2) Стабильность сетки у вас великолепная. К сожалению у меня бывают сбои, причем совсем недавно магазин 20 минут не мог работать, просто перезагружались кассы. Но об этом я расскажу когда свои логи выложу. И как я понимаю это частично пофиксено в Client v.44 Service Pack 3 но не полностью, судя по логам Назым. Сейчас общаемся с тех поддежкой, интересно их мнение. Соотвественно свое выложу скорее в понедельник.
3) 14:46:51: WARNING:OBSOLETE:
Непонятно что вот это. Причем оно очень часто появляется.

4) 16:52:34: DEBUG:SP101FRK:Фискальный регистратор: 9: Принтер не готов. Команда: 48 ('30\x1C\x1C1.0000\x1C33.6000\x1C0\x1C')

Нехорошая ошибка, которая говорит мне о том, что работа УКМ с фискальником еще не идеальна.

5) 11:55:53: WARNING:debug#/usr/local/storage/home/ukm/ukm/rel-44_sp1/ukm/libukm/ccontext_receipt_base.cpp(431) HandleMCR:St13runtime_error( ошибка при выполнении платежной операции )

Безнал операция. Или считыватель подглючивает или тоже нехорошая ошибка УКМ или модуля Сбера.

В целом довольно неплохо.

Здесь не только бэк-оффис, но и подготовка кассиров и многое другое... Это в рамки существующей ветки не укладывается, да и бог с ним...

Насколько я понимаю, это модуль начисления бонусов Золотой Короны
в ответ что-то выдает. Раньше он ругался на что-то при каждом пробитии товара. К 44-ой версии начал писать после каждого чека с начислением бонусов. Уже легче.

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

Это не Сбер. Это модуль Золотой Короны. Операция оплаты чека бонусами. От них был получен ответ, что операция запрещена. Зафиксировано в логах. Ни к считывателю, ни к самому УКМ отношения не имеет.

Меня кстати радует, что судя по логам кассиры:
- научились правильно выключать кассу
- не вырубают питание кассы при любой необычной ситуации.

УКМ 44 sp2, обновились в сентябре. logs[1].from.192.168.2.101.zip.

to 7fox7:
Показывает, что администратор дал права кассиру на запрещенную для него операцию (возврат по чеку, сторнирование позиции, открытие ден. ящика и т.д.).

Ошибок стало меньше, а главное работает Linuxовый модуль Сбербанка (быстрее запускается и никаких гемороев с DOS эмуляцией.

Нет если бы чековая лента кончилась, так бы фискальник и сказал УКМ, а тот в свою очередь в лог и/или на экран. В том то и дело что непонятно.

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

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

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

2) 23:00:55: FATAL:diag:КОД НЕИЗВЕСТЕН НЕИЗВЕСТНАЯ ОШИБКА bad lexical cast: source type value could not be interpreted as target
Неостаточно настроен шаблон ввода. Есть какие то значения, которые шаблон ввода не обрабатывает.

---
Вобщем от С+ не дождался ответа.

16.12.2008 20:58 - 21:10 ребут касс во всем магазине. Как выяснилось колбасило сетку, вот только чем, пока не понятно.
Из этога лога мне стало понятно, что проблемы в отсутвии проверок возвращаемых значений при использовании сокетов для связи с сервером. Причем та же проблема сохранилась и у Назым. УКМ 4.44 sp3. Хотя вполне возможно что это частично пофиксено в новых версиях.

Вложения

log.zip (18.9 Кб, 123 просмотров)

Ну это уже совсем обидное предположение :)

В 46 версии исправили ошибку, проявлялась только под Linux, приводила к перезагрузке кассы. Как её поймать в реальной жизни не знаю, но полазивши по большому количеству логов удалось выловить "шаблон" проблемы. В целом проявлялась ошибка так - спонтанная перезагрузка кассы при возникновении проблемы с сетью. Ситуация возникает редко, вывести сеть в такое состояние нам так и не удалось, уж больно "точечная" проблема, тем не менее проблему удалось вычислить и исправить.

Вот мой лог. УКМ 42.5

Хочу получить комментарии.

Вложения

logs.from.192.168.6.110.zip (205.7 Кб, 133 просмотров)