Как проверить тип значения документа, справочника? Стандартные реквизиты документа

Универсальная обработка "Пакетный ввод документов" предназначена для автоматизации ввода документов на основании табличных данных Excel или других подобных программ.

Обычно в таком случае под каждый конкретный случай пользователь заказывает программисту специальную обработку, программист по описанному техзаданию прописывает код загрузки данных из Excel и код создания новых документов. При этом ему приходится для каждой ситуации описывать связи между столбцами (колонками) таблицы и реквизитами документа. Кроме того, даже если из таблицы берется всего пара реквизитов, программисту все равно необходимо написать код для задания остальных реквизитов документа стандартными значениями. А ведь даже в таком простом документе как приходный кассовый ордер этих реквизитов свыше 40. Что уж говорить, без 2-3 часов работы программиста не обойтись, а это от 3 до 6 тыс. руб. для каждого конкретного случая. Бывают еще ситуации, когда программист поленится прописывать установку всех несущественных на его взгляд реквизитов документа в обработке и это может привести к тому что после того как вы зайдете в созданный этой обработкой документ и закроете его ничего не поменяв программа все равно выведет предложение сохранить документ потому что он был изменен. Это происходит потому, что при открытии документа заполняются некоторые стандартные реквизиты документа значениями по умолчанию и это могут быть как раз те реквизиты которые программист упустил из виду. Можно подумать, что особо страшного в этом ничего нет, ну нажать «да «и документ сохранится. Но если описанная ситуация произойдет не сразу после применения обработки, а допустим спустя месяц и за это время вы задним числом поменяете более старые документы, то после нажатия «да» документ может быть перепроведен с другими проводками, например, по зачету авансов между счетами 60.01 и 60.02.

Обработка Пакетный ввод документов предлагает другой более универсальный подход к решению задач по пакетному вводу документов на основании табличных данных. За основу здесь берется повторение ручных действий человека. А что человек делает, когда ему необходимо ввести много данных вручную? Правильно, он копирует с аналогичных документов и меняет отдельные реквизиты. «Аналогичные документы» в обработке называются шаблоны. Шаблоны настраиваются в отдельной таблице, которую можно сохранить. Структура колонок таблицы данных для загрузки также настраивается в отдельной таблице, где можно указать имя колонки, имя реквизита значение, которого нужно заменить данными из колонки, вид реквизита: реквизит документа или реквизит табличной части и другие параметры.

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

Сравнение версий

Дополнение от 26.11.2018 - Обработка была протестирована на УТ11. Выдавала ошибку в одном месте:

Если ТипЗнч(ДокОбъект)=Тип("ДокументОбъект.КорректировкаДолга") Тогда так как в УТ11 документа Корректировка долга нет

Поменял на Если СтрНайти(Метаданные.НайтиПоТипу(ТипЗнч(ДокОбъект)).ПолноеИмя(),"КоректировкаДолга")>0 Тогда Это выражение не обращается явно к типу а просто ищет в строке с полным именем типа документа подстроку КорректировкаДолга. Если не найдет то ничего страшного, пойдет дальше и ошибку выдавать не будет.

В остальном все работает на УТ11, так как обработка универсальная и работает на всех управляемых формах. Если кого-то заинтересует пишите в комментариях, сделаю версию для толстого клиента 1с 8.2

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

3. В настройках колонок сгруппировал некоторые колонки вертикально, чтобы вся таблица помещалась в ширину на экране (при разрешении 1920*1080)

4. Исправил мелкие баги

Версия 1.2 от 20.12.2018.

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

2. Добавлена возможность многострочного ввода документов. Если в поле шаблон ввести текст "<>" то по этой строке не будут вводиться новые документы, а данные из колонок с видом "Реквизит табличной части" будут добавляться в табличные части документов из предыдущей строки. Например в следующей таблице будет создано 2 документа: в первом будет 3 строки, во втором 2 строки. Многострочный ввод документов имеет смысл использовать для ввода табличных частей документов. Если кроме реквизитов табличной части нужно изменить реквизиты самих документов, их нужно задать в первой строке блока (там где шаблон не "<>")

3. В связи с добавлением возможности многострочного ввода полностью переработан программный код отвечающий за ввод документов. Теперь данные из таблицы сначала собираются в структуру изменяемых реквизитов, а затем на основе разбора структуры реквизитов создаются документы и изменяются реквизиты. Это позволило сделать программный код более кратким, простым, логичным и понятным для отладки. Удалось избежать использование оператора "Выполнить", который в отдельных случаях мог вызывать ошибку. Также новый программный код работает быстрее, так как данные записываются в базу только один раз.

Версия 1.3 от 23.12.2018.

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

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

Гарантия возврата денег

ООО "Инфостарт" гарантирует Вам 100% возврат оплаты, если программа не соответствует заявленному функционалу из описания. Деньги можно вернуть в полном объеме, если вы заявите об этом в течение 14-ти дней со дня поступления денег на наш счет.

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

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

В платформе «1С:Предприятие» за построение отчётов отвечает механизм под названием «Система компоновки данных» (сокращенно СКД). В этой статье мы постараемся дать краткое описание идеи и архитектуры механизма СКД и его возможностей.


СКД – это механизм, основанный на декларативном описании отчетов. СКД предназначен для построения отчетов и для вывода информации, имеющей сложную структуру. Кстати, помимо разработки отчетов механизм СКД также используется в «1С:Предприятии» в динамическом списке , средстве показа списочной информации с богатой функциональностью (показ плоских и иерархических списков, условное оформление строк, группировки и т.п.).

Немного истории

В самой первой версии платформы «1С:Предприятие 8», версии 8.0, отчеты делались так:
  1. Писался один или несколько запросов на языке запросов 1С (SQL-подобный язык, подробнее о нем ниже).
  2. Писался код, который переносил результаты выполненных запросов в табличный документ или в диаграмму. Код также мог делать работу, которую в запросе сделать невозможно – например, вычислял значения, используя встроенный язык 1С.
Подход прямолинейный, но не самый удобный – визуальных настроек минимум, все приходится программировать «врукопашную». А один из козырей на тот момент совсем новой платформы «1С:Предприятие 8» - это минимизация в прикладном решении объема кода, который нужно писать вручную, в частности, за счет визуального проектирования. Логично было бы пойти этим же путем и в механизме построения отчетов. Что и было сделано путем разработки нового механизма - Системы Компоновки Данных.

Одной из идей, легших в основу СКД, была гибкость и настраиваемость отчетов, причем доступная как разработчику, так и конечному пользователю. В идеале хотелось бы дать доступ конечному пользователю к тому же набору инструментов для дизайна отчета, что и разработчику. Логично было бы сделать единый набор инструментов, доступный всем. Ну а раз инструменты предполагают участие конечного пользователя – значит, нужно использование программирования в них убрать до минимума (лучше всего – устранить совсем), и по максимуму использовать визуальные настройки.

Постановка задачи

Задача перед командой разработки стояла такая – сделать систему создания отчетов, основанную не на алгоритмическом (т.е. через написание кода), а на декларативном подходе к созданию отчетов. И мы считаем, что задачу успешно решили. По нашему опыту, около 80% требуемой отчетности может быть реализована с помощью СКД без единой строчки кода (за исключением написания формул вычисляемых полей), по большей части - через визуальные настройки.
Разработка первой версии СКД заняла около 5 человеко-лет.

Два языка

В создании отчетов задействованы два языка. Один – язык запросов, используемый для выборки данных. Второй – язык выражений компоновки данных, предназначен для записи выражений, используемых в различных частях системы, например, в настройках компоновки данных, для описания выражений пользовательских полей.

Язык запросов

Язык запросов основан на SQL и легко осваивается знающими SQL. Пример запроса:

Легко видеть аналоги стандартных для SQL-запроса секций - SELECT, FROM, GROUP BY, ORDER BY.

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

  • Обращение к полям через точку. Если поля какой-либо таблицы имеют ссылочный тип (хранят ссылки на объекты другой таблицы), разработчик может в тексте запроса ссылаться на них через ".", при этом количество уровней вложенности таких ссылок система не ограничивает (например, ЗаказКлиента.Соглашение.Организация.Телефон).
  • Многомерное и многоуровневое формирование итогов. Итоги и подитоги формируются с учетом группировки и иерархии, обход уровней может выполняться в произвольном порядке с подведением подитогов, обеспечивается корректное построение итогов по временным измерениям.
  • Поддержка виртуальных таблиц. Виртуальные таблицы, предоставляемые системой, позволяют получить практически готовые данные для большинства прикладных задач без необходимости составления сложных запросов. Так, виртуальная таблица может предоставить данные по остаткам товаров в разрезе периодов на какой-то момент времени. При этом виртуальные таблицы максимально используют хранимую информацию, например, ранее рассчитанные итоги и т.д.
  • Временные таблицы. Язык запросов позволяет использовать в запросах временные таблицы. С их помощью можно повысить производительность запросов, в некоторых случаях снизить количество блокировок и сделать текст запроса более легким для восприятия.
  • Пакетные запросы. Для более удобной работы с временными таблицами в языке запросов поддерживается работа с пакетными запросами - таким образом, создание временной таблицы и ее использование помещаются в один запрос. Пакетный запрос представляет собой последовательность запросов, разделенных точкой с запятой (";"). Запросы в пакете исполняются один за другим. Результатом выполнения пакетного запроса, в зависимости от используемого метода, будет являться либо результат, возвращаемый последним запросом пакета, либо массив результатов всех запросов пакета в той последовательности, в которой следуют запросы в пакете.
  • Получение представлений ссылочных полей. Каждая объектная таблица (в которой хранится справочник или документ) имеет виртуальное поле - «Представление». Это поле содержит текстовое представление объекта и облегчает работу создателя отчетов. Так, для документа это поле содержит всю ключевую информацию - название типа документа, его номер и дату (например, «Продажа 000000003 от 06.07.2017 17:49:14»), избавляя разработчика от написания вычисляемого поля.
  • и др.
Механизм запросов автоматически модифицирует запрос с учетом ролей , к которым принадлежит пользователь, от имени которого выполняется запрос (т.е. пользователь увидит только те данные, которые имеет право видеть) и функциональных опций (т.е. в соответствии с настроенной в прикладном решении функциональностью).

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

Например:

  • ВЫБРАТЬ. В этом предложении описываются поля, которые пользователь сможет выбирать для вывода. После данного ключевого слова через запятую перечисляются псевдонимы полей из основного списка выборки запроса, которые будут доступными для настройки. Пример: {ВЫБРАТЬ Номенклатура, Склад}
  • ГДЕ. Описываются поля, на которые пользователь сможет накладывать отбор. В данном предложении используются поля таблиц. Использование псевдонимов полей списка выборки недопустимо. Каждая часть объединения может содержать собственный элемент ГДЕ. Примеры: {ГДЕ Номенклатура.*, Склад }, {ГДЕ Документ.Дата >= &ДатаНачала, Документ.Дата <= &ДатаКонца}
  • и др.
Пример использования расширений:

Язык выражений компоновки данных

Язык выражений компоновки данных предназначен для записи выражений, используемых, в частности, для описания выражений пользовательских полей. СКД позволяет определять в отчете пользовательские поля, используя либо собственные выражения, либо наборы вариантов с условиями их выбора (аналог CASE в SQL). Пользовательские поля являются аналогом вычисляемых полей. Они могут задаваться как в конфигураторе, так и в режиме «1С:Предприятие», но в выражениях пользовательских полей нельзя использовать функции общих модулей. Поэтому пользовательские поля предназначены скорее для пользователя, чем для разработчика.

Пример:

Процесс создания отчета на СКД

При создании отчета нам нужно создать макет, определяющий, как данные будут отображаться в отчете. Можно создать макет, базирующийся на схеме компоновки данных. Схема компоновки данных описывает суть данных, которые предоставляются отчету (откуда получать данные и как можно управлять их компоновкой). Схема компоновки данных представляет собой базу, на основе которой могут быть сформированы всевозможные отчеты. Схема компоновки данных может содержать:
  • текст запроса с инструкциями системы компоновки данных;
  • описание нескольких наборов данных;
  • подробное описание доступных полей;
  • описание связей между несколькими наборами данных;
  • описание параметров получения данных;
  • описание макетов полей и группировок;
  • и др.

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

Итогом запуска конструктора запросов будет текст запроса (на языке запросов «1С:Предприятия»). Этот текст можно при необходимости скорректировать вручную:

Наборов данных в схеме компоновки данных может быть несколько, наборы данных могут быть связаны в макете произвольным образом, могут быть добавлены вычисляемые поля, заданы параметры отчета и т.п. Стоит упомянуть интересную особенность работы механизма запросов в 1С:Предприятии. Запросы в конечном итоге транслируются в диалект SQL, специфичный для СУБД, с которой непосредственно работает приложение. Мы вообще стараемся задействовать возможности серверов СУБД по максимуму (нас ограничивает то, что мы используем только те возможности, которые есть одновременно во всех поддерживаемых платформой «1С:Предприятие» СУБД – MS SQL, Oracle, IBM DB2, PostgreSQL). Таким образом, на уровне запроса в вычисляемых полях мы можем использовать только те функции, которые транслируются в SQL.

А вот на уровне схемы компоновки данных мы уже можем добавлять пользовательские поля и использовать в них функции на встроенном языке разработки 1С (в том числе и написанные нами), что сильно расширяет возможности отчетов. Технически это выглядит так – всё, что можно транслировать в SQL, транслируется в SQL, запрос выполняется на уровне СУБД, результаты запроса помещаются в память сервера приложений 1С и СКД вычисляет для каждой записи значения вычисляемых полей, чьи формулы написаны на языке 1С.


Добавление пользовательских полей

В отчет можно добавить произвольное количество таблиц и диаграмм:


Дизайнер отчетов


Отчет во время выполнения

С помощью СКД пользователь может добавлять в отчет сложные отборы (которые будут добавлены к запросу в нужных местах), условное оформление (позволяющее по-разному форматировать – шрифтом, цветом и т.д. – выводимые поля в зависимости от их значений) и многое другое.

Коротко описать процесс построения и формирования отчета можно так:

  • Разработчик в design time с помощью дизайнера (или в runtime с помощью кода) определяет схему компоновки данных:
    • Текст запроса/запросов
    • Описание вычисляемых полей
    • Связи между запросами (если их несколько)
    • Параметры отчета
    • Настройки по умолчанию
    • И т.д.
  • Вышеописанные настройки сохраняются в макете
  • Пользователь открывает отчет
    • Возможно, делает дополнительные настройки (например, меняет значения параметров)
    • Нажимает кнопку «Сформировать»
  • Настройки пользователя применяются к схеме компоновки данных, определенной разработчиком.
  • Формируется промежуточный макет компоновки данных, содержащий в себе инструкции, откуда получать данные. В частности, корректируются запросы, заданные в макете. Так, из запроса удаляются поля, которые не используются в отчете (это делается с целью минимизировать объем получаемых данных). В запрос добавляются все поля, участвующие в формулах вычисляемых полей.
  • В дело включается процессор компоновки данных. Процессор компоновки выполняет запросы, осуществляет связь наборов данных, рассчитывает значения вычисляемых полей и ресурсов, выполняет группировку. Словом, делает все расчеты, которые не были выполнены на уровне СУБД.
  • Процессор вывода данных запускает запрос на исполнение и выводит полученные данные в табличный документ, диаграмму и т.п.


Процесс формирования отчета механизмом СКД

Мы стараемся минимизировать объем данных отчетов, передаваемых с сервера в клиентское приложение. При показе данных в табличном документе при открытии табличного документа мы передаем с сервера только те строчки, которые пользователь видит в начале документа. По мере продвижения пользователя по строкам документа на клиента подкачиваются с сервера недостающие данные.

Пользовательские настройки

Весь инструментарий СКД доступен как разработчику, так и конечному пользователю. Но практика показала, что конечного пользователя часто пугает обилие возможностей инструмента. Тем более что в большинстве случаев вся мощь настроек конечному пользователю и не нужна – ему достаточно иметь быстрый доступ к настройке одного-двух параметров отчета (например, периода и контрагента). Начиная с определенной версии платформы у разработчика отчета появилась возможность отметить, какие настройки отчета доступны пользователю. Делается это с помощью флажка «Включать в пользовательские настройки». Также у настроек отчета появился флаг «Режим отображения», принимающий одно из трех значений:
  • Быстрый доступ. Настройка будет выведена непосредственно в верхнюю часть окна отчета.
  • Обычный. Настройка будет доступна через кнопку «Настройки».
  • Недоступный. Настройка будет недоступна конечному пользователю.


Режим отображения настройки в design time


Отображение настройки в режиме «Быстрый доступ» во время выполнения (под кнопкой «Сформировать»)

Планы развития

Одно из приоритетных направлений в развитии СКД для нас – упрощение настроек пользователя. Наш опыт показывает, что для части конечных пользователей работа с пользовательскими настройками – все еще серьезный труд. Мы это учитываем и работаем в этом направлении. Соответственно, и разработчикам также станет проще работать с СКД, т.к. мы, как и раньше, хотим предоставлять единый инструментарий настройки отчетов и для разработчика, и для конечного пользователя.

Механизм ограничения доступа к данным RLS (Row Level Security) позволяет довольно гибко настраивать и разграничивать права доступа к объектам программы. В типовых конфигурациях "1С Предприятие" механизм развит довольно хорошо, однако бывают ситуации, когда типовой настройки недостаточно. Рассмотрим такую ситуацию на примере программы "ERP Управление предприятием 2".

Представим, что на предприятии действует следующая схема: Заявки на расходование денежных средств оформляют сотрудники нескольких подразделений, например "Плановый отдел", "Хозяйственный отдел". Эти отделы – элементы справочника "Подразделения организаций" (сотрудники оформлены в этих отделах). При этом в Заявках на расходование денежных средств указываются другие подразделения – элементы справочника "Структура предприятия". Например, "Подразделение 1", "Подразделение 2". Существует группа пользователей, которая должна видеть только те заявки, которые оформлены сотрудниками "Планового отдела". Типовая настройка RLS для документа "Заявка на расходование денежных средств" и роли "Чтение заявок на расход ДС" не позволяет выполнить такую настройку, поэтому мы её немного доработаем – добавим новый вид доступа.

Начнём доработку с документа "Заявка на расходование денежных средств". Добавим реквизит, содержащий в себе подразделение автора документа. Назовём его ПодразделениеАвтора . Тип значения реквизита – Э-э... Вот здесь есть над чем подумать. Если установить тип значения – "СправочникСсылка.ПодразделенияОрганизаций", то потом, когда мы попытаемся создать новый вид доступа с названием "Подразделения авторов документов" и типом значения "СправочникСсылка.ПодразделенияОрганизаций", система при обновлении выдаст ошибку:

"Тип значений "Подразделение" уже указан для вида доступа "ПодразделенияОрганизаций". Для вида доступа "ПодразделенияАвторовДокументов" его нельзя указать."

Есть соблазн использовать объект "Определяемый тип", что-нибудь вроде:

ВидДоступа. ТипЗначений = Тип("ОпределяемыйТип.ПодразделенияАвторов" ) ;

Но система не хочет понимать такие формулировки, так что если кто что может дельного подсказать, буду признателен. А пока создаём справочник "Подразделения авторов документов", владелец которого – справочник "Подразделения организаций". В этом справочнике те же подразделения, что и во владельце. И теперь для нового реквизита документа "Заявка на расходование денежных средств" укажем тип "СправочникСсылка.ПодразделенияАвторовДокументов". Настроим заполнение реквизита при записи документа. Думаю, тут описывать это не стоит, так же как и заполнение нового справочника.

Определяемый тип "ЗначениеДоступа"
Добавляем в составной тип ссылки на документ "Заявка на расходование денежных средств" и справочник "Подразделения авторов документов".

Подписка на событие "ОбновитьГруппыЗначенийДоступа"
Добавим в список источника документ "Заявка на расходование денежных средств".

Общий модуль "УправлениеДоступомПереопределяемый"
Добавляем в процедуры модуля несколько строк.

Процедура ПриЗаполненииВидовДоступа(ВидыДоступа) Экспорт ... //Доработка ВидДоступа = ВидыДоступа. Добавить() ; ВидДоступа. Имя = ; ВидДоступа. Представление = НСтр("ru = "Подразделения авторов документов"" ) ; ВидДоступа. ТипЗначений = Тип("СправочникСсылка.ПодразделенияАвторовДокументов" ) ; //КонецДоработки КонецПроцедуры Процедура ПриЗаполненииИспользованияВидаДоступа(ВидДоступа, Использование) Экспорт ... //Доработка Если ВидДоступа = "ПодразделенияАвторовДокументов" Тогда Использование = Истина ; КонецЕсли ; //КонецДоработки КонецПроцедуры Процедура ПриЗаполненииВидовОграниченийПравОбъектовМетаданных(Описание) Экспорт Описание = Описание + " |... |//Доработка |Документ.ЗаявкаНаРасходованиеДенежныхСредств.Чтение.ПодразделенияАвторовДокументов |//КонецДоработки |" ; КонецПроцедуры

Теперь нужно настроить роль для доступа к документу. Можно создать новую роль, а можно доработать уже существующую "Чтение заявок на расход ДС". Рассмотрим второй вариант. В роли "Чтение заявок на расход ДС" уже есть настройка ограничения доступа с использованием шаблона "ПоЗначениямРасширенный".


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


Далее, запускаем конфигурацию в режиме "Предприятие" с параметром запуска "ЗапуститьОбновлениеИнформационнойБазы". Также можно запустить, например с помощью внешней обработки, экспортную процедуру "УправлениеДоступомСлужебный.ОбновитьПараметрыОграниченияДоступа".

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


Автоматизация документооборота невозможна без настройки удобных и эффективных видов документов, с которыми будут работать пользователи. СЭД «Корпоративный документооборот» содержит специальный справочник «Виды документов», справочник может включать в себя произвольное количество видов документов.

После запуска СЭД «Корпоративный документооборот» справочник «Виды документов» уже содержит ряд предопределенных элементов:

  • Внутренний
  • Входящий
  • Исходящий
  • Карточка файла

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

Справочник «Виды документов» доступен через подсистему «Администрирование системы» или непосредственно из корпоративного документа.

Каждый корпоративный документ привязан к одному элементу справочника «Вид документа» ссылка на вид документа указывается в форме документа как показано на рисунке ниже.

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

В элементе справочника «Виды документа» могут быть настроены следующие параметры корпоративного документа:

  • Наименования реквизитов
  • Наименование закладок
  • Наименование кнопок
  • Состав дополнительных реквизитов
  • Колонки произвольной таблицы

Пример настройки наименований и видимости реквизитов для вида документа «Входящий» приведен на рисунке ниже.

На рисунке видно, что реквизит «Автор» сделан невидимым, так как входящие документы создаются за пределами нашего предприятия, а номер в шапке корпоративного документа переименован в «Вх. номер» с помощью задания отображаемого наименования в настройках вида документов «Входящий».

В списке реквизитов можно переопределить любой из заданных в конфигураторе «1С:Предприятие 8.3 / 8.2» реквизит управляемой формы документа. В настройках вида документов можно указать значения по умолчанию, а также задать возможность использования в корпоративных документах данного вида произвольной таблицы и дополнительных реквизитов.

Важным элементом в автоматизации документооборота является наличие возможности добавить в структуру документов новые данные. Например, часто пользователям требуется использовать в документе табличные данные. Система позволяет это реализовать. Если в форме вида документа отметить флажок «Произвольная таблица», то станет возможным настроить вид таблицы документов. Можно отредактировать наименования и видимость столбцов.

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

После настройки вида документа произвольная таблица отображается на закладке «Содержание», подзакладка «Таблица» корпоративного документа соответствующего вида.

Включить использование дополнительных реквизитов корпоративного документа можно отметив флажок «Дополнительные реквизиты».

В списке дополнительных реквизиты можно создать набор дополнительных реквизитов корпоративного документа.

После настройки дополнительных реквизитов в форме элемента справочника «Виды документов», данные реквизиты станут доступными на закладке «Содержание», подзакладке «Реквизиты» корпоративного документа соответствующего вида.

В данном разделе мы рассмотрели важный элемент автоматизации документооборота — настройку видов используемых на предприятии документов.

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


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

Примеры хозяйственных операций: поступление товаров на склад, списание товаров со склада, прием денежных средств в кассу, прием сотрудника на работу и т. д.

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

Итак у нас есть документ бумажный и документ электронный. Между ними необходимо произвести аналогию. При оформлении бумажного документа обязательным условием является наличие в нем номера и даты. Аналогично и электронный документ должен содержать номер и дату. По этим полям мы может найти нужный нам документ. Поэтому номер и дата являются ключевыми свойствами.

Рассмотрим ключевое свойство "Дата" . В версии 7.7 оно называлось "ДатаДок" , в версии же 8 оно стало называться просто "Дата" . Это очень важное свойство документа. Почему это так? Рассмотрим ситуацию с торговой организацией, в которой осуществляется регистрация факта поступления товара и его продажи. Так вот продать товар, дата поступления которого больше даты продажи, не представляется возможным, потому как нельзя продать товар который еще не поступил.

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

Вот именно поэтому наличие даты в документе так важно. Также необходимо отметить, в свойстве "Дата" содержится не только дата, но и время документа с точностью до секунды.

Очень часто такой идентификации документа на временной оси оказывается недостаточно.

Представим ситуацию, когда на склад поступает 100 единиц товара 1-го числа месяца. Далее 2-го числа этого же месяца в 23:59:59 происходит его продажа, в количестве 80 единиц. Документ проводится без проблем, потому как товара хватает. Допустим, что также 2-го числа в 23:59:59 этот же товар еще кто-то тоже продает в количестве 50 единиц. Этот документ также проведется без проблем, потому как на время 23:59:59 этот товар есть. Хотя фактически у нас, по итогу проведения второго документа образуется отрицательный остаток в 30 единиц товара.

Чтобы таких ситуаций не возникало к дате и времени прибавляется еще и позиция документа, а именно его ссылка. Эта идентификация документа по дате и времени + ссылка называется момент времени . И при проведении второго документа система выдаст сообщение о нехватке 30 единиц товара и не позволит провести документ.

Как же получить момент времени? А получается он методом "МоментВремени" , принадлежащий классу "ДокументОбъект" . При этом возвращается тип данных "МоментВремени" .

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

Пример получения момента времени:

&НаКлиенте Процедура ПолучитьМоментВремени(Команда) ПолучитьМоментВремениНаСервере(Объект. Ссылка) ; КонецПроцедуры &НаСервере Процедура ПолучитьМоментВремениНаСервере(Ссылка) Если Ссылка. Пустая() Тогда Сообщить("Документ не записан!" ) ; Возврат ; КонецЕсли ; ДокументОбъект = Ссылка. ПолучитьОбъект() ; МоментВремени = ДокументОбъект. МоментВремени() ; Сообщить(МоментВремени) ; КонецПроцедуры // ПолучитьМоментВремениНаСервере()

Установка времени документа

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


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

И еще ситуация. Представим себе, что у нас в базе есть документ с отметкой времени 23:59:59 и если прибавить еще одну секунду это уже будут следующие сутки. Поэтому система оставляет такое же время, то есть 23:59:59. Описанная выше система установки времени документа является лишь значением устанавливаемым по умолчанию. Но есть возможность переопределить такое поведение. Откроем в конфигураторе форму документа и обратимся к ее свойствам. В свойствах мы увидим поле "АвтоВремя" . Если мы в этом свойстве ничего не меняем, то формирование времени документа происходит так как это было описано выше. Но можно указать время: текущее или в начало дня, всегда первым, всегда последним и не использовать.

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

Возможность проведения

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

Стандартные реквизиты документа

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

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

Документ может находится в трех состояниях:

  • Не помечен на удаление и не проведен;
  • Не помечен на удаление и проведен;
  • Помечен на удаление и не проведен.

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


Хранение документов в информационной базе

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

Нумерация документов

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

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

Префикс устанавливается в модуле объекта документа, в процедуре "ПриУстановкеНовогоНомера" .

Процедура ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс) КонецПроцедуры

Также на вкладке "Нумерация" мы можем задать периодичность документа.

Возможные значения:
  • Непериодический;
  • В пределах года;
  • В пределах квартала;
  • В пределах месяца;
  • В пределах дня.
Обычно выбирают значение "в пределах года" , это означает, что в новом году нумерация документов начнется сначала.

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

Его необходимо указывать в поле "Нумератор" .

Проведение документов

Немного о проведении документов. Для системы означает, что документ проведен если булевский флаг "Проведен" у документа установлен в "Истина" . В общем списке такие документы выделены соответствующей пиктограммой. Для платформы это более ничего не значит, но с точки зрения логики программы, проведенный документ может влиять на финансовый результат компании. То есть он может формировать движения по регистрам, основываясь на которые формируются отчеты.

Когда происходит интерактивное или программное проведение срабатывается выполнение процедуры "ОбработкаПроведения()" , которая находится в модуле объекта документа.

// Вставить содержимое обработчика. КонецПроцедуры

Данная процедура имеет два параметра: отказ и режим . Если выставить параметру отказ значение "Истина" , то проведение не будет выполнено. Параметр "Режим" устанавливает режим проведения документа - оперативное или неоперативное . Сами движения в регистры разработчик должен прописать в данной процедуре самостоятельно.

То, в какие регистры документ будет делать движения задается на вкладке "Движения" .

Пример процедуры обработки проведения

Процедура ОбработкаПроведения(Отказ, РежимПроведения) // Данный фрагмент построен конструктором. // При повторном использовании конструктора, внесенные вручную изменения // будут утеряны!!! // регистр ТоварыНаСкладе Приход Движения. ТоварыНаСкладе. Записывать = Истина ; Для Каждого ТекСтрокаТовары Из Товары Цикл Движение = Движения. ТоварыНаСкладе. Добавить() ; Движение. ВидДвижения = ВидДвиженияНакопления. Приход; Движение. Период = Дата; Движение. Товар = ТекСтрокаТовары. Товар; Движение. Количество = ТекСтрокаТовары. Количество; КонецЦикла ; //__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ КонецПроцедуры

Права доступа на документы

В системе 1С существуют различные виды доступа. Это анализ интерактивных действий и анализ программных действий.

Что такое интерактивные действия? Это действия совершаемые непосредственно пользователем: нажатие кнопок, галок и т. д. Программные же действия совершаются каким-либо алгоритмом, о их совершении пользователь может и не догадываться.

Права доступа к документу настраиваются на закладке "Права" . Здесь мы видим несколько разделов, это раздел где отображаются роли, раздел непосредственно прав, и раздел "Ограничения доступа к данным" (его мы не будем рассматривать, он необходим при использовании так называемого механизма RLS).

Раздел "Роли" отображает все роли заведенные в информационной базе, для которых в разделе "Права" мы как раз и устанавливаем права доступа.

Возможные виды прав доступа:
  • чтение (программно), просмотр (интерактивно);
  • добавление (программно), интерактивное добавление (интерактивно);
  • изменение (программно), редактирование (интерактивно);
  • удаление (программно), интерактивное удаление (интерактивно);
  • проведение (программно), интерактивное проведение (интерактивно);
  • отмена проведения (программно), интерактивная отмена проведения (интерактивно);

Интерактивный вид доступа содержит еще такие права как: интерактивная пометка на удаление, интерактивное снятие пометки на удаление, интерактивное удаление помеченных, интерактивное проведение неоперативное, интерактивное изменение проведенных, ввод по строке.

Табличная часть документа

Табличные части документа задаются на вкладке "Данные" и являются ничем иным как коллекций, элементами которой являются строки табличной части. Поэтому обход ее элементов возможен как циклом, так и прямым обращением по индексу (нумерация начинается с нуля).