Tuesday, 3 September 2013

Simplified Imports PO creation

Hello friends,
Through this post, I would like to share with you an SAP procedure that will greatly simplify the creation of Imports PO. This is particularly relevant in the Indian imports business scenario.

Pain areas in Imports PO procedure:
Imports procurement involves a number of planned delivery costs like customs duties, freight and clearing agent charges. These costs need to be taken care in the MM pricing procedure.
While creating imports purchase order, the percentages for customs duties, freight & clearing agent charges are to be entered manually for every PO item. Also, the relevant vendor code has to be entered for each delivery cost - viz., customs house vendor for every customs duty pricing condition and freight/clearing agent vendor for freight/clearing agent condition.
This is a very cumbersome process for the buyer who creates the purchase order, since he has to navigate back and forth between the condition overview & condition detail screens in the purchase order to complete the entries.
The objective of this post is to present a solution which will simplify this process.

Typical pricing conditions involved in imports:
Client procures certain assemblies and components from vendors abroad. For this purpose, they wanted to create purchase order on the imports vendor. Like in any imports purchase, there will be customs duties and delivery costs like freight and clearing agent charges.
The imports pricing procedure contains the following typical condition types:
                   
Condition Description
Condition
Type
Calculation Basis
Default vendor while creating PO
Actual Vendor to be assigned
Basic Price
PB00
To be entered by buyer
Material vendor
Imports vendor
Customs Assessable Value
JASV
110% of PB00
Material vendor

Basic customs duty
JCDB
10% of ZASV
Material vendor
Customs House vendor
Counter-veiling duty(CVD)
JCV1
10% of (ZASV+JCDB)
Material vendor
Customs House vendor
ECess on CVD
JECV
2% on JCV1
Material vendor
Customs House vendor
SHE Cess on CVD
J1CV
1% on JCV1
Material vendor
Customs House vendor
ECess on Basic customs
JEDB
2% on (JCDB+JCV1+JECV+J1CV)
Material vendor
Customs House vendor
SHECess on Basic Customs
JSDB
1% on (JCDB+JCV1+JECV+J1CV)
Material vendor
Customs House vendor
Additional Duty of Customs (ADC)
JADC
10% on (ZASV + JCDB + JCV1+JECV+J1CV)
Material vendor
Customs House vendor
Freight charges
ZFR1
2% on PB00
Material vendor
Freight vendor
Clearing Agent Charges
ZCLG
1% on PB00
Material vendor
Clearing agent


Buyer has to fill in the percentages for the10 different condition types mentioned above. Assuming
there are 10 items in the PO, buyer would have to make 100 entries for the percentages only. 
Buyer would also have to reassign the vendor codes for customs duty and delivery cost condition
types. By default, all condition types in the PO item will be assigned the material vendor in the
conditions tab.  
If the PO is processed as such, then during MIRO invoice verification, only the
material vendor will be proposed for all these conditions. Finance person who is doing the invoice
verification will have to change the vendor during MIRO to account freight/clearing agent
invoice.  When the number of PO items is high, MIRO screen displays a number of line items and it
becomes difficult to navigate and verify only customs duty or only freight.

Solution overview:

  The proposed SAP solution will default the duty and delivery cost percentages for all the relevant     
  condition types of PO items and also default the relevant vendor code for these condition types.
  The proposed solution consists of the following Steps:
·       A new access sequence is created for delivery cost conditions and assigned to each of the customs duty, freight and clearing charges condition types. This will enable appropriate rates/percentages to be defined at the Purchase Org. level.
·       Condition records are maintained for each customs duty condition at the Purchase Org. level so that any imports vendor assigned to this Purchase Org. gets this default duty rate.
·       While maintaining the above-mentioned condition record master, the relevant vendor code is assigned to the condition type. This will default the vendor code for the condition type in the PO.
Configuration & master data setup:
No.
Process Step
Description
1.
Create new condition table
A new condition table (eg. 801) is maintained using configuration tcode M/03 (Maintain condition tables). This will be at the level of “Purchasing Organization”
2.
Create new access sequence
A new access sequence (eg. ZCUS) is created using tcode M/07 using the condition table created in step1.
3.
Assign this access sequence to condition types
The new access sequence is assigned to each customs duty condtion type, freight condition type and clearing charge condition type using tcode M/06.
4
Maintain condition records
Using transaction MEK1, maintain condition records for condition types ZASV, JCDB, JCV1, JECV, J1CV, JEDB, JSDB, JADC, ZFRT and ZCLG, as per the rates mentioned in the pricing procedure table.  Also assign the customs vendor code for customs duty condition types, freight vendor for freight condition type and clearing agent vendor for clearing charges condition, in the details screen of MEK1.

When we create the imports PO, buyer needs to enter only the basic price.
System automatically defaults all the duty percentages and also freight and clearing charge percentages for the respective conditions, from the condition records, as explained above.
System also defaults the vendor code for customs duty and freight/clearing charges.

Process Steps in detail with screenshots:

Below screenshots serve to illustrate the points:

Step1:  Create new condition table  (for eg. Table# 801) in tcode M/03 @ Purch.Org level – all duties and delivery costs will be captured at Purch.Org level. This will ensure that all the condition records are maintained only once for the entire Purch.Organization.


Step2: Create new access sequence (for eg. ZCUS) using tcode M/07 and assign the condition table to this new access sequence.

Step3:Assign the condition table to access sequence.
Assign the default value for Purch.Org, if required, in the field catalog screen.

Step4: Create condition records for duties and other delivery costs, in tcode MEK1. Enter rates and validity period.
For eg. JCDB condition type for basic customs duty – enter Purch.org, maintain rate (eg.10%), validity start and end date.

Step5:  In the details screen of MEK1, assign vendor code for customs house vendor (in this case vendor # 302760) and save.

Repeat steps 4 & 5 for all customs duty, freight and clearing charges
condition types.

Step6: Create purchase order in ME21N for the imports vendor.
Enter material number, PO qty, basic price and plant.

Step7:Check conditions tab for the PO item.
The imports pricing procedure is invoked by system and systems defaults all duty and delivery costs rates (percentages) as per condition records maintained in steps 4 & 5.
Verify the rates. Finally, go to details screen of condition type by clicking the “Condition details” icon and check the vendor. Please note that system automatically defaults the vendor code for the delivery cost.

Hope the above post is useful to you.
Please feel free to give your feedback, comments or questions.

Regards
Prabhu S

Monday, 2 September 2013

Physical inventory procedure with Warehouse Management

Hello friends,
Through this post, I would like to share with you the procedure to do physical inventory in SAP, when warehouse management is involved.

Let us first begin with a comparison between pure Inventory Management(IM) scenario & Warehouse Management(WM) scenario:
1. In IM scenario, physical inventory is carried out at the storage location level. Whereas, in a WM scenario, it is carried out at the storage bin level.
2. In IM, any stock differences found as as result of physical inventory is cleared through one step in IM module. Whereas in WM, it is first cleared in 2 steps, first in WM, and then in IM.
3. The transactions for IM are MI01, MI21, MI04, MI20 & MI07.  Whereas for WM, the transactions applicable are LI01N, LI02N, LI04, LI11N, LI20 & LI21.

There are various methods of doing physical inventory; they are:
1. Annual inventory (done at the year end)
2. Cycle counting (with A/B/C classification and counting intervals for each class)
3. Continuous inventory (wherein PI is triggered automatically when an empty bin is loaded with stock or when a bin becomes empty) and
4. Manual inventory

We will see how the manual inventory method works with WM.
The manual inventory requires all transactions are to be executed manually. Because it is manually done, the scope is usually restricted to a few storage bins/materials.

Let us look at the IMG settings that are required:
The 1st IMG setting is the defaults for storage types: here we maintain the default values like tolerance for differences, material display in warehouse list, bin display while counting etc.

Next settings is the inventory method per storage type: Here we define the default PI method per storage type. In our case, it would be PZ.

Next setting is for movement types for differences and limit for number of document items.

Next is the setting for clearing difference movement types for each stock type:

Next is the setting for allowing difference posting.

 Next is the number range for PI records:

Next is the parameter for foreground/background execution of PI transactions:

After having done the above IMG settings, we will now see what are the preparations for doing the physical inventory.

1. Identify bins and materials to be inventoried using txn. LX03
2. Process/Close Open Transfer Requirements for the concerned materials using txn. LB11
Use the option Create TO in background to process the posting change.
3. Process/Close Open Posting Change Notices for the materials using txn. LU04.  
Use the option Create Transfer order. If system gives error, go to LU02 and change status of posting change to Processed.

4. Confirm Open Transfer Orders for the material using txn. LT24
Use option confirm TO in the background.

Finally, we get down to doing the actual physical inventory.
Th
Step1:  Record stock before physical inventory:
a. Record WM bin stocks using txnLX03  (make note of available stock)

b. Record IM S.Loc stock using txnMB52  
Make note of unrestricted use stock

Step 2. Create Physical inventory record
    Transaction LI01N

Step 3: Activate physical inventory record – Txn LI02N
Inventory active (IA) indicator set for quants – transaction LX03

Step 4: Print Warehouse Inventory List  Txn: LI04

Step 5: Enter count results
 Transaction LI11N
    • Enter physical count in the “Counted qty” column
  • Check the “zero” indicator if the bin has zero stock


• For zero stock item, system gives additional message,  press Enter to proceed.


4.   Step 6: Clear differences in WM -txn LI20

View list of differences in the report.

Verify count information for each difference item

Write off differences for each bin, after verifying the count information

After the above step, Transfer Orders generated in the background, only for the difference quantities in LT22  (TO by storage type).

Step 7: Clear differences in IM - txn  LI21
PI differences are stored in storage type 999 & storage bin = Inventory record number
Specify the warehouse, storage type = 999 and storage bin = “Inventory record #”

Differences are shown in available stock, but with opposite sign
Material without differences not shown
Select storage bins and click “write off” icon
Material document posted
Accounting document gets generated

Step 8: Verify stocks after Physical inventory
• WM stocks using LX03 – confirm that bin stocks have changed as per PI
  Zero stock material has vanished from the list
  Inventory active indicator has been unchecked as before
Verify IM stocks using MB52
Confirm that unrestricted stocks have changed in Storage location as per physical inventory

Some other useful transactions:
a.Transaction LX22 –  using this single txn. we can
activate PI
print  PI
write-off  differences in WM

b.Transaction LI14  -  Recount

Hope this post was of some use to you.
Please share your feedback / comments about the same.
Thanks & Regards
Prabhu

Sunday, 1 September 2013

How to schedule an SAP program as background job

Many times, organizations need to run SAP programs on a periodic basis for eg. Automatic PO creation from PR, MRP, stock replenishment report etc. Instead of executing them manually everytime, it makes sense to schedule them as background jobs, so that system will trigger their execution at the scheduled time.  In some other cases, there may not be any periodicity required for a program, but due to the sheer time that the program takes to complete, it may be desirable to have system execute it in the background and user can later check the results or output of the program.

In both the above cases, we can schedule the program for background execution.
To do so, please follow the below steps:
1. Execute the program in SE38 or start the transaction from the SAP command prompt.
2. From menu, choose "Execute in background".
3. SAP will show a screen where the options "Immediate" & "Periodic".
If you want to immediately start the background job, select "immediate".
Otherwise, choose "Periodic" and select the periodicity for eg. "Once every 1 hour" or "Once a day" whichever is required and continue.
4. SAP will ask for the device for output of the program/report. Specify the printer.
5. Save the background job settings.

To check for the progress/status of the job,
1.Start transaction SM37.
2.Specify program name/job name , date/date range.
3.Specify status to be included eg. Scheduled, completed etc. & execute.
3.SAP shows a list of jobs that meet the criteria.
4. If the job execution has been completed, it shows status as "Finished" in green.
Otherwise, it shows an appropriate status as "Waiting"/"Cancelled" etc.
5. To know more about the job status, click on job log.
    Job log shows whether the program has run successfully or had errors.
6. To view the output of the program/report, click on "Spool".
    If the program has generated an output, will show the spool request.
    Select the spool and click on "Display" icon to view the spool output.

How to block MRP Controllers in SAP Material Master

Hi,
In my previous blog, I had explained how to block/unblock purchasing groups in material master. In this blog, I will explain how to do the same for MRP controllers.

Business scenario:  As you might be aware, planners in an organisation are assigned to a MRP controllers in SAP.  In due course, a planner may get transferred to another department or may leave the organisation. In such a scenario, the MRP controller assigned to him should not be used anywhere in SAP. For example, the particular MRP controller should not be assigned to any new/existing material in the material master. How to achieve this?

Solution & Implementation:
The requirement can be achieved using setids and a BADI enhancement.
1. Create a new setid with a suitable name for eg. "BLOCK_MRP_CTRLR_XXXX" using transaction GS01. Here XXXX is the name of the plant. Please note that MRP controllers are plant specific and therefore maintained separately for each plant.
Specify table = MARC, field = DISPO and "Basic set" radio option. In the details screen, give a suitable short text (description of the setid) and in the from-to fields, specify single values/ranges for MRP controllers to be blocked.
2. The next step is to write ABAP code to check the value of MRP controller in the MRP view of the material master. This validation can be performed  at the time of saving the material master. The badi "BADI_MATERIAL_CHECK" can be used to perform to perform this validation. Create a new implementation with a suitable name for eg. "ZBADI_MATERIAL_CHECK" under this BADI.  The necessary code to validate the MRP controller can be written in the method "CHECK_DATA". The code will basically check if the value of the MRP controller has been changed and whether the new value is in the  blocked list. If it is in the blocked list, then program should throw an error message.
3. To unblock an MRP controller, go to transaction GS02 and call the setid "BLOCK_MRP_CTRLR_XXXX" and delete the entry for the MRP controller. Unblocking would be required if the blocked code is to be released and reassigned to another planner.

Cheers !

How to block purchasing group in SAP material master

Hi,
Are you an SAP MM consultant assigned with the task of blocking specific purchasing groups for use in material master of SAP?
Don't worry. I'll explain how to achieve this in this blog.

Business scenario:  As you might be aware, the buyers in an organisation are assigned to a Purchasing Group in SAP.  In due course,a buyer may get transferred to another department or may leave the organisation. In such a scenario, the purchasing group assigned to him should not be used anywhere in SAP. For example, the particular purchasing group should not be assigned to any new/existing material in the material master. How to achieve this?

Solution & Implementation:
The requirement can be achieved using setids and a BADI enhancement.
1. Create a new setid with a suitable name for eg. "BLOCK_PURCH_GRP" using transaction GS01
Specify table = MARC, field = EKGRP and "Basic set" radio option. In the details screen, give a suitable short text (description of the setid) and in the from-to fields, specify single values/ranges for purchasing groups to be blocked.
2. The next step is to write ABAP code to check the value of Purchasing Group in the Purchasing view of the material master. This validation can be performed  at the time of saving the material master. The badi "BADI_MATERIAL_CHECK" can be used to perform to perform this validation. Create a new implementation with a suitable name for eg. "ZBADI_MATERIAL_CHECK" under this BADI.  The necessary code to validate the purchasing group can be written in the method "CHECK_DATA". The code will basically check if the value of the purchasing group has been changed and whether the new value is in the  blocked list. If it is in the blocked list, then program should throw an error message.
3. To unblock a purchasing group, go to transaction GS02 and call the setid "BLOCK_PURCH_GRP"and delete the entry for the purchasing group. Unblocking would be required if the blocked code is to be released and reassigned to another buyer.

In a similar manner, the MRP controller (planner) could also be blocked for use in material master. I will be explaining this in a separate blog.