Часто в практике программистов и администраторов 1С возникает ситуация, когда остаток определенной номенклатуры на складе неожиданно уходит в минус. Причина бывает банальна: задним числом отменили проведение документа поступления, изменили товарный состав или перенесли реализацию. Разберем по шагам, как провести расследование, вычислить проблемный документ и понять, почему система это допустила.
Первой мыслью многих специалистов является желание прочитать журнал транзакций базы данных (LDF-файл) и выудить оттуда все записи, связанные с изменением регистра накопления ТоварыНаСкладах по конкретной номенклатуре. Проанализируем этот подход.
Прочитать лог напрямую и найти там текстовые наименования, такие как «ТоварыНаСкладах» или «Колбаса докторская», не получится. Платформа 1С хранит данные в СУБД в неявном виде. Имена объектов метаданных преобразуются во внутренние идентификаторы.
_AccumRg12345._Fld6789.Чтобы сопоставить метаданные 1С с физическими таблицами и полями SQL, нам необходимо воспользоваться встроенной функцией:
СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных(Метаданные.РегистрыНакопления.ТоварыНаСкладах);
Для Каждого СтрокаТаблицы Из СтруктураБД Цикл
Сообщить("Имя таблицы в SQL: " + СтрокаТаблицы.ИмяТаблицыХранения);
КонецЦикла;
Узнав точные имена таблиц, мы можем попытаться проанализировать лог с помощью недокументированной функции MS SQL fn_dblog или сторонних утилит (например, ApexSQL Log). Однако это крайне трудоемкий процесс, требующий высокой квалификации в администрировании СУБД.
Если база MS SQL работает в режиме «Полной» (Full) модели восстановления и регулярно делаются бэкапы журнала транзакций, мы можем восстановить базу на любую конкретную минуту. Рассмотрим этот метод:
Допустим, ночные бэкапы делаются раз в сутки, но отрицательный остаток образовался одним днем. Мы можем развернуть копию базы данных на разное время (например, на 12:00, 15:00 и 17:00). Применяя метод половинного деления, мы сужаем временной интервал и точно вычисляем, в какой промежуток времени и каким именно документом остаток был списан в минус. Это быстрее и нагляднее, чем парсинг сырых логов.
Лезть напрямую в MS SQL — это крайняя мера. Посмотрим на эффективные инструменты внутри самой платформы 1С, которые помогут решить задачу значительно быстрее.
1. Журнал регистрации 1С
В отличие от транзакционного лога СУБД, журнал регистрации ведется в понятных пользователю терминах. Отфильтруем его за проблемный день по следующим событиям:
Фильтр нужно наложить на все виды документов, делающих движения по складу (Реализация товаров, Поступление товаров, Списание, Комплектация и т.д.). Так мы быстро вычислим, кто из пользователей вносил изменения в старые или текущие документы.
2. Версионирование объектов
Если в базе (например, УПП 1.3 или УТ) включено версионирование документов, и документов не сотни тысяч за период, мы можем просмотреть историю изменения конкретных приходных или расходных ордеров. Это позволит увидеть, кто поменял склад, количество или номенклатуру.
3. Анализ партионного учета
Если в конфигурации ведется партионный учет, выясним причину через партии. Нужно сформировать отчет по регистру партий товаров на складах. По каким партиям образовались минусы — те документы Поступления (или документы оприходования), скорее всего, и были распроведены или изменены задним числом.
4. Групповое перепроведение на копии
Развернем вчерашний ночной бэкап и запустим последовательное перепроведение документов за проблемный день. В момент проведения проблемного документа система сама выдаст служебное сообщение о нехватке остатков, что сразу укажет на виновника нарушения последовательности.
В завершение расследования обязательно проанализируем, почему система вообще позволила увести остаток в минус. Проверьте следующие настройки:
Направить свои силы лучше не на "наказание виновных", а на аудит прав доступа и закрытие технических "дыр", позволяющих проводить документы без должного контроля.