Заявка на ввод нового элемента справочника #644176

Необходимо вводить новый элемент справочника заявкой. Элемент справочника записывается после согласования заявки. В заявке кроме реквизитов самой заявки необходимо также заполнить реквизиты нового элемента справочника. Не хотелось бы дублировать реквизиты справочника в реквизитах заявки. Как этот процесс лучше реализовать?

Необходимо вводить новый элемент справочника заявкой. Элемент справочника записывается после согласования заявки. В заявке кроме реквизитов самой заявки необходимо также заполнить реквизиты нового элемента справочника. Не хотелось бы дублировать реквизиты справочника в реквизитах заявки. Как этот процесс лучше реализовать?

что за элемент такой ?

Чего только люди не придумают! А почему бы и не дублировать? В чем проблема?

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

РС-то зачем?

не суть. Реквизитов много. форма элемента справочника вполне себе самодостаточна, зачем мне её дублировать? не хотелось бы заморачиваться с РС. Можно ли хранить СправочникОбъект в реквизите заявки? Т.е. создаю новый элемент справочника, но не записываю его. При проведении заявки выгружаю этот реквизит как новый элемент справочника.

отменная трава

да)

Особенно весело потом будет такой объект сравнивать с данными базы.

потом мне не нужно его сравнивать

потом его нужно просто записать? :)

я имею ввиду после записи сравнивать не нужно

Тогда записывай сразу, а заявкой просто акцептуй. Флаг соответствующий в справочник добаить придется.

Увы. В реквизитах не хранятся объекты. В реквизитах хранятся ссылки.

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

Вам, Петровым, не угодишь. :) Тогда делай РС. Одно измерение, один ресурс, чего там морочиться?

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

а заполненную форму?

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

Чтобы в заявке не хранить. Создал заявку - она пишет в РС, акцептовал заявку - она удаляет запись. Работы на 2 часа.

Извращенное задание, конечно. А если поступить так: Скопировать справочник Контрагенты в конфигураторе и обозвать копию, скажем, "Заявки на контрагента", после чего добавить еще реквизиты, связанные с визированием. И на основании этого справочника организовать ввод элемента справочника Контрагенты при наличии таких галок?

+ СправочникОбъект.<Имя справочника> (CatalogObject.<Имя справочника>) Данный объект может быть сериализован в/из XML. Данный объект может быть сериализован в/из XDTO.

да, я вот так и думал. Не понял, какие изменения по справочнику?

Изменения в метаданных.

Можно, как в . Только дублирование реквизитов и формы намного проще.

интересная мысль, надо подумать.

+ Один драг энд дроп. < 1 сек.

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

лень - двигатель прогресса

Если нужно, чтобы "заявки" видело ограниченное число лиц: Я бы ввел новый реквизит, далее RLS. Или так (отталкиваемся от ): создаем новый документ (или справочник) "Заявка на создание элемента справочника X". В нем создаем две ТЧ: одну с колонками "ИмяРеквизита" (строка) и "Значение" (тип ЛюбаяСсылка). Вторая ТЧ будет содержать 3 колонки: "ИмяТабличнойасти", "Значение", "НомерСтроки" (число). Вроде ничего не забыл.

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

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

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

Ну. О том и речь, что данные дважды хранить не нужно. Тебе +, вот все что нужно.

Тогда читай вторую часть. Чем через ТЧ не устраивает? При желании (если уж очень нужно) сможешь сделать возможность предварительно просматривать утверждаемую заявку.

Удалить запись из РС проще чем элемент справочника - отпадает проблема контроля ссылочной целостности.

я не понял в чем там суть? Задублировать реквизиты, от которых я хочу отказаться?

Тогда соглашусь Сами реквизиты дублировать не придется - данные могут храниться в виде "Ключ-Значение". т.е. у тя в справочнике или документе были бы реквизиты "Номер заявки", "Дата утверждения заявки", а еще табчасть "Реквизиты заявки". В табчасти 3 строки (по количеству реквизитов элемента справочника) - первая строка имеет значения "Ключ" = "Код", "Значение" = 001 вторая строка "Ключ" = "Наименование", "Значение" = "...", третья строка например "Реквизит1", значение = ссылка на что-то

мы сделали по другому, объект в базу вобще не записывается, пакуется в xml и выстреливается в другую базу, там согласовывают и потом обратно летит и записывается

ну т.е. суть - ты предлагаешь заполнять ТЧ на основании метаданных необходимого справочника?

Не ТЧ, а ТЗ. Хотя мне кажется удобнее структура.

В связи с тем, что заявка, возможно, будет и для других справочников, решил попробовать формировать ТЗ на основе метаданных справочника. Тип реквизита в справочнике может быть любой. В ТЗ 2 колонки - Реквизит, Значение. Для колонки Значение выбрал типы - Строка, Число, Дата, Булево, ЛюбаяСсылка. Вопрос: как заполнить колонку пустыми значениями соответствующего типа на основании метаданных? Для каждого Эл из Метаданные.Справочники.ИмяСправочника.Реквизиты Цикл

Прилепить к заявке вложенный файл в формате xls с шаблоном  Реквизит -> Значение.

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

Поместить на HTML-поле заявки html-форму. Юзер заполняет необходимые реквизиты. После согласования заявки ответственный товарищ на этой html-форме жмет кнопку "Ввести новый элемент", кнопка дергает GET-запросом веб-сервис, тот создает элемент.

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

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

Как-то мудрёно. Вопрос в том, как установить типы значений (значения по умолчанию) для реквизитов на основании метаданных? То, что в , как то не true.

это не вариант. Пользователь должен выбирать из типизированных/предопределенных данных, иначе будет разброд и шатание.

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

Ага, понял уже, тогда можно попробовать

так об этом и речь. Есть ТЗ, которая выносится на форму и заполняется. Вопрос в том, как заполнить?

"Вопрос в том, как заполнить?" - кому заполнить, юзеру или алгоритму?

мне, т.е. алгоритму ->

Легко: Просто пихаешь туда пустое значение нужного типа. Во всяком случае раньше такие фокусы прокатывали.

))) да не тип справочника, а типы реквизитов справочника.

Может тебе проще статусы номенклатуры ввести? Активная-неактивная? По неактивным - согласование или в треш, активные используются в работе.

Эл.Тип.ПривестиЗначение(Зн)

->

Да ну, это конфу допиливать придется, учитывать флажок активности в доках/отчетах.

Я понял ) Если у тебя тип реквизита "Справочник.Договора", то при открытии формы для заполнения в пустое поле для заполнения этого реквизита пихаешь Справочник.Договора.ПустаяСсылка

там допил минимальный - запретить в форме выбора номенклатуры в доках использовать неактивные позиции...

Я бы не стал так делать. Лучше таки запретить ввод ненужного.

я не могу сделать приведение типа для колонки ТЗ. Для колонки установлены возможные типы . Теперь мне нужно прсото установить пустое значение соответствующего типа.

+ для каждого НовСтр.Значение

Ну и что тебе мешает привести каждое значение к типу ?

У тебя УФ? Я на УФ это точно делал, счас гляну.

как это сделать универсально на основе метаданных?

УФ

Вот: &НаСервере

У меня присваивание типа происходит явно:

У тебя тип просто надо формировать динамически, условиями

Все понятно

Смеешься? Я как раз и хочу уйти от заполнения ручками. смотри.

"просто"

Это мне было? А чего там сложного?

я не знаю как, подскажи.

Блин ))

Прошу простить, но мне пора уже к своей работе приступить ) Думаю, по этому вопросу можно найти инфу в инете. Отталкиваться надо от кода в , для строка, чисел и дат там все подойдет. Для ссылочных типов всего-то по имени типа надо понять кто это: "Справочник" или "Документ" (в имени типа это есть), там же в имени типа есть и имя справочника/документа.

еще как минимум перечисление.

Ну там тоже все просто, все есть в имени типа

Определяешь по имени типа тип объекта и дальше несколько веток  Если - ИначеЕсли - КонецЕсли, по одной ветке для каждого типа (СТрока, дата, число, перечисление, справочник, документ)

понятно, то же, что в . Звучит просто, но не получается.

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

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

Зачем?

Она у тебя итак пустая, пока ты не присвоил туда ничего

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

у меня там куча типов, а нужен 1.

Предопределенный элемент сделать, пустой, из него заполнять значения.

Возможно ли универсально получить пустую ссылку из типа, содержащего ссылку?

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

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

сабж не о правах

я понимаю, просто предлагаю обходное решение ИМХО более простое чем заявки, как бы они не были реализованы.

да. спасибо. я понял. надо подумать.

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

А у тебя как определяется, какой справочник должно быть?

пока он 1, но в дальнейшем, думаю, будет 3, а может и больше.