Одна номенклатура одновременно в нескольких группах. УНФ 1.6
Добрый день.
УНФ 1.6
Поставлена такая задача - необходимо, чтобы расположение номенклатуры в 1С соответствовало расположению товаров на сайте. Суть в следующем - на сайте один товар одновременно может находиться в нескольких разных категориях. Также требуется сделать и в 1С, чтобы номенклатура могла находиться одновременно в нескольких группах.
Например, имеется номенклатура "Поилка 001", которая должна находиться как в группе "Оборудование для кроликов", так и в группе "Оборудование для шиншилл". При этом не должно быть никаких дублей. Просто один товар в двух или более группах.
Вопрос в том, как это закодить, чтобы все работало корректно. Учитывая, что описанный принцип должен работать в табличной части документов, в форме подбора и, само собой, в справочнике номенклатуры.
Заранее спасибо за помощь.
УНФ 1.6
Поставлена такая задача - необходимо, чтобы расположение номенклатуры в 1С соответствовало расположению товаров на сайте. Суть в следующем - на сайте один товар одновременно может находиться в нескольких разных категориях. Также требуется сделать и в 1С, чтобы номенклатура могла находиться одновременно в нескольких группах.
Например, имеется номенклатура "Поилка 001", которая должна находиться как в группе "Оборудование для кроликов", так и в группе "Оборудование для шиншилл". При этом не должно быть никаких дублей. Просто один товар в двух или более группах.
Вопрос в том, как это закодить, чтобы все работало корректно. Учитывая, что описанный принцип должен работать в табличной части документов, в форме подбора и, само собой, в справочнике номенклатуры.
Заранее спасибо за помощь.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
В такой постановке задача очевидно в рамках 1с не решается.
(1)
но если понять, как предполагается этим пользоваться, то наверное что-то можно придумать. Завести сущность "раздел сайта", организовать связь с номенклатурой "многие ко многим" и во всякие формы запихнуть. Хорошая задача, если исполнитель на повременке )
(1)
чтобы номенклатура могла находиться одновременно в нескольких группах
но если понять, как предполагается этим пользоваться, то наверное что-то можно придумать. Завести сущность "раздел сайта", организовать связь с номенклатурой "многие ко многим" и во всякие формы запихнуть. Хорошая задача, если исполнитель на повременке )
(1) у номенклатуры есть родитель это связь 1 к 1. Поэтому в лоб задача никогда не будет решаться. А вот если завести сущности категории, то не проблема добавить номенклатуре 2 категории и потом вывести это в нужной вам форме.
Но как по мне костыль костылем!
Но как по мне костыль костылем!
(1) Если ничего не путаю, то это классический случай разрешения связи типа М:М.
Ну, "одновременно в нескольких группах", если под группами понимать обычные группы иерархического справочника - это не стоит даже обсуждать. А про "необычные" см. ниже.
Мысли такие:
0. Создаем иерархический справочник "Категории" с иерархией групп.
Для удобства создаем предопределенный элемент "Вне категории" - сюда будем относить всю номенклатуру, у которой категории нет.
1. Вводим промежуточную таблицу (например, РС) с первичным составным ключом КатегорияСсылка, Номенклатура.Ссылка.
2. При заведении новой номенклатуры обновляем табл. из п.1
3. Используем свою форму подбора и списка, где организуем дерево иерархии в разрезе категорий: выводим свое дерево, полученное простым запросом из справочника категорий, при разворачивании ветки, при необходимости, дополняем строками из п. 2.
Тут сами думайте, может по мере, может сразу дерево заполнить, если позиций мало.
Я бы фигней с заполнением дерева не страдал:
Слева выводим справочник категорий.
Справа номенклатуру, попадающую в категорию из категорий слева (для чего использовал индексированную ТЗ с отбором по колонке "категория", можно и дин. список с отбором по категории на основе табл. п.1).
Снизу, справочно, для выделенной строки номенклатуры еще и показываем в какие другие категории эта номенклатура входит (потому и удобней ТЗ).
Если честно, ничего плохого с точки зрения бизнеса в таком подходе не вижу.
Произвольные иерархии - обычно удел СКД (стрелять из этой пушки по форме выбора я бы не стал) и отчетов, но иногда это надо и в других местах.
По времени исполнения, если подходить серьезно, т. е. с тестированием граничных случаев, производительности, выгрузки на сайт, решением бизнес вопросов типа "в каком месте разрешено создавать новые категории", обязательно ли указывать категорию и т.п.
Ну, где-то неделя.
Ну, "одновременно в нескольких группах", если под группами понимать обычные группы иерархического справочника - это не стоит даже обсуждать. А про "необычные" см. ниже.
Мысли такие:
0. Создаем иерархический справочник "Категории" с иерархией групп.
Для удобства создаем предопределенный элемент "Вне категории" - сюда будем относить всю номенклатуру, у которой категории нет.
1. Вводим промежуточную таблицу (например, РС) с первичным составным ключом КатегорияСсылка, Номенклатура.Ссылка.
2. При заведении новой номенклатуры обновляем табл. из п.1
3. Используем свою форму подбора и списка, где организуем дерево иерархии в разрезе категорий: выводим свое дерево, полученное простым запросом из справочника категорий, при разворачивании ветки, при необходимости, дополняем строками из п. 2.
Тут сами думайте, может по мере, может сразу дерево заполнить, если позиций мало.
Я бы фигней с заполнением дерева не страдал:
Слева выводим справочник категорий.
Справа номенклатуру, попадающую в категорию из категорий слева (для чего использовал индексированную ТЗ с отбором по колонке "категория", можно и дин. список с отбором по категории на основе табл. п.1).
Снизу, справочно, для выделенной строки номенклатуры еще и показываем в какие другие категории эта номенклатура входит (потому и удобней ТЗ).
Если честно, ничего плохого с точки зрения бизнеса в таком подходе не вижу.
Произвольные иерархии - обычно удел СКД (стрелять из этой пушки по форме выбора я бы не стал) и отчетов, но иногда это надо и в других местах.
По времени исполнения, если подходить серьезно, т. е. с тестированием граничных случаев, производительности, выгрузки на сайт, решением бизнес вопросов типа "в каком месте разрешено создавать новые категории", обязательно ли указывать категорию и т.п.
Ну, где-то неделя.
(10)Разумное и интересное решение. Но у меня вот возник вопрос, где эта дичь, точнее не так, кому эта дичь может пригодится? Продавцу? Оно ему ни в одно место не брякало. Кладовщику? Точно такая же песня как и с продавцом. Разве, что маркетологу, эти юродивые единственные кто такую дичь может придумать.
(12)
Зачем нужно вместо простого поиска по категории в той же форме подбора делать "как на сайте", не знаю.
Это вопросы к PM.
Заодно можно напомнить, что у номенклатуры может быть много других интересных свойств, например, сезонность, ценовой сегмент, бренд и т.п.
Но, если послушать доводы всех высоких сторон, то все это может оказаться не таким уж бредом.
Вообще, ежели времени вагон, то можно создать универсальную форму подбора с выбором желательного метода иерархии по имеющимся свойствам/категориям/реквизитам. По мне так бесполезное переизобретение СКД, но интересно. :)
Но у меня вот возник вопрос, где эта дичь, точнее не так, кому эта дичь может пригодится?
Зачем нужно вместо простого поиска по категории в той же форме подбора делать "как на сайте", не знаю.
Это вопросы к PM.
Заодно можно напомнить, что у номенклатуры может быть много других интересных свойств, например, сезонность, ценовой сегмент, бренд и т.п.
Но, если послушать доводы всех высоких сторон, то все это может оказаться не таким уж бредом.
Вообще, ежели времени вагон, то можно создать универсальную форму подбора с выбором желательного метода иерархии по имеющимся свойствам/категориям/реквизитам. По мне так бесполезное переизобретение СКД, но интересно. :)
(13)Ну да, можно запилить даже отдельный ДС для этих целей. Мне реально интересно, что за "гений" хочет , что бы в 1с выглядело как на сайте, на ум приходит только маркетолог. У мну такой же, типо вот как на сайте, жесткой аргументации, что это писец как необходимо он привести не смог, ему так удобнее, директор сказал, что как есть так и будет. В битриксе это все уже давно реализовано и работы минимум. все равно сайти и 1с ты не синхронизируешь пуля в пулю
(16) Это вы еще лиды не пробовали считать, приписывая их к тел. звонкам по принципам, от которых ChatGpt повесился бы.
А когда вы все это сделали по ТЗ этого самого маркетолога, анализируя и переводы звонка и "если Иванов и в течении 20 минут, а Петров, но не более чем в течении 3-х дней, а еще есть "менеджер на доверии" и тогда учитываем еще вручную созданные. А если стоит галочка без оплаты, но оплата прошла с аванса, то" и т.п.
Всего каких-то 30, не всегда консистентных, условий.
Маркетолог гордо открывает свой файл Excel и требует объяснить почему не совпадает, причем по каждому пункту.
Но в данном случае, скорее-всего, на обоих концах сидят менеджеры по продажам и один другому:
- открой "обувь для девочек старше 50", там зайди в "летняя", видишь "сапоги женские арт 1577"?
- а теперь открой "изделия из чебурашки", зайди в "шапоклякам", видишь те же сапоги женские?
- и какого у них артикул не совпадает? Озадачь своих 1С-ов.
- Нет я понятия не имею почему это у вас в 1С нет такой группы как "обувь для девочек старше 50", не мудри.
Идея учить менеджера 1С мертворожденная - надо чтобы пока он не уволился, от него хоть какая польза была.
А если человек способен понять как работать с обычными группами и не теряться в категориях, то он тут же и уволится, пойдет в аналитики. :)
А когда вы все это сделали по ТЗ этого самого маркетолога, анализируя и переводы звонка и "если Иванов и в течении 20 минут, а Петров, но не более чем в течении 3-х дней, а еще есть "менеджер на доверии" и тогда учитываем еще вручную созданные. А если стоит галочка без оплаты, но оплата прошла с аванса, то" и т.п.
Всего каких-то 30, не всегда консистентных, условий.
Маркетолог гордо открывает свой файл Excel и требует объяснить почему не совпадает, причем по каждому пункту.
Но в данном случае, скорее-всего, на обоих концах сидят менеджеры по продажам и один другому:
- открой "обувь для девочек старше 50", там зайди в "летняя", видишь "сапоги женские арт 1577"?
- а теперь открой "изделия из чебурашки", зайди в "шапоклякам", видишь те же сапоги женские?
- и какого у них артикул не совпадает? Озадачь своих 1С-ов.
- Нет я понятия не имею почему это у вас в 1С нет такой группы как "обувь для девочек старше 50", не мудри.
Идея учить менеджера 1С мертворожденная - надо чтобы пока он не уволился, от него хоть какая польза была.
А если человек способен понять как работать с обычными группами и не теряться в категориях, то он тут же и уволится, пойдет в аналитики. :)
(1) Конечно группы в данном случае будут не папки справочника. Можно сделать отдельную форму с динамическим списком, в котором номенклатура будет ниже по иерархии, чем реквизит "Группа номенклатуры". А у каждой номенклатуры будет задана одна или более "Групп номенклатуры" (это может быть прописано в табличной части номенклатуры или в отдельном регистре сведений).
Сайт на чем? Как правило настраивается дерево иерархии, которое будет выгружаться на сайт при этом одна позиция может находиться в нескольких разделах сайта, но в базе 1С это одна и та же позиция. Если сайт на какой нибудь cms например тот же битрикс, то это делается прям в модуле обмена, если это самописный сайт и нет организации структуры иерархии для обмена между сайтом и бд 1с то нужно допиливать.
(2) Категорически поддерживаю! Эти самодельные сайты с интеграцией на коленке от программистов на html ни к чему хорошему не приведут - убьют кучу времени и денег. Стопудово потом со стороны вэберов потребуется 100/500 дополнительных справочников (наблюдал за этим адом со стороны). В 100 раз быстрее поставить тот же Битрикс, в котором уже всё реализовано.
Я так понимаю, что нужна форма выбора/подбора в УНФ, чтобы в ней группы были не группами, а категориями, в каждой из которых должны быть относящиеся к ним товары.
Если так, то придется рисовать свою форму с деревом, в которую подгружать всю эту запутанную номенклатуру, для которой нужно сделать табличную часть со списком категорий, в которые конкретная номенклатура входит. Дерево на форме - это не быстро вообще ни разу, если там много значений. Так что грусть-тоска. Остается понять, на сколько это вашему руководству нужно. Скорее всего не нужно вообще, но желание есть...
Если так, то придется рисовать свою форму с деревом, в которую подгружать всю эту запутанную номенклатуру, для которой нужно сделать табличную часть со списком категорий, в которые конкретная номенклатура входит. Дерево на форме - это не быстро вообще ни разу, если там много значений. Так что грусть-тоска. Остается понять, на сколько это вашему руководству нужно. Скорее всего не нужно вообще, но желание есть...
Сайт на чем? Как правило настраивается дерево иерархии, которое будет выгружаться на сайт при этом одна позиция может находиться в нескольких разделах сайта, но в базе 1С это одна и та же позиция
Остается понять, на сколько это вашему руководству нужно
- вот смотрите сидит менеджер по продажам которого только что наняли, звонит ему клиент и говорит я зашел в папку 1 потом в папку 2 и там нашел товар 1
А менеджер смотрит в 1ску и не видет в папке 1 далее в папке 2 товар 1, ну и далее продажа срывается ...
Можно сказать что нужно ему объяснить, можно сказать что нужно на сайте правильную иерархию делать и прочее и прочее - это понятно - но это все лишние действия и лишниее заморочки
Было бы хорошо если и менеджер и покупатель разговаривали на одном Языке ...
(5) ну если артикул товара это слишком банальное решение (ну в самом деле, у всех артикулы, а у нас манагер будет по папочкам шариться, это намного интереснее), то повторить иерархию сайта, пожалуй, будет самое то. Пара недель работы и вуаля ).
Тут же еще надо автоматическую синхронизацию предусмотреть. Мало ли что на сайте учудят, а в базе должно быть то же самое. Можно и месяц работы списать, наверное.
Тут же еще надо автоматическую синхронизацию предусмотреть. Мало ли что на сайте учудят, а в базе должно быть то же самое. Можно и месяц работы списать, наверное.
(5)странно, у нас тоже сайт и тоже товары пересекаются, сделано через справочник (структура сайта) в типовой выгрузке на битрикс, и нормально все все находят. так как обычно используется не иерархия а наименование, код, артикул. а менеджер быстро все это находит по поиску. плюс нафига менеджеру решать это по телефону, с сайта должен приходить заказ.
(1) Смотрите конфигурации с аптеками. В некоторых из них лекарства одновременно могут быть в разных "группах" + взаимозаменяемые.
В вашем случае забудьте про подбор по иерархии справочника. У вас подбор по другим разрезам. Иерархию справочника использовать не нужно совсем. Иерархию будет использовать товаровед для закупок.
В вашем случае забудьте про подбор по иерархии справочника. У вас подбор по другим разрезам. Иерархию справочника использовать не нужно совсем. Иерархию будет использовать товаровед для закупок.
Я продаю авто запчасти, столкнулся с такой делемой: Например
Мне нужно продать подшипники для разных КПП
Первый вариант:
1.Подшипник X,
2.Подшипник Y,
3.Подшипник Z,
4.Подшипник U,
5.Масло транс.
Второй вариант:
1.Подшипник А,
2.Подшипник B,
3.Подшипник Z,
4.Подшипник U,
5.Масло транс.
Как вы заметили, Подшипник Z, Подшипник U, и Масло транс., не может быть в одних и тех же группах, так как же можно объединить эти товары?
Во-первых это удобно в подборе, во-вторых уменьшается риск, например, что ты забудешь предложить клиенту масло, и таких критериев очень много, например запчасти для ремонта двигателя, либо сайлентблоки для подвески. Но как это организовать в рамкам системы 1С УНФ, ума не приложу, есть у кого идеи, поделитесь
Мне нужно продать подшипники для разных КПП
Первый вариант:
1.Подшипник X,
2.Подшипник Y,
3.Подшипник Z,
4.Подшипник U,
5.Масло транс.
Второй вариант:
1.Подшипник А,
2.Подшипник B,
3.Подшипник Z,
4.Подшипник U,
5.Масло транс.
Как вы заметили, Подшипник Z, Подшипник U, и Масло транс., не может быть в одних и тех же группах, так как же можно объединить эти товары?
Во-первых это удобно в подборе, во-вторых уменьшается риск, например, что ты забудешь предложить клиенту масло, и таких критериев очень много, например запчасти для ремонта двигателя, либо сайлентблоки для подвески. Но как это организовать в рамкам системы 1С УНФ, ума не приложу, есть у кого идеи, поделитесь
(19) как для унф не подскажу, но в свое время для упп делали типа стандартных сборок запчастей для автомобилей. и там как раз были такие комбинации, еще была связка со справочником АТ, и один умный менеджер собирал эти сборки, а продавцы реально не задумываясь указав машину и узел получали набор сборок, плюс там были стразу денные о замене, ну и дальше прикручены остатки.
В качестве идеи. Возможно несколько фантастично выглядит.
Нужно по-моему создать отдельный справочник что-то типа ДополнительнаяИерархияНоменклатуры. В справочнике должны присутствовать только группы. Первый уровень справочника - разделы дополнительной иерархии. Вглубь справочника - сами родители. Т.обр. сколько разделов - столько же иерархий.
В справочнике Номенклатура добавить сколько надо реквизитов Родитель1, Родитель2 и т.д. типа справочник ДополнительнаяИерархияНоменклатуры.
И тут самое сложное нужно разработать логику, формы списка, чтобы иерархия шла по Родитель1, Родитель2 и т.д.
Только так может быть возможно по-моему.
Нужно по-моему создать отдельный справочник что-то типа ДополнительнаяИерархияНоменклатуры. В справочнике должны присутствовать только группы. Первый уровень справочника - разделы дополнительной иерархии. Вглубь справочника - сами родители. Т.обр. сколько разделов - столько же иерархий.
В справочнике Номенклатура добавить сколько надо реквизитов Родитель1, Родитель2 и т.д. типа справочник ДополнительнаяИерархияНоменклатуры.
И тут самое сложное нужно разработать логику, формы списка, чтобы иерархия шла по Родитель1, Родитель2 и т.д.
Только так может быть возможно по-моему.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот