sy-uname написал(а):
Вы сами отметили что "в новых конфигурациях для 8.х они сильно поработали чтобы можно было подстраивать 1С без программирования ". Движение явно в направлении SPRO.
Неверный вывод, 1С для каждой прикладной области делает свою конфугурацию - для производства УПП, для оптовых фирм Управление торговлей+Бухалтерия в разных базах, для Лизинга отдельное решение.
А раз конфигурация делается уже для конкретной прикладной области то 1Су не нужен развитый уровень (аналог SPRO) для подстройки без программирования.
N/A написал(а):
Я Вас наверно удивлю, но в SAP это тоже объекты. Даже больше - БИЗНЕС-ОБЪЕКТЫ (см. тр. SWO1)...
Ну а вся "сложность" customizing-а ERP, которую Вы ставите в упрек SAP - плата за универсальность и долголетие.
Только как долголетние модули глянешь, до объекто или хотя BAPI далеко. Да и потом даже BAPI сами разработчики SAP не используют как систему создания решений, они типа дают нам инструмент, но поскольку сами этот BAPI не используют повседневно он у них не очень то развивается. Поэтому когда у Абапера есть выбор BAPI или FM он выбирает FM так там подчас больше возможностей.
У 1С другая ситуация объеткты 1С это инструмент на котором разрабатывают типовые конфы в самой фирме 1С, поэтому там они вылизаны, оптимизированы и т.д.
To trop зачем то убрал ключевую фразу "Это ОБЪЕКТЫ" и естественно смысл получился немного другой.
Левон написал:
Если запустить какую-то транзакцию, и посмотреть анализ производительности, то считывание настроечных таблиц - это капля в море....зато это то, почему 1С еще долго долго будет развиваться в сторону сапа...
Ну понятно что там не только начитка но и всяки соединения проверка условий. Возмите модуль CFM скорость загрузки сделок просто убивает, а анализ показывает что именно код АБАП жрет кучу процессорного времени а не субд. С другими модулями аналогично, запускаешь что нибудь стандартное в FI-FM и тебе звонит базис перегрузили процессор, памяти уже не хватает. При этом когда явно указываешь на места которые жрут производительность Service Sap com отвечает - не можем ничего сделать, такой сложный модуль.
Пономарев Артем написал:
Selis, ну когда жы вы уже сделаете очевидный шаг и замените в этой сентенции MS SQL\Oracle на 1С\SAP соответственно?
Почему "Уровень Customizing'а" Oracle вы считаете премуществом по отношению к MS SQL и, в тот же момент, считаете его недостатком в другом сравнении?
SAP позволяет организовать одновременную работу множества юр. лиц со своей собственной спецификой и законодательной базой (и множеством активных пользователей, работающих в этих лицах) в рамках одной ситстемы. 1С - нет. Точка.
Фразу где фигурировали Oracle\MS SQL наверное надо подкорректировать а то непонятно выражена мысль
1С УПП не подходит ? Там бухгалтерия зарплата бюджетирование производство и все одной. А если в холдинг входит Лизинговая компания, производственная, ИТ компания да SAP скажет мол мы все сможем запихнуть в одну базу, только забывают объяснить что для склеивания модулей нужно очень хорошо поработать с Customizing где шаг вправо влево и хочется схватится за ABAP.
И в заключение.
Вообщето я первоначально поместил топик в тему Перспективы SAP в кризис, однако модераторы решили перенести это в отдельный. Мысль была проста 1С по технической модели сильно догоняет SAP, сочетание этого с ценовой политикой, маркетингом делает 1С не просто конкурентом, а нечто большим, а SAP в это время поет старые песни о главном.
Последние topic вызывают ощущение что коллеги в форуме начинают убеждать себя, что у SAP с технической точки зрения все впорядки, груз прошлого который тащит на себе SAP делает его только сильней.
Предложеные мною формулировки вопроса, как понимаю никого не интересуют,а пока нет согласия о формулировке вопроса наверное смысла дальше обсуждать нет. Предлагаю сделать timeout у нас еще спокойный август отпуска, будет время поглядеть по сторонам, может потом эта тема станет заново интересней
Вход
Регистрация
FAQ пользователя
Поиск
