Уважаемые специалисты по автоматизации учета.

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

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

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

Я начал с попытки сделать идеальный каталог товаров, понял, что эту историю можно моделировать различными способами, и хотел бы остановиться на модели, максимально удобной пользователю, которая:

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

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

3) Сложности реализации модели меня не беспокоят - она может быть сколь угодно сложной, но обязана достигать целей (1) и (2).

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

Итак, модель к которой я пока склоняюсь:

* Категория (класс?, тип?, группа?) товара - задает возможные атрибуты (характеристики) товара (например "Обувь" - цвет, размер, пол, производитель; "Модуль памяти" - производитель, тип-памяти, форм-фактор, объем, частота). Каждая категория описывает товары с одинаковыми физическими свойствами.

* Категории не наследуются. В примере выше, теоретически "Обувь" и "Модуль памяти" могут наследоваться от некоторой базовой категории "Производитель товара" с характеристикой "производитель", но я пока не намерен это разрешать.

* Товар может принадлежать лишь одной категории (может "тип" или "класс" в данном случае более подходящий термин?)

Честно говоря, на этом бы я и остановился. Даже для номенклатуры в десятки тысяч позиций наличие мощного поиска должно решать все проблемы: например в моем почтовом ящике gmail более 100 тысяч писем, и я обычно не испытываю сложностей найти нужное мне письмо, в том числе полученное или отправленное много лет назад.

Открытый вопрос №1 работа с большой номенклатурой.

Решение 1.1: Иерархия категорий.

Разрешить пользователям выстраивать иерархию категорий, вида "Компьютеры и комлектующие > Комплектующиие > (Материнские платы, Модули памяти)". В данном случае "Материнские платы" и "Модули памяти" — это действительно категории, а "Компьютеры и комлектующие" и "Комплектующиие" — просто "папки" (путь к настоящей категории).

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

Решение 1.2: Сохраненные фильтры и иерархия фильтров.

Имея удобный и мощный поиск можно позволить пользователю сохранять критерии поиска в фильтр, наример "Категория:Обувь Производитель: Большевичка, Красный Октябрь" → "Обувь отечественная" и строить иерархию из фильтров, например "Все товары > Техника Apple > iPhone", где iPhone есть фильтр вида "Категория: Смартфон, производитель: Apple".

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

Пока я склоняюсь реализовать оба решения.

Открытый вопрос №2: Наследование категорий.

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

В общем тут можно зайти далеко, и начать строить онтологии описывющие то, что категория "Одежда Мужская" это то же самое, что и категория "Одежда" с аттрибутом "пол" == "мужской". В общем надо понять где остановиться, и нужно ли наследование вообще?

Открыты вопрос №3: Варианты / Модификации товара.

Вообще это частный случай категоризации (классификации) товаров, в котором некоторый товар (например iPhone 11) должен быть конкретизирован по набору аттрибутов (в данном случае "цвет" и "объем памяти". В таком случае товар становится некоторым подобием категории (iPhone 11) с частично заданными аттрибутами (характеристиками), а полные характеристики задаются в вариантах / модификациях iPhone 11, таких как "iPhone 11 64GB Green". Полноценное наследование категорий решало бы задачу модификаций товара автоматом "Смартфон > iPhone 11 > iPhone 64GB Green", где последний - товар, остальные - категории"

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

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

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

Спасибо,
Сергей

(0) Нет

для кого нужен этот каталог товаров?

(2) Имеется ввиду каталог товаров (номенклатура) как часть системы учета.

(0) https://xn--80ajghhoc2aj1c8b.xn--p1ai/

Каталог

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

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

Купи удочку, да сходи рыбу полови. Тягаться он там с кем-то собрался...

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

>>В общем я понял, что без помощи такого опытного комьюнити как на этом форуме не разобраться
Еще одна ошибка. Это очень токсичный форум. Устанешь плевки с лица вытирать. Если нет вопроса, на который можно получить четкий и однозначный вопрос. Очень токсичное сообщество(есть исключения конечно).

Сейчас ты пытаешься решить проблему, которой не видишь. Это изначально не имеет смысла. Если сложность не имеет значения, то делай, показывай. Здесь обосрут достаточно быстро. Удаляй делай заново. Где-то через год, увидим что-то вменяемое. Правда вполне может оказаться, что никому не нужное.

>>Я - программист в отставке, с 30 летним опытом в программировании

Чувак, ты вообще не программист.
Программист все время учится.

Ну если ты расскажешь как там DOS или перфокарты, будет интересно послушать динозавра.

(9) я программист со стажем 30+ лет (если начинать отчёт от програмки "решение уравнений" написанной где-то 7 или 8 классе на фортране для ЕС-1420 (бонусом получил копию программы на перфокартах)). Ничего в старом интересного нет, ну кроме того что тогда за вложенные циклы, рекурсию без надобности и т.п. не укоряли, как сейчас принято, а гнали ссаными тряпками!

тьфу! СМ-1420

ЕС тоже была но уже позднее и 1040

(0) бессмысленная и бесполезная затея, вендор уже вывел на рынок интегрированное решение и наполнил его данными:
https://portal.1c.ru/applications/63
1С:Номенклатура - единый каталог товаров в 1С:Предприятии
Работу с сервисом поддерживают актуальные версии следующих типовых конфигураций: 1С:Розница, 1С:УТ, 1С:УНФ, 1С:ERP, 1С:КА, 1С:Клиент ЭДО, 1С:Касса, 1С:БЭД.

Форум, действительно, встречает такие идеи жестко и негативно, но если вы серьезно взялись за эту задачу то токсичность форума это ерунда. Как пример проект oscript.io. Сейчас это практически стандарт а четыре года назад не понимание и критика.

(14)[Сейчас это практически стандарт]
пока это забава для 1% 1С-ников

(14) oscript это стандарт для 1с? Можно ссылки на ИТС? Или хотя бы номер ГОСТа (на худой конец, ОСТа)

Если это opernsoutse проект то нужна ссылка на GitHub. Заинтересованные товарищи подтянутся.

Несколько комментариев по вашим вопросам.

Создать идеальный каталог товаров очень сложная задача. Например, в развитии торгового решения (Управление торговлей) от компании 1С от версии 9.х до версии 11.х идеология каталога менялась несколько раз. И это в команде которая уже более 20 лет каждый день пишет и развивает свое торговое решение.

При проектировании архитектуры каталога имеет смысл отталкиваться от потребителей этого объекта. Как пример такого потребителя - каталоги интернет магазинов. Анализ структуры каталога товаров популярных CMS интернет магазинов и популярных торговых площадок (Aliexpess, EBay) на мой взгляд это хорошая идея.

(16) Денис, вам слово стандарт не понравилось или вы не согласны, что за последние пару лет oscript вытеснил python и power shell скрипты из администрирования и devops в 1С?

(18) Да, я не согласен. Я не видел ни одного его использования вживую. Значит, не вытеснил.

(16) Самое забавное, что вот эти же же люди лет 7 назад с пеной у рта клеймили 1С тем, что она создает свою экосистему и не использует новомодные тенденции развития айти итыдыитыпы.

(18) Я напомню, что одним из пойнтов продвижения oscript является то, что 1Сникам, дескать, привычно писать все на одном языке, в одной концепции. Что элегантно маскирует, то что питон тупо в массе не осилили.

И всего навсего это тот самый 1% сников, да.

(18) Первый раз слышу об oscript. Да и ни разу не видел чтобы кто то применял, иначе куча вопросов бы было тут на форуме.

(0) моему складу сделать продаваемый программный продукт помогла не молодость а грант в 200 тыс долларов (из Эстонии, если мне память не изменяет), а до этого было убожество страшное, на котором чтобы чтото сделать надо было извратиться неуемным способом. когда они появились и уже не детсад были уж совсем, я пытался на них сделать, ужос был в районе 2006г.

"например в моем почтовом ящике gmail более 100 тысяч писем,"
какая хрень мелкая, у меня в почтовике на компе - уже давным давно за лям перевалило ;-)

(17) Спасибо за совет, смотрю в сторону организации каталогов у площадок и CMS.

(23) Маня, реклама на форуме платная. Ты не забыл?

(17) сомневаюсь, что больше 5 лет в той команде работает хотя-бы 10% разрабочиков.

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

Примеры, для конкретики.
Виды номенклатуры:
-- Товар, ведется учет по серийным номерам
-- Товар, учитывается срок годности
Сегменты номенклатуры:
-- Группы по производителю
-- Группы по виду / подвиду товара
-- Группы по Яндекс.Маркет

(0) Что-то мне подсказывает, что все сведется либо к (4), либо к классификации принятой в СССР.