При работе в конфигурации 1С:Управление торговлей (редакция 11.4) пользователи часто сталкиваются со странным поведением программы: реальные складские остатки не совпадают с тем количеством, которое отображается на рабочем месте кассира (РМК). Ситуация усложняется, когда при проверке базы через утилиту тестирования и исправления (ТиИ) выявляются многочисленные ошибки логической целостности и уникальности кодов справочников. Рассмотрим подробно причины возникновения этих проблем и разберем пошаговые инструкции по их устранению.
Сценарий проблемы выглядит следующим образом: на начало дня остаток товара в магазине составляет 2 штуки, оформляется приход еще на 2 штуки, однако кассир при подборе видит доступный остаток в количестве 5 штук. Выясним, почему файловый режим работы, сетевые терминалы и особенности проведения документов в последних версиях УТ 11 приводят к такому результату.
Причина 1: Механизм транзакционных блокировок в файловой базе данных
В файловом варианте работы платформы 1С (база данных в формате 1Cv8.1CD) при выполнении транзакции записи или проведения документа блокировка накладывается не на отдельные строки таблиц, а на таблицы базы данных целиком. Когда в магазине одновременно работают три кассира в терминальном режиме и пытаются пробить чеки на одной ККТ (или через виртуальный фискальный регистратор), возникает следующая цепочка событий:
Причина 2: Архитектура хранения остатков («Распределение запасов»)
В современных редакциях 1С:Управление торговлей данные для отчетов (например, «Ведомость по товарам на складах») и данные для подбора товаров в РМК берутся из разных регистров:
ТоварыНаСкладах.РаспределениеЗапасов.В условиях постоянных взаимных блокировок файловой СУБД фоновое задание по обновлению регистра РаспределениеЗапасов не может своевременно записать данные или завершается с ошибкой. Из-за этого регистры рассинхронизируются: отчет по складу показывает корректный остаток (например, 3 шт.), а в РМК кассир видит устаревшие или поврежденные данные (5 шт.).
Для исправления рассинхронизации остатков и предотвращения сбоев транзакций выполним следующие действия:
Шаг 1. Восстановление распределения запасов
В конфигурации УТ 11 встроен штатный инструмент для исправления ошибок в регистре распределения. Выполним его запуск:
ИсправлениеОшибокВРегистреСведенийРаспределениеЗапасов.РаспределениеЗапасов фактическим движениям документов.Шаг 2. Разделение кассового оборудования
Использование одного виртуального или физического фискального регистратора на три терминальные кассы в рамках файловой базы — грубая архитектурная ошибка. Драйвер ККТ монопольно захватывает сетевой порт или виртуальный COM-порт во время печати чека. Это приводит к зависаниям сеансов 1С и некорректным откатам транзакций. Настоятельно рекомендуем:
При тестировании и исправлении поврежденной базы данных часто выводится протокол со следующими ошибками:
Справочник.НоменклатураПоставщиков Грунт ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0 Не определен владелецКод справочника стал неуникальным: НоменклатураПоставщиковПроанализируем причину. Эти ошибки возникают из-за некорректного использования внешних обработок загрузки данных (например, популярной обработки ЗагрузкаДанныхИзТабличногоДокумента_УФ_v2.epf). При импорте товаров из файлов Excel пользователи загружают справочник напрямую, минуя стандартные бизнес-логики и проверки платформы. Справочник НоменклатураПоставщиков является подчиненным справочнику Партнеры. Если при загрузке поле Владелец не было заполнено или было заполнено битой ссылкой, в базе появляются «сиротские» записи без владельца. Отключение функционала использования номенклатуры поставщиков в настройках программы не решает проблему — поврежденные записи физически остаются в таблицах СУБД.
Проанализируем, как локализовать и исправить эти ошибки с помощью консоли запросов и программного кода.
Шаг 1. Поиск поврежденных записей без владельца
Откроем внешнюю обработку «Консоль запросов» для управляемых форм. Напишем и выполним запрос для выявления записей справочника НоменклатураПоставщиков, у которых не определен владелец:
ВЫБРАТЬ
НоменклатураПоставщиков.Ссылка КАК Ссылка,
НоменклатураПоставщиков.Код КАК Код,
НоменклатураПоставщиков.Наименование КАК Наименование,
НоменклатураПоставщиков.Владелец КАК Владелец
ИЗ
Справочник.НоменклатураПоставщиков КАК НоменклатураПоставщиков
ГДЕ
(НоменклатураПоставщиков.Владелец = ЗНАЧЕНИЕ(Справочник.Партнеры.PutayaСсылка)
ИЛИ НоменклатураПоставщиков.Владелец.Ссылка ЕСТЬ NULL)
Данный запрос вернет список всех элементов, которые были загружены некорректно и вызывают сбои при проверке логической целостности.
Шаг 2. Программное удаление «битых» элементов
Если функционал номенклатуры поставщиков в вашей системе не используется, эти поврежденные записи можно безболезненно удалить. Для этого создадим внешнюю обработку и напишем следующий программный код, выполняющий непосредственное удаление элементов без владельца:
Выборка = Справочники.НоменклатураПоставщиков.Выбрать();
ЗаписейУдалено = 0;
Пока Выборка.Следующий() Цикл
// Проверяем заполненность реквизита "Владелец"
Если Не ЗначениеЗаполнено(Выборка.Владелец) Или Выборка.Владелец.ПолучитьОбъект() = Неопределено Тогда
Попытка
ОбъектНоменклатуры = Выборка.ПолучитьОбъект();
// Выполняем непосредственное удаление из базы данных
ОбъектНоменклатуры.Удалить();
ЗаписейУдалено = ЗаписейУдалено + 1;
Исключение
Сообщить("Не удалось удалить элемент: " + Выборка.Наименование + " Ошибка: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецЦикла;
Сообщить("Успешно удалено поврежденных записей: " + ЗаписейУдалено);
Если удалять записи полностью нельзя (например, они задействованы в документах поступления), необходимо программно назначить им владельца. Для этого создайте в справочнике Партнеры служебный элемент (например, контрагента «Служебный партнер для загрузки») и укажите его ссылку в поле Владелец для всех дефектных записей перед вызовом метода Записать().
Шаг 3. Устранение неуникальности кодов
После очистки записей без владельцев необходимо решить проблему с повторяющимися кодами в справочнике. Для этого запустим процедуру тестирования и исправления в конфигураторе:
Если после выполнения всех регламентных процедур в файловой базе при пиковых нагрузках на кассах продолжают возникать ошибки блокировок и «плавать» остатки, единственным надежным и системным решением является переход на клиент-серверный вариант работы (SQL).
Для малых предприятий с небольшим количеством рабочих мест покупка полноценной лицензии на сервер 1С:Предприятие экономически нецелесообразна. Однако у фирмы 1С существует специальное предложение — «1С:Предприятие 8.3. Сервер МИНИ на 5 пользователей». Данная лицензия стоит значительно дешевле стандартного сервера и позволяет запустить полноценный клиент-серверный вариант работы на СУБД PostgreSQL (которая является бесплатной и поставляется с открытым исходным кодом).
Переход на СУБД PostgreSQL с использованием Сервера МИНИ гарантирует: