Не всегда.
Сап СНГ любит влезать в пользовательские диапазоны в ADDONе.
А не за горами включение ADDONа в стандарт поставки.

О как, незнал про это диапазон, думал что с 900 пользовательские.
При создании своей формулы на основе саповской рекомендуют копировать текст саповской а почему например не поступать так PERFORM DATEN_KOPIEREN_XXX(include). ?

Спросить не у кого вот

To Mike1:
Так в SAP CIS сидят такие же люди, а программеры там бывают и менее опытные, чем на проектах

To WarWar:
Откуда такая рекомендация - для меня загадка. Видимо, закладываются на изменение своих процедур, чтобы не поломались ваши.
А писать имя главной программы (include) необязательно - все эти include содержатся в одном пуле (по темам).

Конечно, разработки ведутся. У нас, например.
На редко встречающихся (в наших широтах) модулях приходится очень много программировать. И SAPовских багов там много, и локализацию проводить надо, и функционала не хватает... На давно и повсеместно используемых модулях разработок на порядок меньше. Но это все субъективно, обобщать я не могу.

Как показывает практика, большинство разработок функционала случается не из-за отсутствия чего-то в стандарте, а из-за незнания консультантами возможностей этого самого стандарта. Причем часто встречаются консультанты-самоучки со стажем 5 лет и поболе, которые за свою практику на два-три обзорных тренинга сходили. А почему так мало - потому что работодатели на обучении экономят. И получают полгода разработок там, где стандарт все двумя галками делает.
И еще вариант. Есть руководитель проекта, условно говоря, контроллингист. И получает он задачу в числе прочих реализовать процесс такой-то. Стандартом он реализуется, например, на ТОРО. Но пиэм хочет все контролировать сам вплоть до каждой галки, боится отдать на откуп реализацию такого процесса специалисту по другому модулю, и процессы начинают впихиваться в какую-нибудь ко-пу. Естественно, чего-то начинает в таком "стандарте" не хватать, пиэм тянется к "штурвалу", выбивает себе штат абаперов и кое-как реализует процесс. При этом у пиэма увеличивается штат, что раздувает бюджет проекта, но при этом повышает статус пиэма. У него же больше подчиненных стало, он освоил больший бюджет, стал весь из себя солиднее! Посмотрите вокруг, встречались с таким явлением?

[quote="Sedlo"][/quote]

Всё так и есть.
только на счёт обучения... всё настолько плохо?

Ай пряма в яблочко

2Sedlo
Хорошо сказано...риспект.

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

15 курсов это мало?

Сложно с этим не согласиться. Опять же, бывают и исключения.

Нет, все не так плохо. Если целенаправленно искать много работы себе на шею, то она (работа) обязательно найдется

из старого фильма какого-то:
- если нам понадобиться ваша помощь - как нам вас найти?
- если мне понадобяться деньги - я сам вас найду.

Господа, SAP-маньяки.

Есть много мнений и подходов. Но, мне кажется, здесь идёт спор людей, которые 3-4 года просидели на 1 -2 модулях, или вообще занимаются только частью FI (MM,SD...) и другими людьми, которые работают на больших проектах с ограничнными ресурсами, одновременно пишут под 5-6 модулей и где цель не сделать красиво, а сделать, чтоб работало.

Можно долго гнуть пальцы, кто круче, но, сдаётся мне, чем экстримнее проект - тем лучше спецы. Одни копают глубоко и красиво и время у них на это есть.

Другие везде хватают по верхам, пишут кривой код, но могут вздрючить любой модуль.

именно вздрючить - с которым потом никто работать не может, который не подлежит поддержке САПом - и который потом не вписывается в общую схему. Круче тот у кого стандарт - а тот, кто смог убедить и сделать так, что после внедрения не возникает проблем ни с пачированием - ни с апгрейдом - ни с поддержкой САПом - это СПЕЦ (все буковки заглавные)

А почему молчит г.Амосов со своими стандартами ?)))

Уважаемая Светлана.

Вы какая-то идеалистка.
0. Путь к идеальному совершенству бесконечен.
1. Речь шла о проете с ограниченными ресурсами.
2. Речь идёт о большом проекте, со множеством модулей, которые на территории СНГ ещё не внедрялись.
3. Среди этих модулей есть модули, которые до этого не внедрялись НИГДЕ!
4. Когда прямо в тексте программ Большим Сапом делаются грубые ошибки, которые надо исправлять или через ноты, или самим.
5. Когда имеются концептуальные ошибки.

Ещё раз повторю - полировать 1 свой модуль можно бесконечно долго и сделать из него конфетку. А, если есть задача, надо, чтобы чтобы работала, знаешь, что тебе же это и сопровождать и ресурсы ограничены - тогда и приходится изголяться.

Опять же немалую роль играет позиция руководства проекта. Многие идеалисты очень быстро становятся прагматиками, хотя на начальном этапе те же представители САПа рассказывают, что нельзя даже прямо в таблички самому писать. А потом всё приходит на круги своя.

Тему можно раздувать до бесконечности и спорить до хрипоты. Если у Вас все по стандарту (а-ля конечный автомат), то искренне рад за Ваш проект. К сожалению, в жизни не всегда (и не у всех) так радужно и бодро.

p.s. У SAP'а очень много всяких модулей-решений и кому-то, иногда, их приходится внедрять первый раз... Пробовали?

p.p.s. Если не применять модификацию стандартного кода, проблем с накатыванием патчей значительно меньше. Полагаю, Вам это прекрасно известно.