При одновременном пробитии чеков на разных кассах РМК вываливается с ошибкой
1С Розница: Аптека для Украины.
3 кассы работают в терминальной сессии. Фискальные.
Сервер более чем шустрый. Базы на SSD. Тест Гилева выдает 70 очков.
Проблема следующая:
Если одновременно (+/- 1 секунды) кассы пробивают чеки, то они все подвисают на несколько секунд, одна из них, после висяка пробивает и печатает чек, вторая и третья вываливается с ошибкой. Ошибки разные, в 90% случаях одна из касс вывалится с ошибкой блокировки таблиц с чеками, другая с общей ошибкой.
Сами чеки в "документах": первая касса, та которая создает нормально чек и его проводит, отрабатывает на все 100%, по остальным - чека в принципе может не быть; он может быть проведенным но без номера; может быть создан но не проведен.
Понятно, что корень проблемы в блокировках таблиц.
Я вижу такие варианты решения:
1) Не самый лучший. Перевод базы на SQL и запуск управляемых блокировок. Минус этого способа в том, что сама база начинает медленнее работать раза в 2 +/-.
2) Дописать конфигурацию, чтобы при проведении чеков проверялось: проводит ли кто-то сейчас чек или нет, если проводит, то делаем ожидание и становимся в очередь, если очередь свободна, то проводим и печатаем чек.
3) Оптимизация модуля проведения чеков, так как очень много проверок и сам алгоритм проведения не очень удачный - сначала создаем чек, потом проводим, потом печатаем сам чек, потом меняем ему статус на "пробит".
4) Переписали конфигурацию, сначала все действия по проведению чека, потом только печать. Несколько уменьшило количество "сбоев" но не убрало их совсем.
5) Каждая касса своя отдельная база, с "центральной" (операторы, кладовщики, заведующая) и настройка между ними автообмена по расписанию.
Вопрос в том сталкивался ли кто-то с такой проблемой и как оптимальнее ее решить?
3 кассы работают в терминальной сессии. Фискальные.
Сервер более чем шустрый. Базы на SSD. Тест Гилева выдает 70 очков.
Проблема следующая:
Если одновременно (+/- 1 секунды) кассы пробивают чеки, то они все подвисают на несколько секунд, одна из них, после висяка пробивает и печатает чек, вторая и третья вываливается с ошибкой. Ошибки разные, в 90% случаях одна из касс вывалится с ошибкой блокировки таблиц с чеками, другая с общей ошибкой.
Сами чеки в "документах": первая касса, та которая создает нормально чек и его проводит, отрабатывает на все 100%, по остальным - чека в принципе может не быть; он может быть проведенным но без номера; может быть создан но не проведен.
Понятно, что корень проблемы в блокировках таблиц.
Я вижу такие варианты решения:
1) Не самый лучший. Перевод базы на SQL и запуск управляемых блокировок. Минус этого способа в том, что сама база начинает медленнее работать раза в 2 +/-.
2) Дописать конфигурацию, чтобы при проведении чеков проверялось: проводит ли кто-то сейчас чек или нет, если проводит, то делаем ожидание и становимся в очередь, если очередь свободна, то проводим и печатаем чек.
3) Оптимизация модуля проведения чеков, так как очень много проверок и сам алгоритм проведения не очень удачный - сначала создаем чек, потом проводим, потом печатаем сам чек, потом меняем ему статус на "пробит".
4) Переписали конфигурацию, сначала все действия по проведению чека, потом только печать. Несколько уменьшило количество "сбоев" но не убрало их совсем.
5) Каждая касса своя отдельная база, с "центральной" (операторы, кладовщики, заведующая) и настройка между ними автообмена по расписанию.
Вопрос в том сталкивался ли кто-то с такой проблемой и как оптимальнее ее решить?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) starget,
вариант дорогой: 1
вариант подешевле: 5
применимость остальных вариантов можно только по месту определить. Вариант розницы 2 на sql делал, как раз три кассы - все летало. Вариант с кассовыми узлами на отраслевке делал - тоже как вариант, правда пришлось обмен дописывать так как баги были. В вашем случае РИБ скорее всего будет, так что попроще.
вариант дорогой: 1
медленнее работать раза в 2 +/-.
скорее всего дело в неоптимальной настройке сервера
вариант подешевле: 5
применимость остальных вариантов можно только по месту определить. Вариант розницы 2 на sql делал, как раз три кассы - все летало. Вариант с кассовыми узлами на отраслевке делал - тоже как вариант, правда пришлось обмен дописывать так как баги были. В вашем случае РИБ скорее всего будет, так что попроще.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот