Здравствуйте!

Розница, редакция 2.2 (2.2.5.26)

Часто с магазинах (розничная продажа продовольственных товаров) возникает ситуация, что чек выходит из фискальника, но товары не исчезают с Рабочего места кассира (РМК), затем чек висит в списке как непробитый и непроведённый, возникли пара вопросов:

1. Почему это происходит? Почему 1С не может получить ответ от фискальника?

2. Поделитесь пожалуйста хоть какими то советами, как пробовали решить подобные проблемы.

Заранее спасибо!
---
Разносите по времени обмен и пробитие чеков иначе так и будете попадать на обмен и чек будет оставаться не проведённым.
---
Проблема бывает по 2ум причинам. Не получен ответ от фискальника. Например подвис драйвер, отошёл провод. Но это редкая проблема.
Чаще не пробитые чеки появляются из за обмена РИБ.

У вас есть РИБ?
---
пробитые чеки появляются из за обмена РИБ

А каким боком РИБ при чеках? Они же должны быть не включены в план обмена
---
Они включены в состав объектов план обмена, причём это типовая настройка в плане обмена "По магазину".
---
Таким боком.... что при запуске обмена РИБ блокируются таблицы.
---
Два вопроса:
1) Как в кассу может прилететь изменение чека?
2) Блокируется вся таблица чеков? 0_О
---
1. Вопрос не понятен....
2. Блокируется одна из таблиц в базе. По которой чек должен сформировать движения. Если в момент обмена пробить чек то получаем ошибку "Не удалось заблокировать таблицу .....".
Чек записывается в базу, но остаётся не проведённым.
Вот такой архитектурный косяк розницы....
---
У нас проверка отрицательных остатков происходит при проведении ОРП и в самом режиме РМК, поэтому думаю же можно как то отключить эту блокировку при синхронизации?
Про разграничение синхронизации и продаж - спасибо за идею, хороший вариант.
---
А при чём тут отрицательные остатки?
---
Ну блокировка регистров накопления ставится для проверки отрицательных остатков насколько я понимаю, и управление блокировкой в 1С можно настроить. Но в данном случае при синхронизации наших магазинов с центром эта блокировка - лишнее. Скорее всего эта блокировка указана в правилах обмена. Это в теории я высказался, но возможно я ошибаюсь, потому что с блокировками на практике работал мало, только при подготовке к 1С Специалисту.
---
Это не та блокировка которая ставится на регистры для проверки отрицательных остатков.
Это блокировка таблицы механизмом РИБ. Для обеспечения целостности передаваемых данных.
---
Понятно, спасибо!
А РИБ по рабочему месту как думаете решит нашу проблему, или там такая же история возможна?
---
Не решит. Так работает весь РИБ.
К тому же РИБ по рабочему месту это не по магазину. А только по рабочему месту.
---
РИБ по рабочему месту это РИБ по кассе. Когда каждая касса это независимая база. Но магазин у них один.
А по магазину, это по магазину в целом.
---
В теории должно работать, потому что РИБом на Кассе уже будет управлять кассир и она не сможет одновременно продавать и делать РИБ, т.о. произойдёт разграничение по времени продаж и синхронизации данных.
Таким образом конечно структура РИБ у нас усложнится ГлавныйУзел - МагазиныУзлы - КассыУзлы, но программа это позволяет и возможно это решит наши проблемы.
---
Администрирование дополнительных промежуточных узлов только добавит проблем. Вам это ещё обновлять.
---
При чём проще управлять структурой "звезда" чем "дерево".
---
поэтому думаю же можно как то отключить эту блокировку при синхронизации?
Никак. Эта блокировка ставится самой платформой.
---
Блокируется вся таблица чеков? 0_О

Могу конечно ошибаться, но на сколько помню. РИБ блокирует целиком таблицу в момент обмена.
---
Да, у нас есть РИБ (План обмена "По магазину")
---
Разносите по времени обмен и пробитие чеков иначе так и будете попадать на обмен и чек будет оставаться не проведённым.
---
РМК в 1С (от УТ до розницы) явно писали люди далекие как от предметной области, так и от программирования.
Это касается и специфики работы с оборудованием, и методики регистрации операций в базе.
Окончательное решение вопроса с РМК обычно лежит в плоскости установки готовой POS-системы или разработки таковой самостоятельно
---
Значит мои сведения не устарели и в (2) наиболее надежный вариант решения проблемы. На нижнем уровне должна быть автономная система
---
Ну как говорится что имеем... Разнесение обменов и пробития чеков по времени решает эту проблему в РИБе.
Но в Рознице и с этим не всё так радужно как хотелось бы....