Как снять флаг «Оперативный учет» у документа в 1С 7.7 и предотвратить смещение точки актуальности

В процессе сопровождения старых баз на платформе 1С:Предприятие 7.7 программисты часто сталкиваются с архитектурным наследием, которое мешает текущей работе. Одной из таких проблем является флаг «Оперативный учет» у документов, которые по своей сути не должны влиять на остатки в регистрах, но при этом блокируют нормальную работу с датами. Рассмотрим ситуацию: документ «Установка цен» помечен как оперативный. Это приводит к тому, что при попытке провести его будущей датой система принудительно смещает Точку Актуальности (ТА) вперед. В результате пользователи не могут проводить текущие документы без монопольного исправления ТА, а производительность базы падает.

Разберем подробно, как правильно снять этот флаг, обойти запреты Конфигуратора и изменить логику проведения документа для работы с будущими периодами.

Почему 1С 7.7 не дает просто снять «галку» в Конфигураторе?

Проанализируем поведение системы. Когда мы открываем свойства документа в Конфигураторе и пытаемся снять флаг «Оперативный учет», программа выдает ошибку: «Существуют проведенные документы данного вида. Изменение режима оперативного учета невозможно». Это происходит потому, что 1С следит за целостностью структуры таблиц в SQL-базе или DBF-файлах. Оперативный документ имеет определенный статус в журнале (поле AppCode в таблице _1CJOURN), и простое изменение метаданных приведет к рассинхронизации логики движка и данных в таблицах.

Многие пытаются «обмануть» систему, подменяя файл 1cv7.md после внесения правок в пустой базе. Однако, как показывает практика, это не всегда помогает: если в базе остаются записи с признаком оперативного проведения, движок 1cv7.exe все равно может пытаться двигать ТА, ориентируясь на старые индексы или кэшированные данные.

Решение 1: Архитектурно правильный подход через код

Выясним причину, зачем документу «Установка цен» вообще нужна будущая дата. Обычно это требуется для того, чтобы новые цены вступили в силу с завтрашнего дня или с начала следующей недели. Для реализации этой задачи документу не обязательно быть оперативным и не обязательно иметь дату документа в будущем.

Рассмотрим по шагам, как изменить логику работы:

1. Добавим в форму документа реквизит ДатаДействия.
2. Сделаем документ неоперативным (после того как снимем флаг в Конфигураторе, способы ниже).
3. В модуле документа, в процедуре ОбработкаПроведения, будем использовать штатный метод для записи периодических реквизитов справочника с привязкой к нашей новой дате.

Посмотрим на пример кода, который позволяет устанавливать цены на любую дату, независимо от даты самого документа:

Процедура ОбработкаПроведения()
    СпрЦены = СоздатьОбъект("Справочник.Цены");
    // Предположим, мы перебираем строки документа
    ВыбратьСтроки();
    Пока ПолучитьСтроку() = 1 Цикл
        // Вместо использования ТекущийДокумент() для фиксации времени,
        // мы явно указываем дату из реквизита формы
        УстановитьРеквизитСправочника(Товар.Цена.ТекущийЭлемент(), "Цена", НоваяЦена, ДатаДействия);
    КонецЦикла;
КонецПроцедуры

При таком подходе документ может быть проведен сегодняшним числом, он не будет двигать ТА, но цены в справочнике изменятся именно на ту дату, которую указал пользователь. Это избавляет от конфликтов с оперативным учетом.

Решение 2: Прямая правка SQL для снятия ограничений Конфигуратора

Если документов в базе тысячи, и вы не хотите их распроводить для штатного снятия флага в Конфигураторе, можно прибегнуть к «хирургическому» вмешательству в таблицу _1CJOURN. Внимание: всегда делайте бэкап перед такими операциями!

Проанализируем структуру поля AppCode. В версии 7.7 для SQL это поле является битовой маской:

• 1 — документ просто проведен.
• 8 — включен признак оперативного учета.
• 9 (1 + 8) — проведенный оперативный документ.

Разберем алгоритм действий для SQL-версии:

1. Закроем все сессии пользователей и Конфигуратор.
2. Найдем внутренний идентификатор типа документа (IDDocDef). Его можно подсмотреть в самом Конфигураторе или через метаданные.
3. Выполним SQL-запрос для сброса флага оперативности у всех проведенных документов этого типа:
   Скопировать код

   
   UPDATE _1CJOURN 
   SET AppCode = 1 
   WHERE IDDocDef = 'ИД_ВАШЕГО_ДОКУМЕНТА' AND AppCode = 9
   

4. Теперь откроем Конфигуратор. Поскольку в базе больше нет записей с AppCode = 9, система позволит вам снять галочку «Оперативный учет» штатным образом.
5. Сохраним конфигурацию. Теперь новые документы будут создаваться с AppCode = 1 и перестанут требовать смещения ТА.

Важные замечания по Точке Актуальности (ТА)

Проанализируем ситуацию, когда ТА все же улетела в будущее. В 1С 7.7 Точка Актуальности — это временная отметка, на которую рассчитаны все итоги в регистрах. Если вы провели документ 2030-м годом, ТА встанет на эту дату. С этого момента:

• Любой документ, вводимый текущей датой, будет считаться проводимым «задним числом».
• Система перестанет брать готовые итоги из таблиц и будет каждый раз пересчитывать движения с начала периода, что приведет к колоссальным тормозам.
• Блокировки таблиц итогов станут постоянными.

Поэтому использование неоперативных документов для установки цен, как мы рассмотрели в первом решении — единственный верный путь для поддержания здоровья базы. Неоперативный документ записывает данные в историю (таблица _1CONST или _1CV7SCx), не обращаясь к механизму итогов и не влияя на ТА.

Резюме

Мы выяснили, что проблема смещения ТА при установке цен решается переводом документа в режим неоперативного учета. Если Конфигуратор блокирует это действие, используйте прямую правку поля AppCode в таблице _1CJOURN. После внесения правок обязательно скорректируйте программный код в ОбработкеПроведения, используя метод УстановитьРеквизитСправочника с явным указанием целевой даты. Это позволит пользователям планировать изменение цен наперед, не мешая оперативной работе склада и отдела продаж.