Можно ли верить разработчикам?

[Alks]

Цитата:

Изначально опубликовано Maxim Gorbunov
Обсуждалось неоднократно.
http://www.axforum.info/forums/showt...&threadid=2130
http://www.axforum.info/forums/showt...&threadid=1614

Хехе. Мы собственно по большому счёту совместили всё что описано в первом фреде - и древовидный классификатор и заложение первых двух группировок в артикуле товара, чтобы быстро отсеивать его на складе, где компьютера с аксаптой и классификатором под рукой нет.
А мораль фреда одна - все остались при своих мнениях, а ответ на заданный мной вопрос наиболее просто (для пользователя) всё же решается имхо древовидным классификатором. У "классифицированной" нумерации куча проблем.

Цитата:

От себя: никто не говорил, что принципиально иерархическая классификация в Axapta невозможна - вопрос в ресурсах.

Но ведь и я не говорил что кто то говорит что она невозможна, разве не так?

Цитата:

А кто сказал, что это не "плоские таблицы"? См. UtilElements и UtilIdElements.

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

[Alks]

Цитата:

Изначально опубликовано xonix
2 Alks

Цитата:

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

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

Цитата:

Весь вопрос в том, что в описанном случае такую работу (разработку) предстоит выполнять внешним программерам по 60-80 долл/час. С учётом проектирования, прототипирования, разработки, полного тестирования недёшево получится.

Когда я говорил что в случае если купленный кассовый сервер нам не понравится и тогда МЫ вероятнее всего сделаем его на аксапте, под словом МЫ я имел ввиду именно НАС, а не сторонних разработчиков. А зарплата у нас умеренная.

Цитата:

2. Справочники.
Вы тогда определитесь.. Вот товарисч говорит, что ему "дерево" для аналитики надо.
Вы разницу между задачей быстрого поиска в классификаторе, и аналитики поверх дерева чувствуете?

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

Цитата:

Для поиска можно продумать классификацию товаров, где 2-х буквенные аббревиатуры определяют уровень дерева. Ой.. вам уже указали на ветки, где это обсуждалось.

1. У такого подхода возможны "ложные" срабатывания, которые там же обсуждались
2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей
3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.:
4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто)
5. Мне лично показалось что в той ветке в конечном итоге сторонники древовидных классификаторов привели достаточно веские аргументы

Цитата:

Как руководство отчёты характеризует - то это им видней, конечно. Уверен, что и отчёты вашего руководства в другой компании тоже могут назвать "никакущими".

Да конечно. Тут наверное вся проблема в том что руководство наше (как и мы впрочем) "выросло" в 1С и решительно не понимает, почему то что так хорошо, просто, доступно, удобно и естественно работало там не может так же хорошо, просто, удобно и естественно работать здесь. =8() А это действительно большой вопрос.

Цитата:

А как программиста я вас понимаю...

Все люди - братья.

[xonix]

2 Alks

Отвечу покороче.
1. Аналитика на кассовом терминале не нужна. Т.е. совсем. Идеологические различия - побоку, если есть возможность "закачивать" туда номентклатуру (название, Артикул, цена (цены) ) и "выкачивать" факты продаж (дата, количество, цена).
В Аксапте потом мастырьте хоть 20 аналитик и анализируйте как душе угодно!
2. По поводу з/п и ВАС Сколько времени (вашего, постановщиков задач, пользователей, руководства) уйдёт на разработку функциональности для решения этой задачи ? Будте пессимистом при выполнении оценки. Прибавьте время на полное тестирование (в нём не только вы участвовать будете). Прибавьте стоимость проблем, если что-то не предусмотрели...
Потом, учтите, что вашей компании вы обходитесь (в среднем) в 2 - 3 раза дороже своей зарплаты.
"НЕ ПОНРАВИТСЯ" - очень субъективный критерий. Неплохо бы иметь перечень предъявляемых требований (уверен, что он есть. Но тогда корректно писать: не подходит по предъявляемым требованиям).
3. Я не буду дальше огульно давать советы (да меня ещё и не просят ), т.к. не знаю деталей. Вашему руководству виднее - это их деньги.

[Maxim Gorbunov]

А в UtilIdElements ParentId для иерархии, вообще говоря, и не используется. ParentId ненулевой только для определенного набора объектов и он, вообще, не соответствует тому дереву, которое Вы видите в качестве AOT.

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

P.S.: При грамотном построении системы кодировки объектов можно и по частям поля искать.

[Alks]

[QUOTE]Изначально опубликовано xonix
[B]2 Alks

Отвечу покороче.

Цитата:

1. Аналитика на кассовом терминале не нужна.

Хех... Аналитика то действительно КС побоку, но цена на брак должна отличаться от цены на нормальное изделие, а когда продаётся желтая дверная ручка, то должна продаться именно желтая, а не коричневая, не находите?

Цитата:

2. По поводу з/п и ВАС Сколько времени (вашего, постановщиков задач, пользователей, руководства) уйдёт на разработку функциональности для решения этой задачи ? Будте пессимистом при выполнении оценки.

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

Цитата:

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

Именно.

[Alks]

Цитата:

Изначально опубликовано Maxim Gorbunov
А в UtilIdElements ParentId для иерархии, вообще говоря, и не используется. ParentId ненулевой только для определенного набора объектов и он, вообще, не соответствует тому дереву, которое Вы видите в качестве AOT.

А как же древовидность проектов? Древовидность форм, кнопок, панелей в AOT? Древовидность датасоурсов в запросах? И т.д. и т.п. Или это и есть тот "определенный набор объектов" про который вы говорите?

Цитата:

В принципе, это же и ответ на второй вопрос. Кто Вам мешает сделать интерфейс пользователя в виде дерева?

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

Цитата:

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

По моему mazzy говорил где то мысль примерно следующего содержания: "не решайте за пользователя что ему будет удобно, а что - нет.".

Цитата:

И совершенно не обязательно для этого выстраивать много уровней иерархии.
Опять же, посмотрите на AOT.

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

Цитата:

P.S.: При грамотном построении системы кодировки объектов можно и по частям поля искать.

Я уже озвучил выше почему это не так, не поленюсь зацитировать, и еще добавлю к тому списку:

1. У такого подхода возможны "ложные" срабатывания
2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей
3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.:
4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто)
5. Когда приходит клиент и вы у него спрашиваете "что вас интересует?", а он по еврейски в ответ задаёт вопрос "а что вы можете предложить?" только древовидный классификатор сможет быстро дать ему ответ на все вопросы.
6. Грамотной назвать систему в которой внутри столбца хранятся значения, которые по правилам нормализации надо выносить в отдельные стобцы нельзя.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Alks
Или это и есть тот "определенный набор объектов" про который вы говорите?

Я имел ввиду только то, что в utilElements максимум есть главные элементы и подчиненные, а подчиненных элементов для подчиненных нет.

Цитата:

Изначально опубликовано Alks
Вы находите ситуацию когда перед вами выпадает список из 3500 классов, или 1500 таблиц удобной?..

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

Цитата:

Изначально опубликовано Alks
Я уже озвучил выше почему это не так, не поленюсь зацитировать, и еще добавлю к тому списку:

А как на счет запросов с использованием шаблона?

[Alks]

Цитата:

Изначально опубликовано Maxim Gorbunov
За то, что я не впадаю в панику при виде этого богаства, мне платят деньги, и это я нахожу вполне приемлемым.

Охотно верю, но передо мной стоит задача сделать систему удобной, а не доплачивать всем работающим со справочником номенклатуры "за вредность"...

Цитата:

А как на счет запросов с использованием шаблона?

Геморройно, чревато ошибками и не всегда может решить проблему запроса: допустим шаблон артикула при двухуровневой классификации выглядит как XXYYZZZ. Теперь стоит задача - вывести суммму стоимости товаров на складе из группы XX = "01", с ГРУППИРОВКОЙ по её подгруппам YY. В системе с древовидным классификатором (или хотя бы доп. колонками на каждую группу) такой запрос реально сделать, а зашивая информацию о классификации в артикул мы, насколько я понимаю, лишаемся возможности делать группировки.
+ к тому еще:
перенос товаров из одной категории в другую НЕВОЗМОЖЕН (если по ним уже есть проводки);
не дай бог манагер ошибётся одной буквой, занося товар - товар станет "призраком", а ведь осуществить программный контроль над тем правильно ли манагер категоризирует товар при вбивании артикула становиться не так уж и просто;

P.S.
Да мне кажется вы сами прекрасно видите что система с категоризированными артикулами не может заменить полноценное дерево, так же как и я прекрасно вижу, что полноценные деревья вводить в аксапту - занятие неблагодарное, вследствии полного отсутствия логичной, казалось бы, поддержки их её разработчиками (да и по понятным "техническим причинам" СУРБД). Тут спорить о чём либо особого смысла не имеет.

[Lazy_Tiger]

Цитата:

Изначально опубликовано Alks
+ к тому еще:
перенос товаров из одной категории в другую НЕВОЗМОЖЕН (если по ним уже есть проводки);

Эт почему невозможен? Что сменить код нельзя разве? Да ну?

Цитата:

не дай бог манагер ошибётся одной буквой, занося товар - товар станет "призраком", а ведь осуществить программный контроль над тем правильно ли манагер категоризирует товар при вбивании артикула становиться не так уж и просто;
P.S.
Да мне кажется вы сами прекрасно видите что система с категоризированными артикулами не может заменить полноценное дерево, так же как и я прекрасно вижу, что полноценные деревья вводить в аксапту - занятие неблагодарное, вследствии полного отсутствия логичной, казалось бы, поддержки их её разработчиками (да и по понятным "техническим причинам" СУРБД). Тут спорить о чём либо особого смысла не имеет.

это все - нервы и привычка корнями своими уходящая в 1С опыт. Времени потраченном вами на споры в этом топике уже с избытком хватило бы для реализации того что вам хочется.

P.S. не можете сами и (или) не хотите научиться - платите деньги и вам сделают это другие

[Alks]

Цитата:

Изначально опубликовано Lazy_Tiger
Эт почему невозможен? Что сменить код нельзя разве? Да ну?

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

Цитата:

это все - нервы и привычка корнями своими уходящая в 1С опыт. Времени потраченном вами на споры в этом топике уже с избытком хватило бы для реализации того что вам хочется.

1. Так уже месяца два назад как реализовано.
2. Подкреплять своё мнение аргументами будем?
3. Я так отдыхаю на работе

Цитата:

P.S. не можете сами и (или) не хотите научиться - платите деньги и вам сделают это другие

Просто не понял что вы этим хотите сказать...

[Lazy_Tiger]

Цитата:

Изначально опубликовано Alks


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

ммм... я на крупных не работал, но догадываюсь какие проблемы там есть, видел. издалека УЖАСНУЛСЯ. Как все просто у нас и как все муторно там, у "крупных"

На среднем работаю сам, проблемы НЕ ВИЖУ. вообще. более того, механизм используется чуть ли не ежедневно.

P.S. Просто я не понимаю о чем спор.
сделать можно? можно.
Сделано? сделано.
интересно почему оно как не "в 1С"? ну дык и система не 1С: предприятие, она другая

Чего из пустого в порожнее переливаем?

[Alks]

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

[Lazy_Tiger]

у нас тоже среднее, тоже десятки тысяч номенклатур в справочнике.
исповедуем смешанный подход, и ассортиментный классификатор есть и коды у товаров вида "01.23.0034"

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

[Alks]

О, да мы практически братья по разуму
У нас код номенклатуры имеет вид XX-YY-ZZZZ, так что если у вас ассортиментный классификатор имеет 4 уровня, то значит мы идем по вашим стопам.

Цитата:

ассортиментный классификатор, по хорошему, для поиска не используется

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

Цитата:

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

Вот именно (хмуро так). Еще одна причина по которой он нужен. И еще один головняк для меня при работе с кассовым сервером, который поддерживает 5-уровневый древовидный классификатор товаров и скидки по нему...

[Lazy_Tiger]

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

P.S. но все равно, от диавола это все

[wb]

Доброе утро!

Цитата:

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

P.S. но все равно, от диавола это все

Подозреваю, что так.
В моем проекте была создана дополнительно форма создания строк с деревом,
похожая на ту которой пользовались в 1С.
За последний месяц собралась статистика:
использование стандартной формы создания строк заказа - 8504 раз
использование формы создания строк заказа с деревом - 334 раз

[Alks]

Цитата:

Изначально опубликовано wb
Доброе утро!
Подозреваю, что так.
В моем проекте была создана дополнительно форма создания строк с деревом,
похожая на ту которой пользовались в 1С.
За последний месяц собралась статистика:
использование стандартной формы создания строк заказа - 8504 раз
использование формы создания строк заказа с деревом - 334 раз

Помните "Есть ложь, есть большая ложь, а есть еще статистика."?
Во первых - а кто именно на вашем предприятии заставил вас делать эту модификацию в создании строк заказа и пользуется ли он ей сейчас? Знают ли остальные пользователи о ней?
Во вторых - какой у вас объем справочника номенклатуры?
В третьих - чем отличаются те 334 заказа, от тех 8504? Создателем? Количеством номенклатур? Степенью разбросанности номенклатур по разным подгруппам?
В четвертых - а не отсутствует ли в новой форме какая нибудь важная функциональность, которой все привыкли пользоваться в старой? Ну например колонка с остатком. Возможно ли в ней игнорируя дерево пользоваться ей точно так же как и старой?
В пятых - а как вообще происходит процесс создания заказов? (если, например, ваши менеджеры имея на руках распечатку экселя со списком товаров нужных для дозаказа просто тупо вбивают этот перечень в аксапту, то ясен пень дерево им не нужно)
Да и наконец - насколько инерционно мышление ваших пользователей? Не боятся ли они попросту пользоваться новыми кнопками, помня что аксапта не прощает ошибок?

[Zabr]

Когда-то я участвовал в разработки КИС, в которой для большинства ключевых справочников (номенклатура, клиенты, поставщики и т.п.) можно было задать ЛЮБОЕ количество параллельных другу другу классификаторов с любой структурой (правда, не более 20 уровней вложенности, но реально более 6-ти я никогда не видел). И это открывало большие возможности, даже там где сначала и не подозревали... в разных ситуациях менеджеры могли прользоваться тем каким надо в данной ситуации... и это не исключало использования поискапо коду или, скажем, артикулу товара. Но я бы сказал даже что функция поиска не всегда основная, возлагаемая на классификаторы, в 2/3 случаев - для аналитической отчетности.

[George Nordic]

Должно быть четкое распределение для классификации. Иначе потом приходиться искать шариковые ручки в "Аксессуарах"... Острожнее надо быть... или дублировать механизмы.

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

[Zabr]

Да.
Но нельзя оправдывать отсутствие удобных механизмов тем, что ими могут неправильно воспользоваться. Иначе бы у нас до сих пор были только "палки-копалки" - остальное потенциально опасно для здоровья