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

Программирование - Практика программирования

Идея конфигурация документ справочник Конфигуратор Настраиваемый документ произвольный документ реквизит табличная часть задача

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

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

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

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

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

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

Для начала пару справочников:

1. ИмяДокумента - в этом справочнике будем заводить наименования наших произвольных документов (для важных документов лучше сделать предопределённые элементы справочника).

2. Реквизиты - будет хранить наименования реквизитов документов.

Остальные справочники обычно имеются в типовых базах, но моя база пустая, поэтому создам - Контрагенты, Номенклатура, ФизическиеЛица, Материалы.... и всё что угодно душе так сказать.

Далее перехожу собственно к созданию нашего Произвольного документа. Объект в дереве конфигураций так и назову, "ПроизвольныйДокумент". Создадим реквизит ссылочного типа "Имя" и Табличную часть "Шапка". Реквизит "Имя" будет ссылаться на справочник "ИмяДокумента". У табличной части Шапка заведу два реквизита - "Реквизит" - ссылка на справочник "Реквизиты" и "СвойствоРеквизита" - составной тип данных (в моём случае строка 500 символов, число 15 точность 3, все документы и все справочники).

 
 Скриншот дерева конфигурации

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

 
 Скриншоты нашего Произвольного документа

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

 
 Код основной Формы документа

Затем в написанный код можно добавить всё что угодно:

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

- Можно для каждого вида документа при записи или проведении в модуле документа сделать проведение по нужным этому документу регистрам.

- Сделать настройку по ролям пользователей.

-  и т.д. список можно продолжать и продолжать...

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

 
 Анализ метода:

Реализация данной задачи естественно не обязательна именно в таком виде как я написал. Можно, к примеру вместо справочников "ИмяДокумента" и "Реквизиты" сделать регистр/регистры сведений или вообще не создавать справочники, а воспользоваться любым типовым справочником (например в справочнике Номенклатура создадим папку Настройки документов и введем нужные наименования документов и реквизитов туда). Всё исходит от целей конкретно поставленной задачи.

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

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

Благодарю за внимание к статье. На этом всё.

7

См. также

Комментарии
Избранное Подписка Сортировка: Древо
2. Bazil 296 01.06.18 10:50 Сейчас в теме
Для обычных документов в СКД сразу доступны реквизиты документа для отборов, группировок и т. д. А как решался этот вопрос для настраиваемых документов?
6. user748289 109 01.06.18 11:49 Сейчас в теме
(2) Одним из минусов такого программирования и будет неудобство работы с СКД. Отчеты придется ручками писать, об этом я упомянул в конце статьи в разделе минусы. Сложность разработки самый неприятный момент для такого подхода, хотя хотелки бухгалтеров иногда совсем небольшие и сложностей практически нет. Однако если у вашего предприятия 2-3 таких документа и 1-2 отчета по ним то с этим можно жить. Если же речь идет о документе из серьёзного проекта, с движениями в типовых регистрах конечно же делать необходимо только стандартным способом.
10. Bazil 296 01.06.18 13:56 Сейчас в теме
(6), (7) Вы пишете "пара-тройка документов", а есть ли смысл создавать такие сложности для пары-тройки документов?
12. user748289 109 01.06.18 16:25 Сейчас в теме
(10) Николай, смысл есть делать даже для пары-тройки документов. Иногда в нашем деле встречаются весьма и весьма активные бухгалтера и начинают просто засыпать программиста ненужными доработками, когда люди адекватные то делаем пару документов в конфе и ими пользуются годами. Но бывают ситуации когда однотипных документов требуют новых по 2-3 каждые два, три месяца. Потом эти самые "нужные" документы забрасываются полностью и ожидают новых и новых доработок. Далее безумство продолжается. При этом избавляться от ненужных документов нельзя - потому, что они вроде как кому то нужны. Получается, что программист должен просто заваливать "хламом" рабочую конфигурацию, хлам в данном случае это созданные документы и отчеты в конфигураторе по такому вот щучьему велению :). Побороть систему "хотелок" отправляемой из бухгалтерии невозможно, т.к. приказы идут вертикально сверху от руководителя. Когда документ небольшой то его доработка займет у нас ну максимум час вместе с отчетом - и все довольны, если же требуется действительно важный постоянно используемый рабочий документ то и разработка конечно же только стандартным способом производится.
Предложенный в статье способ выглядит как типичный "костыль", но если его нормально дорабатывать, то это поможет. Тем более ребята пишут в комментариях, что этот метод оказывается используется разработчиками в некоторых решениях. В общем ничего плохого в этом подходе я не вижу, да сложнее - но если плюсы могут перевесить минусы в компании с таким решением, то почему бы и нет.
3. razmochaev 01.06.18 11:10 Сейчас в теме
Ровно такой подход использован в продукте Инталев: Корпоративный менеджмент 7.
Там есть документ «Проформа», который позволяет в пользовательском режиме создавать произвольные виды документов, а также справочник «Классификатор», который позволяет создавать произвольные справочники.

Рекомендую его изучить, если вам данная область интересна.
user748289; +1 Ответить
4. user748289 109 01.06.18 11:13 Сейчас в теме
(3)Спасибо Александр. Я не знал, но логически была мысль, что нечто подобное где то уже есть. Посмотрю.
8. Bassgood 814 01.06.18 12:18 Сейчас в теме
(3) Подобный же подход используется и в БИТ:Финанс, плюс на ИС уже выкладывали готовую подсистему, реализующую такой принцип проектирования документов в пользовательском режиме.
user748289; +1 Ответить
5. user633533_encantado 2 01.06.18 11:20 Сейчас в теме
У меня сомнения на счет производительности системы при таком подходе. Каждый реквизит документа имеет все возможные типы.
7. user748289 109 01.06.18 11:58 Сейчас в теме
(5) Я не вижу особых проблем с производительностью для небольших баз с небольшим числом пользователей и при правильном программировании. При многопользовательском режиме работы конечно лучше пользоваться стандартной разработкой, но тут вопрос ещё в другом - кто именно будет пользоваться такими документами. Я не предлагаю писать абсолютно новый продукт типа Торговли используя такой подход к документам, тогда да будет тормозить просто жесть, а вот если использовать на основе типовой базы пару документов типа "Учет подарков переданных детскому саду" которые нигде не движутся и не мешают, то почему бы и нет. Файлики Excel бухгалтера зачастую теряют, а вот за базу данных переживают.
9. razmochaev 01.06.18 13:32 Сейчас в теме
(7) будучи пользователем-разработчиком Инталев:КМ, скажу так: производительность ниже, чем в типовых конфигурациях. В конфе используется собственная система безопасности, поэтому она тоже ест ресурсы. Требования к железу у продукта высокие.

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

За это платишь определенными неудобствами, конечно.
user748289; +1 Ответить
11. qwinter 514 01.06.18 15:15 Сейчас в теме
Такой подход сплошь и рядом. Самое "веселое", что я видел, так это когда код конструирования подобных документов был вынесен в модули внешних обработок, естественно к одному виду могло быть привязано много таких внешних обработок. Монстр был очень веселый))
Оставьте свое сообщение