Проведение оперативно-не-оперативно

Поводом послужил вопрос на форуме Доработка проведения документа в УТ 11.5

Причиной же - вот это место в "Методической поддержке разработчиков":

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

Случается так, из вопроса на форуме это видно, что не понимает ни пользователь, ни 1сник в штате, ни фигурирующие в теме франчайзи, ни, собственно, коллеги в комментариях.

В сети - огромное множество материала. Гугл-запрос "1С оперативное проведение": результатов примерно 424 000.

Но вопрос на форуме остается. Внесем лепту.

Дальше "на пальцах" я попробую объяснить то, что методисты 1С подробно и скрупулёзно  излагают в своей методичке.

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

Я установил предельно возможную низкую цену за эту конфигурацию, поскольку она предназначена в первую очередь начинающим коллегам, не успевшим вникнуть конкретно в эту особенность платформы.

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

---

База.

Есть компьютерная программа, она называется "платформа 1С".

Эта программа имеет два режима запуска, "Конфигуратор" и "Предприятие". Это - не две разных программы, это одна и та же программа. Первый режим, для программистов, дает доступ к настройкам программы. Там программист расставляет галки (флажки) и пишет куски кода на языке "1С". В результате получается "конфигурация", то есть программа 1С + какие-то настройки.

В режиме "Предприятие" работает конечный пользователь, он работает в "конфигурации", то есть, в настроенной "программистом 1С", некоторым образом, "платформе 1С".

Список, который вы видите в первом окне при запуске 1С - это не список разных программ, это список разных баз данных, для работы с каждой из них "платформа 1С" имеет свою настройку (настройка может быть одна и та же для разных баз).

Внутри режима "Предприятие" так же есть свои настройки. Это - другое. Это следствие "универсальности конфигурации". Одна настройка "Бухгалтерия" должна по-разному работать у разных пользователей (в разных организациях). Этот слой настроек нас здесь не интересует.

---

Документы и проводки.

Какой-нибудь конкретный вид документа создается программистом 1С в режиме "Конфигуратор". А конкретные экземпляры данного вида - пользователем в режиме "Предприятие".

Каждый экземпляр какого-либо вида документа заполняется пользователем уникальным набором данных (как минимум уникальность обеспечивается сочетанием даты и номера документа).

Кроме данных, содержащихся в самом документе, программист 1С может реализовать предоставляемую платформой возможность привязать к конкретному документу дополнительные наборы данных, проводки.

Использовать или не использовать эту возможность, программист 1С решает с помощью специального флажка в конфигураторе, разрешить или запретить "Проведение"

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

А вот при "разрешенном" проведении платформа предоставляет программисту 1С ряд возможностей специально для управления дополнительными данными, которые иначе программисту 1с пришлось бы реализовывать самостоятельно с помощью других возможностей.

---

Оперативное проведение.

Так, при разрешенном проведении у программиста есть выбор, разрешить или запретить "оперативное" проведение. Это одна из дополнительных возможностей, предоставляемых платформой.

А при запрете проведения флажок "Оперативное проведение" уже недоступен, платформа не задействует свои дополнительные возможности.

Очень важно: в режиме "Предприятие" при проведении документа при разрешенном "Оперативном проведении" платформа сама решает, в каком режиме, оперативном или не оперативном, ей следует здесь и сейчас выполнить проведение для данного документа. Это - ключевое знание для правильного понимания. И платформа никак не информирует пользователя о том, в каком режиме она выполняет проведение, вопреки тому, что написано в "Методической поддержке...". Кроме одного случая, ради которого и весь этот разбор здесь.

---

Пока не потрогаешь - не узнаешь.

Создадим три вида документов, с разрешенным (1) и запрещенным (2) оперативным проведением, и с запретом проведения вообще.

В модулях документов разместим следующие предопределенные процедуры:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	Сообщить("1. Перед записью");
	Сообщить(РежимПроведения)
КонецПроцедуры

Процедура ПриЗаписи(Отказ)
	Сообщить("2. При записи")
КонецПроцедуры

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
	Сообщить("3. Проведение");
	Сообщить(РежимПроведения)
КонецПроцедуры

(да, автор знает, что "сообщить" - устаревший оператор)

Из них "ОбработкаПроведения" - это то, что понимает платформа, если флажок "Проведение" выставлен в "Разрешено".

Больше ничего в этой пустой конфигурации делать не будем.

Документ "Запрещено оперативное проведение", чтобы мы с ним ни делали...

... сообщает одно и то же:

1. Перед записью

Неоперативный

2. При записи

3. Проведение

Неоперативный

Документ с запрещенным проведением, хотя бы мы и сделали ему точно такой же модуль, с теми же процедурами, не сообщает о третьем пункте, да и кнопки такой, типа "Провести", не имеет. Платформа соответственно флагу запрещения урезала функциональные возможности. Но сообщение о том, что режим проведения - неоперативный, оставила! Несущественно, но можно было бы написать что-то вроде "Неопределено", хотя бы для сохранения стиля.

1. Перед записью

Неоперативный

2. При записи

А вот с документом, у которого разрешено оперативное проведение, вариантов гораздо больше.

Когда мы создаем новый документ, платформа устанавливает ему дату в начало дня текущей. При записи этого документа платформа устанавливает ему текущее время. Но если мы перед записью установим ему прошлую дату, то платформа запишет время 12:00. Это работает во всех режимах, устанавливаемых программистом в конфигураторе.

Впрочем, чтобы не отвлекаться на описание всего того, что платформа делает с этими документами, я прикладываю к статье файл с выгрузкой моей тестовой базы (пароль пустой). Кому интересно посмотреть, тот посмотрит :)

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

Для удобства я поставил в журналах (списках) документов возможность их непосредственного удаления.

---

Варианты режима проведения документа при разрешении оперативного.

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

Если мы вручную установим ему прошлую дату, система проведет его НЕ-оперативно.

И если мы установим будущую дату, система выдаст информацию об ошибке:

Это тот самый "один случай", анонсированный выше.

И это, собственно, ответ на вопрос на форуме, о котором упомянуто в начале статьи. Это делает "голая" платформа, до того как дело дойдет до всяких разных процедур. Бессмысленно искать какие-то хитрости в коде, пытаться поставить где-то точку останова дебаггера и тому подобное. Это платформенная, системная фича, которую программист может только разрешить/запретить указанным флажком.

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

Здесь, как бы надменен и неприятен ни был автор, он может только пожать плечами и ... нет, не перезагрузить компьютер :)))

Почистить кеш - это да, это помогает в большинстве подобных случаев. А сначала вообще убедиться, в одном ли и том же экземпляре базы были сделаны скрины коллегой konsta2006.

---

Проводки и режим проведения.

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

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

Вы помните, что сообщала нам тестовая конфигурация?

Она в тех процедурах уже имеет информацию о режиме проведения, который она выбрала сама (с учетом флажков и даты-времени документа).

И программисты, писавшие конкретную конфигурацию, могли в зависимости от режима по-разному формировать дополнительные данные. Выполнять или не выполнять проверку остатков и все такое.

Тут вспомним о множестве статей в интернете. Вот как, например, об этом пишет коллега Анна Викулина, Руководитель Центра сопровождения 1С (wiseadvice):

Пользователю не рекомендуется изменять настройки разработчика, чтобы не нарушить логику программы и работу проведения документов. Также не рекомендуется изменять системную дату и дату работы в программе с целью изменить дату оперативного проведения, так как это может привести к неверному расчету бухгалтерских данных, вследствие чего могут возникнуть ошибки в учете.

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

Ладно, допустим, ключевой пользователь, когда вы ему доложили о проблеме (отсутствие контроля остатков, например), говорит: "А, обойдусь, у меня все просто и прозрачно, не надо мне вашего контроля!"

Все, вопрос закрыт? Нет. Есть такая вещь, как "итоги" регистров.

Слово Колесникова Дмитрия (koderline):

Если даже предположить, что пользователь работает с документами в будущем периоде, работа всё же происходит не на всей временной оси, а на некотором отрезке времени. Таким образом, если взять некоторую достаточно отдалённую точку будущего, можно будет хранить остатки на эту точку и быстро получать их.

В качестве такой точки актуальности в Платформе 8.x используется 01 ноября 3999 года 00:00:00. Иными словами, текущие итоги регистров остатков периода имеют именно такую дату. Если принять во внимание, что платформа предоставляет пользователю (и программисту) некоторый набор удобных для работы абстракций, скрывающих происходящие уровнем ниже технические подробности, то становится понятно, что точка актуальности как раз и есть такая техническая деталь, скрываемая от пользователя.

Так, от пользователя скрыты технические детали устройства регистров и используемая в них дата 01 ноября 3999 года, и, в самом деле, при повседневном учёте он не будет работать с такой датой, хотя, теоретически, учёт может вестись и до этой даты. Для пользователя же Платформа предоставляет более удобную абстракцию, называемую актуальные остатки (АО), отражающую остатки именно на текущий момент.

При обращении к системе с запросом остатков Платформе 8.x ... рассчитываются остатки, при этом происходит поиск итога - ближайшего равного или большего (из таблицы итогов регистра накопления), после чего, при необходимости происходят дополнительные расчёты по таблице движений на требуемый момент времени.

Вы поняли, что сказал Дмитрий? Я - как-то не очень. Не раскрыта тема "актуальных остатков", и как они связаны с актуальностью далеко-далеко в будущем (тема очередной статьи "доступно и всерьез"?). Но понятно, что теряются не только проверки при проведении, но и достоверность итогов. Ключевой пользователь рискует получать доверительные остатки из старой доброй ексельной таблички на своем рабочем столе. Это вовсе не криминал. Многие люди так и делают, акцапта там у них или 1С. Проблемы будут из-за того, что в эту табличку данные как-то придется заводить.

---

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