В распределенных информационных базах (РИБ) на базе конфигурации «1С:Управление торговлей 11» специалисты часто сталкиваются со специфической проблемой: документы «Перемещение товаров» в подчиненных узлах отображаются как проведенные (с зеленой галочкой), но фактически не делают никаких движений по регистрам накопления. Из-за этого товары пропадают из товарных отчетов (например, ТОРГ-29), нарушается складской учет, а для исправления ситуации пользователям приходится вручную перепроводить документы, причем иногда даже за прошлые периоды.
В этой статье мы подробно разберем, почему возникает этот сбой, проанализируем неочевидные внутренние механизмы платформы 1С и конфигурации УТ 11, а также предоставим пошаговые инструкции и примеры кода для окончательного решения проблемы.
Для начала рассмотрим техническую сторону работы распределенных баз. Когда документ создается и проводится в центральной базе, он регистрируется к обмену. При синхронизации XML-пакет передает данные в подчиненный узел. В этот момент на стороне приемника могут сработать несколько механизмов, приводящих к потере движений.
Проведен = Истина, но сами движения по регистрам сразу не формируются. Документ помещается в специальный регистр сведений — очередь отложенного проведения. Позже регламентное задание должно запустить проведение этих документов в фоновом режиме. Если задание зависает, завершается с ошибкой или заблокировано другими процессами, документы так и остаются «проведенными», но пустыми внутри.ТоварыНаСкладах или ВыручкаИСебестоимостьПродаж). В итоге из центральной базы переносится только заголовок и табличная часть документа, а движения, сформированные в центре, не передаются. Принимающая база при этом не инициирует автоматическое проведение «на лету» из-за экономии ресурсов.К отгрузке, Отгружено, Принято. Движения по складу-получателю делаются только в финальном статусе. Если при обмене возникает коллизия версий и статус документа откатывается назад, движения прихода стираются, хотя сам документ визуально проведен.Прежде чем переходить к доработке конфигурации, выполним базовую проверку системы. Нам нужно локализовать проблему и понять, в какой момент «ломаются» движения.
Проанализируем ситуацию по следующему алгоритму:
ВыполнениеОтложенныхДвиженийПоРасчетамСПартнерами и смежные складские задания выполняются регулярно и не завершаются аварийно.ТоварыНаСкладах или ВыручкаИСебестоимостьПродаж.Для того чтобы быстро находить проведенные документы перемещения, у которых по какой-то причине стерлись движения по складам, программист может использовать простую обработку или воспользоваться консолью запросов. Разберем пример запроса, который находит такие «пустые» документы:
ВЫБРАТЬ
Перемещение.Ссылка КАК ДокументСсылка,
Перемещение.Дата КАК Дата,
Перемещение.Номер КАК Номер
ИЗ
Документ.ПеремещениеТоваров КАК Перемещение
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
ПО Перемещение.Ссылка = ТоварыНаСкладах.Регистратор
ГДЕ
Перемещение.Проведен = ИСТИНА
И Перемещение.ПометкаУдаления = ЛОЖЬ
И ТоварыНаСкладах.Регистратор ЕСТЬ NULL
Этот запрос соединяет таблицу документов перемещения с таблицей записей регистра накопления ТоварыНаСкладах. Если документ отмечен как проведенный, но записей в регистре нет (значение NULL), система выведет его в список. Такую выборку можно сразу передать в цикле на программное перепроведение.
Если обмен данными между базами настроен через «Конвертацию данных 2.1» (или используются правила регистрации и обмена в составе БСП), мы можем гарантировать проведение документа сразу в момент загрузки в принимающую базу. Для этого в правилах обмена объектами (ПКО) для документа ПеремещениеТоваров в обработчике события «После загрузки» необходимо прописать принудительную попытку проведения в неоперативном режиме.
Рассмотрим пример кода, который решает эту задачу:
Попытка
Если Объект.Проведен Тогда
// Запускаем принудительное проведение в неоперативном режиме, чтобы сформировать движения
Объект.Записать(РежимЗаписиДокумента.Проведение, РежимПроведенияДокумента.Неоперативно);
КонецЕсли;
Исключение
// Если проведение не удалось (например, из-за нехватки остатков), записываем документ просто как объект
Объект.Проведен = Ложь;
Объект.Записать(РежимЗаписиДокумента.Запись);
// Фиксируем ошибку в Журнале регистрации для последующего анализа администратором
ЗаписьЖурналаРегистрации(
"ОбменДанными.ОшибкаПроведенияПриЗагрузке",
УровеньЖурналаРегистрации.Предупреждение,
Объект.Метаданные(),
Объект.Ссылка,
"Не удалось провести документ перемещения при загрузке: " + ОписаниеОшибки()
);
КонецПопытки;
Этот код принудительно перепроводит загруженный документ перемещения. Если проведение завершается с ошибкой (например, из-за жесткого контроля отрицательных остатков на складе-отправителе в подчиненном узле), транзакция не прерывает весь обмен. Вместо этого документ аккуратно снимается с проведения (чтобы не вводить в заблуждение пользователей) и записывается, а подробный текст ошибки пишется в Журнал регистрации. После этого системный администратор сможет легко устранить первопричину (например, догрузить недостающий документ поступления товара).
Если сбои происходят регулярно и затрагивают старые периоды, рекомендуем выполнить регламентные процедуры обслуживания базы данных 1С:
Проверка логической целостности и Реиндексация таблиц информационной базы. Это исключит физическое повреждение таблиц базы данных SQL или файловой версии.Пересчет итогов. Часто именно расхождение реальных движений со сводными таблицами итогов в регистрах накопления приводит к тому, что отчеты перестают видеть движения документов.Применение этих методов позволит вам полностью ликвидировать проблему «пропадающих» перемещений, гарантирует актуальность товарных отчетов и значительно снизит нагрузку на техническую поддержку со стороны пользователей.