Добрый вечер!
С помощью расширения в ERP планируется добавление независимого(ых) регистра(регистров) сведений для отражения прохождения контроля, много видов номенклатуры, у каждого вида свои параметры, по несколько штук, как бы Вы лучше сделали? Один регистр на все виды номенклатуры или для каждого вида свой регистр?

один регистр.
Справочники:
1. Параметры
2. Наборы параметров (включает 1 - n параметров).

Набор параметров - значение в регистре сведений. Измерение Номенклатура и что там еще хотите (производственная линия, и т.п.).

(0) Добавляйте в основную конфу.

(0)

Много "много видов номенклатуры" это 10, 100, 1000 видов ?

Контроль проходит:
-- вид номенклатуры
-- номенклатура
-- каждый выпущенный экземпляр?
-- несколько выпущенных экземпляров из партии ?

Всего за месяц (например) в ваш регистр сколько строк попадёт?

(1) Зачем Справочники, если есть допреквизиты?

(2) Вопрос был о другом.

(1) Я бы 2 РС сделал.
1 - РС с видом номенклатуры
2. РС с параметрами.

(3) Продукты разные, у каждого несколько переделов, у каждого передела свои параметры проверки, штук 20 будет минимум.

(6) не совсем поняла, для чего 1 регистр?

(0)
Не понимаю, контроля чего?

(9) физических параметров, герметичность, например

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

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

(12) т.е. будет обмен с оборудованием в регистр

(7) Это проверка партии товара по 20-ти параметрам? Или как? Как понять что конкретно вооооон тот товар на третьей полке - проверен? На этом надо основываться проектируя регистры

(14) По полуфабрикатам не 100% контроль, а именно в разрезе партии производства, а вот уже готовое изделие 100%, по нему справочное указание серий. Было написано не про 20 параметров, а про 20 видов номенклатуры.

(12) У вас каждое готовое изделие отдельно маркируется?

(16) да

(15) Почему такой упор на виды номенклатуры? Она что, так сильно отличается как пиво от обогащённого урана?

(18) потому что у них разные параметры

(19) то что параметры разные, это понятно. Вопрос в том на сколько разные. Если у них 10 параметров однотипные и отличия в 2-3, то не вижу смысла плодить кучу регистров по параметрам. Один регистр со всеми возможными параметрами и у каких-то позиций будут заполнены одни, у каких-то другие.
  Более серьезный вопрос в периодичности контроля этих параметров. Для одной позиции проконтролировали один раз и всё, для другой может быть каждые 5 минут надо что-то контролировать. Вот по периодичности возможно стоит подумать о разделении регистров, но тоже не факт

(20) нет, по самому заморочному продукту, в среднем 5 параметров в каждом переделе, они разные для каждого, где-то булево, где-то число, где-то допзначение, при выпуске готового получается добавится номер серии в регистр, склоняюсь к нескольким регистрам все-таки

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

(22) нет, я штатник

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

(0) один регистр, для каждой маркировки набор параметров со значением для каждого параметра. составной, да, но типы примитивные, доп связей не будет. Либо, если не только примитивные, то просто осторожно в запросах. Типовой ЗначенияСвойствОбъектов нормально справляется, там через ПВХ это сделано, есть и такой вариант.
зы. ну не делать же для каждого нового типа параметров новый регистр
и + напрашивается вопрос - если это статистика, то есть хранить надо все, то это одно, если это только отбраковка, то механизм другой должен быть

(0) Плохо продумано
Явно все будет сложней
1. Метаданные для настройки контроля (константы, перечисления, справочники, регистры)
2. Метаданные для проведения и отражения контроля (тут еще плюсом документы и свои регистры)

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

(25) информация будет хранится для аналитики, для отбраковки пока достаточно типового инструмента

(24) будут отчеты на этом регистре/регистрах

(27) в механизм проведения документа этап производства засунуть?
один фиг настройки нужны и возможность выключить
учесть периодичность настроек

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

0. Добавлять не в расширение, а в конфу
1. Справочник "Параметры контроля видов номенклатуры" подчиненный виду номенклатуры. В реквизитах все параметры по всем видам номенклатуры
2. Регистр "Контроль": измерения "Партия, номенклатура", ресурс "Контроль пройден"
3. Документ-регистратор "Контроль", создается при обмене с контролирующим оборудованием

-

(30) зачем лезть в механизм проведения этапа?

(31) придется снимать конфигурацию с поддержки, не особо хочется

(34) Почему?

(35) потому что планируем обновляться

(36) так будет дольше и гемморойней

(36) А когда снимаешь с поддержки, то обновляться уже нельзя?

(34) Достаточно включить возможность изменений, не надо снимать с поддержки.

(35)

Один раз снимешь, другие начнут приставать, писать туда всякое...

(37) Насколько дольше и геморройней?

(39) +

Но я почему-то сразу и подумал, что они вряд ли хотят удалять конфу поставщика:)

Эмм нынче общепринято включать возможность изменения только для отдельных метаданных
Новые метаданные (реквизиты, ТЧ) в самой конфе, код в расширениях, через &ИзменениеИКонтроль
Формы программно кодом менять
Макеты и прочее желательно тоже, если никак то в расширениях

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

(34) Включить изменения достаточно. Можно и не снимать с поддержки

(41) пока не могу сказать, но явно дольше, чем с замком

(0) При добавлении нового вида вносить новые регистры не логично, поэтому один регистр.

(43) где-то указаны эти стандарты? Сама 1С так рекомендует?

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

(46) Вы никогда не обновляли конфу с изолированными не типовыми объектами?
Хм. Это занимает на 15 минут больше времени, это с перерывом на кофе.

(43) А я говорил...

(50) на практике пока нет, только с замком

(43) Макеты делать общедоступными с помощью типового механизма БСП и менять в пользовательском режиме.

(49) как быть, если в Типовом документе нужно добавить ТЧ, например?

(0) чем меньше ответственности у одного объекта метаданных, тем лучше

(49) Или надо будет с объектом из расширения сделать внешнюю обработку, а тип из расширения выбрать увы нельзя.

Но в целом, зачем добавлять уязвимости системе. Тем более 1су...

(55) берешь и добавляешь
на форму ТЧ тоже кодом
это не сложно
сложно это настройки СКД по бесшовке ЕРП-ДО туды/сюды передавать

(43) О! Измененные макеты в расширениях это песня! Никогда никто не знает, в каком виде откроется такая печатная форма в следующий раз...

(59) с доработкой типовых макетов это тема отдельного холивара

и баста

карапузики

ЗЫ Зачем еще регистр когда есть доп.сведения?

(63) проверка будет не одна в этапе, а несколько в разрезе периода

(64) Троллит же, и по делу кстати

(64) несколько доп.сведений

(66) Ага на каждый этап/период/партию/номенклатуру свое. Ахахах.

(67) кто мешает одно и внутри json?

(68) Можно и заархивировать еще сверху (места меньше, а значит Архитектура лучше). Хранить, соответственно, бинарники.
Чтобы жизнь медом не казалась.

Даже уже франчи-внедренцы практически все через расширение делают, на Инфостарте статистику спрашивала, тоже большинство за расширение, совсем меня смутили)

(70) дык внешникам обычно насрать что будет

(70) Да, хороших разработчиков не так много.

(70) Это Вы ещё не теряли данные при проблемах с расширением. У Вас всё впереди.

(73) У Вас было такое?

Еще прикольно конструктором запросов и консолью пользоваться, при данных в расширении

(75) Обычно все достается, были косяки с ресурсами в 21 релизе платформы по-моему, но вроде бы исправили

(75) Решено в 8.3.28

(76) Как мне достать в пользовательском режиме в консоли в конструкторе запроса данные расширения?

(77) понял, у меня постарее платформа. Спасибо:)

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

(78) пользовательском режиме
вообще никаких проблем нет

А регистра достаточно одного

Объект/ПроверяемоеСвойство/ЗначениеПроверки (строчка под каждое свойство)

(81) У меня они не отображаются. Проверьте, у вас они точно там есть? А если их добавить руками, то конструктор не откроется, также как и из основной конфигурации кстати.

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

Ну и непонятно, как хранить сами наборы параметров, нам же надо понимать какую номенклатуру по каким параметрам проверять.

В целом это вариант из (1), но без второго справочника, хороший вариант.

(0) в случае альтернативы "один или много" , при прочих равных, всегда выбирай - один

один регистр конечно. больше регистров - больше шансов на взаимоблокировки

(84) Обычно, наоборот.

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