Имя: Пароль:
1C
 
1С УТ (чеки) устал :(
0 nikast
 
27.11.19
12:06
Всем привет. Тему я уже поднимал, но решение так и не придумал. Попытался сделать как тут советовали, но проблема не решилась.
Сейчас все попробую изложить подробно: Есть сервер ут 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 Lokli
 
27.11.19
12:24
А если поменять логику?
1. Проводим чек.
2. Пробиваем чек на ККМ.
3. Если пробилось, то записываем номер чека (можно в документ, можно в РС).
4. Если не пробилось, то пробуем пробить еще раз.

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

Но ни как не наоборот. Так что делайте так же.
4 nikast
 
27.11.19
12:38
(1) :)
5 nikast
 
27.11.19
12:39
(1) Спасибо друзья
6 nikast
 
27.11.19
12:39
Хорошее решение, замыливание глаза)
7 Kigo_Kigo
 
27.11.19
12:42
А объясните мне как можно вообще догадаться пробивать чек не проведенного документа?
Ведь док может не повестись по ряду причин ограничений, к примеру - контроль остатоковТМЦ
8 nikast
 
27.11.19
12:43
(7) Это косяк)
9 piter3
 
27.11.19
12:43
1С вряд ли предполагала,что буден больше одного кассира на ККМ
10 nikast
 
27.11.19
12:43
(9) Совершенно верно, раньше в каждом магазине крутилась громадная база
11 d4rkmesa
 
27.11.19
12:46
(0) Как мне кажется, работа УТ10 в качестве РМК больше все-таки ориентирована на РИБ. Я не помню предыдущую тему, у вас типовой код в плане формирования чека? Т.е. открывается явная транзакция?
12 nikast
 
27.11.19
12:52
(11) Режим управления блокировками - автоматический. Проведение чека - метод типовой.
Формирование чека - самописный
13 yavasya
 
27.11.19
13:04
(11) +  , а чем РИБ не подошел ?
14 d4rkmesa
 
27.11.19
13:05
НачатьТранзакцию()... оставили, как в типовом коде?
15 Ник080808
 
27.11.19
13:17
(0) это что вы с чеками делаете что у вас ошибки скуля лезут? может устранить причину, а не симптомы лечить? Если не вариант, то решение в (1)
16 nikast
 
27.11.19
14:58
(13) Риб не подошел тем, что в программе имеются бонусные карты ну и соответственно бонусы. Некоторые магазины находятся в непосредственной близости, и получается, если базы будут редко меняться, то один покупатель может потратить бонусы и там и там. Поэтому решили посадить их на один сервер.
17 nikast
 
27.11.19
15:03
(14) (15) Конечно мне хотелось решить проблему...
Откуда берется проблема с транзакцией я не знаю. Как я понимаю, что если тип блокировок автоматический, то транзакциями управляет сервер SQL. В обработке проведения нет ни слова НачатьТранзакцию()  
Что он там блокирует, хз. Только запись или всю таблицу. Но как было замечено.. запускаю два сеанса 1с.. и одновременно пробиваю чек, то вылетает ошибка блокировок sql
18 yavasya
 
27.11.19
15:15
(16) подними веб сервис и сделай онлайн обмен или внешний источник данных
19 yavasya
 
27.11.19
15:16
(17) значит в забросе написано блокировать или у вас нагрузка на диск стала большая и он медленно фиксирует транзакции
20 yavasya
 
27.11.19
15:17
(17) обрати внимание на ресурсы сервера
21 nikast
 
27.11.19
15:33
(18) Ага.. так и хочу, потому планируется бонусы тратить на сайте, потребуется сервачок для централизованного хранения бонусов и карт.
А по поводу нагрузки, да.. массив из HDD планирую заменить на массив из SSD
22 s_trikozin
 
27.11.19
15:37
А чем не устраивает такой алгоритм:
Цикл
5) Проводим документ()
Если Проведен() = 0
Пауза N секунд
Продолжить
Иначе
Прервать
КонецЦикла


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

ОбщиеПараметры.НомерЧека = КассовыеСменыВызовСервера.ТекущийНомерЧека(ДопДанные.ОписаниеПКС) + 1;
24 d4rkmesa
 
27.11.19
15:41
Но, конечно, всех проблем это не решит.
25 nikast
 
27.11.19
15:44
(23) Ага.. релиз у меня старый, так что возможно этот запрос у меня и выполняется. Спасибо, буду копать.
26 nikast
 
27.11.19
15:52
(22) Тоже неплохой вариант. Но при ошибке проведения будет постоянно выскакивать модальное окно с текстом ошибки.
27 zippygrill
 
27.11.19
16:04
В рознице:
1. Кассир в РМК набил товар
2. Жмакает к примеру Оплатить наличными
3. Вывод окна и кнопка "Пробить"
3.1 Перед нажатием Пробить 1С создает новый документ ЧекККМОбъект и записывает его, включая выбранный тип оплаты
4. кассир жмакает Пробить. Формируется пакет для ККТ и далее Fiscalization...Печать фискального чека
5. Результат фискализации (номер чека, смена и т.д.) сохраняется в документОбъект
Есть два вида языков, одни постоянно ругают, а вторыми никто не пользуется.