Добрый день.

Посмотрел драйвер, состояние 255 определено
только для ККМ Элвес03 как 'выбор режима'.
Скорее всего это состояние 'выбор режима'.

Благодарю за помощь, я разобрался с тем как загружать / выгружать товары, остатки. В принципе в 1с работает стабильно. Осталось реализовать еще один маленький нюанс - выгрузка продаж за кассовую смену. Я мог бы разобраться с ним самостоятельно, но к сожалению аппарат фискализирован и мне нельзя на нём "играться"... Поэтому очень рассчитываю на помощь, помогите пожалуйста...

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

Но тут всплывает вопрос логики работы... Вот допустим я кассир и начало работать утром. При открытии смены у меня обнуляются остатки? Если да, то мне просто не нужно вносить никаких изменений в остатки товаров и потом сведения об отрицательных остатках товаров будут моими продажами. А если остатки не обнуляются или обнуляются вручную (через драйвер или комнадой на ККМ) то как мне в таком случае получать информацию о сменных продажах? И вопрос собственно тогда такой - какая логика обнуления ведения и обнуления остатков и как и откуда тянуть информацию о сменных продажах?

Кроме того, насколько я понимаю, мне каждый раз прийдётся обновлять остатки по всем 1000 позициям... Это конечно быстрее чем чтение / запись таблицы товаров, может есть ли способ игнорировать 0-е значения?

P.S. по поводу статуса 255 понятно... у меня если ккм не переводить в режим выбора (255) то не создаётся объект драйвера... насколько я понимаю то так и должно быть или мне стоит перечитать инструкцию по подключению к ПК?

Добрый день.

1. Объект драйвера должен создаваться в любом случае.
Для создания объекта драйвера ККМ не нужна совершенно.
Наверное при создании драйвера у вас сразу выполняется подключение к ККМ.
Нужна дополнительная информация по этой ошибке.

2. Насколько я знаю, для изменения остатков в ККМ есть только команда записи регистра остатков.
Может разработчик ККМ меня поправит. Если он сделает команду для чтения только ненулевых остатков,
а также отменит произвольную задержку (или вынесет ее в настройки), то можно будет ускорить
чтение остатков.

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

Сегодня свяжусь с ним.

Про товарные регистры подробно написано в руководстве по эксплуатации. Есть 2 варианта работы: 1-й регистры остатка товара, 2-ой регистры проданного. За выбор отвечает, настройка №30. По умолчанию 1-й вариант. При различных вариантах настройки меняется знак операции изменения товарного регистра. При 2-ом варианте редактирование регистров и таблицы товаров разрешено только в закрытой смене.

По поводу доработок. Про ненулевые регистры, мне не понятна концепция:) можно поподробней!!! Какой смысл проверять мне значение регистра, если сначала проверять его нужно вам? Если регистр нулевой, то не подавайте команду на изменение его значения... Или может я не понял чего-то? По поводу задержки, да и доработок вообще, можно конечно сделать настройку, но это связано с заменой программного обеспечения ККМ!!! Вы готовы к этому шагу? Сможете ли сделать самостоятельно? Или согласятся ли это сделать в Вашем ЦТО?

Про ненулевые регистры.
Предположим что у нас 10000 видов товаров, но продавали сегодня мы только 20.
Хотелось бы иметь команду, которая позволит прочитать только ненулевые регистры.
Можно сделать три команды: начать, получить следующий, прервать.
Можно сделать одну команду с параметром (начать, получить следующий, прервать).
Также неплохо бы иметь команду для обнуления всех регистров остатков.

присоединяюсь к Виталию... если товары, по которым будут изменяться остатки будут находиться в конце списка, к примеру позиции 850 - 950, то данные по остаткам этих товаров выгрузятся только после того, как будут обработаны 1 - 849 позиции. есть ли возможность не делать лишнего?
по обнулению всех остатков тоже беда, ведь если они никак не обнуляются (при закрытии смены к примеру), то также прийдётся это делать программно, а это опять же множество вызовов...
если можно как-то разобратсья с помощью существующего функционала, то будет прекрасно, а пока приходится "лопатить" кучу лишнего...

Ну ребята, я так понимаю, что следующим шагом станет поддержка SQL запросов каких-нибудь... Давайте мы все-таки как-нибудь научимся отделять мясные полуфабрикаты от насекомых. Виталь, твоя безграничная фантазия, как-нибудь сыграет с тобой злую шутку:), но самое плохое, что у тебя тут же появляются последователи .

Все, выше написанное, конечно же стоит воспринимать как шутку, но как говорится: в каждой шутке, есть доля шутки. Давайте не будем требовать от устройства с памятью программ в 64 КБайта (из которых свободных остался 1) того, что ему, нуууу совсем..., не свойственно делать!!! Я считаю, что вопрос увеличения скорости обмена не стоит решать за счет переноса на клиентский уровень серверного функционала. Если задуматься, то программа, которая инициализировала регистры начальными значениями, просто обязана знать какие регистры она инициализировала, дабы не опрашивать ненужные... Да и десятитысячного количества этих регистров в кассе нет, там, как я уже сказал выше, из-за скудности ресурсов, их в десять раз меньше, всего 1000.

Обнуление регистров происходит при снятии отчета с гашением по товарам, там же на печать выводятся и ненулевые регистры остатков.

Что касается задержки. Провел эксперимент на ККМ YARUS-TK, с теми же исходными данными, только там задержка отсутствует, и возможна работа на 115200. Версия драйвера 1.7.16. Плюс процессор работает на много быстрее чем в ШТРИХ-МИНИ-К. Хотя я думаю, что результаты будут приблизительно одинаковые из-за наличия прерываний для обработки различной периферии.

Вот результаты:

скорость RS_____Скорость______Время выполнения команды_______Чт. 1000 регистров____Увеличение скорости
__Бод__________команд/с________________с______________________с (мин:сек)____________%
115200____________~7,7_________________0,13____________________133 (2:13)_____________+30
9600______________5,(5)_________________0,18____________________186 (3:06)______________0

Какие выводы напрашиваются:
1. Увеличение скорости обмена влияет не настолько существенно, как того хотелось бы (прирост производительности в лучшем случае 30%).
2. Удаление задержки (со слов Виталия в этой теме, на ШТРИХ-МИНИ-К команда выполняется за 0.3 с {1000 команд за 5 мин.}) + ~50% к производительности.

Отсюда мораль, основную задержку формирует ККМ при обработке запроса!!! По-этому, друзья, давайте, все-таки, вернемся к тому, что это системная ККМ, а не ФР и, уж тем более, не POS терминал. Её ресурсов едва хватает на обеспечение собственных потребностей, а вы от нее хотите отчеты, да еще и в реальном времени....

Ну и мои выводы по доработкам: если есть острая необходимость получать отчеты не за 5 мин, а приблизительно за 3 -- 3:30, то задержку я могу убрать в настройку (еще раз только напоминаю про замену ПО!!!). Про ненулевые регистры, извините братцы, тут точно мимо.