2 Enterprise Structure - Definition
2.1 Define Valuation Level
Menu
path
|
|
Transaction Code
|
OX14
|
Configuration Description
|
Here
we specify the level at which material stocks are valuated. We have used the
Plant level since the application component Production Planning (PP) and
Costing are being used.
|
2.2 Define Plant
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
As
a part of the Logistics Organizational Structure, Plants are defined in SAP.
The ‘Plant’ is an operating area or a branch or a location within a company.
Each 'Plant' is assigned to a single 'company code'. A 'company code' can
have several 'Plants'. In case of ITZ Pvt. Ltd.,
the various 'Plants' are assigned to a each 'company code'.
|
2.3 Maintain Storage Location
Menu path
|
|
Transaction Code
|
OX09
|
Configuration Description
|
A
storage location is the place where stock is physically kept within a plant.
There may be one or more storage locations within a plant.
A
storage location has the following attributes:
|
2.4 Maintain purchasing organization
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
At
this node we configure the Purchasing Organization .The purchasing
organization is the highest level of aggregation (after the organizational
unit "client") for purchasing statistics.
In
case of ITZ One single Purchase Organization is created as under :
|
3 Enterprise Structure Assignments
3.1 Assign Plant to Company Code
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
A Plant needs to be assigned to one of the Company Codes, the
relation is always one to one i.e. One Plant can be assigned to only one
company code
All the plants can’t be shown here(for
complete list refer MM KDS document)
|
3.2 Assign purchasing organization to company code
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this node we assign the Purchasing Organization to the
company code under which it works.
In case of ITZ the Purchasing Organization is Central, so it is
not assigned to any Company Code
|
3.3 Assign purchasing organization to Plant
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step we assign purchasing organizations to the plants for which they are
responsible.
In
case of ITZ since it operates with Centralized Purchasing Org. we have
assigned the Purchasing Org. to all the plants defined as of now
|
3.4 Assign standard purchasing organization to plant
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
If several
purchasing
organisations procure for a certain plant, we can define one of them as the
standard purchasing organization for the transactions "pipeline
procurement", "consigmnent" and "stock transfers".
In source
determination for stock
transfers and consignent, the system
automatically utilizes this standard purchasing organization. In the case of
goods issues of pipeline materials, the purchasing info records of the
standard purchasing organization are read.
In ITZ, we have not defined this Setting as we
are using single Purchasing Organisation
|
4 General Logistics
4.1 Assign Fields to Fields Selection Groups
Menu path
|
|
||||||||||||
Transaction Code
|
OMSR
|
||||||||||||
Configuration Description
|
Assignment of Material Master Fields is
required to define whether a field is hidden or displayed, or whether an
entry is mandatory or optional in material master maintenance, it is always
advisable to work with Standard SAP settings, but for few business
requirement some assignments are changed to new field selection groups defined
as per reserved name space. in case of ITZ, some of the list of changed
entries is as given below:
|
4.2 Maintain Field Selection for Data Screens
Menu path
|
|
Transaction Code
|
OMS9
|
Configuration Description
|
In this step we define the nature of a
Field belonging to a particular Field Selection Group wrt the Screen
Reference of a Material Type. Steps involved are :
|
4.3 Maintain Company Codes for Materials Management
Menu path
|
|
Transaction Code
|
OMSY
|
Configuration Description
|
This activity is done for making a
Company Code relevant for materials Management and to define the starting
posting period This is a prerequisite for creating a Material Master
|
4.4 Define Attributes of Material Types
Menu path
|
|
Transaction Code
|
OMS2
|
Configuration Description
|
Material
type is analogous to the family of a material master; all the important attributes
of a material are governed by settings in the material type. To be precise it
governs :
|
4.5 Define Number Ranges for each material types
Menu path
|
|
Transaction Code
|
MMNR
|
Configuration Description
|
In this step, we have
defined the type of number assignment and the number range intervals for
material master records. When creating a material master record, system must
assign it a unique number. There are two ways of doing this:
In
this case, a number within the number range interval allowed is assigned by
the SAP system.
Here, the user assigns a number
within the number range interval allowed. We can define the intervals for
external number assignment numerically and alphanumerically.
We have defined the number
range intervals for so-called groups. We assign one or more material types to
each group.
|
4.6 Define Attributes of system messages
Menu path
|
|
Transaction Code
|
OMT4
|
Configuration Description
|
When
processing material master records, the system issues a number of system
messages containing important user information. In this activity, we define
how the SAP system handles these messages. We have the following options:
For ITZ requirement Message Numbers MM189 & 312 are changed
as Error message
We are using Standard SAP Messages.
|
4.7 Define Material Groups
Menu path
|
|
Transaction Code
|
OMSF
|
Configuration Description
|
Here we define the Groups for Materials &
Services, This Grouping shall be defined keeping in mind the reporting
requirement of the company for analysing Purchases, Consumptions, Stocks etc,
Setting is just a table entry, few
records are shown in the screen shot, for complete list refer to the MM KDS
document or the actual system node
|
4.8 Define External Material Groups
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Here we define the Groups for giving an
extra key for filtering, sorting the list of materials from a criterion other
than Material grouping
In case of ITZ we have not used External
Material Groups
|
4.9 Initialize Period
Menu path
|
|
Transaction Code
|
MMPI
|
Configuration Description
|
This
Transaction can be used to initialize the period in materials management ,
i.e. it opens the already closed period (thru Txn : MMPV), but opening a
period has serious implications on data consistency in SAP so as recommended
by SAP Follow the instructions in Note 487381 before initialization
|
5 Materials Management – Consumption based Planning
5.1 Activate MRP for MRP Areas
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
This setting is required if we want to
have planning at a level other than plants i.e. either of Storage location /
at Subcontractor level.
An MRP area represents an
organizational unit for which we can perform material requirements planning
separately.
An MRP area can include
one or several storage locations of a plant or a subcontractor. We can define
MRP areas in a plant.
For ITZ Ltd., we have not
used MRP Areas.
|
5.2 Define MRP Areas
Menu path
|
|
Transaction Code
|
SCAL
|
Configuration Description
|
Here we define the MRP areas for a plant for which we would like
to carry out material requirements planning separately.
When creating an MRP area, we enter the number, which must have
at least 5 digits to avoid any overlapping with the plant MRP area, the
description and the MRP area type
In case of ITZ
we have not defined MRP area
Important
: If MRP area is activated Conversion of Planning file entries needs to
be run in every new System Client through Report RMDBVM00 in Txn : SE38
The
conversion report causes the system to create a new planning file. In
addition, the system creates MRP area for the existing plants. These MRP
areas do not, however, affect the way material requirements planning is
carried out. The number for plant MRP areas is identical to the plant number
and therefore consists of four digits.
The
conversion of the current planning file (table MDVM) to the new planning file
(table DBVM) is a prerequisite for carrying out material requirements
planning with MRP areas.
|
6 Materials Management – Purchasing
6.1 Define Attributes of System Messages
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
Purchasing, certain system messages containing important information for
users may be issued from time to time
In this
step, we can specify whether the SAP System:
In the case of an error message,
processing cannot be continued until user input has been corrected
For ITZ requirement, messages (as a
change from standard) are configured as given below:
|
6.2 Define Purchasing Value Keys
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
With
Purchasing value key we can control following functions by using it in the
material master purchasing view, purchasing value key governs:
This data appears as default data in
purchasing documents and is taken from the material master record (unless a
purchasing info record exists, in which case it is taken from the info
records).
|
6.3 Entry Aids for Items without a Material Master
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step we assign In
this step, we can assign a purchasing value key and a valuation class to a
material group.
The
assignment of a purchasing value key default values for reminder levels etc.
in purchase order items without a material master record and without an info
record.
The
assignment of a valuation class to a material group enables the system to
determine different accounts for the individual material groups.
For
ITZ we have maintained Valuation Classes in the accounting view of the
materials.
|
6.4 Create Purchasing Groups
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
It’s a key for a buyer or group of buyers responsible for certain purchasing activities. useful in accessing information, controlling authorizations, setting up release strategies etc. for ITZ ‘s Requirement following groups are configured, configuration is a simple table entry but purchasing group has a comprehensive use in all purchasing transactions/ documents |
6.5 Define Document Types (RFQ/Quotation)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
SAP manages RFQs and
quotations as documents which are grouped into different document types., in
this step we have :
The
update group determines how the data from the document header is updated in
the statistics file.
Linkage
determines which PR document types can be referenced for creating a
particular RFQ document type
|
6.6 Define Text Types for Header Texts (RFQ/Quotations)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define different Texts which appear in RFQ/Quotation Headers, which
are used to store information applicable for a particular RFQ document
We have standard Header Text Types.
|
6.7 Define copying rules for Header Texts (RFQ/Quotations)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define copying rules for different header Texts which appear in
RFQ/Quotation Line Items
Copying
rules are used to determine which texts can be adapted from other objects
(for example, vendor master records, contracts) to the header text of the
RFQ. We link text types in the RFQ with text types in other objects. System
can adopt header texts from the following objects:
We can also
specify whether the adopted text can be edited in the destination document or
not. This type of setting is more useful in PO Header Texts
|
6.8 Define document types (Purchase Requisitions)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
SAP manages Purchase
Requisitions as documents which are grouped into various document types., in
this step we have :
The
update group determines how the data from the document header is updated in
the statistics file.
Above
linkage governs which type of PO can be created using PR of a
particular type
|
6.9 Release Procedure with Classification (Purchase Requisitions)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step, we have set up the release procedure with classification.
Purchase
Requisition release is the process in which Purchase Requisition is approved
and released by HOD of concern department for request of required material or
services specified in Purchase Requisition. Once the Purchase Requisition is
approved and released then Purchase Order or RFQ will be created for that
material or services against same Purchase Requisition.
Configuration
involves following elements in sequence:
Release
Group:
Specify
for the release group either "overall release" or "item-wise
release"
Release
codes:
The
Release Code is a two-character ID allowing a person to release (approve) a
requisition.(analogous to approver code)
Release
Indicators:
A
release indicator shows the release status of a purchase requisition
Field selection key via the field selection key, we can specify which fields in a purchase requisition with this release indicator can be changed or must be populated Changes after start of release process
Release
Strategy
The Release Strategy defines the
approval process for Purchase Requisitions. The strategy specifies the
release codes which are necessary and the sequence in which releases have to
be affected. We can define a maximum of eight release codes i.e. 8 Levels of
approval.
Release Prerequisites
indicate the sequence in which a Purchase Requisition must be approved via
the release codes. (In ITZ case release is parallel(either / or so indicators
are kept blank)
Release
Status indicates
the affect after the release by a particular release code
Release
Values
These
values need to be maintained in every client manually, this forms the basis
on which release strategy is triggered for a PR.
An
important prerequisite for this is to create Class & Characteristics in
class type 032
Characteristics
for Release Strategy
Create
the Characteristics required for release strategy as master data thru
transaction CT04, here the most important setting is to attach the characteristics
to corresponding field of structure CEBAN
attach
it to the structure
Class
for Release Strategy
Create
the class as master data thru transaction CL02
and
attach the Characteristics created earlier to the class
|
6.10 Define Number Ranges (Purchase Orders)
Menu path
|
|
Transaction Code
|
OMH6
|
Configuration Description
|
In this
step we define number ranges for Purchase order document types, (defined
separately in customizing), this setting also includes number ranges for
other external purchasing documents i.e. for Contracts/Scheduling Agreements
and RFQs. There are two ways of doing this:
In
this case, a number within the number range interval allowed is assigned by
the SAP system.
Here, the user assigns a number
within the number range interval allowed. We can define the intervals for
external number assignment numerically and alphanumerically.
In case of ITZ all the documents are assigned with internal number ranges with the exception for document type “Legacy Open P.O”, as it was required to retain the legacy P.O number for this case.
go
in change mode and define the intervals as shown:
|
6.11 Define Document types (Purchase Orders)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
SAP manages Purchase Orders
as documents which are grouped into various document types., in this step we
have :
The
update group determines how the data from the document header is updated in
the statistics file.
Above
linkage governs which type of PR can be referenced created while
creating a particular Contract document type
|
6.12 Set Tolerance Limits for Price Variance
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
When processing a purchase order, the system checks whether the
effective price of a PO item shows variances compared with the valuation
price stored in the material master record. In addition, it checks whether
the specified cash discount value is admissible.
Variances are allowed within the tolerance limits. If a variance
exceeds a tolerance limit, the system issues a warning or error message. In
SAP, the types of variance are represented by the tolerance keys. For each
tolerance key, we can define percentage and value-dependent upper and lower
limits per company code.
|
6.13 Release Procedure for Purchase Orders
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step, we have set up the release procedure for Purchase Orders(this also
covers the process for other external purchasing documents e.g.
contracts/scheduling agreements)
Purchase
Order release is the process in which PO is approved and released by HOD of
concern department for request of required material or services specified in
PO. Once the Order is approved and released then GR can be created against
the PO
In
case of ITZ, Release strategy is used in case of all purchases.
Configuration
involves following elements in sequence:
Release
Group:
Release
groups are created for each type of purchasing
Release
codes:
The
Release Code is a two-character ID allowing a person to release (approve) a
requisition.(analogous to approver code)
Release
Indicators:
A
release indicator shows the release status of a Purchase Order
Changeability Indicator With the Changeability indicator, we can specify the effects of changes to a PO document. For example, certain changes may require a new release strategy to be determined for the requisition.
Release
Strategy
The Release Strategy defines the
approval process for PO. The strategy
specifies the release codes which are necessary and the sequence in which
releases have to be affected. We can define a maximum of eight release codes
i.e. 8 Levels of approval.
Release Prerequisites
indicate the sequence in which a Purchase Requisition must be approved via
the release codes. (In ITZ case release is by a single authority so there are
no prerequisite involved)
Release
Status indicates
the affect after the release by a particular release code
Release
Values
These
values need to be maintained in every client manually, this forms the basis
on which release strategy is triggered for a PO.
An
important prerequisite for this is to create Class & Characteristics in
class type 032
Characteristics
for Release Strategy
Create
the Characteristics required for release strategy as master data thru
transaction CT04, here the most important setting is to attach the
characteristics to corresponding field of structure CEKKO
And
attach it to the structure
Class
for Release Strategy
Create
the class as master data thru transaction CL02 and attach the Characteristics
created earlier to the class
|
6.14 Define Screen Layout at Document Level
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step we define the attributes of various fields contained in a field
selection key (defined for a document type) inside which various fields
are grouped into fields selection groups.Steps
involved in the process are :
Select
a field selection key and set the attributes inside as shown:
get
inside a field group and choose the attributes
settings
can be made similarly for other fields in various other groups as &
when required
|
6.15 Define Text Types for Header Texts (Purchase Orders)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step we define different Texts which appear in Purchase order header, these are used to store information applicable for a particular PO document |
6.16 Define copying rules for Header Texts (Purchase Order)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define copying rules for different header Texts which appear in
Purchase Order Headers
Copying
rules are used to determine which texts can be adapted from other objects
(for example, vendor master records, contracts, RFQ) to the header text of
the Purchase Order. We link text types in the PO with text types in other
objects. System can adopt header texts from the following objects:
We can also specify whether the
adopted text can be edited in the destination document or not. Currently we
are not maintaining any copying rule for header texts
|
6.17 Define Text Types for Item Texts (Purchase Orders)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define different Texts which appear in Purchase order item level,
these are used to store information applicable for a particular PO document
line item |
6.18 Define copying rules for Item Texts (Purchase Order)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define copying rules for different item Texts which appear in
Purchase Order ITEM
Copying
rules are used to determine which texts can be adapted from other objects
(for example, vendor master records, contracts, RFQ) to the header text of the
Purchase Order. We link text types in the PO with text types in other
objects. System can adopt header texts from the following objects:
We can also specify here whether the
adopted text can be edited in the destination document or not.
maintain
the rules for a text as under
|
6.19 Define Document Types (Contracts)
Menu path
|
|
Transaction Code
|
OMH6
|
Configuration Description
|
SAP manages Contracts as
documents which are grouped into various document types., in this step we
have :
The
update group determines how the data from the document header is updated in
the statistics file.
In
case of ITZ, use of Contracts and Scheduling agreements is very minimal so we
have retained and used standard SAP document types
Above
linkage governs which type of PR can be referenced created while
creating a particular Contract document type
|
6.20 Define Screen Layout at Document Level (Contracts)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step we define the attributes of various fields contained in a field
selection key (defined for a document type) inside which various fields
are grouped into fields selection groups.Steps
involved in the process are :
Select
a field selection key and set the attributes inside as shown:
get
inside a field group and choose the attributes
settings
can be made similarly for other fields in various other groups as &
when required
|
6.21 Define Text Types for Header Texts (Contracts)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step we define different Texts which appear in Contract header, these are used to store information applicable for a particular Contract document |
6.22 Define copying rules for Header Texts (Contracts)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define copying rules for different header Texts which appear in
Contract Headers
Copying
rules are used to determine which texts can be adapted from other objects
(for example, vendor master records, Contract, RFQ) to the header text of the
Contract. We link text types in the PO with text types in other objects.
System can adopt header texts from the following objects:
We can also specify whether the
adopted text can be edited in the destination document or not.
We
are maintaining Standard Text and copying Rules for Header Texts
|
6.23 Define Text Types for Item Texts (Contracts)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step we define different Texts which appear in Contract item level, these are used to store information applicable for a particular Contract document line item |
6.24 Define copying rules for Item Texts (Contract)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we define copying rules for different item Texts which appear in
Contract Headers
Copying
rules are used to determine which texts can be adapted from other objects
(for example, vendor master records, contracts, RFQ) to the header text of
the Contract. We link text types in the Contract with text types in other
objects. System can adopt header texts from the following objects:
We can also specify here whether the
adopted text can be edited in the destination document or not.
maintain
the rules for a text as under
|
6.25 Define External Confirmation Categories
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Notification from
the vendor to the recipient regarding the status of a purchase order., In
case of ITZ , CONFIRMATIONS are not being used Confirmation categories are
defined to symbolize the key for a type of confirmation
|
6.26 Define Internal Confirmation Categories
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step, we assign an external confirmation category to each internal
confirmation category.
Internal Categories
are for system controls.
|
6.27 Set Up Confirmation Control
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In
this step, we assign an external confirmation category to each internal
confirmation category.
Internal Categories
are for system controls.
As
shown all the conformation categories are relevant for MRP, but the last one
is relevant to GR also, which means that when a GR is made against the P.O
line item it will get defaulted with qty of last conf. category
|
6.28 Define Access Sequence
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Access
sequence is an important element of pricing determination. It is the Order in
which the system searches through the condition tables when searching for
particular condition records. The search order goes from specific condition
records to general condition records.
Access sequence is
made up of condition table (the level at which data is stored)
In
the access sequence shown system will search for the record from first to
last table in sequence. (e.g. if Custom duty % for a material is maintained
at all the three levels i.e. Incoterms-plant-maerial / Plant-Material /
Plant-Material Type level , then system will take the record from 1st
available level only i.e. Incoterms-plant-maerial in this case)
Each
condition table is defined as an combination of fields for data access and is
assigned to different condition types ( In case of ITZ , we are not
maintaining any access sequence),
|
6.29 Define Condition Types
Menu path
|
|
Transaction Code
|
M/06
|
s
Configuration Description |
In
this step we have defined condition types.
The
condition types are used to represent pricing elements such as prices, discounts,
surcharges, taxes, or delivery costs in the SAP. These are stored in the
system in condition records.
For
condition types for which we want to maintain conditions with their own
validity period we have specified an access sequence. (e.g. for all import
duty conditions
Important
Settings Condition type include:
Condition Class: Defines nature of
condition as Prices / surcharge / discounts etc.
Calculation type: Defines nature of
condition unit i.e. Amount type / Percentage / Qty etc
Condition Category : e.g. Packaging,
Cost , Tax, Delivery Costs(requiring extra vendor at condition level)
Access Sequence : Allows condition
records to be maintained
Header Condition : Allows usage at
Header level of Purchasing document
Accruals : Makes a condition
irrelevant to net price calculation i.e. excluded from tax base
|
6.30 Define Calculation Schema
Menu path
|
|
Transaction Code
|
M/08
|
Configuration Description
|
In this step, we have defined the calculation schemas.
In MM area, a calculation schema is a framework of steps used to
calculate pricing in as purchasing document
Analogous to this is referred to in the Sales and Distribution
(SD) area as a pricing
procedure.
In
the calculation schema (pricing procedure), we specify which condition types
are to be taken into account in which sequence.In the price (or cost) determination process, the SAP System automatically determines which calculation schema is valid for a business transaction and takes into account, one after another, the condition types it contains.
In
case of ITZ we have defined schemas all starting with Z*, these will get
derived in different types of purchasing documents as per the rule explained
in Schema determination configuration
Select
one of the schema and see the control data as shown below:
Important
keys in defining Schema are as under:
Step No. & Counter: For determination
the sequence of conditions and to act as a base for calculations with in
condition
From- To : Base for
calculation of condition value, this is only relevant for % type of
conditions
Statistical: Makes a condition
non-relevant to account postings
Subtotal: Used to pass the
condition value in to fields of P.O item tables and other pricing structure
Requirement : Used for validating
Condition value determination using small ABAP written formulae
Base
Type: Here
a Formula for determining the condition basis as an alternative to the
standard.
Accrual key: for deriving a
separate account during GR / Invoice postings
|
6.31 Define Schema Group
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Every External
Purchase document derives Calculation Schema from a combination of Purchasing
Organization and Vendor, to simplify data maintenance for this process SAP
works with grouping concept. So all the purchasing org. are grouped in to a
Schema group and Vendors requiring same pricing stricture are grouped into a Schema
group , now for the combination of these , system derives the pricing schemas
Click on a row to
enter :
the other part i.e.
vendors are assigned with schema group in vendor master
|
6.32 Define Schema Determination
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step we have defined the determination of Pricing schema for different type
of Purchasing documents and for Stock transport orders
For standard purchase
orders
(depending on the schema group of the vendor and the purchasing organization)
For stock transport
orders
(depending on the supplying plant, the document type and the schema group of the purchasing organization) and second item |
6.33 Define Transaction Event keys
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step, we
have defined transaction/event keys for condition types involving provisions.
This enables the
system to find the relevant account for provisions (for accrued delivery
costs or miscellaneous provisions, for example),
We have assigned
these transaction/event key to each condition type that is relevant to
provisions in the step Define Calculation Schema.
Select the 1st
row
Select second row,
it displays the usage of key in schema
|
6.34 Maintain Condition Table
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step, we create custom tables, these table are used to store condition
records for different condition types , for this these tables should be a
part of access sequence
With
help of this we can derive prices, discounts and surcharges dependent on almost
all the fields in a purchasing document.
In a condition table, we specify the combination of fields for which we can create condition records.
As per
SAP recommendation we
should not change the condition tables that are included in the standard
version of the SAP System.
Check the extent to
which we can use the condition tables that are supplied with the standard SAP
System, for our tables we can only choose names between 501 and 999. If we
make no entry, the system will automatically assign a consecutive number.
For
ITZ we have not defined any tables:
Steps:
For
creating new condition tables. copy a similar condition table and proceed as
follows:
IMP:
All the fields that shall be used to pick up any condition value must be part
of Header/Key field in the condition table.
|
6.35 Define Grid for Quantity Variances
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
For Purchasing information system for
vendor performance the statistics is managed on the amount of quantity variances of
vendors.
The delivery
quantity variance specifies in percent the variance between the purchase
order quantity and the quantity actually delivered.
This
key figure is determined if an order item is completed and is updated for the
entry date of the goods receipt or for the entry date of purchase order
change.
In this
step we can determine four interval limits for every purchasing organization.
Five intervals are then available to we for evaluation of vendors
|
6.36 Define Grid for Delivery Date Variance
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Delivery
date variance data is used in statistics for evaluating vendor performance.
The delivery
date variance specifies the difference in days the difference between the
statistically relevant delivery date and the date of the goods receipt.
This
key figure is updated during the goods receipt for the entry date.
In this
step we can determine four interval limits for every purchasing organization.
Five intervals are then available to we for evaluation of vendors
|
6.37 Define Weighing keys
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In vendor evaluation criteria are weighted according to their
importance through Weighing key.
For example, the overall evaluation of a vendor is calculated
from the scores awarded for the main evaluation criteria "price,"
"quality," and "delivery." The latter comprises
"on-time delivery performance" and "quantity
reliability."
If we consider a vendor's price to be more important than
quality, and quality to be more important than delivery, we can assign
weights to the criteria in a ratio of three for price, two for quality, and
one for delivery. This ratio is recorded in a weighting key.
|
6.38 Define Criterion (Vendor Evaluation)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Here we have defined
the criteria by which the system computes scores for vendors and specify
whether the scores for the subcriteria are computed manually, semi-automatically,
or automatically.
Select
One of the criterion and drilldown to sub criterion
|
6.39 Define Scope of List (Vendor Evaluation)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step we
define various types of list, each representing different main criteria or
the same main criteria in a different order. In the standard system, the scope-of-list parameters 'standard' and 'version 1' are supplied as an example:
check the details
of list inside
|
6.40 Maintain Purchasing Organization data
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Select
a row and displays criterion for Purchasing Organization
Sub
criterions for main criterion
Weighing
for a Purchasing Org.
We
have provided Equal Weighting to the Criteria as we have different weighing
parameters for ITZ
Point
scores for a Purchasing Org.
|
6.41 Define Permissible Partner Roles per Account Group
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Here we can
specify for each account group of the vendor which roles the vendor may
assume.
Example we can specify that certain vendors may only serve as
an ordering address, not as an invoicing party.
|
6.42 Define Partner Schemas (Vendor Master)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Partner
schemas allow us to group various partner roles. We can specify that certain
roles in a schema are mandatory, i.e. cannot be changed after entry. For ITZ, Schema groups Z1 is defined
select a schema to
detail the allowed partner functions
|
6.43 Assign Partner Schemas to Account Groups
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Here we
assign the already defined schema groups to vendor account groups
|
6.44 Define Partner Schemas (Purchasing Documents)
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
Partner
schemas allow us to group various purchasing documents for partner
determination. We can specify that certain roles in a schema are mandatory,
i.e. cannot be changed after entry. For ITZ, Schema group Z001 is defined
Select a Schema to
detail the partner function allowed
|
6.45 Assign Partner Schemas to Document Types
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this
step, we have assigned the partner schemas to the various types of purchasing
document.
As a
result, only the roles of the schema in question can be maintained in
documents of the relevant types.
|
7 Materials Management – External Services Management
7.1 Define Service Category
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step, we define the service
category.
The service category is the most
important criterion for structuring
Service master records. It provides a
default value for the valuation
|
7.2 Define Number Ranges
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step, we define Number Ranges for each service category.
|
7.3 Define Number Range for Service Entry Sheets
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In this step, we define the service
category.
The service category is the most
important criterion for structuring
Service master records. It provides a
default value for the valuation
|
7.4 Define Attributes of System messages
Menu path
|
|
Transaction Code
|
SPRO
|
Configuration Description
|
In External Services Management, a
number of system messages containing important information for users may be
issued. Users can process this information further.
In this step, we can define whether the
SAP System
For ITZ requirement, additional messages
no. SE 346 / 347 / 361 is activated as Error along with other
additional Standard SAP Messages
|
8 Materials Management – Inventory Mgmt. & Physical Inventory
8.1 Plant Parameters
Menu path
|
|
Transaction
Code
|
SPRO
|
Configuration
Description
|
In this step, we make the
general plant settings for ‘Inventory Management’. All settings are also
contained in the individual steps of the Implementation Guide for Inventory
Management.
|
8.2 Define Number Assignment for Accounting Documents
Menu path
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transaction
Code
|
OMBA
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuration
Description
|
In this step, we set the
number ranges for the accounting documents which are created when goods
movements or inventory differences are posted.
Goods
Issue Document Type
Goods
Receipt Document Type
Automatic
Movements Document Type
Physical
Inventory Document Type
|
8.3 Define Number Assignment for Material and Physical Inventory Documents
Menu path
|
|
|||||||||||||||||||||||||
Transaction
Code
|
OMBT
|
|||||||||||||||||||||||||
Configuration
Description
|
In this step, we maintain
the number assignment for the following documents:
Note
We
cannot change the transaction/event types. However, we can change the number
range intervals or we can allocate transaction/event types to new groups.
Her you ned to maintain the number ranges for the group attched to the key.
If you want to maintain new number range
intervals for an existing group:
a) Choose Group -> Maintain. b) Select a group and choose Interval -> Maintain. c) Choose Edit -> Insert year. d) Maintain the number interval for the new fiscal year. |
8.4 Define Number Assignment for Reservations
Menu path
|
|
Transaction
Code
|
OMJK
|
Configuration
Description
|
In this step, we set up
number assignment for reservations. The number assignment applies to all plants in the client.
Note
If
we create reservations with method CreateFromData1 (function module
BAPI_RESERVATION_CREATE1), we can use the number range RB for an external
number assignment.
|
8.5 Field Selection for Goods Movement/Initial Header Screens
Menu path
|
|
Transaction
Code
|
OMJN
|
Configuration
Description
|
In this step, we define the
field selection for goods movements initial and header screens. Note that the field selection for the item screens depends on the movement type and is configured in separate steps.
In
this step, we specify whether the fields are input, mandatory, display or
hidden.
|
8.6 Field Selection for MIGO
Menu path
|
|
Transaction
Code
|
OMJX
|
Configuration
Description
|
Here we can:
Hide the print indicator if we do
not want to print out GR/GI slips in Inventory Management
|
8.7 Field Selection per Movement Type
Menu path
|
|
Transaction
Code
|
SPRO
|
Configuration
Description
|
In this step, we maintain
all the settings for field selection by movement type. This step replaces the
activity Define Screen Layout for the Enjoy transactions. The settings from
Define Screen Layout are adopted in these settings automatically so that we
do not need to maintain new entries here. |
8.8 Settings for Transactions and Reference Documents
Menu path
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transaction
Code
|
SPRO
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuration
Description
|
We can limit the number of
selectable transactions (goods receipt, goods issue, and so on) and reference
documents (material document, delivery note), and we can specify the movement
type that the system is to propose for every reference document. MIGO_GR - Used to enter goods receipts from external procurement. MIGO_GO - Used to enter goods receipts for production orders. MIGO_GI - Used to enter goods issues.
Transaction
MIGO; Actions Mentioned in the table
Reference
Document Types (For details go to the path mentioned)
|
8.9 Create Storage Location Automatically
Menu path
|
|
Transaction
Code
|
OMB2
|
Configuration
Description
|
In this step, we specify
whether the automatic creation of storage location data is allowed for goods
issues and transfer postings. We have to allow automatic creation per plant first of all. We then have to explicitly allow the creation of storage location data for each movement type. |
8.10 Set Manual Account Assignment
Menu path
|
|
||||||||||||||||||||||||||||||||
Transaction
Code
|
OMB6
|
||||||||||||||||||||||||||||||||
Configuration
Description
|
In the R/3 System, account
assignment is predefined via the automatic account determination facility.
|
8.11 Define Screen Layout
Menu path
|
|
Transaction
Code
|
OMBW
|
Configuration
Description
|
In this step, we set the
field selection for the movement types including goods issues and transfer
postings.
Note
We
do not maintain the input features of the G/L account and Reason fields here,
but in the following steps:
Caution
The
field selection for the movement type must correspond with the following
field selections:
|
8.12 Maintain Copy Rules for Reference Documents
Menu path
|
|
||||||||||||
Transaction
Code
|
SPRO
|
||||||||||||
Configuration
Description
|
In this step, we configure
whether the items of the reference document are proposed as selected on the
item selection list when entering a document with reference, or not.
|
8.13 Set up Dynamic Availability Check
Menu path
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transaction
Code
|
OMCP
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuration
Description
|
In this step, we configure
the dynamic availability check.
We
can define
Checking
Rule
Define
Checking Rule
Transaction
Codes
|
8.14 Generate Physical Inventory Documents for Goods Movements
Menu path
|
|
||||||
Transaction
Code
|
OMCC
|
||||||
Configuration
Description
|
In this step, we define for
each plant and movement type whether a physical inventory document is
automatically generated when posting a goods movement. We must define the document number assignment for this transaction/event type. Automatic generation of physical inventory documents must be allowed for the movement type.
The
above list is indicative
|
8.15 Check Tolerance Limits
Menu path
|
|
Transaction
Code
|
OMC0
|
Configuration
Description
|
In this step, we set the
tolerance limits for goods receipts.
(Explanation)
For
this variance, two tolerance keys are provided:
(Explanation)
We use tolerance key VP to
define the percentage variance from which a warning message is issued. This
warning message indicates a price change. |
8.16 Create Storage Locations Automatically
Menu path
|
|
Transaction
Code
|
OMB3
|
Configuration
Description
|
In this step, we specify
whether the automatic creation of storage location data is allowed for goods
receipts. |
8.17 Set Manual Account Assignment
Menu path
|
|
Transaction
Code
|
OMCH
|
Configuration
Description
|
In the R/3 System, account
assignment is predefined via the automatic account determination facility. |
8.18 Define Screen Layout
Menu path
|
|
Transaction
Code
|
OMCJ
|
Configuration
Description
|
In this step, we set the
field selection for the goods receipt movement types.
|
8.19 Maintain Copy Rules for Reference Documents
Menu path
|
|
|||||||||||||||||||||||||||
Transaction
Code
|
SPRO
|
|||||||||||||||||||||||||||
Configuration
Description
|
In this step, we configure
whether the items of the reference document are proposed as selected on the
item selection list when entering a document with reference, or not.
|
8.20 Set Dynamic Availability Check
Menu path
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transaction
Code
|
OMCM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuration
Description
|
In this step, we configure
the dynamic availability check.
The system checks whether the
material to be withdrawn is available and issues a message, if necessary.
Movement
Type
Checking
Rule
Transaction
Code
|
8.21 Set “Delivery Completed” Indicator
Menu path
|
|
Transaction
Code
|
SPRO
|
Configuration
Description
|
In this step, we can define
that the R/3 System automatically suggests
Note
Even
if the "delivery completed" indicator has not been set, an item is
considered closed once the total quantity has been delivered. This means that
the "delivery completed" indicator is not necessary in this case.
|
8.22 Set Expiration Date Check
Menu path
|
|
Transaction
Code
|
OMJ5
|
Configuration
Description
|
In this step, we set the
material shelf life expiration date check for goods receipts for each plant
and movement type. The shelf life expiration date of a material can only be entered if:
|
8.23 Create Storage Location automatically for automatic movements
Menu path
|
|
Transaction
Code
|
OMJ8
|
Configuration
Description
|
In this step, we specify
whether the automatic creation of storage location data is allowed for
automatic goods movements.
The
storage location data is only created if the quantity is posted to 'standard'
storage location stock. It is not created for receipts into a special stock
(for example, into sales order stock).
|
8.24 Set manual account assignment for automatic movements
Menu path
|
|
||||||||||||||||||||||||||||||||||||||||||||
Transaction
Code
|
OMJ9
|
||||||||||||||||||||||||||||||||||||||||||||
Configuration
Description
|
Maintenance of this
indicator is only useful in conjunction with movements for which a G/L
account can be entered or is provided by the calling program.
|
8.25 Define Screen Layout for automatic movements
Menu path
|
|
Transaction
Code
|
OMJA
|
Configuration
Description
|
In this step, we set the
screen Layout for automatic movement types. |
8.26 Generate Physical Inventory Documents for Goods Movements
Menu path
|
|
Transaction
Code
|
OMJC
|
Configuration
Description
|
In this step, we define for
each plant and movement type whether a physical inventory document is created
automatically when a goods movement is posted. |
8.27 Define Default Values for Reservations
Menu path
|
|
Transaction
Code
|
OMBN
|
Configuration
Description
|
In this step, we specify
the default values for the following functions for each plant:
We can only post a goods movement with reference to a reservation if the Movement allowed indicator is set in the reservation item. The management program sets the deletion indicator for reservation items whose requirements date is earlier than the number of days specified here. When this indicator is set, the storage-location stock data is automatically created when a reservation is posted. This applies both to planned outward movements and planned receipts. |
8.28 Maintain Copy Rules for Reference Documents
Menu path
|
|
Transaction
Code
|
SPRO
|
Configuration
Description
|
In this step, we configure
whether the items of the reference document are proposed as selected on the
item selection list when entering a document with reference, or not. |
8.29 Set Dynamic Availability Check for Reservations
Menu path
|
|
||||||||||||
Transaction
Code
|
OMB1
|
||||||||||||
Configuration
Description
|
In this step, we configure
the dynamic availability check.
|
8.30 Default Values for Physical Inventory
Menu path
|
|
Transaction
Code
|
SPRO
|
Configuration
Description
|
In this step, we specify
the following default values for physical inventory for each plant:
These indicators are suggested as
default values when we enter a physical inventory document. But we can also
change them there.
Pre-settings for entering physical inventory documents
We only see this field when we enter inventory differences if we have activated it in the step Field selection for physical inventory. |
8.31 Record Reasons for Goods Movements
Menu path
|
|
Transaction
Code
|
OMBS
|
Configuration
Description
|
In this step, we can carry out the
following for each movement type:
When we enter a goods movement, we
can only enter reasons which have been defined for the movement type here.
|
8.32 Copy, Change Movement Types
Menu path
|
|
Transaction
Code
|
OMJJ
|
Configuration
Description
|
In this step, we can
When we enter a goods movement, we
must always enter the movement type. The movement type has important control
functions in Inventory Management. It is essential for
|
9 Materials Management – Valuation and Account Assignment
9.1 Split Valuation
Menu path
|
|
Transaction
Code
|
OMW0
|
Configuration
Description
|
You configure whether split valuation is allowed at your
company. If you generally allow split valuation, this does not mean that you
must valuate each material on this basis. You decide whether to do so or not
for a particular material when creating the material master record.
|
9.2 Configure Split Valuation
Menu path
|
|
Transaction
Code
|
OMWC
|
Configuration
Description
|
In split valuation, we can distinguish between
partial stocks of a material according to certain criteria and valuate them
separately.
a) Select "Goto --> Global Categories".
b) Position the cursor on a valuation category and select
"Goto --> Global Categories --> Allocations -->
Types->Category".
c) Activate the valuation types you want.
a) Select "Goto --> Local definitions".
b) Position the cursor on a valuation area and select "Goto
--> Local Definitions --> Allocate Categories->Org.units". You
obtain a list of the global valuation categories.
c) Activate the categories to be used in this valuation area.
The system creates the local valuation types based on the
allocations under point 2.
|
No comments:
Post a Comment