Всем привет. Хотел получить совет от тех кто уже сталкивался и решал подобную проблему.
Есть РИБ на УТ 10.3 На каждом узле пробиваются чеки ККМ и соответственно создается документ. Обмен происходит 1 раз в час. И получается, что если момент пробития попадает на обмен, то чек по онлайн кассе проходит, а в 1с не записывается.
Как решить подобное ?
Код простой:
Когда пробивается Чек:
1)НовыйЧек = СоздатьЧек()
2)НомерЧека = ПробитьЧекНаККМ()
3)НовыйЧек.ЗаписатьНомер(НомерЧека)
4)НовыйЧек.Провести()
Соответственно, если чек не записался, мы лезем в офд там смотрим что было продано.

Проверять, идёт ли обмен. Если идёт, то ждать с пробитием чека.
Решение же очевидно

Ага... хорошо. Тогда такой момент, как обработать, если два сотрудники одновременно пробивают чеки, возникает ошибка транзакций, типа таблица SQL заблокирована.

(0) Для высокоинтенсивной работы с чеками там слишком неоптимально некоторые функции работают. От явной транзакции можно попытаться избавиться или сократить.

(2) Аналогично. Первый, кто начинает пробивать - поднимает флаг. Второй (флаг) его видит и идёт курить

можно для общего развития еще здесь почитать
http://catalog.mista.ru/public/629017/

пробивать чек в событии ПослеЗаписи формы

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

(5) Спасибо, сейчас читну.

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

Начать можно с установки максимального разумного времени ожидания блокировки. Тогда сеанс просто будет висеть до момента завершения блокировки из другого сеанса.
А дальше зависит от того, а сколько параллельно кассиров в этой базе на сервере сидит и проводит? Если их только два, то подождать реально,
а если много - от получения модального окна простым повышением времени ожидания не уйдешь

(8) Для начала можно просто потыкать в замер производительности, там в документе между НачатьТранзакцию() и ЗафиксироватьТранзакцию() куча избыточных вызовов функций, которые в принципе не нужны или их можно закэшировать. К примеру, КассовыеСменыВызовСервера.ТекущийНомерЧека (не факт, конечно, что именно эта функция есть в вашем релизе) - не нужно вообще, т.к. ККМ сам возвращает номер чека.

Друзья всем спасибо за информацию!

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

(13) Да, точно.

Конфига уже сильно переписана?

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

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

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

За исключением установки актуальных цен, что просто ставит раком всю смену, если вдруг ее не успели запустить до начала смены.

Кассиры никогда не кричат - а у меня товара в остатках нету! НЕ бывает такого :-)

Они кричат - караул! У меня товар без цены на кассу принесли.