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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Классификация типов производства в статье не позволяет разделять различные производства.
К примеру, по данной классифкации металлургическое производство можно отнести как к дискретному, так и к серийному, так и к позаказному типу производства:
-есть передельный учет
-есть позаказное планирование производства
-выполнение больших заказов обладает всеми характеристиками серийного производства (о чем в принципе и сказано в п.2.1.3 статьи)
 
Может имеет смысл разделить тип производства на 2 составляющие:
-собственно тип производства (дискретное, непрерывное).
-тип планирования производства (серийное, позаказное)
 
Это позволит более четко разделить особенности учета в производстве.

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

Выход был найден за счет очень оригинального (хотя и невероятно «древнего») решения, которое в процессорах Power применила компания IBM. Это создание специального механизма, который осуществляет разделение ресурсов не пространственно, а во времени. Попросту говоря, каждая задача выполняется в течение ряда процессорных тактов, и при этом другие приложения НЕ выполняются. Как в старые времена при работе на больших ЕС ЭВМ или мейнфреймах, люди клали перфокарты, и каждая колода перфокарт обрабатывалась отдельно. Одна задача не влияла на другие. Сейчас этот механизм на новом уровне технологий внедрен в процессора Power и уже несколько лет активно используется на практике. Это позволило процессорам Power получить сертификат, подтверждающий независимость работы приложений в разделах, а сами разделы трактовать как аппаратные (!), хотя «жесткого» разделения ресурсов в них нет. Это принципиально важный момент, который позволил совмещать работу различных приложений в одном сервере и существенно экономить ресурсы.

При этом необходимо отметить, что IBM и SAP вели многолетнюю совместную работу по совместимости механизмов виртуализации, и технологии SAP Adaptive Computing могут прекрасно дополнять возможности процессоров Power. Оба механизма дают нужную гибкость системе. При этом мы абсолютно согласны с автором: сотрудничество и получение полной и подробной информации при выборе типа виртуализации и понимание ее возможностей являются крайне необходимыми при построении оптимального SAP-ландшафта.

А под словами о необходимости серьезного подхода и обучения команды у самого заказчика я бы просто подписался. Здесь как нельзя более подходит прямолинейное и грубоватое, но точное определение преподавателя нашей военной кафедры (МВТУ, 1980-е): «Техника в руках дикаря – кусок железа». Какими бы причинами не был вызван отказ от вдумчивого подхода к проекту и обучению своих специалистов, на бизнесе это скажется крайне негативно.