Нередко при интеграциях, обменах данными или исправлении исторической информации возникает ситуация: документы поступления и реализации загружены на одну и ту же дату и время (например, ровно 00:00:00). Требуется создать и провести промежуточный документ — например, перемещение товаров со склада на склад — так, чтобы при проведении он гарантированно видел остатки от поступления, а последующая реализация видела остатки от перемещения. Разберем, как устроена ось времени в платформе 1С, почему невозможно произвольно «вклиниться» между документами с одинаковой секундой без изменения данных и какие существуют решения этой задачи.
Чтобы понять механику работы системы, проанализируем, из чего состоит объект МоментВремени. В платформе 1С позиция любого документа определяется не порядковым номером в журнале, а комбинацией двух значений:
GUID / УникальныйИдентификатор).Если у двух или более документов дата и время совпадают до секунды, платформа определяет их взаимный порядок путем бинарного сравнения их внутренних ссылок (GUID). Названия видов документов, метаданные и порядок в интерфейсе на это сравнение не влияют. При обращении к виртуальным таблицам остатков на определенный МоментВремени платформа учитывает движения только тех документов, чья позиция строго меньше переданного момента.
Поскольку GUID генерируется автоматически при создании объекта, новый документ, записанный в ту же секунду 00:00:00, не гарантирует попадания строго между ранее созданными поступлением и реализацией. Рассмотрим основные пути решения этой проблемы.
Наиболее надежный, прозрачный и стандартный для 1С подход — разнести документы по времени хотя бы с разницей в одну секунду или по логическим интервалам суток. Разберем, как это реализовать:
Документу поступления оставляем время 00:00:00, перемещению присваиваем 00:00:01, а реализации — 00:00:02. В рамках отчетов и регламентированного учета за день это считается той же датой, но хронологическая цепочка проведения и контроля остатков становится абсолютно детерминированной.
В типовых решениях часто применяется регламентное распределение времени по видам операций:
06:00:00 (утро);12:00:00 (день);18:00:00 (вечер).Проанализируем вопрос влияния сдвига времени на взаиморасчеты и зачет авансов (счета 60.02, 62.02): если платежные документы (выписки, приходные кассовые ордера) оформлены другой датой, секундный сдвиг внутри дня реализации вообще не повлияет на проводки. Если же оплата произошла в тот же день, достаточно установить время платежа до реализации или после нее в соответствии с фактической последовательностью событий.
Если документы приходят из внешней системы через обмен, настроим автоматическую корректировку времени в обработчиках событий (например, в модуле объекта перед записью или в правилах конвертации данных). Посмотрим на пример кода в событии ПередЗаписью:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Если время документа не задано или установлено в полночь, скорректируем его
Если НачалоДня(ЭтотОбъект.Дата) = ЭтотОбъект.Дата Тогда
ЭтотОбъект.Дата = КонецДня(ЭтотОбъект.Дата); // Смещаем в конец дня для реализации
КонецЕсли;
КонецПроцедуры
В исключительных случаях, когда изменение даты и времени категорически запрещено бизнес-логикой, существует низкоуровневый способ управления позицией нового документа. До первой записи объекта в базу данных можно принудительно задать ему идентификатор с помощью метода УстановитьСсылкуНового().
Рассмотрим, как это работает: если сгенерировать GUID, значение которого при бинарном сравнении платформой будет строго больше GUID поступления и строго меньше GUID реализации, то при времени 00:00:00 перемещение займет нужную позицию в последовательности. Однако данный метод является трудоемким, зависит от внутреннего порядка байтов платформы и применим только для еще не созданных в базе документов.
При разработке собственных механизмов проведения обратим внимание на следующие особенности платформы:
Граница с режимом ВидГраницы.Включая или ВидГраницы.Исключая, что позволяет точно контролировать, попадают ли движения текущей секунды в расчет.Автопозиционирование управляет тем, как платформа автоматически размещает документ на оси времени при интерактивной записи в конец секунды или дня.Таким образом, самым надежным и поддерживаемым решением для выстраивания правильной последовательности движений остается явное разнесение документов по времени с минимальным шагом в 1 секунду.