Культура нумерации номенклатур

[Narayana]

Не знаю как у других, но мне вопрос систематизации номенклатур не дает покоя очень давно.

Немного поискал, не было ли обсуждения этой тематики на сайте.
Нашел замечательную, но несколько не законченную в самом интересном месте статью Mazzy http://axapta.mazzy.ru/lib/tree/ .

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

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

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

Был бы очень признателен, если кто-то поделится собственными соображениями на этот счет. То есть, - а как правильно?

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

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

[Ivanhoe]

При таком количестве, имхо, просто автоматическая сквозная нумерация без какой-либо логики.

[EVGL]

Я присоединял номерные серии к группам номенклатуры.

[ikopyl]

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

[gl00mie]

Цитата:

Сообщение от Narayana

Предприятие специализируется на запчастях для автоматических коробок передач. Есть около 400 типов агрегатов и каждый агрегат содержит около 200 деталей, плюс варианты деталей. Поимимо этого на складе какое-то количество разношерстной номенклатуры типа масел, герметиков, инструмента, стройматериалов для собственных нужд, канцтоваров, компьютерного барахла и т.д. Первым встает вопрос о формате номеров номенклатуры. Аксапта при этом предполагается 2012-я.

В 2012-й вроде как в стандартной поставке идет AX for Retail. Я видел пример организации номенклатурного справочника на внедрении AX for Retail на 2009-й. Там есть иерархический каталог номенклатуры, на верхнем уровне которого - крупное деление (основные товары, аксессуары, оборудование...), затем - подгруппы и в них уже - розничные группы (таблица RBOInventItemRetailGroup). Вся нумерация числовая, коды розничных групп трехсимвольные со сквозной нумерацией (скажем, розничные группы 000..020 - это подгруппа1 основных товаров, 090..110 - подгруппаN аксессуаров и т.п.). Все номенклатуры поделены по розничным группам, первые 3 символа в коде номенклатуры - это код соотв. розничной группы. При этом в справочниках - порядка 10 тысяч номенклатур в 140 розничных группах. Создание новых кодов номенклатур следует соотв. нехитрым соглашениям. Еще, как вариант, можно использовать суффиксы, если можно дополнительно сгруппировать несколько (в пределах дюжины) связанных номенклатур, и такая однотипная группировка встречается часто. Вообще, можно накидать разных свойств номненклатур в таблицу и покрутить сводные/диаграммы по этим данным в Excel, тогда могут возникнуть идеи, какие группировки стоит использовать.

[Narayana]

Спасибо за высказанные мнения, попробую сделать некоторые обобщения по теме.

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

Но, как мне кажется, mazzy упустил одну деталь. Я тоже этой детали не видел раньше, но, когда стал рассматривать категории продуктов в 2012-й Аксапте, вдруг, понял, что Майкрософт в очередной раз сделал правильный идеологический выбор.
Речь вот о чем...
Когда размышляешь о принадлежности какой-то номенклатуры одной из вложенных папок иерархического каталога, то молчаливо предполагаешь, что одна номенклатура может лежать ТОЛЬКО В ОДНОЙ папке.
Этим, собственно, mazzy и обосновывал сложность поиска нужной позиции в многоуровневой системе папок. Ну, действительно, поди догадайся, как автор представляет себе упорядоченность списка. Ничего не остается, кроме тупого перебора всех папок и вынужденного обучения представлениям о систематизации автора.
Но, в новой Аксапте поступили хитро и правильно.
Они изменили идеологию привязки номенклатуры к папке иерархического уровня.
У них в папке более высокого уровня лежат все номенклатуры, лежащие в папках более низкого уровня. То есть, здесь категория (папка) работает, действительно, как фильтр. И это гениально. Хотя, если такой прием использовать для файловых каталогов, то картина получится веселая. Например, диск С: будет содержать помимо папок еще и все файлы, которые есть на диске.

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

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

И вот, речь заходит о систематизации.
Каким образом можно хранить информацию о принадлежности объекта к этой систематизации в виде иерархической структуры?
Эту информацию можно хранить либо в самой же записи объекта, либо где-то снаружи.
Только, если мы решаемся хранить информацию для объекта не только о самом себе, но и представлении об этом объекте для внешнего мира, мы тем самым принимаем решение сделать внешний мир неизменным.

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

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

Второй подход более лояльный.
Он начинается от полного отсутствия какой либо информации о систематизации и пользователи вынуждены диким способом искать нужные записи, либо дает возможность формировать информацию о любом количестве всевозможных иерархий вне записи о самом объекте. Что и сделано в категориях продуктов в 2012-й Аксапте. Сделано, как мне показалось, удачно.

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

Остается понять, у какого подхода больше приверженцев?

[Владимир Максимов]

Цитата:

Сообщение от Narayana

Когда размышляешь о принадлежности какой-то номенклатуры одной из вложенных папок иерархического каталога, то молчаливо предполагаешь, что одна номенклатура может лежать ТОЛЬКО В ОДНОЙ папке.

(...)

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

Вы "за деревьями не увидели леса" . Идеология осталась неизменной. Одна позиция номенклатуры по прежнему принадлежит ОДНОЙ папке. Просто в данном случае Вам предлагается ВЫБОР. Либо осуществлять поиск по иерархии дерева, либо напрямую в линейном списке. И этот выбор заложили by-design. Только и всего.

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

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

Вы путаете два процесса:

1. Составление отчетности
2. Создание (ввод) первичных документов

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

При этом то же "дерево" крайне не удобно при создании документов. При создании строки документа и так известен код (или название). Зачем же лишняя нервотрепка с поиском по дереву?

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

Проблема только в том, что начальство привыкло работать именно с "бумагой". Поэтому разработчики просто вынуждены впихивать дерево в систему. Иначе просто сложно будет продать Axapta.

[EVGL]

Цитата:

Сообщение от Владимир Максимов

Вы "за деревьями не увидели леса" . Идеология осталась неизменной. Одна позиция номенклатуры по прежнему принадлежит ОДНОЙ папке. Просто в данном случае Вам предлагается ВЫБОР. Либо осуществлять поиск по иерархии дерева, либо напрямую в линейном списке.

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

Цитата:

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

Я вам предложил гибридный вариант, но не был понят: при создании товара идет запрос группы или какого-нибудь признака, с которым связана номерная группа. Нумерация внутри группы - сквозная.

[ice]

Цитата:

Сообщение от Владимир Максимов

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

При этом то же "дерево" крайне не удобно при создании документов. При создании строки документа и так известен код (или название). Зачем же лишняя нервотрепка с поиском по дереву?

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

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

[George Nordic]

Насчет унификации. Мне как архитектору хотелось, чтобы работа с системой выглядела единообразно. Это касается не только интерфейса, но и данных - т.е. выработать полезные и применимые базовые решения, которые можно использовать по всей системе. Например, решал вопрос с артикулом номенклатуры - разработали правила наименования номенклатурных групп и номенклатуры, а после чего разработали шаблоны и мастер для создания номенклатуры, который был понятен всем сотрудникам компании. Например:
1 часть: тип: М - материалы, ПФ - полуфабрикат, ГП - готовая продукция.
Теперь, например, по материалам: 2часть - тип материала: МДФ, ДСП, ПВХ и т.п.
Для МДФ - 3я часть - толщина. 4я - размеры. 4я - базовый цвет. Да, получился составной искусственный ключ: М-МДФ-32-160-320-сер
Производственникам и технологам было очень легко искать номенклатуру по артикулу, да и заводить (без дубликатов, это не клиент, по ИНН на уникальность не проверишь).

Цитата:

Сообщение от Narayana

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

А вот теперь - пошли категории. Справочник номенклатуры (как и клиентов) - это плоский справочник. Однако у клиентов - есть возможность указать головную компанию или холдинг, для построения иерархий. А в номенклатуре - необходимо вводить категорийный менеджмент и строить иерархии в разрезе категорий. Т.е. набирать справочник по выбранным разрезам категорий. Но хранить - в плоском виде.

С Уважением,
Георгий

[pitersky]

Цитата:

Проблема только в том, что начальство привыкло работать именно с "бумагой". Поэтому разработчики просто вынуждены впихивать дерево в систему. Иначе просто сложно будет продать Axapta

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

[komar]

Ещё такой момент есть - а если:
1. Есть несколько категорий группировки
2. Они могут меняться во времени.
3. Они могут пересекаться.

Единственный разумный выход здесь - это манипуляция товарными группами, с минимальной информацией в кодах. То есть в код можно вносить некую информацию, но только ту, которая принципиально статична (хороший пример - VIN-номер автомобиля). Какие-то характеристики товара, допускающие произвольное толкование, либо которые могут изменяться - в коды пихать не стоит совсем.

[vmoskalenko]

Делюсь своим опытом в этой области.

Для AX 4.0 делали справочник номенклатур для автомобильных запчастей. Точнее переносили из самописной программы в Аксапту. Там было следующее бизнес-правило: Код номенклатуры соответствует коду номенклатуры по справочнику производителя (каталогу бренда).
Реализация в AX4 (Только торговля, без ОС, малоценки и проч):
Номенклатурная группа: 1,2,3,4,5 – Код подразделения (Масло, Доп.оборудование, Запчасти, Краски, прочее)
Код номенклатуры: Максимально приближенный код к наименованию, уникальный, ограниченный набор символов, 20 символов длиной.
Наименование номенклатуры: Код номенклатуры как указано в каталоге бренда.
Текст номенклатуры: Наименование номенклатуры, как оно должно быть в печатных документах.
Дополнительные поля: Код бренда, Код товарной группы.

А вот для AX2009, уже для другого проекта, делал справочник номенклатур. В этом проекте была специфика использования номенклатурных аналитик Размера и Конфигурации для основных номенклатур. И мы рискнули использовать аналитику Конфигурация для неосновных номенклатур. Получилось хорошо. Боялся, что пользователи (кладовщики) не осилят, но всё получилось и с первого же дня запуска кладовщики делали всё как надо.
Для неосновных номенклатур, в том числе для запасных частей, действуют следующие правила:
Номенклатурная группа: Деление по бухгалтерским счетам + деление по группам номенклатур. Например, ГСМ, Метизы, Запчасти, Одежда и т.п.
Код номенклатуры: Русскими буквами указывается суть детали/номенклатуры. Код должен быть понятным человеку. (Уникальный, Ограниченный набор символов, 20 символов). Например, Болт, Батарейка, Гайка, Подшипник, Вал, Гвозди_кг, Масло_л и т.п.
Конфигурация: Указывается код уникального товара. (Уникальный, Ограниченный набор символов, 10 символов). Например, WD40_400мл, D240х530, GP_AAA, Ш5х16нерж, М20нж, и т.п.
Наименование номенклатуры: Указывается наименование сущности. Для целей поиска, наименование сущности может содержать перечень синонимов, например, «Респиратор (Полумаска, фильтры к ним)»
Наименование Комбинации номенклатурных аналитик: Указывается наименование номенклатуры с учетом конфигурации для вывода в печатные документы.

Номенклатурный справочник получился компактным (3280 записей в InventTable, 7200 в ConfigTable, 8800 записей в InventDimCombination). Но столкнулся с проблемами: Практически все русские отчёты не слышали, что в номенклатурном справочнике имеются номенклатурные аналитики. Номенклатурный справочник готовится вручную для миграции. Номенклатуру с конфигурациями сложно учитывать, как материал в производстве, т.к. базовая себестоимость задаётся для номенклатуры в целом.