Цитата:
Сообщение от
lagr221374
Где вы меня в гугл отсылали? Ну даже не в этом суть. По конкретным формулировкам Zabr-а вы не нашли по большей части такой функциональности в SAP. И к чему это приведет? К тому что возникнет необходимость создавать все это ручками. А это в SAP делается тяжело и трудоемко в сравнении с Ax.
А Вы найдите по формулировкам Zabrа функционал в AX, хотя бы по п. 2
1. В AX невозможно сделать каждый магазин складом и дать права на приемку товара пользователю из магазина? Надо писать? Мне казалось это организационный момент для любой системы, где можно делать несколько складов.
2. Надо писать такой функционал в DAX? imho придется, в SAP предусмотрен такой вариант с различными условиями для различных магазинов /сегментов закупок.
3. С юридической точки зрения спорно, но в случае необходимости в чем проблема поменять условия оплаты по действующим договорам?
4. Если Вам так сильно надо, могу уточнить, сходу ответа не знаю. Прикинете трудоемкость разработки решения для DAX?
5. Специально спросил про механизмы управления ценами/скидками для ритейла - получил лекцию на 20 минут про возможности SAP Price Optimization, SAP Markdown Optimization, SAP Promotion Managent. Пересказывать не возьмусь, но с заинтересованными в решении задачи лицами можно пообщаться.
Расскажете со свой стороны про AX? =)
Цитата:
Сообщение от
lagr221374
Видите как вас SAP развратил
: в отличие от SAP в Ax обычно требования формирует закачик в согласовании с консультантами. Принимать это может любую форму.
Это меня еще со школы так развратили - четко и понятно мысли формулировать
Опыт c DAX только добавил понимания, что четкость формулировок помогает в общении с заказчиком.
Но мы живем в свободной стране и если кто-то считает что работа консультанта это просто передать нечетко и непонятно сформулированную задачу в разработку, то видимо и такому мнению место есть.
Цитата:
Сообщение от
lagr221374
Ну во первых была пятница и было скучно еще ранее были сформулированы утверждения что SAP это наше все для ретейла. Это не совсем так, а если совсем честно совсем не так. Потому и для поддержания равновесия Ночной дозор я и упомянул Бананамаму + когда то упоминал данную сеть и очень переживал за нее.
Во вторых, как ни странно, но бизнес зависит от используемой ERP: часто автоматизация пронизывает все процессы предприятия и их изменение должно находить отражение в информационной системе предприятия.
Если это по каким-то причинам такое отражение невозможно, то контроль над измененным процессом теряется и ставит под вопрос ценность самого изменения.
Невозможность/сложность отражения/изменения каких именно бизнес-процессов в ERP привело к банкротству Банана-мама?
Цитата:
Сообщение от
lagr221374
SAP как отписал ранее менее гибок к "резким" изменениям: это логично так как он более проработан и это само по себе наверное хорошо для компаний с устоявшимися и незыблемыми процессами, но при "резком" изменении вызывает большее количество изменений (в силу проработанности деталей много и они должны быть все учтены), что в итоге приводит к повышенной трудоемкости подобного (и как понимаю идет в разрез с тезисом что все в идеале решается настройками) + на это накладывается сложность изменений, обусловленная достаточно хреновой системой разработки (ессно в сравнении с X++).
Такое мнение на чем основано? У Вас есть опыт настройки и DAX и SAP?
У Вас есть опыт разработки и DAX и в SAP? Вы писали ЧТЗ для DAX и SAP на примерно одинаковые модификации и можете оценить трудоемкость?
Я вот от квалифицированных разработчиков не слышал жалоб на сложность/неудобство SAP как среды разработки, очень даже наоборот.
Цитата:
Сообщение от
lagr221374
Сложно судить так как статистики не имею.
Неопределенные последствия имею ввиду - неопределяемые сразу баги, как логические так и программные и их влияние на жизнь и затраты на их уборку.
Хм. в чем такая принципиальное разница между системами на поиск и уборку багов?
Цитата:
Сообщение от
lagr221374
Вот видите.
Типичное решение для SAP: для соединения кассы и SAP купить модуль SAP POS Data Management с кучей не пока нужных функций.
Типичное решение для Ax: дать задание программисту и консультанту и получить желаемое за день - за два (это я грубо в реалии судя по приведенному в соответствующем разделе джобу пара часов).
Вот потому и идет речь о большей гибкости Ax, что в конкретной ситуации для нее является +. Понятно что и трудоемкость не сравнимая.
А место или нет кассы в интеграции с Ax вопрос спорный (почему нет, для каких то шаманств) и наверное по описанию темы был отдан на откуп заказчику - в него и тапки.
А вас не смущает необходимость покупать модули от MS/партнеров? =)
Странно Вы читаете. Я Вам написал что можно и напрямую если сильно хочется. Только вот для кого это нужно?
Для SAP есть выбор - купить узкоспециализированный функционал или писать, еще раз повторюсь для танкистов, кардинальной разницы в трудоемкости разработки нет. По многим задачам есть и решения партнеров, как и для DAX, где инвестиции в разработку уже сделаны. Только в силу традиции не спешить менять стандарт обычно их гораздо легче собрать между собой.
Для DAX же решений от вендора ОЧЕНЬ мало.
Вы сделаете интеграцию DAX с любой кассой за 2 часа? включая тестирование и отражение реализации в проектной документации? У вам МЕГА производительность труда.
P.S. SAP POS DM стоит смешных денег, гораздо дешевле обойдется чем доп. лицензия для магазина на DAX, не говоря уже о полных размерах ущерба проектного решения "дотянуть ERP до магазина" для бизнеса.