Олег, спасибо за комментарий!
Возможно, для отражения подобных требований следует ввести еще один критерий - "мягкость" системы. Мягкость - как способность системы удовлетворять еще не сформировавшиеся потребности пользователей, т.е. система мягкая, если пользователь не знает что он хочет, и из какой области он может захотеть, а система уже может.
А для того, чтобы пресечь излишние запросы, в концепте, как известно, желательно прописывать не только то, что будет делать система, но и что она делать не будет.

Весь подход - это сплошная архитектурная ошибка, не понимание и не знание технологий SAP BW. Зато автор владеет JAVA технологиями - что и продемонстрировал. Напоминает древний анекдот про торжество советской медицины в деле удаление гланд.

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

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

Из практики на скольких проектах топ-менеджмент озвучивал следующую фразу, типа система не гибкая, причем в их понимании гибкость, это когда чуть ли не каждый месяц меняется оргструктура компании, а система должна за этим всем успевать и ответы, что ну нельзя менять коды БЕ/Заводов/Пароходов раз в месяц и т.д., их подчиненность между собой натыкаются на один ответ: "Ваша система не гибкая". Причем объяснение, что это даже не система, а принципы построения и функционирования реляционных баз данных, не проходит. В общем я так понимаю, многие продолжают путать гибкость с флюгером.

Полезная нота 1375425, а то с этими экселями вечные проблемы с отображением. А что по факту загрузки курса, ну оно к сожалению по данному методу все в диалоге грузит, а это значит есть человек, рабочий день у которого или начинается или заканчивается данным процессом, а курсы они могут и в 22:00 и позже, стать известными. В свое время мы просто через интернет из системы дергали курсы размещенные на официальном сайте национального банка Украины, часа в 2 ночи и автоматом заполняли таблицу курсов, затем ответственному сотруднику отправлялась сис, что все ОК или наоборот проблемы загрузки, так что ты мил человек типа выйди по раньше на работу, чтобы разрулить ситуацию. Времени оно конечно заняло написать эту программу больше, чем эту статью прочитать, но как по мне это более автоматизированно вышло.

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

В теории написано все правильно, на практике мы сталкиваемся с иной реальностью.
1. Отсутствие устоявшейся, регламентированной и измеримой модели процессов компании сводит на нет сравнение процессов as-is и to-be. Следует также понимать, что в условиях нашей экономики бизнес-процессы компании динамично изменяются (этим мы сильно отличается от Запада). За 1 год могут измениться не только бизнес-процессы, их владельцы, оргструктура (не говоря уже о KPI и системе отчетности), но и само направление развития бизнеса.
2. Если ранее в компании не была внедрена ERP система, то никто из владельце бизнес-процессов и представить себе не может на что он подписывается. Новые бизнес-процессы, как правило существуют в голове у консультантов уже проходивших не одно внедрение и знающих систему. Доказывать, что-либо бизнесу в этой ситуации не просто.
3. Сразу ограничиваем круг внедрений ERP - коммерческими проектами (Госсектор и Нефтянку вычеркиваем) - это так называемые ограничения проекта.
 
Можно было бы еще написать массу замечаний, но не вижу смысла. В целом, согласен с посылом авторов - сейчас на рынке ERP экономический эффект как правило не измеряется. Это факт.

Как-то пункт 2.3.1.:
 
======== цитата ========
В настоящее время ERP система настраивается на предоставление «отчетных» данных (составление многочисленных отчетов о затратах, о «локальной» эффективности деятельности подразделений). Эти данные не дают возможности принимать управленческие решения, направленные на достижение главной цели - увеличение прибыльности бизнеса.
 
Однако возможна такая настройка системы, которая позволит предоставить менедже-рам информацию, необходимую для принятия управленческих решений, обеспечивающих достижение главной цели Компании.
======== конец ========
 
И 2.3.3 по факту одно и тоже два раза два раза... выходит написано, с изменениями пары слов. Оно конечно повторение мать учения, но тут мне кажется это лишнее.
 
======== цитата ========
В настоящее время ERP система настраивается на предоставление «отчетных» данных (составление многочисленных отчетов о затратах, о «локальной» эффективности деятельности подразделений). Эти данные не дают возможности принимать управленческие решения, направленные на решение главной задачи.
 
Однако возможна такая настройка системы, которая позволит предоставить менеджерам информацию, необходимую для принятия управленческих решений, обеспечивающих достижение цели – увеличение эффективности бизнеса.
======== конец ========

Интересные замечания, но вопрос: Зачем Вы выбрали данную функциональность?
Вам необходима простота подтверждения? - Вы ее получили.
Вам тяжело вести технологические ил производственные заказы? - Вы существенно упростили процесс ведения документов (они практически удаляются без следа).
Что же вы хотели получить?
 
PS. орфографию лучше поправить, например слово аксельратор.

Ваши комментарии напомнили мне ситуацию, когда для того, чтобы забить гвоздь, использовали микроскопом. На вопрос, зачем вы это сделали был дан при этом простой ответ: "А что, он тоже тяжелый".
Это я к тому, что перед использование функциональности необходимо ее знать, знать как ее плюсы, так и минусы. Тогда и не будет разговоров о том, что "никогда в жизни не буду ее использовать".
Функциональность серийного производства простая и ее легко использовать. Кроме того, для построения отчетности (по простому) можно использовать ИСИ, что является нормальной практикой.

ИМХО: Лучше использовать элементы функциональности серийного производства, такие как Варианты изготовления, Таблица данных планирования, Коллектор затрат в сочетании с Технологическими заказами, чем просто использовать функциональность серийного производства.
 
PS. Очень жаль, что шаблоны иногда пишут безграмотные консультанты, а потом выдают это за "шедевры решений SAP". Не повезло с центральной командой :)

Абсолютно верно с точки зрения отчетности. Использование функциональности серийного производства целесообразно только в тех случаях, когда требования к отчетности не содержат явно выраженных требований к хранению плановых данных для последующего анализа планов и их выполнения (сравнение план/факт/отклонение) как по выработке, так и по потерям ингридиентов.
Это с точки зрения теории, де-факто же получается что это практически мало применимо для большинства российских предприятий, а также и производств иностранных компаний, базирующихся в России, т.к. исторически в России сравнение план-факт в различных разрезах - это базис аналитической отчетности производства.
В итоге получается, что использование данной функциональности при внедрении по умолчанию предполагает наличие разработок нестандартных отчетов (одна из причин - "бедность" функциональности серийного производства в плане отчетности). А также сразу же предполагает что получение отчетности в разрезе 1 производственного цикла практически невозможно (или требует неадекватных трудозатрат на ввод данной информации), т.к. объект вида "Производственный заказ" или "Технологический заказ" отсутствует.

Спасибо, поправил.

Немножко лишних ошибок.
И если "комонент" не так сильно режет глаз, то "мифическую простату" лучше исправить.......

Как-то вот читал, читал, и вроде тема интересная и комментариев что-то нет, а потом понял или точнее не понял, но предположу почему в ответ тишина, а потому что никто наверное так и не понял как же у вас получается совместить две эти задачи и главное их решить. Покажу на небольшом примере, итак задача исходя из предложенного:
 
1. Вы – руководитель ИТ-отдела на крупном предприятии и Ваше бизнес-руководство (инвесторы, владельцы, управляющие) посовещались и ставят вас перед известием: «будем внедрять SAP».
 
А вот теперь то что вы написали в пункте два, как это звучит со стороны, нужно решить следующая задачу: Будем покупать машину, нет не так... будем покупать МАШИНУ, с большой буквы! Дальше все тоже, вам как начальнику гаража надо:
 
Определить бюджет покупки МАШИНЫ, сроки на покупку, подготовить документы для покупки, выбрать что за машина будет, провести тендер, определить размеры гаража и вспомогательных помещений, определить требования к механикам и водителю машины, определить как будет использоваться машина, какая стоимость и периодичность ТО для этой машины и можно ли на этом деле с экономить?
 
А теперь заметьте я вам не говорю и не уточняю какую машину, для чего машину и т.д. но вы должны мне написать, опять же ваши слова: "какие из этих пунктов вызывали наибольшие трудности (для тех, кто уже полностью или частично, таки купил уже себе МАШИНУ)".
 
В общем если еще короче, то подите туда, не знаю куда, купите то не знаю что... и в цифрах...

Хорошо бы развить тему и сделать ролик в стиле Сержа Горелого.

Нужная статья, рекомендую обратить внимание на SAP ноту 152571.

Авизо об отправке - это входящая поставка
Накладные - исходящая поставка
Зависимые резервирования - это потребности РР/РМ заказов
Потребности отзыва - заказы/заявки на перемещение.

Да, это значит, что для сбытовых заказов и поставок объем проверки зависит только от материала (группы проверки).