Tag Archive for 'SD'

This post is an extension to a previous post on Credit Checks exceeded. When you are in a testing environment it is common that it’s difficult to quickly process sales orders and/or deliveries because the credit check is exceeded for a customer. Credit is building up, since so many sales orders and deliveries are entered but are usually not going through the whole process including payment processing. To quickly clear a blocked order got to transaction VKM1.

VKM1 – Blocked SD Documents

In the main screen enter a common criterion like Credit account (usually sold-to) and hit the execute button (F8). In the report screen that follows, select the document to be unblocked and press the green flag button followed by saving the approval. Now you can continue processing the order or delivery.

In some cases it may be necessary to exclude a storage location from ATP (and MRP). This is often the case at companies who e.g. keep inventory on materials that are stored in a well-sized showroom. How you can block a storage location for MRP, I explained in an earlier post. This will give you some pointers on blocking for Available-to-Promise.

I’m working in a business process where a sales orders requirement date should never be transferred to MRP with the original customer’s requested date.

Example: at the time of order entry ATP bounces the requested delivery date, since product is not available at the time. The system suggests a new date for confirmation. The customer at this time has the option to agree to the new proposal or a sales order will not be entered. I want this new committed date transferred to MRP.

To do this I select the ‘Fixed date and quantity’-indicator in the Schedule lines tab in VA01. As in my case this should always be the case, in customizing I choose this as a default setting for the specific SalesArea(IMG > Sales and Distribution > Basic Functions > Availability Check… > Availability Check > Availability Check with ATP… > Define Default Settings)

VA01 – Fixed date/qty indicator

Without setting the indicator you are basically suggesting that production can still catch up with this additional requirement and the customer’s original requirement date will be transferred to MRP. See also SAP Help.

Using a test environment that is due for a refresh I run into credit limits when entering sales orders more than often. Manipulating the credit check for a customer in FD32 is not always sufficient. The following reports also are useful (if not essential):

RVKRED06 - Background jobs for checking blocked credit management.
If an order is no longer outside the horizon as defined in the dynamic credit check, (i.e. it is INSIDE the horizon) it can cause existing “good” orders to block. If you run this job every night, if you have your horizon set for 1 month it can cause a lot of blocks at beginning of month. Try to use ‘W’ for weekly horizon status.

RFDKLI10 – Customers With Missing Credit Data

RFDKLI20 – Reset Credit Limit for Customers

RVKRED77 – Reorganize SD credit data
When updating errors occur, it enables you to reorganize the open credit, delivery and billing document values.

RVKRED08 – Checking sales documents which reach the credit horizon
You should runs this report periodically, usually at the start of a period. The report checks all the sales documents, which reach the dynamic credit check horizon. The period for the ‘date of the next credit check’ is proposed from the current date, with the help of the period split for open sales order values.

(Courtesy of SAPTechies)

If you prefer the quick way of unblocking the one sales document go to this post.

According to SAP when inbound deliveries are used and your delivery item category is set up for mvt type 101, these should be received with transaction VL32N. If you use MIGO/MB0A instead, the GR status in the delivery will not be updated. If you then report on open deliveries you’ll notice that nothing is received in the course of time. Amazing. Now if you set up the delivery item category without the movement type your inbound will not even be GR relevant. Just one of these things that’s nice hugely critical to be aware of.

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

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;

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 .