Requirements Type Determination and Requirements Class

How an order for a particular material is processed by the system, depends on the requirements type and the requirements class. This is illustrated in the graphic below.

There are two objects in the system that influence how a sales document is processed: the material master and the sales document itself. On the SD side the item category group and the sales document type determine the default item category.

The combination of the item category and the MRP type from the material master determines the origin of the requirements type, that is whether the strategy in the material master or the SD item category determine the requirements type. It does so by listing possible combinations in a Customizing table. If an entry does not exist in this table for the current combination, the strategy determines the requirements type.

The requirements type in turn determines the requirements class. The requirements class determines how the sales document is processed.

There are three fields that are important for assembly processing in the requirements class: the assembly type, theaccount assignment category and theorder type.

The assembly type determines which type of orders the system can create during assembly processing. For use with networks this field should always have the valueProduction order, network or service (static) (2) .

The order type is in this case the same as the network type. It determines whether the network is header-assigned or activity-assigned, whether internal and external numbers are used, and other parameters of the network. Whether you use header- or activity-assigned networks depends on the amount of detail you require. In general we recommend that you use internal numbers. For more information, see Network Type and Network Parameters or Settings in the Standard System .

The account assignment category determines how the system treats stock quantities and values. This field is described in more detail in Account Assignment .

Requirements Transfer

Depending upon whether the sales document is an inquiry, a quotation or a sales order, you may or may not want to transfer requirements for the sales document and the follow-on orders, such as production orders and purchase requisitions . For a quotation you may want information about material availability, but you do not want to transfer requirements.

In order to use availability checking, the requirements transfer indicator in the requirements class has to be set (in Customizing for the Project System choose  Material Control of Sales-Order-Related Production ).

Networks are not linked with a material of their own accord. (In the case of assembly processing, you maintain this link manually.) The material that you enter in the sales document is often a sales material, which means that there is no actual product with this material number. Networks themselves cannot cover requirements in materials requirements planning (MRP) and are therefore not taken into account in MRP runs. If the sales document item were to generate requirements, these requirements could not be covered. Therefore you should prevent requirements from being generated for the sales document item in MRP. To do so, you must set the No MRP indicator in the requirements class, or the MRP type indicator in the material master to No planning ( ND) (see Settings in the Material Master ).

You can generate requirements for components in the network. For more information, refer to Activating Reservations and Purchase Requisitions .