Delivery block on item (schedule line) is not getting removed when the schedule line is changed

[Former Member]

Greetings,

Recently we configured a new schedule line category with a delivery block in it. When ever this schedule line gets determined for a line, a delivery block gets updated on it. This is fine. But when that material is replaced with another material - Item category and its corresponding schedule line category gets re-determined. Even after re-determination of schedule line category, the delivery block which got updated earlier is not getting removed.

I believe when the schedule line category is changed then the delivery block should be removed automatically as the new schedule line category don't have the block in the configuration.

Attaching the screen shots for reference.

Please share your thoughts.

Thanks for your support.

AK

[andrea_brusarestelletti · Accepted solution]

Hello,

I just can confirm that this is the standard behaviour, according to my experience. I guess the technical reason is that the "Delivery block" is read only during the item creation, but not read and filled anymore when the "Schedule line category" type is changed. I think this behaviour has good explanation. Think about this scenario:

- you create a Sales Order line which triggers a "Schedule line category" type without delivery block;

- then you set manually the "Delivery block " at schedule line level;

- After that, you change the item category, triggering a different "Schedule line category" again without delivery block: in this case, what the system should do? Keep the delivery block since was set by the user, or delete the delivery block, since the new "Schedule line category" has no delivery block?

My suggestion is to use USEREXIT_MOVE_FIELD_TO_VBEP to update the delivery block at schedule-line level according to your own logic.

Best regards,

Andrea

[VeselinaPeykova · Accepted solution]

I tried also the exact opposite scenario:

1. Initially in the order there is a material A with item category ZTN and schedule line CP - no delivery block.

2. The material is changed from A to B, which triggers a new item category determination and as a result we get ZAR + schedule line ZZ (with delivery block 03).

When A is changed to B, the setting for delivery block for ZZ updates the schedule line from ' ' to '03'.

So maybe the idea is - they will only set delivery block once automatically, but will not clear or change the delivery block on schedule line level after item category re-determination once it is not initial.

This seems to be the standard behavior at least in my old sandbox - no access to a standard system newer than EhP 4.

If initially I have material B with schedule line block determined automatically and I change the material to A, then I get the same result as you - the delivery block is not cleared.

From what I saw, the correct settings for the new item category and schedule line are determined, including the delivery block, but later in FV45EFEP_VBEP_FUELLEN_TVEP an additional check is done if previously there was a delivery block set for this item and if yes, the ' ' is replaced with the old value - in my case 03.

I saw a very old note on 4.7 599624 - Change of the material number: Delivery block is retained, which mentions a similar case, the solution there is not relevant of course, now we have userexit_move_field_to_vbep as Andrea correctly pointed out, but I mention it because of the explanation provided, which could still be valid:

This is the standard system response. The system retains a delivery block because it does not know whether a redetermination is desired. Thus, the delivery block should be changed or removed manually.

I don't agree completely in this specific case, because schedule lines were determined automatically based on what material I entered, but at least the workaround in userexit_move_field_to_vbep will work.

I wonder if this is the same in newer versions.

One more thing - if you use a BAPI to change the order, it is a different story, I think.

[Former Member]

Thank you, we are proceeding with the userexit.