Monthly Archive for October, 2008

Page 2 of 3

Recovery of SD requirements for MRP

At some point in time sales and delivery requirements may get out of sync due to maintenance resulting in planning errors. Usually these errors are found when going through MD04. You will typically find deliveries (collective requirements) that cannot be traced back to original delivery documents.

The proper solution for this is to run report SDRQCR21 (via SE38):

Program SDRQCR21

Program SDRQCR21

  • select the material and plant you wish to run the correction;
  • select the option data transfer when you actually wish to run the correction on the database;
  • select compare always in order to improve performance. Without selecting this the whole database for material/plant will be regenerated;
  • select planning entry to ensure the material is included in the next MRP run;
  • the option Processing per material results in a different log.

After this your MRP overview should be back in sync.

Form design: standard texts

Transporting SapScript Texts created in SO10 can be a mystery.  Transport of these texts to other clients is done using program RSTXTRAN (SE38). Here you can attach the text objects to a previously created transport.

Transport SE10 SapScript texts

Program RSTXTRAN

If you are wondering what you can use these texts for: you can create dynamic text fields that are used by custom made forms. You can create one standard SmartForm that refers to a text item you created in SE10. When the text in the future requires a change you don’t need a programmer to modify hardcoded text in the order form. You can just modify the text in SE10.

EU membership

Sometimes it may be necessary to build a custom solution to check the European Union-membership status of a country. For example for tax purpose you want to identify on the basis of sold-to whether the customer is in the EU. Check the country code from the address of this customer with the EU membership field (XEGLD) in T005 .

Copy price from purchase requisition to purchase order

SAP does not standard copy the price from Purchase Requisition to  the Purchase Order. It is either the price from contract (if referenced), material master, Inforecord or a previously created PO. To enable SAP to take the price from the PR you should create a function authorization profile in customizing:

1) in SPRO go to Material Management > Purchasing > Authorization Management > Define Function Authorizations for Buyers. Then select Function Authorizations : Purchase Order. Here you can define/restrict what a buyer can do in a PO. Make sure that “Order price adoption” is selected.
Order Price Adoption

Order Price Adoption


2) Also you have to assign the Function Authorization you created to a user. Enter the key as a parameter under the parameter ID EFB in the user master (SU3).
User Profile Parameters

User Profile Parameters

3) Now you are set to go. These settings allow the buyer to select in the PR that the price is taken over in the PO. This is a selection in the valuation tab on item level in ME51N. It is not defaulted!
ME51N - PO Price

ME51N - PO Price

Transaction variant

Lots of clients who wish to make their SAP transactions dummy-proof by making fields mandatory, closing fields for editing or craving for default values. Different paths to Rome here, but one powerful solution being offered through transaction SHD0 in conjunction with SE93. The first transaction allows you to create a transaction variant where it is possible to hide fields, make them mandatory, add default values, add voice recognition, opt for world peace, etc. OK so the last two maybe not, but the message is: “you can do a lot of modifying here.” The second transaction SE93 allows you to link the variant to a new home made transaction code. Your customer will love you till the end of times because of this.

Inventory Information System

I bet that if half the SAP end-users knew what wealth of stock information is stored in the inventory information system in SAP tons of money could be saved on custom reports (either R/3 or BW). You can find some cool KPIs in there: a.o. stock turnover, dead stock analysis, slow movers, ABC-analysis. Some fundamental data to actually control your stock levels and improve your bottom line by turning stock into (investment) cash. The information system can be accessed from the main menu with transaction code MCC1. Somehow it’s not accessible when in a transaction using \n. On a critical note: it is worth checking the correctness of some reports, especially time-phased stock reports may show some funny data. At some point in time “die Leute” at SAP thought they could build a business model around providing a separate information system like BW and don’t spend too much effort on the R/3 info system.

User defined fields (UDF): change/edit

Problem we ran into today: we added a couple user-defined fields in the customer data tab in ME21N – Purchase Order. This worked fine, but we found that when in transaction ME22N after we saved the changes in these fields, the fields themselves would still be editable. Also going to a purchase order in ME23N, the UDF would always show as editable fields. After a search we found that function MEPO_DOC_GET_TRANSACTION_STATE was able to return the transaction state (I_TRTYP) that is required to tell the system to lock or unlock the new fields.

Maintain posting periods

“Posting only possible in periods 2008/10 and 2008/09 in company code…”.

This is a typical error when you are working in a test environment. This will be job controlled in a production environment and should never be an issue there. It means that the fiscal period (the previous month) is not closed yet. You are probably trying to post a goods movement in the new fiscal period/month. The system will not stand for this kind of behavior! First you have to close the previous period. You can use transaction MMPVClose Period for Material Master Records to close the previous period.

MMPV - Close previous period

MMPV - Close previous period

When you are in a test environment you don’t really care about checks and balances: tick the button Close period only. This will get SAP into the new period without any problems.

And to check the current period for your company use OMSY. This will help you determine what the next period is to fill out in MMPV. Your Finance colleagues can tell you what the current fiscal period is. Usually the periods follow the calendar month logic. It is also possible that the fiscal year is determined otherwise.

OMSY - Active period

OMSY - Active period

Especially in test environments that are hardly ever used periods may not have been closed for months. In this case you have to close each period one-by-one.

Edit SAP tables

No matter security on table editing. When in transaction SE16N use the command &SAP_EDIT in the command field in SAP and off you go: edit table content directly.

Know what you are doing cause this is far from a best practice way of changing data and can screw up things pretty bad if you don’t really know what you are doing. If the value that you wish to change is a dependent variable to another (background) process stay clear of this method. If you are not sure – seriously: don’t edit the table content.

See my other post on how to track change by people who edited tables with this method.

Step-by-step

1) Go to transaction SE16N or alternatively use shortcut and type just ‘N’. Enter here the table that you wish to edit.

SE16N or just N

SE16N or just N

2) In the command field enter ‘&SAP_EDIT’ and press enter. The maintenance indicator in SE16N will switch on.

Command field entry

Command field entry

3) Narrow your search results by entering selection criteria and press F8 to run the report.

4) You can remove lines or just add/change data and press save.

&SAP_EDIT - SE16N - Table results

&SAP_EDIT - SE16N - Table results

Voila! You just hacked your way into the table structure and made some changes.

Update 05-Oct-2009: interesting comments made on this hack: blog on IT toolbox

Transaction usage history

A very useful tool to track usage of transaction: ST03N and STAD. This transaction can report on different levels how often a specific transaction is used and by which users. This can be handy in determining authorization profiles after Golive. It can also be used by Big Brother to check whether end user testing has really taken place.