Profit center in the SD billing document

With sales document, the determination of the profit center is carried out in the sales document item according to the following rules (in ascending order):
1) From the material master (table MARC)
2) Via a substitution
3) By manual entry
4) From a “real” account assignment (profitability segment, cost center, and so on)

If billing is carried out using the external billing interface (function module GN_INVOICE_CREATE) via the communication structure (field KOMFKGN-PRCTR), following rule applies:

1) From the material master (table MARC, field MAEPV-PRCTR)
2) By “external” specification

In Conventional business process, the profit center is transferred from the sales document item (field VBAP-PRCTR) to the billing item (field VBRP-PRCTR).

In cross-company business process, the profit center is transferred from the sales document item (field VBAP-PRCTR) to the intercompany billing item (field VBRP-PRCTR) since the company codes of the document item and document header match in this case. The profit center is always deleted for the external billing document and a new profit center (the profit center of the billing document) is determined since the company codes of the document item and document header differ in this case. Redetermination is carried out using a substitution. Therefore, you must maintain and activate a substitution rule in Customizing for the profit center invoice (transaction 0KEL and 0KEM).

This concept ensures that a profit center that can be posted to in the company code of the document header is available for a document item.

Special case for cross-company business process:
If the profit center of the billing document (field VBAP-PCTRF) is already determined in the sales document item, this profit center is transferred to the external billing item.

Customer-specific adjustment can be achieved if you want to transfer the profit center in the billing document differently from the concept described, you use transaction VOFM to create a data transport routine RV60C6XX or you enhance the routine already in use as described in the attached solution proposal


Self Billing Procedure in SD

Self Billing Procedure in SD is the counter part of MM Invoicing through ERS (Evaluated Receipts Settlement)

When the customer receives a delivery from you, they price the materials based on:

  • Prices from the customer’s purchasing department
  • Differences between the delivery note and goods receipt
  • Differences due to the quality of the material, for example
  • Retroactive price adjustments

The customer uses materials and prices to prepare an invoice on your behalf that they send to you by Electronic Data Interchange (EDI). The system receives and converts this invoice into intermediate document (IDoc) GSVERF. It then forwards it to function module IDOC_INPUT_SBINV, which determines the reference delivery and items based on the internal delivery number, or external delivery number, sent in the external invoice.

In this self-billing procedure, you cannot create an invoice for the delivery: no original invoice exists. However, the system simulates invoice creation to determine internal prices and their conditions.

 Once the system has determined the reference delivery, and simulated an invoice, it compares condition values in these documents to those in the external invoice (in IDoc form). The system compares only those conditions specified in the IDoc and entered in Customizing.

 If the values in the external invoice match the values in the simulated invoice, and the delivery, the system creates an invoice in the R/3 System exactly as the customer has prepared it. Note that the system does not use the standard billing transaction here, but rather a special billing interface (GN_INVOICE_CREATE). The external invoice number, in the External number field, is used in the settlement process.

 If the system finds any differences in the values, it updates the IDoc status records, and sends a mail to the employee responsible. It continues processing the IDoc and, if no serious errors occur, creates the document anyway. The employee then informs the customer to send one of the following correction or retro-billing documents:

  • Credit memos for quantity corrections
  • Credit and debit memos for price corrections in retroactive billing
  • Cancellation documents

The system determines the invoices for these documents, along with the related deliveries, credit and debit memos, and cancellation documents.

If the values in the external credit memo (quantity correction) match the values in the invoice, and delivery, the system automatically creates a credit memo exactly as the customer has prepared it.

Credit or debit memo requests based on return deliveries, are treated just as credit memo requests for quantity corrections, except that the system carries out pricing only for those materials that are returned. Also, instead of comparing each condition value, the system determines an overall difference per item and compares it to the overall correction value.

In the case of retro-billing, the system reprices all documents in the transaction before comparing the condition values of the items. It calculates the difference between the old and new prices in the invoice and delivery, and enters it into condition PDIF to use in the pricing procedure. The difference calculated by the customer in the credit or debit memo is entered in the internal condition that you have assigned in Customizing. If these values match, the system automatically creates the credit or debit memo.

If these values do not match, the system sends a mail to the employee responsible, but creates the document anyway. If you do not want this, make the appropriate settings in Customizing for the sales document type.

Self Billing procedure through EDI  has process if the customer sends the vendor self-billing documents per EDI, they can be read and processed automatically by the vendor system. EDI processing enables a high level of automation and a low error count.

As a rule, the SAP system controls exchange of messages with other systems by means of logical messages. The message type for transmission of self-billing documents is SBWAP (Self Billing With Automatic Postings). The process code for this transaction is SBAP. This process code must be assigned to the partner profile. A partner profile is required for each partner involved in the process.

Some of important Notes on this topic are:

Commitments in Purchasing

Commitments are liabilities arising from contractual obligations incurred. A commitment is passed on to other applications for budgetary control purposes for purchase requisitions and purchase orders with account assignment only.

For knowing more details on this please click here.

Frequently asked questions and their answers can be located in Note 459509 – FAQ: Commitments in purchasing. You may need to log in to service marketplace to access this link.

If the value-based commitment indicator (global settings > application parameters of a unit of measurement) is set in Customizing, note that this setting does not apply to purchase requisition commitments; it applies only to purchase orders and GR/IR commitments. Purchase requisition commitments are always reduced on a quantity basis. This means that they are linked to the purchase orders only on a quantity basis.

Valuated GR Blocked Stock in SAP

From SAP Release 6.0, the valuated goods receipt (GR) blocked stock is available. Its use is subject to following restrictions:

  1. Subcontracting was not taken into account in the program design. Therefore, the component value (up to Enhancement Package 2) is incorrectly not included in the valuation of the ordered material.
  2. Valuated special stock was not taken into account. Therefore, you cannot use the movement types 107 and 109 with the special stock indicators E and Q.
  3. Split valuated materials cannot be managed in the GR blocked stock.
  4. Valuated GR blocked stock cannot be managed for non-valuated materials. Error M7 022 occurs.
  5. No serial numbers are provided for the valuated GR blocked stock. Therefore, the use of serialized materials in GR blocked stock is not possible.
  6. It is not expected that goods receipts are to be posted with a mixture of types 101, 103 and/or 107 within a purchase order item. This may result in incorrect checks with regard to ordered quantity or GR quantity.
  7. You cannot use materials with batch-specific units of measure (proportion unit or product unit of measure) The batch-specific quantity in the base unit of measure cannot be determined with movement type 107, because the batch can or must be entered only at step two with movement type 109.
  8. If you have posted movement 107 with reference to an inbound delivery, a batch split must not then be carried out in this inbound delivery. Otherwise, the release of the blocked stock (109) fails with error message M7 036 or M7 022 (EKLA-LWSBB).

For overcoming these restrictions please refer to OSS Note 1110140 – Valuated goods receipt blocked stock: Restrictions (FAQ)

Warehouse Management movement type 999

Warehouse Management movement type 999 (warehouse supervision) is not linked to Inventory Management and can be used as a template for movement types required ONLY in Warehouse Management. The settings in the master record of this movement type in Customizing for Warehouse Management allow manual creation of a transfer order (that is, without a transfer requirement or delivery as a reference document). You can enter the storage bin manually because you usually have to inform the system which bin stocks have to be moved to which location. The GR data in quant indicator is not activated because, generally, the original goods receipt data of the quant is not changed during a stock transfer. If you set the indicator, the creation date of the stock transfer transfer order would be entered as the (new) goods receipt date in the quant data record, as a result of the stock transfer.

Storage Section Indicator

Storage Section Indicators is an indicator that is used by the system to determine that a material is to be placed into one particular storage section in preference to another.  It is possible to define up to ten storage sections in priority order when defining strategies for storage section searches.

The storage section indicator performs a similar function as that of a storage type indicator (Stock removal and stock placement indicators used for storage type search) for the storage section search. If several materials should always be put away in a certain storage section,you define a storage section indicator as a “governor” and assign it to the storage section in an entry in the storage section search table. You can then enter the indicator in all of the relevant material master records.

MB51 Performance Improvement

The performance of MB51 / MB5B is seriously affected if there are extremely large number of MM documents in your system. The SELECT JOIN statement on the header and item table (MKPF and MSEG) is very demanding on system performance due to large volumes of data and the system takes a long time to get the list of material documents and sometimes it exceeds “timeout” time set by the basis team in RZ10 and ultimately it ends up with short dumps i.e ABAP Runtime error.

SAP off late has come out with some performance improvement features and re-designed MB51 by making some fields from MKPF available in MSEG and avoiding the SELECT JOIN statement. A Report (ZMST_FILL_MSEG_FROM_MKPF) has been designed to migrate data for the newly added field in MSEG from MKPF for old transactions. Note corrections ensure that the new fields of the table MSEG are updated in the same way as the fields in the table MKPF by each goods movement in the system.

Please refer the following Notes for this performance improvement.

  1. 1516684 MKPF fields added to MSEG – Performance optimization
  2. 1550000 MB51: Redesign of selection for performance optimization
  3. 1558298 MB5B: Redesign of selection to optimize performance
  4. 1567602 DB dependent steps to support the redesign of MB51
  5. 1598760 FAQ: MSEG Enhancement & Redesign MB51/MB5B

Following activities need to be taken for this performance improvement enhancement:

  1. Enhance the table MSEG by fields from table MKPF
  2. Implement correction instruction of note 1516684 to ensure update of new fields of table MSEG
  3. Implement report ZMST_FILL_MSEG_FROM_MKPF from note 1516684
  4. Perform data conversion using report ZMST_FILL_MSEG_FROM_MKPF to update existing MSEG records according to the values in MKPF as explained in longtext of note 1516684
  5. Apply note 1550000 for coding change in MB51, Note 1558298 for MB5B
  6. Apply manual steps of note 1550000 including creation of new DB indexes -> see note 1567602 for details about the indexes to be created

NOTE: The process steps are explained in details in the long text of notes 1516684 and 1550000 – See FAQ Note 1598760 for questions

Creating or Extending a material to multiple Organizational levels in SAP

In standard SAP it is not possible to create or extend a material to multiple organizational units (plant, sales org & distibution channel). You need to create your own customized object for this using BAPI or BDC or LSMW. In a limited extent, we can use MM17 for extending a material but not to the sufficient level of satisfaction.

However, SAP has come out with an add-on implementation which occurs in the Z namespace and can be carried out remotely in the respective customer system by SAP on consulting basis. Once a customer purchases this add-on from SAP, support is given free of charge for 6 months after implementation and subsequently any support on this is against consulting charges.

For more details on this, please refer to Note 1050643 – Material master copier