В процессе ведения учета в «1С:Управление торговлей 11» часто возникает ситуация, когда пользователи по ошибке или намеренно создают документы будущим числом. Это приводит к серьезным искажениям в отчетах, некорректному расчету себестоимости и отрицательным остаткам на текущий момент. При планировании перехода на новую версию программы подбор решений для переноса данных в УТ поможет заранее предусмотреть все нюансы миграции. В данной статье мы подробно разберем, как программными и административными методами ограничить возможность записи документов «в будущее».
Прежде всего, проанализируем, как сама платформа 1С работает со временем. В метаданных каждого документа существует свойство ОперативноеПроведение. Рассмотрим, как оно влияет на логику системы:
Оперативное проведение установлено в значение «Разрешить», платформа при попытке проведения документа текущим днем предлагает выполнить оперативное проведение.Однако на практике этот механизм часто «пропускает» документы. Выясним причину: чаще всего это связано с правами доступа. У многих пользователей (особенно с расширенными правами) включена роль, содержащая право «Неоперативное проведение». Если это право активно, система позволяет проводить документ любой датой без контроля со стороны платформы. Чтобы исправить это без программирования, необходимо пересмотреть профили групп доступа и отключить данную привилегию для рядовых менеджеров. При необходимости можно воспользоваться расширением для настройки доступности реквизитов документов по пользователям, чтобы запретить редактирование поля даты.
Если административные меры не помогают или требуется жесткий контроль, наиболее правильным с точки зрения стандартов разработки будет использование расширения конфигурации. Разберем по шагам, как реализовать проверку даты документа.
Нам необходимо перехватить событие ПередЗаписью в модуле объекта документа. Почему именно ПередЗаписью? Потому что это позволяет заблокировать не только проведение, но и простое сохранение документа с некорректной датой.
Рассмотрим пример кода, который можно внедрить через расширение:
&НаСервере
&Перед("ПередЗаписью")
Процедура ИН_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем, не включен ли режим загрузки данных (чтобы не блокировать обмен)
Если ЭтотОбъект.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Сравниваем дату документа с текущей датой сеанса
Если ЭтотОбъект.Дата > ТекущаяДатаСеанса() Тогда
ТекстСообщения = "Запрещено создание документов будущей датой!
|Текущая дата: " + ТекущаяДатаСеанса() + "
|Дата документа: " + ЭтотОбъект.Дата;
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, , "Дата");
Отказ = Истина; // Прерываем запись документа
КонецЕсли;
КонецПроцедуры
Проанализируем важный нюанс: использование функции ТекущаяДатаСеанса() вместо ТекущаяДата(). Это критически важно для распределенных систем. Если сервер находится в одном часовом поясе, а пользователь — в другом, функция ТекущаяДата() вернет время сервера, что может привести к ложным срабатываниям или пропуску документов. ТекущаяДатаСеанса() всегда учитывает настройки часового пояса конкретного пользователя.
Если по каким-то причинам использование расширений невозможно, рассмотрим альтернативу — Подписку на события. Этот механизм позволяет вынести проверку в общий модуль, не изменяя код самого документа в основной конфигурации.
ИН_СобытияДокументов) с установленными флажками «Сервер» и «Внешнее соединение».ПодпискаНаСобытие.РеализацияТоваровУслуг, СчетНаОплатуПокупателю).ПередЗаписью.Посмотрим на пример универсального обработчика для подписки:
Процедура ПроверитьДатуДокументаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Ограничиваем проверку только для новых документов или при изменении даты
// Для этого можно использовать ТекущаяДатаСеанса() с точностью до дня
Если НачалоДня(Источник.Дата) > НачалоДня(ТекущаяДатаСеанса()) Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Вы не можете оформить документ завтрашним числом!";
Сообщение.УстановитьДанные(Источник);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Проанализируем ситуацию с точки зрения бизнес-процессов. В «1С:Управление торговлей» существуют документы разных типов:
1. Фискальные и складские документы. Это «Реализация товаров и услуг», «Поступление товаров и услуг», «Приходный кассовый ордер». Для них будущая дата действительно недопустима, так как это нарушает налоговый учет и логику складских остатков (товар не может быть отгружен завтра, если отчет строится за сегодня).
2. Плановые документы. Сюда относятся «Заказ клиента», «Заказ поставщику», «Коммерческое предложение». Запрет будущей даты для таких документов часто вреден. Менеджеры могут планировать отгрузки на следующую неделю, и дата документа в этом случае служит ориентиром для логистики.
Рекомендация: При внедрении запрета используйте выборочный подход. Не применяйте проверку ко всем документам системы без разбора, иначе вы заблокируете работу отдела планирования и закупок.
Малоизвестный, но эффективный способ — использование механизма «Дата запрета изменения данных». В последних версиях БСП, на которых базируется УТ 11.3, можно настроить динамические даты запрета.
Рассмотрим вариант настройки:
Мы рассмотрели несколько способов решения проблемы. Подведем итог, какой из них выбрать:
ПередЗаписью.ТекущаяДатаСеанса().Соблюдение этих правил позволит вам поддерживать чистоту в базе данных и избежать проблем с расчетом себестоимости и складскими остатками.