Как организовать работу в 1С:УПП 1.3 при подключении через сервер терминалов из разных часовых поясах?

При территориально распределенной структуре компании часто возникает задача организации одновременной работы филиалов из разных часовых поясов в единой информационной базе. В конфигурации 1С:Управление производственным предприятием 1.3 (УПП), запущенной на сервере терминалов (RDP), возникает ряд архитектурных и учетных сложностей, связанных с регистрацией даты и времени документов. Проанализируем особенности поведения платформы и конфигурации, а также разберем проверенные способы решения этой задачи.

Архитектурные ограничения конфигурации УПП 1.3

Конфигурация УПП 1.3 разрабатывалась до появления в платформе развитых механизмов работы с часовыми поясами сеансов. В отличие от современных конфигураций на базе Библиотеки Стандартных Подсистем (БСП), архитектура УПП имеет следующие особенности:

1. Использование серверного времени: В подавляющем большинстве модулей документов и отчетов используется функция ТекущаяДата(), которая возвращает системное время того компьютера, на котором выполняется код (для сервера 1С — время хоста сервера, для клиентского сеанса — время терминальной сессии). Метод ТекущаяДатаСеанса() в типовом коде УПП 1.3 практически не применяется.
2. Специфика терминального доступа (RDP): По умолчанию все пользователи терминального сервера работают в контексте операционной системы хоста. Даже если на сервере включена групповая политика перенаправления часовых поясов (Time Zone Redirection), при выполнении серверного кода 1С (при проведении документов, выполнении фоновых и регламентных заданий) платформа обращается к системному времени сервера 1С, игнорируя локальное время клиента.
3. Формирование отчетов: Многие отчеты при автоматической подстановке даты окончания периода берут текущее время. Если пользователи находятся в разных поясах, интервалы выборок могут отсекать документы, проведенные коллегами из более восточных регионов, либо захватывать лишние данные.

Влияние часовых поясов на партионный учет и последовательности

Основная сложность попытки проведения документов «по местному времени» заключается в нарушении хронологии учетных событий на единой оси времени базы данных:

1. Искажение списания партий (ФИФО/ЛИФО): Если филиал в часовом поясе +7 часов проводит документ реализации своим местным временем 09:00, а головное подразделение (пояс UTC+3) проводит поступление товара в тот же физический момент в 05:00, то в единой хронологической шкале документ филиала окажется в «будущем» относительно поступления. Это приводит к зависанию остатков, списанию партий в неверном порядке и образованию отрицательных остатков.
2. Восстановление последовательностей: При партионном учете смещение времени вызывает сдвиг границ последовательностей (последовательность партионного учета, последовательность по приобретению/реализации). При этом важно помнить, что в УПП для партионного учета достаточно восстанавливать специализированные последовательности партий, не прибегая к полному перепроведению всех документов базы, что значительно снижает время блокировок.

Вариант 1. Единое расчетное время базы с фиксацией местного времени

Наиболее надежным и стандартным подходом является ведение всей учетной хронологии по единому времени головного офиса (или по поясу сервера базы данных). Все документы проводятся в единой шкале времени, что гарантирует корректность работы партионного учета, регламентных процедур закрытия месяца и расчета себестоимости.

Если руководству необходимо контролировать реальное время совершения операций сотрудниками филиалов, разберем по шагам, как это реализовать без нарушения учетной логики:

1. Добавить в документы дополнительный реквизит МестноеВремя или ЧасовойПоясПодразделения.
2. Заполнять данный реквизит при записи документа на основании часового пояса, привязанного к пользователю или подразделению.
3. Вывести данный реквизит в списки и журналы документов для визуального контроля руководством.

Вариант 2. Программная инициализация часового пояса сеанса

Если требуется, чтобы интерфейс платформы отображал время с учетом пояса пользователя, рассмотрим настройку часового пояса сеанса средствами встроенного языка.

Платформа предоставляет методы УстановитьЧасовойПоясИнформационнойБазы() и УстановитьЧасовойПоясСеанса(). Разберем пример инициализации пояса сеанса при авторизации пользователя:

// В модуле обычного приложения или модуле управляемого приложения
Процедура ПриНачалеРаботыСистемы()
    
    // Получаем часовой пояс текущего пользователя из справочника или настроек
    СтрокаПояса = ПолучитьЧасовойПоясПользователя(ПараметрыСеанса.ТекущийПользователь);
    
    Если Не ПустаяСтрока(СтрокаПояса) Тогда
        УстановитьЧасовойПоясСеанса(СтрокаПояса);
    КонецЕсли;

КонецПроцедуры

При реализации этого подхода проанализируем необходимость доработки кода конфигурации: потребуется выполнить аудит и заменить прямые вызовы ТекущаяДата() на ТекущаяДатаСеанса() в процедурах инициализации новых документов и отчетов.

Вариант 3. Использование распределенной информационной базы (РИБ)

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

1. Каждый филиал работает в отдельном узле РИБ, настроенном на локальный часовой пояс.
2. Оперативное проведение, складской и партионный учет внутри филиала происходят мгновенно без сетевых задержек.
3. Обмен данными с центральным узлом головного офиса выполняется по расписанию через планы обмена с трансляцией или сопоставлением движений.