Saturday, July 18, 2009

Mass Maintenance of Purchase OrderThere are situations in real life scenarios, when transactional data needs

to be updated en-mass. This could arise due to change in material

specifications, vendor terms etc. To update each and every document,

one by one would be time taking, prone to errors and very tedious. To

simplify this, SAP has provided utilities to update certain transactional

data en-mass.

This article highlights one such mass maintenance utility for updating

Purchase orders in bulk.

Go to T Code MEMASSPO.

Let's say we want to update Purchase Order Line Items. Select the line as

shown below.

Blog Contents:▼ 2009 (5)

▼ July (3)

Mass Maintenance of Purchase

Order

How to Control Inspection Lot

Creation

Solution Manager at a Glance

► January (2)

► 2008 (13)

0 More Next Blog» Create Blog Sign In

SAP MM Expert

Click on Execute Button.

Enter the Purchase Order Number. If the purchase orders have multiple

line items, only those purchase orders should be entered here which need

maintenance of the same line item.

Click on Select Fields button.

About MeMamta

View my complete profile

Select the fields in the screen above which you want to mass maintain.

Select both the columns and click on mass update, as shown below.

Click on SAVE.

Click on the check box.

Below is the update log.

Posted by Mamta at 9:01 PM 43 comments:

How to Control Inspection Lot Creation

This article explains the setting required to control Inspection Lot creation

for Purchase Order / Production Order or Process Order.

In the material master > QM view of the material, click on Inspection type

and the following pop-up screen will open.

The field “Control insLot” controls the behavior of Inspection Lot creation.

For each purchase order item, batch and storage location – only one

inspection lot gets created. Even if there are multiple Goods

Receipt on the purchase order line.

For each material document, material, batch and storage loc. – for

each partial GR a new inspection lot is created, even if the batch is

the same.

The following screen shows the settings for a Production Order / Process

Order.

Early lot creation for the order item – It means when a process /

production order is released an inspection lot is created. This

setting is particularly useful if there are in-process inspections.

Posted by Mamta at 8:39 PM No comments:

Solution Manager at a Glance

Solution Manager, as the name suggests is used to manage the entire IT

Solution landscape for an organization. Solution Manager can be used to

manage SAP as well as non SAP applications. SolMan has applicability in all

kinds of SAP projects viz. implementation, rollout, support or upgrade. It

supports all phases of a project by using appropriate pre-delivered

roadmap. Apart from projects, SAP solution manager is also used for

Solution Monitoring, Service Delivery (operations) and Service Desk (for

steady state support).

The following is a typical transaction / process sequence while using

solution manager,

• T Code – SOLAR_PROJECT_ADMIN

This transaction is used to create a project and assign a roadmap. While

creating a project, a project type needs to be selected. The different

types include, Implementation, Template, Optimization Project (for SAP

services), Safeguarding Project (for critical situations) and Upgrade

Project. Project language is also determined at the time of project

creation which can not be changed later.

• T Code – RMMAIN

This transaction enables the user to see the roadmap in a graphic form. It

basically outlines the roadmap in terms of deliverables, milestone and

services for each project phase.

• T Code – SOLAR01

This transaction is used during the business blueprinting stage. It is

divided into 4 groups viz Org Unit, Master Data, Business Scenario and

Interface Scenarios. The business scenario group is further subdivided

into Org Unit, Master Data and Business Process. Under business process

the various steps / tasks are defined which generally include the logical

sequence of transactions codes which need to be executed to cover the

business process.

The Org Unit and Master Data under a business scenario are meant for

business scenario specific data.

The data from this transaction is used in all subsequent phases of the

project.

• T Code – SOLAR02

This transaction is used during Realization / Build phase. It uses the

structure created in SOLAR01 to add further details. The user can add

transactions for each business process, Configuration Nodes for

configuration items, Test Cases, Business Configuration (BC sets) sets

etc. SOLAR02 also provides access to create new test case or a new BC set

from the same transaction.

SOLAR02 is also used to add training material for each business process

along with the end user roles for which it is applicable.

• T Code – STWB_2

This transaction is used for Test Plan Management. It is used during

Integration testing. Test plan(s) corresponding to a project are created by

this transaction. Based on the test cases defined in SOLAR02, applicable

test cases are identified and then a test package is built. This test

package is assigned to the end user who is responsible for testing.

STWB_2 can also be used to monitor messages created during testing by

users. It also provides a status overview of the test cases. For instance

how many have not yet been tested (No Result), how many are in error and

how many have been passed (OK).

• T Code – STWB_WORK

This transaction represents the testing workbench. It is used by users

responsible for testing the SAP solution. It provides a user specific

worklist based on the test package assined in STWB_2. The tester can run

the test transaction from this workbench and then update the test status

like No Result or Error or OK. If required, the tester can also create a

message and assign to another person, for a particular test from this

transaction. The progress of these messages can then be monitored using

STWB_2.

• T Code – STWB_SET

This is used to initialize test workbench for testing and to set additional

parameters for message handling during testing.

• T Code – SOLAR_LEARNING_MAP

This is used to create a learning map assigned to a project. It is usually in

the form of chapters with documents assigned to each chapter. The end

users can see this using a browser link and provide their feedback on the

training content from the same web page window. This transaction also

provides means to analyze end user feedback on training and to monitor

the usage of the training link(s) based on the number of hits.

Additional Transactions:

• T Code – SMSY

This is used for system landscape management. The system landscape

consists of Logical Components. Logical components include a set of

logical systems along with their system roles with the applicable product

version.

• T Code – SMSY_SETUP

This transaction is used for system landscape data collection.

• T Code – SOLAR_EVAL

This transaction is used to auto determine upgrade relevant IMG activity

and documentation for configuration and business process.Posted by Mamta at 8:32 PM No comments:

Sunday, January 25, 2009

Batch ManagementBatch management is used to identify one lot of production from another.

This helps in tracking the lots during their life-cycle, as well as recording

the unique characteristics of each lot. For instance, the expiry date or

date of production of 2 lots can be different.

Batch Management can be applied to both process and discrete

manufacturing industry. It is tightly integrated with all business processes

viz., procurement, manufacturing, sales and inventory management.

Some of the prominent functionalities supported as part of standard SAP

batch management process are as under:

• Batch Specification / Classification - Classes can be defined for a batch

and characteristic values can be entered accordingly.

• Auto Batch Creation – Batches can be configured to be automatically

created as part of certain standard SAP processes.

• Batch Determination - This provides an automatic batch search

technique based on pre-defined criteria. It is useful during Goods Issue

and SAP condition technique is used to configure this. It also helps in

searching for batches using specifications.

• Batch Status - it specifies whether the batch is active, can be used

further etc.

Configuration Steps:

Step 1 – Click on the link below “specify batch level and activate status

management”.

The first setting is, at what level the batch number should be unique. The

default setting is as below,

The advantage of having batch unique at material level is, the batch

number remains consistent during stock transfer between different plants.

Next the batch status management is activated,

The node “initial status of a new batch” allows to set the status as

“restricted” when a new batch is created. If there is no check mark

against “initial status” as shown in the figure below, the stock remains

unrestricted. This setting is at material type level. The check box may not

be required to be set in case Quality Management is active. With QM, the

stocks are anyways inspected, so putting them into restricted would

increase one more step of bringing them from restricted to quality

inspection stock.

The node “plants with batch status management” will be required if batch

level is at plant level.

Step 2 – Activate batch number assignmentThe batch number can be

internally assigned or externally assignment. Depending upon the business

requirement, it can be configured.

Step 3 – Creation of new batchesThe new batches can be created

automatically by the system or manually vide transaction code MSC1N. To

create batches automatically during certain transactions / movement

types, follow the path to the following node in configuration:

The node "define batch creation for production order / process order",

allows you to configure for a combination of plant and production

scheduling profile. It specifies whether a batch is created automatically at

production order creation or production order release or no batch creation

at all. Similarly “batch creation for goods movement” controls the batch

creation for each movement type. The next node controls the batch

creation for each material type, as shown below.

Step 4 – Batch ValuationThis step is used to maintain batch characteristic

values while creating batches in the background (automatically) or

manually in the foreground. Batch characteristics are also useful when

batch determination functionality is required during goods issue. The

batch anyways inherits the material characteristics / class for which it is

created.

Step 5 – Batch DeterminationIt uses the standard sap access sequence

search strategy. Over here, strategy type is like condition type in pricing.

The following screen shows how to set it up.

Click on the above node and the list of existing strategy types will appear.

A new strategy type can be created here, preferably a copy of one of the

existing strategy type. These strategy types are then used in “Batch

search procedure definition” as shown below.

The batch search procedure configured above, now needs to be allocated

to IM movement types.

Step 6 – Define Sort RulesThis step determines, as the name suggests, a

rule is created to sort the batches during batch determination. This

sorting happens based on the characteristics defined for the batch.

Step 7 – Master Data SettingIn material master, “batch management”

indicatory needs to be set if the material is to be handled in batches.

The condition type / strategy type for batch determination needs to be

maintained. The T Code for the same is MBC1.

The key combination displayed above (for T Code MBC1) is as per the

access sequence configured under “batch determination and batch check”.

Shelf Life Expiration Date Check:

This can be enabled as per the node below.

The system allows the date check to be activated at Plant Level and at

Movement Type Level.Posted by Mamta at 10:47 AM 3 comments:

Logistics Invoice VerificationLogistics invoice verification is the final step in procure to pay cycle. It

begins with the vendor submitting the invoice for the goods sold. The

Accounts Payable group, after receiving the invoice from the vendor,

enters it in SAP. Based on the Purchase Order details, Goods Receipt,

invoice data and configuration settings, the system prompts the user with

messages. The user then takes one of the following action:

• Park / Save the invoice

• Post the invoice

Park / Save the invoice allows user to make changes later on, so that it

can be posted. Once posted, the invoice is released to accounting for

payment. Under certain circumstances, depending upon the configuration,

the invoice can get blocked upon posting. It means that until the block is

removed from the invoice document, it will not be released to accounting

for payment. There is an alternative way to carry out Logistics Invoice

Verification. The process is called Automatic Settlement or Evaluated

Receipt Settlement (ERS). In this process, instead of vendor submitting

the invoice for payment, the company creates an invoice document (based

on the purchase order and goods receipt). This document is then used as

the basis for payment by the accounting team.

Frequently used transactions:

MIRO - Enter Invoice

MIR7 - Park Invoice

MIR4 - Display Invoice Document

MR8M - Cancel Invoice Document

MRBR - Release Blocked Invoices

MIR6 - Invoice Overview Automatic Settlement

MRRL - Evaluated Receipt Settlement (ERS)

Invoice BlockingInvoice is blocked either by the system automatically or

manually. The reason for blocking is usually a high variance between the

PO data and Goods Receipt data as compared to the details mentioned in

the invoice document. If an invoice is blocked, all the items are blocked;

even if the block is applicable to a particular line item. Invoice block needs

to be removed on time particularly if the invoice includes a cash discount.

Delay in releasing the invoice may cause expiry of cash discount, if

applicable. The most common variances which are encountered during

invoice processing are:

• Quantity VarianceThis generally relates to the difference between

quantity received and invoiced by vendor. Or quantity in the purchase

order and invoiced by the vendor.

• Price VarianceThis refers to the variance of per unit price as compared

to the purchase order.

• Schedule VarianceThis is generally invoked if the date of invoice entry is

earlier than the delivery date in the purchase order.

The variances can be configured and activated as per the company posting

rules. Setting up these variances helps in two ways. It allows the invoices

with minor differences to go through so that a lot of time is not wasted on

small differences. At the same time, these variances stop invoices from

financial payment when the difference exceeds company standards thereby

providing a strong control in the process. There is a different kind of

block, 'stochastic block' which is sometimes implemented by the Accounts

Payable group. It means that certain invoices will be blocked for payment

at random, so that they can be checked again. There will be no particular

reason for blocking and the block will not be at any line item level. If it is

set, there will be an "R" in the payment block field in document header

data. It is usually based on 'threshhold value' and 'probability'.

Configuration Setting for Tolerance Limits:

Tolerances are defined in customizing to configure which variance to be

accepted and which one to be blocked. Tolerance limit for invoice block is

set at company code level. The Tolerance limit for each company code is

specified here for each Tolerance Key.

The following screen shows how to set it up for tolerance key “PP” – Price

Variance. It says that tolerance key PP is active for company code 2600

and the lower limit for tolerance is 5% and upper limit is $ 100.

There are also situations when the invoice, though within tolerance, is

entered with a large amount. It is then recommended to block the invoice

to check the amount. It can also be applicable to cases when invoices do

not refer to any purchase order. To activate this check, tolerance key

“AN” - Amount for item without order reference and “AP” - Amount for

item with order reference, need to be configured. Subsequently the

following node “Activate Item Amount Check” needs to be activated.

Configuration Setting for Stochastic Block:

In the step "Activate Stochastic Block", stochastic block is activated at

company code level for desired company codes. The next step is "Set

Stochastic Block" and here "threshold value", "currency" and "percentage"

is entered to set the stochastic block on invoices. If the invoice value

exceeds threshold value, based on the percentage (probability) block will

be set on the invoices. If the invoice value is lower than the threshold

value, the percentage (probability) gets reduced in proportion to the

invoice value and accordingly a block is set on the invoices.

Example

Threshold value: $6000 Percentage: 50

Invoice value Percentage or probability of a block

$7000 50 %

$8000 50 %

$3000 25 % (= 3000/6000 * 50)

$300 2.5 % (= 300/6000 * 50)

Releasing Blocked Invoices

The invoice block needs to be removed before any payment can be

processed for the vendor. To remove the block, invoices can be released

individually, collectively and automatically.

T Code - MRBR

Process

Newer Posts Older Posts

• Enter the selection criteria to select the desired invoices for processing.

• Process the invoice list by removing individual blocking reasons. This

could be a result of workflow between buyer and Accounts Payable

specialist.

• The invoice is then released, either by the buyer or the Accounts Payable

resource.

Posted by Mamta at 8:32 AM 5 comments:

Home

Subscribe to: Posts (Atom)