Всем привет. Тему я уже поднимал, но решение так и не придумал. Попытался сделать как тут советовали, но проблема не решилась.
Сейчас все попробую изложить подробно: Есть сервер ут 10.3 (sql) + написал РМК + онлайн касса. Конечно есть куча РИБ -ов, но сейчас рассмотрим простой вариант: на сервере работают 2 кассира и им надо пробить чек.

Начальная логика
{
1) Открыть чек()
2) Заполнить табличную часть продаваемыми товарами()
3) Пробить чек на кассе()
4) В открытый документ записываем номер чека()
5) Проводим документ()
}
Все просто.

Допустим два кассира одновременно пробивают чек:

   Оба открыли
   оба пробили чек по ККМ
   ...
   дошли до п.5

И тут проблема, у первого чек провелся, а у второго ошибка (ну какая-нибудь sql что-то там is blocked)

Имеем:

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

Решение: Добавить пункт 2.1 (смотрим, что в нем)

Отредактированная логика - 1
{
1) Открыть чек()
2) Заполнить табличную часть продаваемыми товарами()
2.1) После того, как заполнили табличную часть ЗАПИСЫВАЕМ документ!!!
     Если (документ не записан) тогда
     возврат (и кассир еще раз жмет попробовать еще раз или что-то типа этого)
3) Пробить чек на кассе()
4) В открытый документ записываем номер чека()
5) Проводим документ()
}

Что нам это дает, а то, что если даже чек не проведется, то он хотя бы будет записан и мы не потеряем проданную номенклатуру.

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

Прошлый раз мне на мисте порекомендовали синхронизировать работу кассиров константой:

Отредактированная логика - 2
{
1) Открыть чек()
2) Заполнить табличную часть продаваемыми товарами()
2.0) Если (Идет пробитие чека) Тогда
        Ждем
     Иначе
        Меняем константу(блокируем)
        2.1) После того, как заполнили табличную часть ЗАПИСЫВАЕМ документ!!!
             Если (документ не записан) тогда
             возврат
        Как только чек пробит мы меняем константу (разблокируем)
     Конец если
3) Пробить чек на кассе()
4) В открытый документ записываем номер чека()

5.0) Если (Идет пробитие чека) Тогда
        Ждем
     Иначе
        Меняем константу(блокируем)
        5) После того, как заполнили табличную часть ПРОВОДИМ документ!!!
        Как только документ проведен мы меняем константу (разблокируем)
     Конец если
}

Сейчас у меня вот такая штука с константой, но все равно чеки не проводятся.
Возможно есть другие документ,ы которые используют те же регистры, что и документ ЧЕК
Возможно пробитие чека попадает на обмен: Но это легко проверить ПланОбмена.ИдетОбмен? и как-то реагировать

Вопрос: как добиться железного проведения чека?
Такой же константой обложить все методы проведения документов, которые используют регистры что и чек ??? Дайте совет?

СПАСИБО

А если поменять логику?
1. Проводим чек.
2. Пробиваем чек на ККМ.
3. Если пробилось, то записываем номер чека (можно в документ, можно в РС).
4. Если не пробилось, то пробуем пробить еще раз.

Если номера чека нет, то не попадает в закрытие смены. Пока чекККМ проведён товар находится в неком резерве.

(1) у нас так и было сделано

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

Но ни как не наоборот. Так что делайте так же.

(1) :)

(1) Спасибо друзья

Хорошее решение, замыливание глаза)

А объясните мне как можно вообще догадаться пробивать чек не проведенного документа?
Ведь док может не повестись по ряду причин ограничений, к примеру - контроль остатоковТМЦ

(7) Это косяк)

1С вряд ли предполагала,что буден больше одного кассира на ККМ

(9) Совершенно верно, раньше в каждом магазине крутилась громадная база

(0) Как мне кажется, работа УТ10 в качестве РМК больше все-таки ориентирована на РИБ. Я не помню предыдущую тему, у вас типовой код в плане формирования чека? Т.е. открывается явная транзакция?

(11) Режим управления блокировками - автоматический. Проведение чека - метод типовой.
Формирование чека - самописный

(11) +  , а чем РИБ не подошел ?

НачатьТранзакцию()... оставили, как в типовом коде?

(0) это что вы с чеками делаете что у вас ошибки скуля лезут? может устранить причину, а не симптомы лечить? Если не вариант, то решение в (1)

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

(14) (15) Конечно мне хотелось решить проблему...
Откуда берется проблема с транзакцией я не знаю. Как я понимаю, что если тип блокировок автоматический, то транзакциями управляет сервер SQL. В обработке проведения нет ни слова НачатьТранзакцию()  
Что он там блокирует, хз. Только запись или всю таблицу. Но как было замечено.. запускаю два сеанса 1с.. и одновременно пробиваю чек, то вылетает ошибка блокировок sql

(16) подними веб сервис и сделай онлайн обмен или внешний источник данных

(17) значит в забросе написано блокировать или у вас нагрузка на диск стала большая и он медленно фиксирует транзакции

(17) обрати внимание на ресурсы сервера

(18) Ага.. так и хочу, потому планируется бонусы тратить на сайте, потребуется сервачок для централизованного хранения бонусов и карт.
А по поводу нагрузки, да.. массив из HDD планирую заменить на массив из SSD

А чем не устраивает такой алгоритм:
Цикл
5) Проводим документ()
Если Проведен() = 0
Пауза N секунд
Продолжить
Иначе
Прервать
КонецЦикла


Работает устойчиво при наличии в базе нескольких кассиров и других пользователей.

(17) Скорее всего, блокирует таблицы с документами, где есть реквизит НомерЧекаККМ - там довольно тяжелый запрос. Хотя, в последних релизах вроде реквизит перенесли в регистр сведений (Фискальные операции). Но скорее всего, этот запрос не нужен вовсе, т.к. номер чека обычно получают из ККМ. Я бы просто закомментировал вызов процедуры (к примеру, в не самой новой УПП это КассовыеСменыВызовСервера.ТекущийНомерЧека), в документе ЧекККМ там что-то вроде:

ОбщиеПараметры.НомерЧека = КассовыеСменыВызовСервера.ТекущийНомерЧека(ДопДанные.ОписаниеПКС) + 1;

Но, конечно, всех проблем это не решит.

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

(22) Тоже неплохой вариант. Но при ошибке проведения будет постоянно выскакивать модальное окно с текстом ошибки.

В рознице:
1. Кассир в РМК набил товар
2. Жмакает к примеру Оплатить наличными
3. Вывод окна и кнопка "Пробить"
3.1 Перед нажатием Пробить 1С создает новый документ ЧекККМОбъект и записывает его, включая выбранный тип оплаты
4. кассир жмакает Пробить. Формируется пакет для ККТ и далее Fiscalization...Печать фискального чека
5. Результат фискализации (номер чека, смена и т.д.) сохраняется в документОбъект