← На главную

Ситуация, когда при одновременной работе нескольких кассиров в 1С:Управление торговлей 11 (особенно в версии 11.4 и выше) система начинает «подвисать» на 30–60 секунд, является классической для файлового режима работы базы данных при терминальном доступе (RDP). Проблема усугубляется тем, что один чек может пробиться успешно, а остальные выдают ошибку, при этом данные в базе могут искажаться: сумма фиксируется, а товарные остатки не списываются. Разберем подробно, почему это происходит и как мы можем исправить ситуацию, используя различные подходы — от программных настроек до изменения архитектуры системы.

Причина 1: Специфика блокировок в файловом режиме

Проанализируем механику работы файловой базы 1Cv8.1cd. В отличие от клиент-серверного варианта (SQL), где блокируются только конкретные строки таблиц, в файловом режиме при записи данных происходит блокировка всей таблицы целиком. Когда первый кассир нажимает кнопку «Пробить чек», система инициирует транзакцию, блокируя таблицы документов и регистров остатков. В этот момент второй кассир, нажавший ту же кнопку на секунду позже, попадает в очередь ожидания. Если выполнение операции первым пользователем затягивается (например, из-за медленного отклика кассового аппарата), у второго пользователя истекает время ожидания блокировки, и транзакция обрывается с ошибкой.

Выясним, как это можно диагностировать. Для этого нам понадобится Замер производительности в конфигураторе. Проделаем следующие шаги:

1. Запустим базу в режиме отладки.
2. Включим замер производительности перед пробитием чека.
3. Посмотрим, на каких строках кода система проводит больше всего времени.

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

Причина 2: Проблемы проброса COM-портов через RDP

Зачастую «зависание» на 60 секунд связано не с самой 1С, а с задержкой связи между сервером и кассовым аппаратом (ККТ). При работе через терминальный сервер касса обычно подключается к локальному компьютеру, а порт «пробрасывается» на сервер. Это создает огромные задержки в передаче пакетов данных. Пока 1С ждет ответа от ККТ о том, что чек успешно напечатан, она держит блокировку на таблицы базы данных. Другие пользователи в это время не могут совершить ни одного действия, требующего записи.

Рассмотрим пути решения проблемы связи:

• Переход на TCP/IP: Если ваши кассовые аппараты поддерживают подключение по сети (Ethernet или Wi-Fi), откажемся от проброса портов через RDP. Подключим ККТ напрямую по IP-адресу. Это уберет лишнее звено в виде службы проброса портов и в разы ускорит обмен данными.
• Увеличение таймаута: В настройках торгового оборудования в 1С (раздел ПодключаемоеОборудование) найдем параметры драйвера и увеличим «Таймаут» до 10000 мс. Это поможет избежать обрыва связи, но не решит проблему блокировок.

Решение 3: Оптимизация проведения и отключение расчета партий

Одним из эффективных способов ускорить проведение документа «Чек ККТ» является минимизация расчетов в момент продажи. В конфигурациях УправлениеТорговлей расчет себестоимости и партий при проведении — очень ресурсоемкая операция. Проанализируем настройки системы:

Перейдем в раздел НСИ и администрирование — Финансовый результат и контроллинг — Учет товаров. Попробуем отключить опцию расчета партий в режиме реального времени. Если расчет партий происходит при каждом пробитии чека, система вынуждена пересчитывать огромные массивы данных, удерживая таблицы заблокированными.

Чем это грозит? Только тем, что актуальную себестоимость и прибыль вы увидите после выполнения регламентного задания «Закрытие месяца» или «Расчет себестоимости». Для оперативной работы на кассах это обычно не критично.

Решение 4: Использование механизма «Отложенного проведения»

В современных версиях УТ 11 реализован механизм, позволяющий развязать процесс печати чека на ККТ и процесс отражения данных в учете. Посмотрим, как это работает: При пробитии чека система сначала отправляет команду на фискальный регистратор. Если ККТ ответил успехом, 1С записывает чек, но не выполняет его полное проведение по всем регистрам немедленно. Проведение происходит в фоновом режиме или чуть позже.

Чтобы настроить этот режим, разберем настройки РМК (Рабочего места кассира):

1. Зайдем в Продажи — Розничные продажи — Настройки РМК.
2. Убедимся, что включены опции, ускоряющие работу (например, использование упрощенного интерфейса).
3. Проверим наличие настройки фонового проведения для розничных документов.

Решение 5: Переход на 1С:Сервер или Мини-сервер

Если оптимизация настроек не помогает, значит, файловый движок 1С исчерпал свои возможности для вашего объема транзакций. Самым правильным архитектурным решением будет переход на клиент-серверный вариант. Для небольших организаций (до 5 пользователей) существует 1С:Сервер (мини-версия). Он стоит значительно дешевле полноценного сервера приложений 1С, но позволяет использовать мощь SQL-серверов (например, бесплатного PostgreSQL). Это полностью решит проблему табличных блокировок, так как SQL блокирует только те строки, с которыми идет работа в данный момент.

Решение 6: Техническая оптимизация инфраструктуры

Разберем еще несколько «железных» и системных нюансов, которые помогут ускорить работу файловой базы:

1. SSD Диски: Файловая база крайне чувствительна к скорости дисковых операций. Перенос файла 1Cv8.1cd на NVMe SSD дает ощутимый прирост скорости транзакций.
2. Исключения антивируса: Проверим, чтобы файл базы данных и временные папки пользователей (AppData\Local\1C) были добавлены в исключения антивируса на сервере. Постоянное сканирование меняющегося файла базы при каждом чеке — частая причина «зависаний».
3. Регламентные задания: В файловой базе регламентные задания (например, «Полнотекстовый поиск») могут запускаться в самый неподходящий момент. Рекомендуем ограничить их выполнение в часы пиковой нагрузки касс или полностью отключить полнотекстовый поиск через УправлениеПолнотекстовымПоиском.

Рекомендация по исправлению «пропавших» чеков

Ситуация, когда сумма в ККТ списалась, а в 1С чек пропал или выдал ошибку, крайне опасна. Для борьбы с этим в 1С предусмотрен регистр или список «Чеки ККТ, пробитые с ошибкой». Если транзакция прервалась после печати чека, но до записи в 1С, вы должны найти этот документ в статусе «Ошибка» и воспользоваться штатной функцией «Подтвердить пробитие». Никогда не удаляйте такие чеки вручную, так как это приведет к расхождению данных в 1С и ОФД (фискальном накопителе).

Подводя итог, проанализируем последовательность действий: начните с TCP/IP подключения касс и замера производительности. Если замер покажет длительное проведение — отключайте расчет партий. Если же проблема в очередях к базе — рассмотрите внедрение мини-сервера 1С. Совместное применение этих методов позволит вашим кассирам работать без задержек даже в моменты пиковых нагрузок.