В платформе «1С:Предприятие 8.3.21» появятся множественные характеристики
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
7 лет назад делал подобный фильтр в обработке подбора товаров для УПП 1.2, на свойствах номенклатуры, набор свойств определялся номенклатурной группой, значения свойств выбирались из справочника доп. значений, при переходе между группами товаров в форме подбора, изменялись доступные наборы свойств фильтра, работало отлично. Подобная штука к тому времени уже появилась в УТ11.
покупатель хочет увидеть все смартфоны, в корпусе которых используется стекло
Пример некорректный. Кто мешает сейчас сделать общую характеристику "Материал корпуса" и отбирать по ней в отчетах и списках?
А вот одежду из нескольких цветов отбирать по каждому цвету невозможно, если не делать характеристики "Цвет1", "Цвет2" и т. д.
(5) Ну как для чего. Представим себе минеральные добавки к кормам например. Одна добавка подходит для кошек и собак. Вторая только для кошек. Третья для кошек, собак, лошадок, коровок.
Нам надо отобрать к подбору все добавки, которые подойдут собачкам. Сейчас это решается через свойство "ПодходитДляСобак" = истина. Но хочется конечно многие ко многим. в МДМ системах количество атрибутов может исчисляться сотнями. С остатками по характеристикам будет как раньше, но можно будет посчитать и в доп. разрезе
Нам надо отобрать к подбору все добавки, которые подойдут собачкам. Сейчас это решается через свойство "ПодходитДляСобак" = истина. Но хочется конечно многие ко многим. в МДМ системах количество атрибутов может исчисляться сотнями. С остатками по характеристикам будет как раньше, но можно будет посчитать и в доп. разрезе
(8) "Доп разрез" я так думаю это в регистре сведений "Значения свойств объектов" значение переедет в измерение. А вот как дополнительные реквизиты реализуют - вопрос, текущий вариант с табличной частью справочника неидеален, предполагаю что сделают как справочник "присоединенные файлы" - на каждый объект к которому нужны допреквизиты отдельный справочник
Про "это всё элементарно решается" - интересно было бы послушать
Про "это всё элементарно решается" - интересно было бы послушать
(6)
Функционал сегментов? При этом если строить отчет остатков товаров организации (или в рабочем месте менеджера смотреть) в разрезе подобных характеристик, то возможен вариант когда остатков первой добавки 1шт, второй 1шт, третьей 1шт. Казалось бы в сумме 3шт, а нет - всего лишь две. У менеджера мозг взорвется.
Одна добавка подходит для кошек и собак. Вторая только для кошек. Третья для кошек, собак, лошадок, коровок.
Функционал сегментов? При этом если строить отчет остатков товаров организации (или в рабочем месте менеджера смотреть) в разрезе подобных характеристик, то возможен вариант когда остатков первой добавки 1шт, второй 1шт, третьей 1шт. Казалось бы в сумме 3шт, а нет - всего лишь две. У менеджера мозг взорвется.
(5) ну в продажах, попросил клиент кроссовки с желтым элементом - сформировали отчет, получили все варианты - желто-синие, желтые, красно-бело-желтые
в производстве ОТК выяснили, что в январе фиолетовая краска была оказалась опасной, решили отозвать партии с фиолетовыми элементами - сформировали отчет по выпуску партий...
тут конечно можно попробовать отчет текстовым отбором "содержит", но не везде, а если еще пересечение/исключение множеств потребуется...
интересно, как реализовали сабж, будут ли связанные изменения в языке запросов, скд
в производстве ОТК выяснили, что в январе фиолетовая краска была оказалась опасной, решили отозвать партии с фиолетовыми элементами - сформировали отчет по выпуску партий...
тут конечно можно попробовать отчет текстовым отбором "содержит", но не везде, а если еще пересечение/исключение множеств потребуется...
интересно, как реализовали сабж, будут ли связанные изменения в языке запросов, скд
Так и не смог точно понять что они сделают :-/
Попробую проанализировать:
Возможность декларативно (через раздел настройки "Характеристики", или в языке запросов СКД) привязать к объекту владельцу (в примере одному элементу справочника "ХарактеристикиНоменклатуры", а нет - там вероятно там напрямую справочник "Номенклатура" как Товар - но это не принципиально) несколько значений одного и того же свойства - элемента Плана видов характеристик - в примере "ДополнительныеРеквизитыИСведения" - в примере это свойство названо "Цвет".
Эта настройка "Характеристики" обрабатывается в платформе сейчас только механизмом СКД, в т.ч. "ДинамическимСписок" - значит результатом значения такого свойства будет скорее всего "Массив" - "ДинамическийСписок" его значения сам выведет через запятую. Отчеты СКД тоже умеют выводить массивы (хотя элементы вроде бы выводятся через ";", может и "ДинамическийСписок" тоже и сейчас умеет выводить через ";" значения колонки типа "Массив" - не проверял) - хотя разделитель можно заменить на другой - но нужны будут доп манипуляции.
Значения свойств хранятся обычно либо в регистре сведений (в примере это возможно "ДополнительныеСведения") - одно значение - одна запись. Значит - в конфигурациях нужно будет расширить регистр ещё одним измерением - для нумерации - чтобы хранить несколько значений).
Но значения характеристик обычн сейчас хранятся как доп реквизиты в отдельной табличной части владельца (справочника "ХарактеристикиНоменклатуры" или "Номенклатура" - с именем ТЧ "ДополнительныеРеквизиты") - а там уже и так можно указать множественные значения одного и того же свойства (доп реквизита) в разных строках.
Тогда остаётся только доработать сам механизм декларативной привязки в разделе "Характеристики" (если кто не знает - это отдельный пункт действий во всплывающем подменю действий целевого объекта; яркую кнопку/закладку в форме метаданных объекта не ищите; можно ещё найти Характеристики Открыть в эксплорере свойств метаданного целевого ссылочного объекта, рядом с открытием стандартных реквизитов).
То есть - добавить необязательную возможность указать поле-источник перечисления значений - если допускается множественные.
Хотя если ограничиться только табличными частями - то и эту настройку можно не делать - а просто выбирать все строки, по отбору свойства - а не одну.
По сути - если не заворачивается с типовыми фишками - то всё это можно реализовать и сейчас - куроча конфигурацию - просто это лишит некоторой доп автоматизации обработки таких свойств - придётся дописывать руками!
Про то что выше спросили про остатки - данная фича на них никак не влияет. Это просто доп свойства. То есть - если это "Номенклатура" - то как был один элемент справочника - так и останется - и остатки будут по нему и только по нему. Если это справочник "ХарактеристикиНоменклатуры" - то тоже самое - сколько их будет - столько и будет рарезов хранения остатков. Если будет одна характеристика с разными значениями одного свойства - то и остатки по ней будут общие. Не всем они нужны для учета раздельно по всем свойствам.
Да и сами характеристики и свойства - это не только Номенклатура и ХарактеристикиНоменклатура - это и контрагенты, и контактные лица и документы и т.д. - вариантов много - и сам уже сталкивался с тем, что бывает нужно хранить несколько значений в одном свойстве (например номера исходных документов после какой-то операции консолидации данных). Сейчас хранить так можно только строки - объединяя их конкатенацией с тем же разделителем "," или иным.
Доработка платформы позволит хранить и другие значения списком. А главное - позволит по ним строить, например, отборы - обрабатывая каждое значение по отдельности.
Ну, вот так я себе это понял! А как буде - узнаем когда появится 21 релиз платформы для ознакомления!
Попробую проанализировать:
Возможность декларативно (через раздел настройки "Характеристики", или в языке запросов СКД) привязать к объекту владельцу (в примере одному элементу справочника "ХарактеристикиНоменклатуры", а нет - там вероятно там напрямую справочник "Номенклатура" как Товар - но это не принципиально) несколько значений одного и того же свойства - элемента Плана видов характеристик - в примере "ДополнительныеРеквизитыИСведения" - в примере это свойство названо "Цвет".
Эта настройка "Характеристики" обрабатывается в платформе сейчас только механизмом СКД, в т.ч. "ДинамическимСписок" - значит результатом значения такого свойства будет скорее всего "Массив" - "ДинамическийСписок" его значения сам выведет через запятую. Отчеты СКД тоже умеют выводить массивы (хотя элементы вроде бы выводятся через ";", может и "ДинамическийСписок" тоже и сейчас умеет выводить через ";" значения колонки типа "Массив" - не проверял) - хотя разделитель можно заменить на другой - но нужны будут доп манипуляции.
Значения свойств хранятся обычно либо в регистре сведений (в примере это возможно "ДополнительныеСведения") - одно значение - одна запись. Значит - в конфигурациях нужно будет расширить регистр ещё одним измерением - для нумерации - чтобы хранить несколько значений).
Но значения характеристик обычн сейчас хранятся как доп реквизиты в отдельной табличной части владельца (справочника "ХарактеристикиНоменклатуры" или "Номенклатура" - с именем ТЧ "ДополнительныеРеквизиты") - а там уже и так можно указать множественные значения одного и того же свойства (доп реквизита) в разных строках.
Тогда остаётся только доработать сам механизм декларативной привязки в разделе "Характеристики" (если кто не знает - это отдельный пункт действий во всплывающем подменю действий целевого объекта; яркую кнопку/закладку в форме метаданных объекта не ищите; можно ещё найти Характеристики Открыть в эксплорере свойств метаданного целевого ссылочного объекта, рядом с открытием стандартных реквизитов).
То есть - добавить необязательную возможность указать поле-источник перечисления значений - если допускается множественные.
Хотя если ограничиться только табличными частями - то и эту настройку можно не делать - а просто выбирать все строки, по отбору свойства - а не одну.
По сути - если не заворачивается с типовыми фишками - то всё это можно реализовать и сейчас - куроча конфигурацию - просто это лишит некоторой доп автоматизации обработки таких свойств - придётся дописывать руками!
Про то что выше спросили про остатки - данная фича на них никак не влияет. Это просто доп свойства. То есть - если это "Номенклатура" - то как был один элемент справочника - так и останется - и остатки будут по нему и только по нему. Если это справочник "ХарактеристикиНоменклатуры" - то тоже самое - сколько их будет - столько и будет рарезов хранения остатков. Если будет одна характеристика с разными значениями одного свойства - то и остатки по ней будут общие. Не всем они нужны для учета раздельно по всем свойствам.
Да и сами характеристики и свойства - это не только Номенклатура и ХарактеристикиНоменклатура - это и контрагенты, и контактные лица и документы и т.д. - вариантов много - и сам уже сталкивался с тем, что бывает нужно хранить несколько значений в одном свойстве (например номера исходных документов после какой-то операции консолидации данных). Сейчас хранить так можно только строки - объединяя их конкатенацией с тем же разделителем "," или иным.
Доработка платформы позволит хранить и другие значения списком. А главное - позволит по ним строить, например, отборы - обрабатывая каждое значение по отдельности.
Ну, вот так я себе это понял! А как буде - узнаем когда появится 21 релиз платформы для ознакомления!
«Востребованность такого функционала понятна – например, покупатель хочет увидеть все смартфоны,
в корпусе которых используется стекло.
для этого есть интернет-магазин
а вот решение ошибок в платформе :
"Востребованность такого функционала НЕ понятно" :)
в корпусе которых используется стекло.
для этого есть интернет-магазин
а вот решение ошибок в платформе :
"Востребованность такого функционала НЕ понятно" :)
Очень востребованный функционал, удивлен, что раньше в 1С была только 1 характеристика, это ужас! У нас магазин одежды. Имеем Название, + 5 размеров + 5 цветов + нюансы ( длина рукава, капюшоны и т.п.) . Т.е. по сути как минимум больше 25 вариантов для 1 номенклатуры. Вместо того, чтобы иметь 3-4 столбика с характеристиками, приходилось создавать кучу лишней однотипной номенклатуры: "Куртка синяя с капюшоном" + размер ( характеристикой) , "Куртка синяя без капюшона" + размер ( характеристикой).... А характеристика-то одна!! В итоге бардак в справочнике номенклатуры и требование к знаниям в Экселе ))
Если теперь можно завести номенклатуру: "Куртка" + синяя ( характеристика) + капюшон ( характеристика) + размер ( характеристика). То это будет просто прорыв для 1С, и сокращение справочника в мегараз!!
Если теперь можно завести номенклатуру: "Куртка" + синяя ( характеристика) + капюшон ( характеристика) + размер ( характеристика). То это будет просто прорыв для 1С, и сокращение справочника в мегараз!!
(18) то что вы написали это свойства характеристик (или в новых конфигурациях можно сделать через доп. реквизиты характеристик со своими значениями - цвет, наличие капюшона, размер), и уже работает давно.
Как я понял они добавляют возможность у куртки указать что она одновременно синяя и красная в одной характеристике - для работы в отборах и отчетах, но при этом остаток по данному виду курток будет один, потому что это один объект.
У нас в электрике такая же проблема - через свойства характеристик достаточно сложно добавить разнообразные виды технических показателей, например количество полюсов автоматов, жил кабеля и т.д., особенно в разнотипных товарах если они встречаются, но не все сразу. А в интернет-магазинах например dns вы наверное видели отборы типа по емкости аккумулятора, типу сети например поддерживает и 3G и 4G и надо чтобы попадал в оба варианта поиска, и тд - вот такие вещи можно будет делать в 1С, и это хорошо.
Как я понял они добавляют возможность у куртки указать что она одновременно синяя и красная в одной характеристике - для работы в отборах и отчетах, но при этом остаток по данному виду курток будет один, потому что это один объект.
У нас в электрике такая же проблема - через свойства характеристик достаточно сложно добавить разнообразные виды технических показателей, например количество полюсов автоматов, жил кабеля и т.д., особенно в разнотипных товарах если они встречаются, но не все сразу. А в интернет-магазинах например dns вы наверное видели отборы типа по емкости аккумулятора, типу сети например поддерживает и 3G и 4G и надо чтобы попадал в оба варианта поиска, и тд - вот такие вещи можно будет делать в 1С, и это хорошо.