![]() |
#21 |
Участник
|
Цитата:
Изначально опубликовано Maxim Gorbunov
Обсуждалось неоднократно. http://www.axforum.info/forums/showt...&threadid=2130 http://www.axforum.info/forums/showt...&threadid=1614 ![]() А мораль фреда одна - все остались при своих мнениях, а ответ на заданный мной вопрос наиболее просто (для пользователя) всё же решается имхо древовидным классификатором. У "классифицированной" нумерации куча проблем. Цитата:
От себя: никто не говорил, что принципиально иерархическая классификация в Axapta невозможна - вопрос в ресурсах.
![]() Цитата:
А кто сказал, что это не "плоские таблицы"? См. UtilElements и UtilIdElements.
![]() ![]() |
|
![]() |
#22 |
Участник
|
Цитата:
Изначально опубликовано xonix
2 Alks Цитата:
Задача сопряжения в данном случае не сложная. Не буду углубляться в детали, вкратце - в одну сторону идут справочники (и только они), в другую - факты (неизменные, т.е. не надо поддерживать UPDATE ).
![]() Цитата:
Весь вопрос в том, что в описанном случае такую работу (разработку) предстоит выполнять внешним программерам по 60-80 долл/час. С учётом проектирования, прототипирования, разработки, полного тестирования недёшево получится.
![]() Цитата:
2. Справочники.
Вы тогда определитесь.. Вот товарисч говорит, что ему "дерево" для аналитики надо. Вы разницу между задачей быстрого поиска в классификаторе, и аналитики поверх дерева чувствуете? ![]() Цитата:
Для поиска можно продумать классификацию товаров, где 2-х буквенные аббревиатуры определяют уровень дерева. Ой.. вам уже указали на ветки, где это обсуждалось.
2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей 3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.: 4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто) 5. Мне лично показалось что в той ветке в конечном итоге сторонники древовидных классификаторов привели достаточно веские аргументы Цитата:
Как руководство отчёты характеризует - то это им видней, конечно. Уверен, что и отчёты вашего руководства в другой компании тоже могут назвать "никакущими".
Цитата:
А как программиста я вас понимаю...
![]() |
|
![]() |
#23 |
Участник
|
2 Alks
Отвечу покороче. ![]() 1. Аналитика на кассовом терминале не нужна. Т.е. совсем. Идеологические различия - побоку, если есть возможность "закачивать" туда номентклатуру (название, Артикул, цена (цены) ) и "выкачивать" факты продаж (дата, количество, цена). В Аксапте потом мастырьте хоть 20 аналитик и анализируйте как душе угодно! ![]() 2. По поводу з/п и ВАС ![]() Потом, учтите, что вашей компании вы обходитесь (в среднем) в 2 - 3 раза дороже своей зарплаты. "НЕ ПОНРАВИТСЯ" - очень субъективный критерий. Неплохо бы иметь перечень предъявляемых требований (уверен, что он есть. Но тогда корректно писать: не подходит по предъявляемым требованиям). 3. Я не буду дальше огульно давать советы (да меня ещё и не просят ![]() |
|
![]() |
#24 |
Administrator
|
А в UtilIdElements ParentId для иерархии, вообще говоря, и не используется. ParentId ненулевой только для определенного набора объектов и он, вообще, не соответствует тому дереву, которое Вы видите в качестве AOT.
В принципе, это же и ответ на второй вопрос. Кто Вам мешает сделать интерфейс пользователя в виде дерева? Вы говорите, что пользователю будет не удобно использовать синтетический код номенклатуры. Ну так сделайте, чтобы было удобно. И совершенно не обязательно для этого выстраивать много уровней иерархии. Опять же, посмотрите на AOT. Представление в виде дерева - это только лишь представление. Физически иерархия в таблице не хранится. P.S.: При грамотном построении системы кодировки объектов можно и по частям поля искать.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
![]() |
#25 |
Участник
|
[QUOTE]Изначально опубликовано xonix
[B]2 Alks Отвечу покороче. ![]() Цитата:
1. Аналитика на кассовом терминале не нужна.
Цитата:
2. По поводу з/п и ВАС
![]() Правда вероятнее всего, когда время таки появится найдутся другие, более насущные проблемы чем переделка КС, который и так работает, так что для нас скорее всего вопрос этот уже решенный. Что касается изначальной постановки вопроса - а не сделать ли модуль КС на аксапте, то мне кажется деньги и время потраченные на это всё таки пропадут не зря. Жаль только что у самих дамгардовцев до этого еще руки не дошли. Цитата:
3. Я не буду дальше огульно давать советы (да меня ещё и не просят
![]() ![]() |
|
![]() |
#26 |
Участник
|
Цитата:
Изначально опубликовано Maxim Gorbunov
А в UtilIdElements ParentId для иерархии, вообще говоря, и не используется. ParentId ненулевой только для определенного набора объектов и он, вообще, не соответствует тому дереву, которое Вы видите в качестве AOT. Цитата:
В принципе, это же и ответ на второй вопрос. Кто Вам мешает сделать интерфейс пользователя в виде дерева?
Цитата:
Вы говорите, что пользователю будет не удобно использовать синтетический код номенклатуры. Ну так сделайте, чтобы было удобно.
Цитата:
И совершенно не обязательно для этого выстраивать много уровней иерархии.
Опять же, посмотрите на AOT. Цитата:
P.S.: При грамотном построении системы кодировки объектов можно и по частям поля искать.
1. У такого подхода возможны "ложные" срабатывания 2. Проблему отчётов он не решает, т.к. в X++ в селектах недопустимо в условиях указывать части полей 3. Такой подход не работает пока менеджеры еще не притерлись к классификации, т.к.: 4. В таком подходе невозможно найти что то, не зная правил и кодов классификации (в древовидном подходе - запросто) 5. Когда приходит клиент и вы у него спрашиваете "что вас интересует?", а он по еврейски в ответ задаёт вопрос "а что вы можете предложить?" только древовидный классификатор сможет быстро дать ему ответ на все вопросы. 6. Грамотной назвать систему в которой внутри столбца хранятся значения, которые по правилам нормализации надо выносить в отдельные стобцы нельзя. |
|
![]() |
#27 |
Administrator
|
Цитата:
Изначально опубликовано Alks
Или это и есть тот "определенный набор объектов" про который вы говорите? Цитата:
Изначально опубликовано Alks
Вы находите ситуацию когда перед вами выпадает список из 3500 классов, или 1500 таблиц удобной?.. Цитата:
Изначально опубликовано Alks
Я уже озвучил выше почему это не так, не поленюсь зацитировать, и еще добавлю к тому списку:
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|
![]() |
#28 |
Участник
|
Цитата:
Изначально опубликовано Maxim Gorbunov
За то, что я не впадаю в панику при виде этого богаства, мне платят деньги, и это я нахожу вполне приемлемым. Цитата:
А как на счет запросов с использованием шаблона?
+ к тому еще: перенос товаров из одной категории в другую НЕВОЗМОЖЕН (если по ним уже есть проводки); не дай бог манагер ошибётся одной буквой, занося товар - товар станет "призраком", а ведь осуществить программный контроль над тем правильно ли манагер категоризирует товар при вбивании артикула становиться не так уж и просто; P.S. Да мне кажется вы сами прекрасно видите что система с категоризированными артикулами не может заменить полноценное дерево, так же как и я прекрасно вижу, что полноценные деревья вводить в аксапту - занятие неблагодарное, вследствии полного отсутствия логичной, казалось бы, поддержки их её разработчиками (да и по понятным "техническим причинам" СУРБД). Тут спорить о чём либо особого смысла не имеет. |
|
![]() |
#29 |
NavAx
|
Цитата:
Изначально опубликовано Alks
+ к тому еще: перенос товаров из одной категории в другую НЕВОЗМОЖЕН (если по ним уже есть проводки); ![]() Цитата:
не дай бог манагер ошибётся одной буквой, занося товар - товар станет "призраком", а ведь осуществить программный контроль над тем правильно ли манагер категоризирует товар при вбивании артикула становиться не так уж и просто; P.S. Да мне кажется вы сами прекрасно видите что система с категоризированными артикулами не может заменить полноценное дерево, так же как и я прекрасно вижу, что полноценные деревья вводить в аксапту - занятие неблагодарное, вследствии полного отсутствия логичной, казалось бы, поддержки их её разработчиками (да и по понятным "техническим причинам" СУРБД). Тут спорить о чём либо особого смысла не имеет. ![]() P.S. не можете сами и (или) не хотите научиться - платите деньги и вам сделают это другие
__________________
И все они создания природы... |
|
![]() |
#30 |
Участник
|
Цитата:
Изначально опубликовано Lazy_Tiger
Эт почему невозможен? Что сменить код нельзя разве? Да ну? ![]() Цитата:
это все - нервы и привычка корнями своими уходящая в 1С опыт. Времени потраченном вами на споры в этом топике уже с избытком хватило бы для реализации того что вам хочется.
![]() 2. Подкреплять своё мнение аргументами будем? ![]() 3. Я так отдыхаю на работе ![]() Цитата:
P.S. не можете сами и (или) не хотите научиться - платите деньги и вам сделают это другие
|
|
![]() |
#31 |
NavAx
|
Цитата:
Изначально опубликовано Alks
Хотите сказать - тривиальная задача? Вы посмотрите на это с точки зрения масштабов среднего/крупного предприятия и поймёте что совсем не тривиальная, и далеко не только потому что во всех таблицах колонки имеющие тип ItemId надо будет апдейтить на новое значение. ![]() На среднем работаю сам, проблемы НЕ ВИЖУ. вообще. более того, механизм используется чуть ли не ежедневно. P.S. Просто я не понимаю о чем спор. сделать можно? можно. Сделано? сделано. интересно почему оно как не "в 1С"? ну дык и система не 1С: предприятие, она другая Чего из пустого в порожнее переливаем? ![]()
__________________
И все они создания природы... |
|
![]() |
#32 |
Участник
|
Ну не сказал бы что у нас крупное, скорее среднее. Просто справочник номенклатур будет иметь около 50000 позиций и в будущем будет расширятся и спор в общем то о том реально ли (удобно ли) заведовать таким хозяйством без древовидной классификации. Мне лично кажется что подход с использованием категоризированного артикула не решает и половины проблем, которые возникают при таком обилии номенклатур. Он в принципе решает то только проблему быстрого поиска и фильтрации при том что ты знаешь что ищешь и ориентируешся в принятых мнемониках. Остальные моменты я озучил тремя мессагами выше. Однако многие здесь присутствующие (не только в этом топике) упираются что это всё происки дьявола и на самом деле мудрые создатели аксапты намеренно не поддерживают древовидные справочники, т.к. они на самом деле никому кроме пользователей 1С не нужны, а если кто то и думает что нужны, то ошибается.
![]() ![]() |
|
![]() |
#33 |
NavAx
|
у нас тоже среднее, тоже десятки тысяч номенклатур в справочнике.
исповедуем смешанный подход, и ассортиментный классификатор есть и коды у товаров вида "01.23.0034" P.S. хотя, на самом деле, все это происки дьявола. ![]() И ассортиментный классификатор, по хорошему, для поиска не используется. а используется например для ценообразования, системы скидок и т.д. Но это совсем другая история...
__________________
И все они создания природы... |
|
![]() |
#34 |
Участник
|
О, да мы практически братья по разуму
![]() У нас код номенклатуры имеет вид XX-YY-ZZZZ, так что если у вас ассортиментный классификатор имеет 4 уровня, то значит мы идем по вашим стопам. ![]() Цитата:
ассортиментный классификатор, по хорошему, для поиска не используется
Цитата:
используется например для ценообразования, системы скидок и т.д.
|
|
![]() |
#35 |
NavAx
|
ну мы это в комплекте с аксапта ретейл получили
![]() причем там даже не один иерархический классификатор, а два. т.е. есть два взгляда на справочник номенклатуры. независимых. в рамках проекта ввели третий ![]() каждый отдел смотрит так, как ему удобно. P.S. но все равно, от диавола это все ![]()
__________________
И все они создания природы... |
|
![]() |
#36 |
Участник
|
Доброе утро!
Цитата:
Изначально опубликовано Lazy_Tiger
ну мы это в комплекте с аксапта ретейл получили ![]() причем там даже не один иерархический классификатор, а два. т.е. есть два взгляда на справочник номенклатуры. независимых. в рамках проекта ввели третий ![]() каждый отдел смотрит так, как ему удобно. P.S. но все равно, от диавола это все ![]() В моем проекте была создана дополнительно форма создания строк с деревом, похожая на ту которой пользовались в 1С. За последний месяц собралась статистика: использование стандартной формы создания строк заказа - 8504 раз использование формы создания строк заказа с деревом - 334 раз |
|
![]() |
#37 |
Участник
|
Цитата:
Изначально опубликовано wb
Доброе утро! Подозреваю, что так. В моем проекте была создана дополнительно форма создания строк с деревом, похожая на ту которой пользовались в 1С. За последний месяц собралась статистика: использование стандартной формы создания строк заказа - 8504 раз использование формы создания строк заказа с деревом - 334 раз ![]() Во первых - а кто именно на вашем предприятии заставил вас делать эту модификацию в создании строк заказа и пользуется ли он ей сейчас? Знают ли остальные пользователи о ней? Во вторых - какой у вас объем справочника номенклатуры? В третьих - чем отличаются те 334 заказа, от тех 8504? Создателем? Количеством номенклатур? Степенью разбросанности номенклатур по разным подгруппам? В четвертых - а не отсутствует ли в новой форме какая нибудь важная функциональность, которой все привыкли пользоваться в старой? Ну например колонка с остатком. Возможно ли в ней игнорируя дерево пользоваться ей точно так же как и старой? В пятых - а как вообще происходит процесс создания заказов? (если, например, ваши менеджеры имея на руках распечатку экселя со списком товаров нужных для дозаказа просто тупо вбивают этот перечень в аксапту, то ясен пень дерево им не нужно) Да и наконец - насколько инерционно мышление ваших пользователей? Не боятся ли они попросту пользоваться новыми кнопками, помня что аксапта не прощает ошибок? ![]() |
|
![]() |
#38 |
Участник
|
Когда-то я участвовал в разработки КИС, в которой для большинства ключевых справочников (номенклатура, клиенты, поставщики и т.п.) можно было задать ЛЮБОЕ количество параллельных другу другу классификаторов с любой структурой (правда, не более 20 уровней вложенности, но реально более 6-ти я никогда не видел). И это открывало большие возможности, даже там где сначала и не подозревали... в разных ситуациях менеджеры могли прользоваться тем каким надо в данной ситуации... и это не исключало использования поискапо коду или, скажем, артикулу товара. Но я бы сказал даже что функция поиска не всегда основная, возлагаемая на классификаторы, в 2/3 случаев - для аналитической отчетности.
|
|
![]() |
#39 |
Модератор
|
Должно быть четкое распределение для классификации. Иначе потом приходиться искать шариковые ручки в "Аксессуарах"... Острожнее надо быть... или дублировать механизмы.
С Уважением, Георгий. |
|
![]() |
#40 |
Участник
|
Да.
Но нельзя оправдывать отсутствие удобных механизмов тем, что ими могут неправильно воспользоваться. Иначе бы у нас до сих пор были только "палки-копалки" - остальное потенциально опасно для здоровья ![]() |
|