Представим типичную стрессовую ситуацию для розничной или оптовой торговой точки: еще вчера, 31 августа, менеджеры и кассиры спокойно выписывали накладные и пробивали чеки — все остатки товаров были видны и актуальны. Но наступает утро 1 сентября, программа запускается, и пользователи с ужасом обнаруживают, что все остатки полностью обнулились. При этом, если в отчете или подборе установить дату «31 августа», все товары снова чудесным образом появляются на складах. Работа магазина заблокирована, клиенты уходят, а руководство требует немедленного решения.
В этой статье мы подробно разберем, почему возникает эта проблема, как устроен механизм расчета остатков в платформе «1С:Предприятие 7.7», и пошагово восстановим работоспособность базы данных «1С:Торговля и Склад».
Для специалистов, привыкших работать в современных конфигурациях на платформе «1С:Предприятие 8.3» (таких как «Управление торговлей» или «Управление нашей фирмой»), поведение старой «семерки» может показаться странным. В современных базах данных итоги и остатки рассчитываются динамически и бесшовно. В «1С 7.7» архитектура хранения данных устроена иначе.
Ключевую роль здесь играет понятие Точки Актуальности (ТА). ТА — это специальная системная отметка (конкретный момент времени, привязанный к последнему проведенному документу), до которой платформа гарантирует мгновенный доступ к рассчитанным и актуальным оперативным итогам. База данных физически хранит эти итоги помесячно в специальных таблицах.
Проанализируем структуру хранения регистров в СУБД формата DBF:
RA*.dbf): содержат подробные записи обо всех приходах и расходах, созданных документами за все время ведения учета.RG*.dbf): хранят рассчитанные остатки на конец каждого закрытого месяца, а также текущие оперативные остатки на момент ТА.Когда наступает новый календарный месяц (в нашем примере — 1 сентября), для системы этот день считается «будущим» по отношению к текущей точке актуальности, если ТА осталась в августе. Если пользователь формирует отчет на 1 сентября, программа обращается к таблице итогов RG*. Но поскольку период сентября еще не открыт и ТА не перенесена вперед, физических записей итогов на сентябрь в базе данных просто не существует. Из-за этого система выдает нулевые остатки, хотя документы поступления и продаж за прошлые периоды никуда не исчезли.
Выяснив причину, рассмотрим три последовательных метода решения этой проблемы — от самого простого и быстрого до радикального восстановления поврежденных таблиц.
В большинстве случаев для решения проблемы достаточно штатно сдвинуть ТА и открыть новый расчетный период. Разберем этот процесс по шагам:
Операции -> Управление оперативными итогами.После завершения операции можно запустить программу в обычном (немонопольном) режиме и проверить остатки. Если они появились — проблема успешно решена.
Иногда при попытке сдвинуть точку актуальности или открыть новый период программа аварийно завершает работу, зависает или выдает системные ошибки. Часто это связано с повреждением индексных файлов базы данных, которые «застревают» и не позволяют корректно обновить таблицы остатков.
В такой ситуации выполним принудительную переиндексацию таблиц:
*.cdx. Это служебные индексные файлы, которые не содержат пользовательских данных, а лишь ускоряют поиск.*.cdx. Внимание: файлы с расширением *.dbf (таблицы данных) и *.md (конфигурация) трогать категорически запрещено!Если предыдущие методы не принесли результата, либо если при попытке переноса ТА база данных сообщает об ошибках переполнения (например, размер файлов RG*.dbf приблизился к критическому для формата DBF лимиту в 2 Гб), потребуется выполнить очистку таблиц итогов с последующим их восстановлением.
Этот метод основан на том, что таблицы движений RA* содержат всю первичную информацию. Мы можем полностью удалить таблицы остатков RG*, а затем заставить программу пересчитать их с нуля на основе первичных документов.
Выполним процедуру по шагам:
RG (например, rg*.dbf и соответствующий ему rg*.cdx). Этим действием мы полностью обнулим кэш остатков во всех регистрах.Администрирование -> Тестирование и исправление ИБ.RA* и воссоздаст чистые, корректные файлы итогов RG*, автоматически установив правильную Точку Актуальности.После успешного завершения пересчета закроем Конфигуратор и запустим программу в режиме «Предприятие». Все остатки на 1-е число нового месяца гарантированно вернутся на свои места.
Описанная проблема с ТА — это архитектурное ограничение устаревшей платформы «1С:Предприятие 7.7», разработанной более двадцати лет назад. Помимо регулярных ручных манипуляций при переходе на новые месяцы, работа в таких базах сегодня сопряжена с серьезными рисками:
Для стабильной и комфортной работы настоятельно рекомендуется запланировать переход на современные программные продукты линейки «1С:Предприятие 8.3», где подобные проблемы с остатками полностью исключены за счет автоматического и бесшовного управления итогами регистров.