Почему документы в 1С:ЗУП проводятся только со второго раза и как это исправить?

В процессе работы с конфигурацией 1С:Зарплата и управление персоналом 3.1 (особенно на релизах ветки 3.1.8) пользователи часто сталкиваются с крайне странным поведением системы. При нажатии на кнопку Провести и закрыть документ визуально меняет статус на «Проведен», однако данные в отчетах не обновляются. Стоит зайти в этот же документ и провести его повторно — данные магическим образом появляются в регистрах и отчетах. Проанализируем причины этой технической аномалии и разберем по шагам методы её устранения.

Причина 1: Ошибки кэширования и логика «грязных» данных

Разберем ситуацию, которая часто возникала в релизе 3.1.8.112. В этой версии разработчики внедрили механизмы оптимизации расчета, которые призваны ускорить работу системы. Однако на практике возник побочный эффект: система ошибочно определяет состояние данных как «чистое» (не измененное). Выясним причину этого поведения.

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

Причина 2: Проблемы платформы 8.3.12 и серверные транзакции

Проанализируем влияние платформы. Использование версии 8.3.12.1616 в связке с серверной базой данных (MS SQL Server) накладывает свои особенности. Существовал известный баг платформы, связанный с управлением блокировками. Рассмотрим подробнее механизм возникновения ошибки:

1. Пользователь инициирует транзакцию проведения.
2. Платформа успешно записывает изменения в таблицу самого документа.
3. Транзакция по записи движений в связанные регистры (например, НачисленияУдержанияПоСотрудникам или ВзаиморасчетыССотрудниками) «зависает» или тихо откатывается из-за внутренних конфликтов платформы при управлении блокировками.
4. Пользователь не видит ошибки, так как основная транзакция записи объекта завершена.

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

Причина 3: Механизм фонового пересчета в ЗУП 3.1

Посмотрим на пример работы документа Начисление зарплаты и взносов. В ЗУП 3.1 реализован механизм фонового пересчета зарплаты. Если в момент проведения документа система обнаруживает, что по сотрудникам в документе изменились кадровые данные или графики работы в других сеансах, запускается фоновое задание. Это задание может конфликтовать с процессом записи движений. Первое нажатие Провести лишь «усмиряет» фоновый процесс, а второе — реально фиксирует результат.

Метод исправления 1: Проверка движений документа

Прежде чем приступать к обновлению, проверим, что именно происходит в базе при первом проведении. Выполним следующие действия:

1. Откроем проблемный документ после первого проведения (когда статус уже «Проведен»).
2. Перейдем в меню Еще — Движения документа.
3. Если список регистров пуст или в них отсутствуют записи, значит, мы столкнулись именно с программным сбоем формирования движений.

Если движения отсутствуют, попробуем применить временное решение, предложенное опытными администраторами: сначала Отменить проведение, а затем снова нажать Провести. Это гарантированно очищает старые записи и инициализирует новый цикл проведения.

Метод исправления 2: Очистка серверного кэша и настройка SQL

Рассмотрим технические шаги для системного администратора. Часто проблема кроется в «засорении» папок сеансовых данных на сервере 1С. Разберем процедуру очистки:

1. Остановите службу 1C:Enterprise 8.3 Server Agent.
2. Перейдите в каталог кластера серверов (по умолчанию это C:\Program Files\1cv8\srvinfo).
3. Найдите и очистите содержимое папок snccntx и conf. Это удалит некорректные кэшированные данные сеансов.
4. Запустите службу сервера.

Для серверных баз на MS SQL Server крайне рекомендуется включить режим READ_COMMITTED_SNAPSHOT. Это позволит избежать блокировок при чтении данных во время их записи. Выполним SQL-скрипт:

ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;

Метод исправления 3: Обновление конфигурации и платформы

Как показывает практика, наиболее стабильным решением является уход с «сырого» релиза 3.1.8.112. Выясним, на какие версии стоит ориентироваться:

• Если вы планируете оставаться в ветке 3.1.8, необходимо обновиться минимум до 3.1.8.137 (от 29.10.18) или выше. В этих патчах разработчики 1С внесли исправления в процедуру ОбработкаПроведения для исключения прерывания транзакции при закрытии формы.
• Оптимальным вариантом будет переход на долгосрочную ветку поддержки (например, 3.1.10, 3.1.14 или актуальные текущие релизы).
• Платформу рекомендуется обновить до версии 8.3.14 или выше, так как в них существенно переработаны механизмы взаимодействия с сервером базы данных в части записи наборов записей регистров.

Резюме действий для исправления ситуации

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

1. Диагностика: убедитесь через «Движения документа», что записи в регистрах действительно отсутствуют после первого нажатия кнопки.
2. Обходной путь: используйте последовательность «Отмена проведения» — «Проведение» вместо простого перепроведения уже проведенного документа.
3. Техническая профилактика: выполните тестирование и исправление базы через конфигуратор, выбрав пункт Пересчет итогов.
4. Кардинальное решение: запланируйте обновление платформы до версии не ниже 8.3.14 и конфигурации ЗУП до актуального релиза. Это устранит саму программную причину возникновения «фантомного» проведения.