Вот честное слово, никак не могу понять, зачем 1С так упорно продвигает эту убогую и корявую идею?

Ну понятно, что если нет никакой возможности изменить конфигурацию, то это позволяет пользователям добавлять какие-то свои поля в виде свойств и вести по ним учет. Но ведь добавить поле в справочник - это 15 минут работы. Можно даже пользователю по телефону объяснить, как это сделать. А поле в справочнике со всех сторон красивее выглядит, чем свойство и характеристика. И 8 - это не 7.7, где с добавленными полями обновления затруднялись на порядок. Тут с этим особых проблем нет.

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

Минусы характеристик:
1) довольно сложный интерфейс по добавлению характеристик;
2) необходимость лишних измерений в регистрах, что их работу явно не ускоряет;
3) необходимость поддержки характеристик во всех отчетах и обработках.

А вот каковы полюсы этого всего дела?
Извините, наболело.

п.2 и 3 в минусах ошибочны

(0)[Но ведь добавить поле в справочник - это 15 минут работы]
пипец

(1) Почему? Если бы не было характеристик, то это сделало бы конфигурации ощутимо проще.

Наверное, я не совсем правильно задал вопрос.

В каких случаях без характеристик нельзя обойтись или с ними проще, чем без них?

(3) угу
отменим заодно субконто на плане счетов

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

если "все равно половину конфигурации переписывают" тогда смысла в характеристиках и правда нет.

(6) Не согласен.
Если добавить поле в справочник, то в отчеты его прописывать не придется.
А в регистры его добавлять в 99% случаев необходимости нет.

(5) Я БП не рассматриваю.
В БП характирстик нет.

(TigerPXN) - Характеристики нужны что бы конфу не курочить, раскуроченная конфа автоматом привязывает пользрователя к тому кто ее курочил.

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

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

(11)а индексировать это поле не надо будет?
(10)А как по другому?

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

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

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

(12) у меня есть свое мнение как должно быть(но оно именно мое, может и неправильное) - описывать тут слишком долго да и не к месту.
(14) ты смотришь из расчета добавления одного поля..в реальности добавлять придется далеко не одно поле + далеко не в одном справочнике и не в одном документе

(11) Для фильтрации - не надо. Хотя и можно, если очень хочется.

(17) --> (12)

(12) Например как в Инталеве классификаторы. Черезвычайно удобная вещь.

(19)Можно в двух словах что там за классификаторе в Инталеве?

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

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

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

(22) не понял - что измерение ХарактеристикаНоменклатуры в РС ШтрихКоды отменили?

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

TigerPXN - это не в обиду, а по существу!
Помни нашу поговорку про "семь раз..."
Я свою номенклатуру мерял 1.5 месяца, - а "народ" рядом "тащился" - насчет куйни.

Дятел?

(22) По поводу загрузки накладных есть Регистр сведений Номеклатура контрагента в котором проставляются соответствия позиция контрагента и позиция в программе...
Поэтому нет ни каких заморочек с характеристиками...

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

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

Очень полезная вещь - сочетания вариантов характеристик.

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

"Но ведь добавить поле в справочник - это 15 минут работы"
во франче работаешь?

(33) Не надо портить ветку. Это здесь при чем?

(34) что-то мне подсказывает, что фикси так рассуждать не будет

(35) Понятно, но давай не здесь. В кои-то веки более менее конструктивно постят люди..

(36) да просто было интересно, не более того...
PS мои посты можно затереть

Автор не в теме...

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

Волшебник! Пиши в тему...

ОБЩИЕ ПРИНЦИПЫ ФОРМИРОВАНИЯ СТРУКТУРЫ СПРАВОЧНИКА НОМЕНКЛАТУРА

ПРОГРАММНАЯ СХЕМА УЧЕТА НОМЕНКЛАТУРЫ

Определяя структуру справочника номенклатуры в применении к учету тех или иных изделий (продукции) будем исходить из следующих возможностей программы:
•    Объединение однотипных элементов номенклатуры в группы. Например, пряжа суровая, пряжа крашенная, полотно трикотажное, раскрой и т.п.;
•    Разделение элемента номенклатуры по понятиям характеристики и серии. При этом исходим из того, что:
o    Характеристика это комплексная составляющая, объединяющая в себе не ограниченный набор свойств изделия. Один и тот же набор характеристик может распространяться на группы элементов;
o    Серия – партионное понятие, при этом суть партии не бухгалтерская (по сроку поступления), а в большей степени качественная. Например, понятие лота хлопка, прядильной сортировки, ванны крашения и т.п. Каждая серия привязана к отдельному элементу номенклатуры (справочник серий подчинен элементу номенклатуры).

При этом мы понимаем, что:
o    учет движения продукции  (приход, расход, остатки) ведется в разрезе: ЭлементНоменклатуры+НаборХарактеристик+Серия;
o    спецификации на выпуск продукции составляются в разрезе: ЭлементНоменклатуры+НаборХарактеристик;
o    все стандартные механизмы отбора остатков номенклатуры составляются в разрезе: ЭлементНоменклатуры+НаборХарактеристик;
o    Параметры: артикул, вид номенклатуры, настройки учета и т.п. задаются только для: ЭлементНоменклатуры.
Кроме этого нужно учитывать:
o    НаборХарактеристик может быть общим для группы элементов номенклатуры, т.е. «один ко многим». Серия действительная только для одного элемента – «один к одному».
o    НаборыХарактеристик и Серии это два разных справочника, подчиненных элементу номенклатуры. Поэтому, например при отгрузке готовой продукции, чтобы поиметь соответствующий качественный сертификат, серию нужно создавать из расчета каждого отдельного набора характеристик. Например, для элемента «Ботинки» с наборами характеристик «мужские,42 размер, кожаные» и «мужские,41 размер, кожаные» должны быть две разные серии «сертификат для мужские,42 размер, кожаные» и «сертификат для мужские,41 размер, кожаные».

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

В этой связи, будем руководствоваться следующим принципом:

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

Далее написаны предыдущие личные размышления, которые то же нужно учитывать, но они менее однозначны.  
•    Понятие элемента номенклатуры должно соответствовать уникальному составу исходного сырья и уникальной технологической цепочке производства, как правило, это напрямую связано с ГОСТом, ОСТом или ТУ по которому производится продукция с разделением на артикулы;
o    Все остальные параметры можно засунуть в характеристики;
o    Серии! Программно серии «заточены» для разделение выпуска одного элемента номенклатуры по качественным партиям (на одну партию один сертификат качества).  Т.е. для хлопка, это «лот», для пряжи «сортировка», для крашенной пряжи или трик.полотна – это партия (сеанс) крашения и.т.п. Но, конечно, все не так однозначно. И в данный момент есть понимание, что серию на первом этапе использовать не надо, а в дальнейшем это будет ссылка на ДОКУМЕНТ ВЫПУСКА!

Это ребята не факт!
Это мои размышления по поводу внедрения УПП в моем - прядильном производстве.
...и Вам советую - немного подумать...

(24) Ситуация с загрузкой по характеристикам была больше года назад, и занимался ее разруливанием не я; деталей не помню. Я помню просто, что долго удивлялся, глядя на то, как вся стройная картина разбивки на номенклатуру/характеристики (по типу того, что предложено в (40)) рассыпается как карточный домик, когда дело дошло до реального начала работы с системой. В результате, назначение всех справочников спуталось. А если бы народ не извращался с этой разбивкой, то никаких проблем бы не было.

(30) >В любой отрасли , где нужно учитывать единичный товар. Например ювелирка.

А чем добавление нового элемента справочника Характеристики принципиально лучше добавления нового элемента Номенклатуры?

(32) >п.1 - если ты для тебя это трудно, то это вовсе не означает, что трудности возникнут у других

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

(39) >удобная фича, особенного когда не для всего справочника нужны доп. реквизиты

Так это не характеристики, это свойства. В принципе, имеют право на жизнь.

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

(45)
Иногда ту же номенклатуру нужно группировать по совершенно неожиданным свойствам. Более того - такая потребность может продолжаться месяц и все. Из-за каждой такой хотелки городить реквизиты? А что потом?

" -  А что это за реквизит?
 - А я уже и не помню."

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

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

С точки зрения пользователя, нет большой разницы между вариантами:
1) выбрать группу справочника, выбрать элемент (в случае с доп. уровнем иерархии, но без характеристик);
2) выбрать элемент, выбрать характеристику.
Первый вариант даже попроще, так как окошек меньше открывается и полей в документах меньше. Да и вообще интуитивно понятнее.
Зато программно обрабатывать одно поле заметно проще, чем два.

(40) Кстати, а что это за тема с ОКП? Не понял, какое отношение этот классификатор имеет к номенклатуре? В номенклатуре можно указать ссылку на ОКП, замечательно.
Но если имеется в виду, что должно быть ВЗАИМНО однозначное соответствие, то это полный бред (можно посмотреть на автосервисы, где могут быть сотни тысяч позиций номенклатуры, и это нормально; это наиболее яркий пример, а так их - множество). А если соответствие только в одну сторону, то как это может быть критерием разделения на номенклатуру и характеристики?

(0) что это такое ?

субконто ?

(46) >...городить реквизиты...
Не сложнее, чем городить свойства :)
Почему бы и нет? Это что, религия такая - не дай бог добавить лишний реквизит. Пусть мы лучше нагородим свойств, будем работать с ними через ж..., и пусть вся база тормозит от запросов к регистрам свойств каждый раз. Но зато у нас не будет дополнительных реквизитов в справочнике!

" -  А что это за свойство?
- А я уже и не помню."
:)

Кстати, тема не столько про свойства, сколько про характеристики и учет в их разрезе.

(49) Открой УТ или любое другое торговое поделие от 1С.

(51)
Уважаемый, ты же в 1С пришел не из мира больших СУБД, верно?

(52) расширенное субконто ?

(53) Верно.
Но и не все базы - большие.

(54) Так, теперь моя очередь спрашивать. При чем здесь субконто?

зачем в УТ в регистре ВзаиморасчетыСКонтрагентами есть два измерения :
ДоговорКонтрагента и Контрагент ?

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

Добавить реквизит в справочник - это создать себе дополнительные проблемы с обновлением. А пользователя к конфигуратору вообще лучше не подпускать.

(58)
И стаж вроде есть, но перл типа "по телефону объяснить, как реквизит добавить"... Жесть.

мдя... бедная конфигурация...

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

и вообще в чем проблема? не хочешь не используй, если функционал есть это хорошо, хуже если функционал нужен, а его нет

(60) Шучу. Уже лет шесть так не делал. Но в случае, когда клиент жутко надоел, а ехать не охота, можно и так :)
(61) Мои конфигурации жалеть не надо. Обычно после того, как я влезаю в измененные конфигурации, количество различий с типовыми уменьшается, иногда значительно. А простота обновления сильно улучшается.

Честно сказать, не вижу больших проблем при обновлении УТ. Релизы выходят не так часто, можно даже не до каждого обновляться. Ну придется потратить полчаса раз в несколько месяцев - не особо большая проблема. Зато все остальное время с базой работать намного проще - и мне, и пользователям.
У кого проблемы с обновлением из-за дополнительных реквизитов справочников? Как вам удается их получить? Почему у меня их нет? ЧЯДНТ?

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

(62) Почему не удалось обойтись без характеристик? Мне как раз такие случаи интересны.

(0) а если мне нужно создавать штрихкоды для каждой отдельной характеристики (для каждого размера, для каждого материала)? Будешь переписывать весь механизм использования штрихкодов? А если у меня размерный ряд для одной из позиций номенклатуры состоит из 15-20 позиций, и мне нужно только для одной из них назначить свою цену, а для других одинаковую? Я обойдусь всего 2-мя записями в установке цен, а если делать через свойства, это придется либо весь механизм цен, скидок и штрихкодов переписывать, либо создавать отдельные номенклатуры, и для каждой прописывать свою цену? То есть объем работы у пользователей возрастает в десятки раз. А если такой номенклатуры сотни, где у каждой по 20 характеристик, но для парочки характеристик своя цена?

без сомнений

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

Пример 2. Учет в разрезе заказов в УТ. Похоже, идею стащили из какого-то западного учебника или из системы типа SAP. Не знаю откуда точно, не я придумывал. Но явно не на основании анализа практики. Потому что потом ВНЕЗАПНО выяснилось, что учет по заказам очень мало кому нужен, а нужен учет в разрезе документов реализации. Пришлось срочно сделать уродливую схему на двух регистрах в УТ 10.3. А могли бы и сразу о реальных людях подумать, а не о сферических организациях в вакууме.

Пример 3. Многоступенчатый механизм планирования закупок в УТ. Это когда сначала общий план, а потом его уточнение по номенклатуре и характеристикам номенклатуры. На бумаге выглядит еще более или менее прилично. Но когда начинаешь объяснять пользователям, что для каждой позиции номенклатуры (из нескольких десятков тысяч позиций) нужно задать ее коэффициент вхождения в номенклатурную группу (и откуда этот коэффициент взять?!!), пользователи смотрят на тебя как на ненормального. И правильно делают. Потому что вся эта система планирования хороша только на бумаге. На практике посчитать все это в Excel в разы проще - хотя бы не надо по тысячам карточек номенклатуры лазить. Один раз коллеги сдуру прописали внедрение этой системы в ТЗ. Когда дело дошло до обучения пользователей, выяснилось, что использовать эту систему на практике совершенно невозможно, так как даже программисты в ней сильно путаются, а простые пользователи просто выпадают в осадок и закатывают истерики.

Все это примеры того, как типовые пишутся, не глядя на потребности и возможности пользователей.
Кстати, то, что делают в УТ 11 мне нравится. Кажется, нашлись умные люди в 1С.

на ошибках учатся иногда...

Ух ты!
Уже есть УТ11? Это под 8.2?

Не нравится, не ешь

(71) - пока допилят не один год пройдет...

(71) также как и БП 2.0. Но пока еще тестовые версии.
Нет, не обязательно под 8.2.

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