Артикулы в прайс-листе товаров с характеристиками
Артикулы создаются для номенклатуры. При создании товаров с характеристиками и генерации прайс-листов, каждый товар с характеристикой одной номенклатуры имеет один и тот же артикул. Это не подходит получателям прайс-листов, потому что им нужна идентификация каждой товарной позиции для своих собственных нужд.
При импорте прайс-листов, одним из вариантов поиска товаров есть поиск по артикулу и в дальнейшем можно каждому артикулу присвоить сопоставление нашего товара с конкретной характеристикой из нашей базы данных. Странно, что в процессе экспорта подобный вариант не учитывается.
В общем, подскажите, пожалуйста, как правильно организовать для внешних пользователей идентификацию наших собственных позиций по однозначному коду?
При импорте прайс-листов, одним из вариантов поиска товаров есть поиск по артикулу и в дальнейшем можно каждому артикулу присвоить сопоставление нашего товара с конкретной характеристикой из нашей базы данных. Странно, что в процессе экспорта подобный вариант не учитывается.
В общем, подскажите, пожалуйста, как правильно организовать для внешних пользователей идентификацию наших собственных позиций по однозначному коду?
По теме из базы знаний
- СТАБИЛЬНАЯ Загрузка справочника номенклатуры в 1С:Управление торговлей 8 из прайс-листа в Excel (код открыт скачать можно бесплатно)
- Формирование в УТ 10.3 прайс-листов с выгрузкой в Excel 2003 с картинками товара в примечаниях (пиктограммами)
- Облачный каталог товаров на 1C
- Простая выгрузка в файл формата XML товаров, остатков, цен свойств и характеристик, складов, фирм и фото для сайта. 1С: УТ 10.3
- Анализ закупок и продаж товаров – УТ 11.5, КА 2.5, ERP 2.5
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) FCDM, У вас есть свои артикулы? А в поле артикул номенклатуры вы забили Артикулы поставщиков или производителей? Для вывода прайсов СКД представляет почти безграничные возможности. Возможно вам придется создавать реквизит для внутренних идентификаторов. Это нормально.
(2) Захаров_Николай,
1. Пока идет продумывание базы. Если получателям прайс-листов удобно иметь какую-то привязку наших товарных предложений через артикулы - значит будем создавать артикулы.
2. В поле артикулы ничего не стоит. Ни поставщиков, ни производителей. если поставщиков одного и того же товара несколько - не имеет смысла туда помещать артикул одного из поставщиков. Но если забивать в это поле свои артикулы - они будут относиться только к номенклатуре - женские ботинки. А товарные предложения типа женские ботинки зеленые и женские ботинки красные будут иметь один и тот же артикул при генерации прайс-листа. Для клиентов нужно как-то идентифицировать каждое из товарных предложений.
Если создать дополнительный реквизит (наш артикул) - он будет относиться к позиции номенклатуры, а не к конкретной характеристике. Можно конечно создать отдельное свойство характеристики "артикул" с типом данных строка - и в него забивать артикул - но во-первых, это как-то извращенно выглядит по своей сути, во-вторых, при генерации прайс-листа генерируются не отдельные свойств из которых состоит характеристика, а целостная харакстерика. Нельзя вывести отдельной колонкой свойство артикул под видом артикула
[img][/IMG]
1. Пока идет продумывание базы. Если получателям прайс-листов удобно иметь какую-то привязку наших товарных предложений через артикулы - значит будем создавать артикулы.
2. В поле артикулы ничего не стоит. Ни поставщиков, ни производителей. если поставщиков одного и того же товара несколько - не имеет смысла туда помещать артикул одного из поставщиков. Но если забивать в это поле свои артикулы - они будут относиться только к номенклатуре - женские ботинки. А товарные предложения типа женские ботинки зеленые и женские ботинки красные будут иметь один и тот же артикул при генерации прайс-листа. Для клиентов нужно как-то идентифицировать каждое из товарных предложений.
Если создать дополнительный реквизит (наш артикул) - он будет относиться к позиции номенклатуры, а не к конкретной характеристике. Можно конечно создать отдельное свойство характеристики "артикул" с типом данных строка - и в него забивать артикул - но во-первых, это как-то извращенно выглядит по своей сути, во-вторых, при генерации прайс-листа генерируются не отдельные свойств из которых состоит характеристика, а целостная харакстерика. Нельзя вывести отдельной колонкой свойство артикул под видом артикула
[img][/IMG]
(1) FCDM, тоже размышляли над этим вопросом.
Одни клиенты ввели просто доп свойство SKU в характеристику, которое и стало аналогом артикула. Основной минус такого решения: можно создать характеристику с одинаковыми свойствами и разным SKU. Клиент оставил этот контроль на человека.
Так же предлагалось решение с доработкой (минимальной). Характеристика - справочник, в котором можно включить код. уникальность просто надо назначить в рамках всего справочника, а не подчинения
Одни клиенты ввели просто доп свойство SKU в характеристику, которое и стало аналогом артикула. Основной минус такого решения: можно создать характеристику с одинаковыми свойствами и разным SKU. Клиент оставил этот контроль на человека.
Так же предлагалось решение с доработкой (минимальной). Характеристика - справочник, в котором можно включить код. уникальность просто надо назначить в рамках всего справочника, а не подчинения
Артикул в вашем случае - это ваш внутренний идентификатор, или, как в случае каких нибудь запчастей, однозначный для всей индустрии?
Если первое, то нагенерите штрих-кодов для каждого сочетания номенклатура/характеристика и их используйте.
Если второе, то скорее всего использование пары идентификаторов (для тех же запчастей - артикул + производитель) практически не избежно.
Если первое, то нагенерите штрих-кодов для каждого сочетания номенклатура/характеристика и их используйте.
Если второе, то скорее всего использование пары идентификаторов (для тех же запчастей - артикул + производитель) практически не избежно.
(3) ditp,
1. Артикул свой собственный.
2. Вариант со штрихкодами хорош, но - во-первых, пока что не идет работа через штрихкод. Во-вторых, можно было бы настроить работу через штрихкод, но пока что не все товары есть на нашем складе, некоторые продаются напрямую со склада поставщика, соответственно не известны штрхкоды товара. В-третьих, можно было бы придумать свои собственные штрихкоды вместо реальных штрихкодов, но когда станут известны настоящие штрихкоды производителей - их придется заменять на настоящие штрихкоды, а клиентам придется переделывать свои сопоставления. Можно было бы, конечно, не переделывать свои штрихкоды и ими пользоваться - но использовать поле реальных штрихкодов под придуманную систему собственную систему штрихкодов - опять таки глупо в случае, если в конечном итоге все переведется на систему идентификации товара по штрихкоду, ведь тогда приется клеить на каждую коробку свои внутренние штрихкоды и только после этого заводить в базу данных. И в-четвертых - в разделе цены (прайс-листы) нельзя вывести штрихкоды как отдельную колонку (есть ставка ндс, испоьзовать характеристики (да нет), варианты оформления продажи и прочая ненужная для генерации прайс-листа чушь) - но поле штрихкод в списке отсутствует.
1. Артикул свой собственный.
2. Вариант со штрихкодами хорош, но - во-первых, пока что не идет работа через штрихкод. Во-вторых, можно было бы настроить работу через штрихкод, но пока что не все товары есть на нашем складе, некоторые продаются напрямую со склада поставщика, соответственно не известны штрхкоды товара. В-третьих, можно было бы придумать свои собственные штрихкоды вместо реальных штрихкодов, но когда станут известны настоящие штрихкоды производителей - их придется заменять на настоящие штрихкоды, а клиентам придется переделывать свои сопоставления. Можно было бы, конечно, не переделывать свои штрихкоды и ими пользоваться - но использовать поле реальных штрихкодов под придуманную систему собственную систему штрихкодов - опять таки глупо в случае, если в конечном итоге все переведется на систему идентификации товара по штрихкоду, ведь тогда приется клеить на каждую коробку свои внутренние штрихкоды и только после этого заводить в базу данных. И в-четвертых - в разделе цены (прайс-листы) нельзя вывести штрихкоды как отдельную колонку (есть ставка ндс, испоьзовать характеристики (да нет), варианты оформления продажи и прочая ненужная для генерации прайс-листа чушь) - но поле штрихкод в списке отсутствует.
Поставщики ваши как из этой ситуации вышли? Их метод может скопировать, раз уж пока ничего своего нет?
И насчет формирования прайса и доп колонок в нем - это одна из самых безобидных, но необходимых доработок, по моему опыту.
И насчет формирования прайса и доп колонок в нем - это одна из самых безобидных, но необходимых доработок, по моему опыту.
(6) ditp,
1. поставщики вышли из этой ситуации проще простого. НЕ ИСПОЛЬЗУЮТ ХАРАКТЕРИСТИКИ. Этот вариант не подходит.
2. допиливать пока что ничего не хотелось бы. Планируется регулярное обновление программы. Так как система 1с в этом плане достаточно топорно организована, есть подозрение, что она будет еще обновляться. Но то такое, по этому вопросу еще предстоит поразмыслить. Пока что, главная проблема сформулирована в 1 посте.
1. поставщики вышли из этой ситуации проще простого. НЕ ИСПОЛЬЗУЮТ ХАРАКТЕРИСТИКИ. Этот вариант не подходит.
2. допиливать пока что ничего не хотелось бы. Планируется регулярное обновление программы. Так как система 1с в этом плане достаточно топорно организована, есть подозрение, что она будет еще обновляться. Но то такое, по этому вопросу еще предстоит поразмыслить. Пока что, главная проблема сформулирована в 1 посте.
Самый простой путь решения имхо в данном случае (если необходимо использовать характеристики) - это создать свой регистр сведений, в котором сопоставить номенклатуру с характеристиками и артикулы, откуда можно будет их считывать в прайс (или куда еще), и при обновлении это не будет сильно мешать, ибо не ломается типовой регистр сведений, а создается новый.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот