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

[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

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

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

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