В процессе работы с программными продуктами «1С:Предприятие 8», особенно в конфигурациях на обычных формах, таких как Управление торговлей 10.3, пользователи и администраторы иногда сталкиваются с загадочным поведением системы. Представим ситуацию: на часах сервера 10:00 утра, бухгалтер создает документ, записывает его — время отображается корректно. Однако стоит нажать кнопку «Провести», как время документа внезапно прыгает вперед, например, на 6 часов, и документ оказывается проведенным будущим временем (16:00).
Такая ситуация критична для учета, так как нарушается последовательность документов, возникают ошибки по отрицательным остаткам в течение дня и некорректно рассчитывается себестоимость по ФИФО. В этой статье мы подробно разберем, почему это происходит и как устранить данную проблему, используя комплексный подход: от настроек операционной системы до программного кода.
Первым делом нам необходимо исключить самую неочевидную системную причину. Многие администраторы проверяют время на рабочем столе сервера под своей учетной записью, но забывают, что сервер «1С:Предприятия» работает как служба. Рассмотрим этот механизм подробнее.
Обычно служба сервера 1С запускается от имени специального пользователя (например, USR1CV8). У этого пользователя в операционной системе Windows создается собственный профиль с индивидуальными региональными настройками и, что самое важное, собственным часовым поясом. Если в профиле этого системного пользователя установлен часовой пояс UTC+6, а администратор настраивал сервер под своим профилем с UTC+0, то при выполнении серверных процедур (к которым относится проведение документа) система будет брать время именно из настроек службы.
Для решения этой проблемы мы рекомендуем выполнить следующие действия:
services.msc.HKEY_USERS.В платформе 1С существует разделение понятий времени. Разберем, чем отличаются функции ТекущаяДата() и ТекущаяДатаСеанса(). Проанализируем ситуацию: если информационная база работает в клиент-серверном варианте, ТекущаяДата() на сервере вернет время серверной ОС. Однако ТекущаяДатаСеанса() возвращает время с учетом часового пояса, установленного для конкретного сеанса пользователя или всей информационной базы.
Для диагностики мы можем использовать простой код в консоли запросов или обработке:
Сообщить("Системная дата сервера: " + ТекущаяДата());
Сообщить("Дата сеанса пользователя: " + ТекущаяДатаСеанса());
Сообщить("Часовой пояс сеанса: " + ПолучитьЧасовойПоясСеанса());
Если вы видите разницу в несколько часов, значит, проблема кроется в настройках часового пояса информационной базы. Проверить это можно в меню Администрирование — Настройки параметров системы (или программно через ПолучитьЧасовойПоясИнформационнойБазы()).
Одной из ключевых особенностей УТ 10.3 является использование оперативного проведения. Выясним причину, почему оно влияет на время. Когда документ проводится текущей датой (сегодняшним числом), платформа 1С считает это проведение оперативным. В этом режиме система старается обеспечить актуальность данных на текущий момент времени.
Если документ записывается «задним числом» (даже если это было 5 минут назад), при нажатии кнопки «Провести» в режиме оперативного проведения платформа может автоматически изменить время документа на текущее системное время сервера. Рассмотрим, как это происходит:
Если же при этом наблюдается скачок на 6 часов, это означает, что системные часы сервера «спешат» относительно клиентских машин, либо настройки UTC на сервере баз данных (SQL) и сервере приложений рассинхронизированы.
Проанализируем работу системы на уровне базы данных. Платформа 1С хранит все значения типа Дата в формате UTC (Universal Coordinated Time). Преобразование в локальное время пользователя происходит в момент отображения данных в интерфейсе.
Если на сервере SQL некорректно настроено смещение времени или не установлены последние обновления часовых поясов (что часто случалось при отмене переходов на летнее/зимнее время), может возникать ситуация, когда при записи транзакции SQL-сервер интерпретирует время иначе, чем сервер 1С. В результате при записи в таблицу _Document данные попадают со смещением.
Для исправления ситуации необходимо:
Если база является нетиповой (в нее вносились изменения), велика вероятность наличия программного кода, который принудительно меняет время. В конфигурации УТ 10.3 часто реализуют логику «расстановки» документов в течение дня: например, все поступления ставятся на 08:00 утра, а все реализации — на конец дня, чтобы избежать нехватки остатков при проведении документов одной датой.
Нам стоит проверить наличие вызовов метода УстановитьВремяДокумента(). Этот метод может принимать различные параметры режима автоустановки времени. Посмотрим на пример кода, который может быть встроен в модуль объекта или в подписку на событие ПередЗаписью или ПриПроведении:
// Пример кода, который может изменять время документа
Если ЭтоНовый() Тогда
// Установка времени в конец дня для реализации
ЭтотОбъект.УстановитьВремяДокумента(АвтоВремя.КонецДня);
ИначеЕсли РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
// Принудительное текущее время
ЭтотОбъект.Дата = ТекущаяДатаСеанса();
КонецЕсли;
Чтобы найти виновника, выполним глобальный поиск по конфигурации (Ctrl+Shift+F) по ключевым словам: .Дата =, УстановитьВремяДокумента, ДобавитьМесяц (иногда так ошибочно прибавляют часы через ДобавитьМесяц(Дата, 0) + 6*3600).
Как отметил автор одного из сообщений, иногда помогает только полная перезагрузка с «выгоном» всех пользователей. Это указывает на проблему с серверным кэшем метаданных. В процессе работы сервер 1С (процессы rphost) кеширует параметры сеансов и настройки базы. Если произошел сбой в электропитании или некорректное изменение системного времени «на лету», кэш может выдавать неверные данные о текущем моменте времени.
Рассмотрим порядок правильной очистки кэша сервера:
C:\Program Files\1cv8\srvinfo).reg_) и внутри нее папку snccntx.snccntx — это кэш сеансов.LocalSettings\Temp для пользователя, от имени которого работает сервер 1С.Подводя итог, можно сказать, что «глюк» с прибавлением 6 часов чаще всего связан с рассинхронизацией часовых поясов между профилем службы сервера 1С, настройками сеанса информационной базы и системным временем SQL-сервера. Тщательная проверка этих настроек в сочетании с анализом программного кода оперативного проведения позволяет полностью устранить данную проблему.