Skip to Content
avatar image
Former Member

Shipment creation (VT01N) gave number but it's not saved

Hello.

Im creating a Shipment on VT01N transaction in QAs. At time of saving, SAP display the normal message: "Shipment ### has been saved".

But inmediatly I received SAP Office Express info with the next message:

Update was terminated

System ID....   ECQ
Client.......   300
User.....   CPB
Transaction..   VT01N
Update key...   BA0145E43E94F1718272001E4F42C372
Generated....   25.09.2014, 17:18:20
Completed....   25.09.2014, 17:18:20
Error Info...   Modo interno cancelado con un error en tiempo ejecución (véase ST22)

I already check tables VTTK & VTTP and document was not saved, also I verified my shipment number ranges .... after I save the shipment the "Current Number" increases 10 numbers, but in VTTK nothing is saved.

If I try to create new shipment, the inbound delivery is selectionable...

I believe that is an incongruence with the number ranges, but I'm not sure how to verify this....

Thanks!

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    avatar image
    Former Member
    Oct 01, 2014 at 02:14 PM

    Thanks all for your help...

    Yes, indeed it was a number range problem.... but with 3 different ranges!

    For futher uses or people who have the same issue, this is what I had to correct:

    • Shipment Number Range (VN07)
    • External Handling Unit ID range (HUEX)
    • Shipping Units range (VNKP)
    Add comment
    10|10000 characters needed characters exceeded

  • Sep 26, 2014 at 01:15 AM

    Yes you are right mostly this error comes due to number range

    To check the number range

    Check number range assignment if number range is assigned properly then additionally Goto VTTK table and check the last number of shipment then goto your number range and see the current number if that is below the last number (which you got from VTTK)  then change it and rerun the program

    Add comment
    10|10000 characters needed characters exceeded

  • Sep 26, 2014 at 02:20 AM

    Hi,

    Kindly check whether the number range of the shipment document has already been created in system .

    As it is in QAS ,kindly assign a new number series as Internal  and test the Shipment creation . Kindly do get the help of ABAP consultants to check if any User- Exit exists during saving the Shipment Documents in the SAP system.

    Regards,

    SRK

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 26, 2014 at 03:26 AM

    Hi Cesar,

    If a Shipment is getting saved, it may not necessarily be a number range issue. Please check the ST22 tcode for details of the Dump. It should give you a clear indication of where the error is. To me it looks more like an update termination due to incorrect code somewhere. As regards the fact that the current shipment number increases 10 numbers, can be due to some faulty loop in the user-exit, etc and is proof enough that Number range is not an issue.

    Regards,

    Shashi Thakur

    Add comment
    10|10000 characters needed characters exceeded

    • It is a standard that 10 numbers are taken, this is a default in buffer settings of a number range object. This is for performance reasons. SAP reads and updates  the number range 1x and keeps those 10 number in memory and takes it from there when you create the next shipment.

      However, you may lose several numbers if you dont create 10 shipments until the system is switched off. This causes gaps in the numbers, but even this is a standard and not avoidable, and there is no legal requirement for that.

      It is as well standard that you get already a success message with the number before the record is physically written to the database tables. If writing to the database fails then you get the express message. This can be analyzed further in SM13 transaction.Find your faulty transaction there, and go into the detail,  select the failed module (displayed red) and click the header icon to see the real error message for more details.

      While a conflict with the numbers is the root cause for a very high percentage of such failures it still cannot be assumed that this is the reason. Hence you need to check SM13. And monitoring of SM13 should be done regularly. We have a job for this. It creates automatically tickets and sends it to the responsible support team.