Существуют ли недостатки у Axapta

[Maxim Gorbunov]

Цитата:

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

Т.е. у пользователя в сводном планировании есть выбор Заказы - Да/нет, Производство - Да/нет, а планирование по Проектам выбирается всегда?

Прочитал Ваше сообщение, посмотрел Аксапту, подумал... А как выбрать "Производство - Да/Нет"? Прилагаю скриншот, на котором видно, что можно включать/исключать при сводном планировании. Производства в качестве базы там, разумеется, нет. Планирование идет по складским проводкам и в случае производства, и в случае проектов. Для сводного планирования эти проводки равноправны совершенно.

Вы, наверное, выскажете сейчас "фи" на тему, что XAL умеет планировать их раздельно. Заранее задам встречный вопрос: а XAL умеет планировать их все вместе?

[Pavel]

Цитата:

Сообщение от Maxim Gorbunov

Вы, наверное, выскажете сейчас "фи" на тему, что XAL умеет планировать их раздельно. Заранее задам встречный вопрос: а XAL умеет планировать их все вместе?

Конечно, в XALе пользователь имеет возможность получить как валовую потребность, так и детализацию в виде чистых потребностей под каждый модуль/источник (заказы клиентов, потребность в проектах, расход в производство, складской прогноз, уровень запаса на складе).

[EVGL]

Цитата:

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

Конечно, в XALе пользователь имеет возможность получить как валовую потребность, так и детализацию в виде чистых потребностей под каждый модуль/источник (заказы клиентов, потребность в проектах, расход в производство, складской прогноз, уровень запаса на складе).

Как в анекдоте: "В комнате спорили люди. В споре родилась истина. Постояла и ушла, а люди все спорили."

Нетрудно видеть, что таблицу ReqTrans, являющуюся базисом для сводного планирования в Аксапте, можно отфильтровать по полю ReqTrans.RefType. Это будет детализацией потребностей по модулю/источнику во всей красе.
Потребности материалов в проектах действительно в любом случае порождают складские проводки и благополучно втекают в сводное планирование. Их отфильтровать несколько сложнее. Если попытаться обойтись стандартными средствами, то можно давать "проектным" заказам специальный префикс/суффикс и фильтровать потом ReqTrans.RefId. Что касается сомнительной задачи, как отключить сводное планирование отдельно взятого производства ли, заказов ли и т.п., то это решается на уровне отдельных номенклатур или групп номенклатуры. Раздельное же покрытие можно получить с моделью покрытия "1:1" или как оно там по-русски называется.

На практике же наличие всей этой гибкой фильтрации имеет чисто умозрительную ценность. Какова вероятность того, что одну и ту же номенклатуру собираем в рамках проекта, но еще и параллельно производим на склад? Алгоритмы сводного планирования в Аксапте покрывают 99% задач. Сложности возникают тогда, когда нужно искусственно расщепить покрытие потребностей в одном и том же продукте на две, скажем, части в зависимости от какого-либо свойства (тип заказа/клиента, например), но складскую аналитику для этого брать не хочется. Сложности возникают, когда надо планировать время доставки да еще в зависимости от местонахождения клиента, хотя и это можно решить ценовыми соглашениями.

Резюме: не о том спорим.

Цитата:

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

тот же модуль проекты дорабатывать не будут

Ну откуда такие сведения? Для "красного словца"? Как раз его-то и дорабатывают в поте лица. В 3.0 дорабатывали и в 4.0 по всем утверждениям развивают. Судя по всему, провалили только интеграцию с MS Project, но не очень-то и надо было
(это к вопросу о "силе в единстве" с MS Office http://www.axforum.info/forums/showt...0616#post90616 )

[TasmanianDevil]

Уважаемый vleg, позволю себе сильно усомниться в том, что сквозной пример из 67 отдельных заданий полностью отражает ВСЮ практику российского бухучета...

Цитата:

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

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

Хотите, поговорим про модуль Основных средств в разрезе Вашего утверждения, обсудим реализацию функционала согласно правил ведения учета ОС, сравним примененные идеологии проведения операций в этом модуле и других ?

[Maxim Gorbunov]

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

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

[EVGL]

Non-disclosure agreement. Пусть Microsoft сам презентует.

[EVGL]

Вообще-то этот вопрос к теме отношения не имеет и я не знаю, кто такой "бизнес-архитектор". Скажу так: моя роль на 90% - разработчик, на 10% - "бизнес-консультант".

[Pavel]

Цитата:

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

Вообще-то этот вопрос к теме отношения не имеет...

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

Цитата:

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

...и я не знаю, кто такой "бизнес-архитектор". Скажу так: моя роль на 90% - разработчик, на 10% - "бизнес-консультант".

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

Так вот мне не понятно, как EVGL (разработчик) утверждает о нецелесообразности в прикладной области. Т.е. понятно как рассуждает ("На практике же наличие всей этой гибкой фильтрации имеет чисто умозрительную ценность"), но отсутствуют аргументы, подтверждающие, что это не пустая иллюзия.

[mazzy]

Разрешите вмешаться.

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

Обсуждение личности - пожалуйста в личку.

Pavel, это соображение не обсуждается.
При несоблюдении будет включена цензура.

[Pavel]

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

[EVGL]

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

[Pavel]

Цитата:

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

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

Интересно, это какие-такие вопросы?

[Maxim Gorbunov]

Павел, докажите обратное. Кто ж Вам мешает? Привидите прикладной пример, в котором необходимо наличие фильтрации потребностей по проектам.

[Pavel]

Цитата:

Сообщение от Maxim Gorbunov

Павел, докажите обратное. Кто ж Вам мешает? Привидите прикладной пример, в котором необходимо наличие фильтрации потребностей по проектам.

Это же более чем очевидно. Так, разговора ради?

[Maxim Gorbunov]

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

Нет, правда, приведите. Именно профиль потребностей. Не потребление, не прогноз.

[Pavel]

Цитата:

Сообщение от Maxim Gorbunov

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

Нет, правда, приведите. Именно профиль потребностей. Не потребление, не прогноз.

Эти наезды мне непонятны. На бытовом уровне ситуация такова, что мне надо доказать - "шуруповерт с набором начинок, лучше чем обычная отвертка" + деталь - "докажи, что именно вот эта начинка когда-нибудь пригодится".

Опыт общения доказывает бесполезность данного занятия. Уже приводил Глазову таблички с примером ошибок трансляции, Маззи - экраны с отсутствующими функциями в проектном модуле, ошибки локализации и прочее. Результат в народной поговорке: "Плюнь в глаза, а в ответ - божья роса".

[Maxim Gorbunov]

Ок. Я умываю руки. Будут еще вопросы, зовите

[mazzy]

Вернемся к теме?
Итак, Существуют ли недостатки у Axapta?

[komar]

Цитата:

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

Вернемся к теме?
Итак, Существуют ли недостатки у Axapta?

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

[Pavel]

Цитата:

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

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

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