Технологический сервер ККТ Меркурий

[ewgen]

Shtirlic Еще на некоторых кассах та же проблема: не удается выгрузить настройки из кассы на сервер, висит неисчезающая галка "Запрос в очереди". Проверьте, пожалуйста, ID 245156, 00041813, может и еще на других. Это вообще системное или каждый аккаунт надо проверить?

[Shtirlic]

Насколько я понимаю 00041813 это заводской номер Вашей текущей кассы с ID 245156, а на сервере с этим ID прописан заводской номер 00040072. Вот сервер и обрывает связь, считая кассу с заводским номером 00041813 как злоумышленника.

[ewgen]

Shtirlic Ну опечатка же. ID 245156 и 239955. Вопрос остался.

[Shtirlic]

Теперь мы поняли проблему и решили её.

[ewgen]

Спасибо, вроде бы появилась четкость в нажатиях кнопочек и реакции сервера на них.

[RomanStrel]

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

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

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

Вот пример. Выдавая в работу кассу, нужно прописать кассиров, персонально каждого. Прописали кассиров – отправили обновление. Через час другая касса выдаётся другой группе кассиров. Прописали – отправили. Еще через час третья касса выдается новой группе кассиров. Прописали – отправили. В таких условиях ориентироваться не дату-время – это издевательство над людьми.
А еще есть регулярные обновления по всем кассам группы. Как товаров, так и настроек.

В кассе сейчас нет такого элемента. Но, насколько я понял, в кассе поддержат эту метку, если она появится у сервера.

Давайте обсудим.

[Shtirlic]

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

[RomanPrg]

Идеи .

Представлять дату-время в UNIX-время формате. Текущее время 1520427327.

Печатать контрольную сумму файлов CRC32 3A1D2D1A

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

[RomanStrel]

Shtirlic
спасибо.

Метка обновления лучше даты-времени потому, что она короче - её проще транслировать людям, например, по телефону; и её проще анализировать глазами при проверке.
К тому же, метку можно наделить неким смыслом. Например, первой буквой обозначая концепцию/группу касс. (на самом деле, метка всегда наделена смыслом - поэтому просто CRC32 слабо поможет, хотя это и лучше отсутствия метки)

Я повторюсь - метка не заменяет идентификатор дата-время. Метка дополняет его.
Метка - не обязательный параметр. Метку можно не указывать и не использовать вообще. Тогда будет только дата-время. Метку можно не менять - при этом идентификатор дата-время будет меняться при каждом обновлении, а метка так и останется такой, какой была.
Идея в том, чтобы меткой управлял человек. Как человек управляет, например, текстом заголовка.

Исторически, на старых кассах 180К, обновления приходили единым пакетом, и имели возможность ручного указания метки для каждого обновления. Мы дублировали метку в текстовом заголовке - чтобы людям было понятно, прошло обновление или нет, нужное ли прошло обновление. И в отчете-статусе (аналог нынешнего статуса по точке) печаталась метка. Чтобы всегда можно было разобрать ситуации типа "цены не обновились, товары не появились, я тыщу раз уже пробовала".
В нынешних кассах обновления настроек и товаров разделены. Поэтому нет уверенности, что обновление прошло полностью - может настройки обновились, отображается новая метка, а товары еще не обновились. Отсюда и все эти условности с последовательностью обновления (чтобы сначала товары, затем настройки).

Что касается кассиров.
Для кассиров каждый раз нужно отправлять обновление. И делать это так, чтобы всегда было понятно, что именно это конкретное обновление пришло на эти несколько касс.
Конечно, в идеале, лучше бы касса вмещала в себя не 16 кассиров, а 999, например. Но касса не умеет. Поэтому приходится как-то впихивать 600 кассиров в 16 записей.
Пока я ничего не придумал лучше, чем указывать в метке обновления настроек номер бригады кассиров. Так хоть понятно, что именно прилетело на кассу и то ли это, что мы ожидаем.
Ориентироваться на дату-время в таком активном режиме, когда каждый час разные пачки касс обновляются разными пачками кассиров, - это не то, чтобы совсем нереально, но определенно до бессмысленного сложно.

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

Я могу еще подробнее, если надо.
Без метки обновления сложно работать.

[Shtirlic]

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

[RomanStrel]

Shtirlic
спасибо.
Буду очень ждать. Если надо будет что-то уточнить - я готов, да.

Ну и какая-же это проблема?! - это возможности, а не проблемы. С этими возможностями старая касса 180К со всеми своими ограничениями была лучшим аппаратом на рынке! (Спасибо Станиславу!) И новая касса 180Ф еще пока даже не догоняет старую по возможностям (а очень бы хотелось).

[RomanPrg]

Ну и какая-же это проблема?! - это возможности, а не проблемы.

На данный момент Вы самый уникальный пользователь наших касс с 999 кассирами .

В общем, была путаница в терминологии.

Как поняли, Вам нужен не уникальный маркер, а дополнительный реквизит, с типом строка, в который пользователь может записать произвольный комментарий для базы и настроек ?

[RomanStrel]

RomanPrg
верно!
Просто текстовый реквизит, который будет заполняться на сервере и печататься на кассе в статусе обновления (в идеале - еще и в отчете-статусе по точке).

[mservis2]

При выгрузке настроек для регистрации ккт, сервер выдает ошибку: Ошибка загрузки в кассу:Настройки:260(3)
На кассе потом появляется ошибка: Платежный агент 1, ошибка 260.
Проверяем вручную настройки агента и далее проходит нормально.
Меркурий-185Ф, прошивка с сервера последняя, режимы агента не используются.

[Shtirlic]

эту ошибку касса вернула, а сервер отобразил.
Перешлите нам настройки на support@incotex-service.ru попробуем разобраться

[афро]

mercury 115f 1.05 последняя прошивка

статус обновления Ошибки загрузки в кассу: Инф.кассы:511(2) Настройки:260(1)
в самой кассе все вроде верно и работает, настройки при внесении изменений обновляет, но ошибки напрягают, как выяснить в чем проблема?

[Shtirlic]

mservis2
Посмотрел и Ваш файл и данные в Вашей учетной записи. Проблем не нашел.
Насколько я понял в 7:41(19.03.18) была выгрузка с ошибками, затем в 08:28 выгрузка была успешной.
Пока мы показываем ошибки по последним ошибочным данным в течении 3 дней. При последующих правильных данных информация не уходит.
Это временное решение для того, чтоб ошибки не пропали при следующей удачной передаче данных.
Сейчас переделывается закладка "Общие" и там будет список переданных и передаваемых данных и там будет более понятно какие ошибки к каким выгрузкам относится.

афро
Возможно у Вас подобная ситуация как у mservis2.

[афро]

mservis2
Посмотрел и Ваш файл и данные в Вашей учетной записи. Проблем не нашел.
Насколько я понял в 7:41(19.03.18) была выгрузка с ошибками, затем в 08:28 выгрузка была успешной.
Пока мы показываем ошибки по последним ошибочным данным в течении 3 дней. При последующих правильных данных информация не уходит.
Это временное решение для того, чтоб ошибки не пропали при следующей удачной передаче данных.
Сейчас переделывается закладка "Общие" и там будет список переданных и передаваемых данных и там будет более понятно какие ошибки к каким выгрузкам относится.

афро
Возможно у Вас подобная ситуация как у mservis2.

угу, вчера ушла одна ошибка, сегодня вторая

[AleksSH]

Может кто подскажет, каким образом можно распечатать список товаров с кодами ПЛУ?Выгрузить в формат exel?
И еще, планируется ли возможность получать список товаров с кассы?

[Shtirlic]

Может кто подскажет, каким образом можно распечатать список товаров с кодами ПЛУ?
В настоящий момент такой возможности нет, если Вам это нужно, можете предложить в каком виде это Вам нужно(хотя бы какие поля нужны) и мы по возможности реализуем в отчетах.

Выгрузить в формат exel?
нельзя и пока не планируем

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