Skip to Content
avatar image
Former Member

Handling Unit in STO scenario.

We have a STO scenario where a Handling Unit is shipped out (GI-ed) from the sender and has to be received (GR-ed) at the receiver.

As per standard SAP functionality, the Handling Unit will go to Posted Status on Goods Issue against the Outbound Delivery and cannot be re-used/packed in the Inbound Delivery during Good Receipt.

What could be a way around this? The only option I can think of is delete the HU's records from VEKP and VEPO tables after GI (using SE16 debug/edit) and then recreate a new HU with same external number (VEKP-EXIDV) and use that to pack the Inbound Delivery.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Dec 26, 2014 at 04:04 AM

    H S Roy, what error do you see when you try to manually pack the HUs on the inbound delivery? 

    We see the message "Handling unit has the status 'goods issue posted', cannot be changed."  But this is just an information message and does not actually impact our ability to pack the HU.

    Also, have you tried using the V2 SPED output type?  We use this output type in a STO scenario to automatically create and pack the inbound delivery with the shipped HUs.  It is processed after PGI.

    Add comment
    10|10000 characters needed characters exceeded

  • Dec 23, 2014 at 09:13 AM

    do you really think that (using SE16 debug/edit)  should be incorporated into a standard business case that can happen some thousand times in a year?

    Before you even consider table updates in production you should have tested such an entire process chain in your test system, and entire means for  me including data archiving, as I expect that you get an error here since your data is not consistent anymore

    by the way, is there anything wrong today in the forum, or did you remove the flag for question intentionally?

    Add comment
    10|10000 characters needed characters exceeded

    • Archiving means getting the unneeded data off your table space and storing it somewhere else in a content repository for audit purposes, this is done with a compression of about 5:1

      I would certainly not fear about space used for archiving, I am rather concerned about space needed because of not doing archiving.

      And my experience with archiving is that it is sensitive like a mimosa. If you do not test this part after your desired table change, then you may get in big trouble which may cost some extra money to get it solved.

      One workaround was discussed in

      You already created 2 discussions prior to this one, and they were created as desired. If you create your discussion without removing any defaulted ticks then it appears as question, otherwise it is a discussion/ an announcement which cannot have a single correct answer.