При работе с распределенными базами данных (УРБД) и создании периферийных узлов в 1С:Предприятии 7.7 нередко возникает ситуация, когда в новой базе искажаются остатки регистров. Чаще всего это проявляется так: отчет за узкий период не видит входящего сальдо, однако при расширении временного интервала начальные остатки внезапно появляются. Проанализируем внутренние механизмы хранения итогов, выясним ключевые причины подобных сбоев и разберем практические способы их устранения.
Для понимания корня проблемы рассмотрим структуру регистра накопления в 1С 7.7. Данные разделены на две таблицы:
RA — содержит детальные записи операций документов с флагом прихода или расхода (DEBKRED).RG — хранит периодические срезы остатков на начало каждого расчетного периода (обычно начало месяца) плюс текущие оперативные итоги на момент точки актуальности (ТА).Когда формируется отчет на произвольную дату, система не сканирует всю историю с самого начала учета. Платформа берет готовый срез из таблицы RG на начало соответствующего месяца и последовательно накладывает на него движения из RA до указанного момента. Если промежуточные месячные записи в RG повреждены, не рассчитаны или содержат скрытые расхождения, платформа не может опереться на ближайший срез и выполняет откат к более ранним корректным данным. Именно поэтому при увеличении периода отчет начинает «видеть» остаток.
Рассмотрим, почему сдвиг точки актуальности назад и возвращение ее вперед помогает лишь частично. При смещении ТА назад пересчет записей таблицы RG выполняется только в диапазоне между выбранной датой и текущим положением ТА. Все срезы, созданные ранее выбранной точки, остаются без изменений. Если ошибка кроется в давних периодах, сдвигать ТА необходимо на дату самого первого документа в информационной базе.
Одной из главных причин некорректного чтения итогов в файловых базах является ограничение размера таблиц. Разберем технические особенности:
.DBF) или индексов (.CDX) свыше 1 Гб (0x40000000 байт) чтение данных начинает давать сбои. Платформа пропускает часть записей или возвращает пустые результаты.0x7FFFFFFF байт) таблица полностью блокируется и выдает критическую ошибку ввода-вывода.Если размер таблицы итогов RG превышает размер таблицы движений RA, это свидетельствует о том, что регистр не закрывается в ноль. В 1С 7.7 строка регистра с определенной комбинацией измерений переносится из месяца в месяц до тех пор, пока абсолютно все ее ресурсы не станут равны нулю. Если в учете количество списалось в 0, а сумма осталась (или наоборот), эта строка сохраняется в каждом последующем месячном срезе, приводя к лавинообразному росту файла RG.
Посмотрим на типичную структуру регистра партий в конфигурации «Торговля и Склад 9.2»:
# Таблица RG328: Регистр ПартииНаличие
# Измерения: SP4061 (Фирма), SP330 (МОЛ), SP331 (Номенклатура),
# SP340 (СтатусПартии), SP341 (Партия), SP1554 (ДатаПартии), SP7404 (ЦенаПрод)
# Ресурсы: SP342 (Количество), SP421 (СуммаУпр), SP343 (СуммаРуб), SP344 (СуммаБезНДС)
Наличие в измерениях реквизитов с высокой вариативностью (например, ЦенаПрод или ДатаПартии) приводит к взрывному росту уникальных комбинаций. Если при списании партии хотя бы одно измерение заполнено некорректно, закрытия не происходит.
Разберем по шагам комплекс мер для восстановления корректности итогов и уменьшения объема таблиц.
RG (записи, где все ресурсы равны 0, но строка продолжает храниться в срезах). Это позволяет уменьшить размер файла итогов в 2–3 раза..CDX в каталоге базы данных, запустим конфигуратор и выполним пункт меню Администрирование — Тестирование и исправление ИБ с флагами «Реиндексация» и «Пересчет итогов».RG.ЦенаПрод и ДатаПартии из измерений в реквизиты регистра или справочника, а также отключим флаги отбора итогов у измерений, не требующих быстрого фильтра, чтобы сократить размер индексного файла .CDX.1SUPDTS, 1SDWNDS и корректировать код узла в 1SSYSTEM, избегая искажений данных при стандартной выгрузке образов.