← На главную

Рассмотрим распространенную и весьма неприятную проблему, с которой сталкиваются пользователи программы 1С:Управление торговлей 11.5. В момент пробития чека система может внезапно «зависнуть» на 5–10 минут, выдавая служебное сообщение «Выполняется операция актуализации распределения расчетов с клиентами». Причем возникает эта ситуация плавающим образом — временами чеки пробиваются мгновенно, а иногда полностью блокируют работу кассы. Разберем по шагам, почему возникает эта задержка и как мы можем исправить ситуацию.

Проанализируем архитектурные особенности взаиморасчетов

В новых релизах 1С:УТ 11.5 разработчики существенно переработали механизм взаиморасчетов. Новая архитектура онлайн-взаиморасчетов спроектирована так, чтобы данные о долгах и оплатах контрагентов были достоверны в любую секунду времени. Это означает, что при проведении любого финансового документа (в том числе при пробитии чека) система обязана заблокировать данные клиента, выполнить сложные алгоритмы распределения (например, по методу ФИФО) и записать результат.

Ресурсоемкие вычисления частично вынесены в фоновые процессы. Но если фоновое распределение не справляется, система начинает принудительно пересчитывать все взаиморасчеты «на лету» прямо в момент проведения чека. Отключить этот механизм полностью в онлайн-схеме невозможно.

Выясним основные причины зависаний

Проанализируем ситуации, которые приводят к критическому замедлению работы при актуализации расчетов:

1. Накопление огромной истории на одном контрагенте. Часто в базах используется следующая цепочка: ЗаказКлиента ➔ РеализацияТоваровУслуг ➔ ПриходныйКассовыйОрдер ➔ ЧекККМ. Если все эти розничные продажи оформляются на одного общего контрагента (например, служебного партнера «Физлицо» или «Розничный покупатель»), а расчеты ведутся «По договорам», в базе скапливается гигантский массив данных. При каждом пробитии чека 1С пытается проанализировать всю историю долгов и авансов по этому единственному договору, что и приводит к минутным зависаниям.
2. Очередь фоновых заданий не обрабатывается. Если регламентное задание, отвечающее за фоновое распределение расчетов, отключено, зависло или завершается с ошибкой, алгоритм начинает выполнять расчеты прямо в транзакции проведения документа.
3. «Грязные» остатки в регистрах. Ручные корректировки долгов, незакрытые копейки, пересортица по объектам расчетов или активный ввод документов «задним числом» ломают хронологическую последовательность расчетов. Платформа тратит колоссальное время на попытки связать старые «зависшие» авансы с новыми реализациями.
4. Отсутствие обслуживания базы данных. При больших объемах данных и неактуальной статистике индексов СУБД SQL транзакция блокировки таблиц длится недопустимо долго.

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

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

1. Изменение бизнес-схемы для розницы (Рекомендуемый метод)

Если специфика бизнеса — это потоковые продажи физическим лицам, нам необходимо уйти от оптовой схемы документооборота. Используйте специализированное Рабочее место кассира (РМК). В этом режиме кассир пробивает обычные документы ЧекККМ, которые в конце кассовой смены сворачиваются в один сводный документ ОтчетОРозничныхПродажах. В такой цепочке тяжелые алгоритмы распределения долгов по каждому чеку просто не задействуются, так как нет индивидуальных взаиморасчетов с каждым покупателем.

2. Смена детализации расчетов

Если мы обязаны использовать цепочку оптовых документов (через заказы и реализации) для физических лиц, нам следует изменить настройки детализации расчетов в договоре или соглашении с клиентом. Измените настройку с «По договорам» на «По заказам» или «По документам расчетов». В этом случае при проведении оплаты платформа 1С будет искать и актуализировать данные только в рамках одного конкретного заказа, а не перебирать десятки тысяч строк по всему договору общего контрагента.

3. Разделение контрагентов

Еще один рабочий способ — автоматизировать создание отдельной карточки партнера и контрагента для каждого нового розничного клиента (например, идентифицируя их по номеру телефона). Это разделит финансовые потоки, и система перестанет блокировать огромные общие таблицы расчетов.

4. Аудит регламентных заданий и базы данных

Убедимся, что техническая часть работает исправно:

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

5. Использование офлайн-взаиморасчетов (как временная мера)

В некоторых релизах УТ 11.5 сохранена возможность выбора режима взаиморасчетов. Переход на режим «Офлайн» отложит тяжелое распределение долгов на фоновое задание. Это мгновенно вернет скорость пробития чеков на кассе. Однако мы должны понимать, что данные о задолженности в отчетах будут актуализироваться только после выполнения этого регламентного задания, поэтому этот метод лучше рассматривать как временное решение до исправления архитектуры документооборота.