Delivery Due List

[former_member562353]

Hi,

I have two problems in delivery due list for SD:

1- I have a sales order for which I can create outbound delivery manually using VL01N; however, this sales order is not showing up in delivery due lists such as VL10C and VL10G. I have checked the status of the order. There is neither a shipment block or credit block for this delivery. Moreover, all the schedule lines of the order items are confirmed.

2- I have several orders for which there is credit block; however these orders are showing up in the delivery due list. Despite the fact that system dose not allow creating the delivery due to credit blockage, their existence create a lot of problems for our dispatch team.

Is there any configuration to prevent this behavior in the system?

Any comment will be appreciated!

Thanks,

Amir

[VeselinaPeykova · Accepted solution]

Regarding the orders not appearing in VL10* transaction:

Is the issue isolated to a specific business process - if yes, please share the sequence of business steps.

A couple of things to check - are there any delivery blocks for the order? If yes, check the settings for the delivery block -if it has DDueList = 'X', but does not block confirmations, it will not appear in VL10* but you can still create a delivery via VL01N.

Does the order appear in VEPVG?

Do you get any mesages for incompletion or a problem with delivery groups whan you create the delivery via VL01N?

I believe you have already checked whether there is any filter applied for VL10* and have eliminated authorization problems.

Regarding orders blocked for credit appearing in delivery due list:

What kind of credit check are you using - simple credit check or automatic credit control?

Please check OVB9 - what is the routine assigned - in case it is not a standard one, please share the logic.

It could be also that the two problems you mentioned share a common root cause.

If both issues can be reproduced in a sandbox system - does running report RVV05IVB for such documents resolve the problem? If yes, I would definitely suggest to check for recent developments resulting in modification of the delivery due index.

[former_member562353 · Accepted solution]

Dear Vaselina,

Thanks for your kind answer.

Regarding the orders not appearing in VL10* transaction:

The issue is about a simple order to cash process that starts with sales order.

There are no delivery blocks for the sales order. I also have checked VBUK for the order and all the credit related statuses are OK. Where can I check DDueList for the 'X' value?

The order is not in the table VEPVG.

There is no message when I create delivery with VL01N except there is no stock available for some items (which I believe has nothing to do with this issue).

Regarding orders blocked for credit appearing in delivery due list:

We are using automatic credit control

There is no requirement for Delivery Due Index in OVB9 as depicted in the figure below:

Running the report you have mentioned fixed the first problem but had no effect on the second issue.

[VeselinaPeykova · Accepted solution]

DDueList = 'X' is a setting for delivery blocks, so it is not relevant in your case (Define Reasons for blocking in Shipping).

Orders not appearing in delivery due list

You mention that you received a message that some items have no available stock. In case all your items are BOM-relevant and for some of the subitems there is no available stock, the delivery cannot be created via VL10A, but it can be created via VL01N (standard system behaviour). It is possible to restrict delivery group from processing in VL01N via a modification, but the idea of using VL01N is that it is granted to knowledgeable users, who understand the consequences of not delivering all subitems for a certain BOM material.

Since you mentioned that after the index was regenerated, some orders appeared in VL10*, it is still a good idea to check whether you have implemented some user exits that mess up the delivery due index. In case you are able to reproduce the case in a test system, I would suggest to ask a colleague from the development team to assist you in checking for inconsistencies.

Orders blocked for credit

It is very strange that you do not have a requirement assigned in OVB9. Please assign routine 104 and retest with a new set of documents. In case this problem gets resolved, please check with the solution architect and with the business whether the logic in routine 104 fulfills the company requirements and whether it could impact negatively some company-specific process.

[former_member562353 · Accepted solution]

Thanks Vaselina,

Here are some points regarding your comments:

Orders not appearing in delivery due list

The items in the order are not related to each other in term of BOM. They are all finished products that are sold separately. I am a functional consultant and I should ask a technical consultant regarding any user exits that may be used for this purpose.

Orders blocked for credit

It is also strange that there is no requirement for delivery due list. Maybe the development team somehow wrote some codes in the background to fulfill this requirement. In our IDES system, the requirement that you have mentioned is defined.

[VeselinaPeykova · Accepted solution]

You may be right, if they execute the same or similar logic in the background, probably they have considered routine 104 as obsolete.

Unfortunately if your company does not keep up-to-date information on the customer-specific developments in a repository - asking a developer for assistance could be the the fastest and most efficient way to find the root cause.

In case the problems appeared recently and it is not right after an upgrade project or a major development import, it might be good to check whether somebody implemented a sap note that could result in unexpected behaviour of the custom logic. In an ideal world a sap note implementation would not have an impact on user exit logic, but it happens.

[michael_kozlowski]

In trx. VL10C/VL10G tab. 'User Role' check setting of 'Role'.

[former_member562353]

Dear Michael,

Here is the role setting: