В практике работы с 1С:Управление нашей фирмой (УНФ) пользователи иногда сталкиваются с пугающими симптомами: штрихкоды, созданные через внешние обработки или вручную, внезапно исчезают, а характеристики номенклатуры (например, размеры) меняются «сами собой», даже когда в системе якобы никто не работал. Разберем детально причины этого явления и пошагово пройдем путь от диагностики до полного решения проблемы.
Первое, на что стоит обратить внимание в данной ситуации — это использование Базовой версии конфигурации совместно с веб-публикацией через Apache. Рассмотрим, почему это сочетание может приводить к потере данных. Базовые версии имеют жесткие ограничения на уровне платформы по количеству одновременных сеансов и специфике работы с COM-соединениями и HTTP-запросами.
Проанализируем механизм работы веб-сервера. При использовании тонкого или веб-клиента через протокол HTTP, Apache может удерживать сеансы (так называемые «зависшие сеансы»). Если лимит соединений в базовой версии исчерпан, попытка записи нового штрихкода может прерваться без явной ошибки для пользователя. Система сообщает об успехе, но транзакция на стороне сервера откатывается из-за конфликта доступа. Важным шагом в решении стало обновление конфигурации до версии ПРОФ, что снимает ограничения на сессии и обеспечивает более стабильную работу веб-сервисов.
Если штрихкоды загружаются через внешнюю обработку (загрузка из табличной части или внешнего файла), необходимо тщательно проверить программный код. Выясним причину, по которой данные могут затираться. В 1С:УНФ штрихкоды хранятся в регистре сведений ШтрихкодыНоменклатуры. Рассмотрим типичную ошибку при написании кода загрузки:
// Опасный метод: может затереть существующие данные при неправильном поиске
НаборЗаписей = РегистрыСведений.ШтрихкодыНоменклатуры.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Номенклатура.Установить(ТекущаяНоменклатура);
// Если не добавить отбор по штрихкоду, набор очистит все старые записи!
НаборЗаписей.Записать();
Для корректной работы рекомендуется использовать МенеджерЗаписи или всегда проверять наличие дублей перед записью. Разберем правильный подход к добавлению штрихкода:
МенеджерЗаписи = РегистрыСведений.ШтрихкодыНоменклатуры.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Номенклатура = ВыбраннаяНоменклатура;
МенеджерЗаписи.Штрихкод = НовыйШтрихкод;
МенеджерЗаписи.ТипШтрихкода = ПланыВидовХарактеристик.ТипыШтрихкодов.EAN13;
МенеджерЗаписи.Прочитать();
Если Не МенеджерЗаписи.Выбран() Тогда
МенеджерЗаписи.Записать();
КонецЕсли;
Часто данные никуда не пропадают физически, но становятся невидимыми для пользователя. Посмотрим, как это происходит. В современных интерфейсах 1С поиск в списках (например, в справочнике номенклатуры) часто опирается на индекс полнотекстового поиска. Если вы массово загрузили штрихкоды через веб-сервер, индекс может не успеть обновиться мгновенно.
В результате, когда вы вводите штрихкод в поле поиска, система выдает «Ничего не найдено», хотя в базе запись существует. Чтобы исключить эту причину, необходимо выполнить следующие действия:
В рассматриваемом кейсе полное отключение ППС помогло стабилизировать отображение данных, так как система перешла на прямой поиск по базе данных.
Еще один скрытый враг стабильности — включенное Версионирование объектов. В базовых и файловых версиях запись каждой версии объекта (номенклатуры) создает значительную нагрузку на таблицу ВерсииОбъектов. Разберем ситуацию: внешняя обработка записывает штрихкод, и в этот же момент фоновое задание пытается создать версию объекта номенклатуры.
Происходит блокировка таблицы. Поскольку веб-клиент более чувствителен к таймаутам, транзакция записи штрихкода может быть отменена. Проанализируем Журнал регистрации: если в нем встречаются события «Транзакция. Отменена» с комментарием о конфликте блокировок, значит, версионирование при массовой загрузке нужно отключать.
Ситуация, когда «никто не подключался, а размер изменился», обычно связана с автоматизированными процессами. Проверим список регламентных заданий в 1С:УНФ. В этой программе работают механизмы синхронизации, которые могут изменять данные:
Чтобы гарантированно избавиться от «мистических» изменений и пропаж, выполним следующие шаги:
KeepAliveTimeout до 60 секунд, чтобы исключить разрывы соединений во время длительных транзакций.После выполнения этих действий и отключения избыточного версионирования, стабильность работы с базой данных восстанавливается, а «самопроизвольные» изменения данных прекращаются.