Difference between MRP Type PD and VB

Depending on this field , the behaviour of MRP will be completely different.When you work with PD, you work with BOM structures.

Imagine the final material A , and its component B you need 2 pieces of B to produce 1 piece of A.If you work with PD and you receive for example a sales order for A of 10 pieces , the MRP with PD will determinate that you need 20 pieces of B taken into account the sales order delivery date. The system will use the BOM to know the quantity that you need. You will not have additional stock for the component B. The system will procure when and how many pieces you need.

IF with the same example you work with VB for component B, then you have to define a reorder point (example 5).

If your stock is bellow that level ,the system will procure to get again the reorder point level. If you have enough stock (example 30) the system will not create any purchase requisiton for B, independent of the sales orders of A , and the reservation of 20 pieces.

When yuo work with expensive components you should use PD , because you don´t have stock without pegged requirements. if the materials are cheap and you need to have allways some stock , you can define VB as planning type.IF you use ND. the component B will not be planned, that means the MRP will not create any planned order or purchase requisition to cover requirements. you have to create manually.

What are different MRP types?

The differnt types of planning procedures are
1. MPS - Master Production Scheduling
2. MRP - Material Reuquirements planning
3. Consumption based planning - (there are two types)
   i) Forecast based planning
   ii) Reorder point planning
       a) Manual Reoderpoint planning
       b) Automatic reorderpoint planning

Configure SAP Payment Terms

SAP payment terms function as determiner of when a receivable from customer and a payable from vendor is due for collection/due for payment. Moreover, it function also as determiner when is a discount availed/granted and how much is the discount.

The default payment term of an individual customer or vendor can be maintained in the master record. The maintained payment term in the customer/vendor master record is the default payment term during posting of invoices. The default payment term can be changed during transaction entry, if a different payment term is more appropriate.

Some companies using SAP have complex payment terms.

Scenario example:

• Invoices posted on or before the 25th of the current month should be payable on the 25th of the following month. And, invoices posted after the 25th of the current month should be payable on the 25th of the NEXT NEXT month.

To explain the scenario above, an invoice has issued on August 24, 2009. The payment due date should be on September 25, 2009. Another invoice has issued on August 26, 2009, the payment due date should be on October 25, 2009.

To cater the payment term in the above scenarios example, just follow this simple procedure.

Path: SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business Transactions → Outgoing Invoices/Credit Memos → Maintain Terms of Payment.

Transaction code: OBB8

You need to create 1 payment term with different day limit (25, 31).

1. Day limit 25, additional months 1

2. Day limit 31, additional months 2

After saving the above configuration, you may now test the new payment terms. For sure, the above payment term scenario is resolved.

Source: http://www.sap-knowledge.com/archives/2816

Account xxxxxx requires an assignment to a CO object

Message no. KI235

“Account xxxxxx requires an assignment to a CO object”.

Diagnosis and Analysis:

The G/L account you are posting to is relevant to cost accounting, however you’ve not assigned or defined a CO account assignment.

If you’re posting manually to any accounts which are relevant to cost accounting (meaning cost element accounts) and overlooked to assign a cost object, the above error occur.

For automatic posting, such as depreciation of fixed assets, internal order settlement to a g/l account, and etc, the above error occur if the the system could not find any cost objects assigned to the cost elements used. The system will look into the IMG for configured cost objects default, if non to substitution rule if applicable, if non still to cost object maintained in the cost elements master data.

Solution:

1. If you’re posting manually, always assign the line item posting to a relevant cost objects (e.g. cost center, order, profit center).

2. For automatic posting transactions, you need to maintain in the system default cost object assignment of the cost element. Follow this simple procedure:

Transaction Code: OKB9

Path: IMG → Controlling → Cost Center Accounting → Actual Posting → Manual Actual Posting → Edit Automatic Account Assignment.

 The “Chage View “Default account assignment: Overview” appears. Enter the company code, cost element, and default cost object. The cost object could be a cost center, internal order or profit center.

Account assignment

During automatic posting to the cost element, the system get the assigned cost object. The above error “account xxxxx requires an assginment to a cost object” would not occur.

User Exit for Delivery (STO and SO)

Inorder to customize the behavior of delivery functions we need to write codes in the following modules:

Program name: SAPMV50A
Include File: MV50AFZ1

SAP .NET Connector or SAPLink Logon Problem

Always use SAP logon details such as client, userid, password, and language in all capital letter when using .NET to connect to SAP using .NET Connector or SAPLink.

Tools provided for ABAP Performance Analysis

Courtesy: thespot4sap

Following are the different tools provided by SAP for performance analysis of an ABAP object

1. Run time analysis transaction SE30

This transaction gives all the analysis of an ABAP program with respect to the database and the non-database processing.

2. SQL Trace transaction ST05

The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.

The trace list contains different SQL statements simultaneously related to the one SELECT statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated component of the R/3 Application Server - maps every Open SQL statement to one or a series of physical database calls and brings it to execution. This mapping, crucial to R/3s performance, depends on the particular call and database system. For example, the SELECT-ENDSELECT loop on the SPFLI table in our test program is mapped to a sequence PREPARE-OPEN-FETCH of physical calls in an Oracle environment.

The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP statement. This is because in an R/3 system, a client is a self-contained unit with separate master records and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open SQL statement automatically executes within the correct client environment. For this reason, a condition with the actual client code is added to every WHERE clause if a client field is a component of the searched table.

To see a statement's execution plan, just position the cursor on the PREPARE statement and choose Explain SQL. A detailed explanation of the execution plan depends on the database system in use.