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

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

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

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

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

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

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

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

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

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

Если есть возможность, поясните пожалуйста, что такео Авизо об отправке (это входящая поставка?), Зависимые резервирования (это резервирования созданные из заказов РР и РМ ??), Потребности отзыва.
 
Хотелось бы так же чтобы вы рассмотрели взаимодействие связанных потребностей. Например Сбытового заказа и Исходящей поставке. Заказа на поставку и входящей поставки.

В этои посте к сожалению, много опечаток и ошибок :(
 
По поводу объема проверки хотел уточнить. Раньше вы писали что для сбытовых заказов и исходящих поставок жестко устанавливаются правила проверки (А и В соответственно). Значит ли это, что в таких документах объем проверки зависит только от материала (группы проверки) и нет возможности настроить разную логику проверки для разных видов заказов?

Начнем читать с анонса :)

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

Во всей русскоязычной документации давно принято Universe BusinessObjects именовать Юниверс, и не универс.

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

Адиль, можно попросить Вас обновить скриншоты?

Да уж, было дело, вот например есть индусцы, которые предлагают услуги по тестирования, само собой за деньги, само собой все равно на выходе будет фигня, зато денег стоит не мало (от 100 000 не нашими деньгами), а руководство верит, что качество будет супер. Я даже было как-то подумал, что если бы эти деньги дали непосредственно ключевым пользователям, которые должны по логике проводить эти тесты, то стресса и "ломания" в большинстве случае можно было бы избежать, потому что люди знали бы за что собственно они так напрягаются.

Хорошая статья. Рассмотрены сценарии разной степени сложности.
Функция номера детали производителя полезна и удобна не только для учета; при внедрении планирования потребности в материалах удобно когда для запаса с одинаковыми свойствами используется один инвентаризационный номер.

Существует интересный вариант классификации производств по ассортименту готовой продукции, которая изготавливается в одной технологической цепочке, т.н. VAT-классификация. Это не аббревиатура, а схематическое обозначение разузлования в технологическом цикле. Так например, примером T-производства является металлургия, V - переработка нефти, А - сборка автомобиля.