cancel
Showing results for 
Search instead for 
Did you mean: 

In SM13 updates terminates for transaction MIR7 only

Former Member
0 Kudos

Greetings,

Updates for transaction MIR7 are terminating. The tablespace is not full and other updates are successful.

I just want to explore the number range issue. I want to understand which number range might be used-up (i.e. update [OMRJ] or the invoive specific [SM56]). Please provide detailed informations in your response.

All fails at step/module:

"5 MRM_INVOICE_DOCUMENT_POST V1 Error"

Error: M8 185: Invoice document 5105640270

Also advise who is repsonsible extending which number ranges (functional or basis)

Thanks

Accepted Solutions (0)

Answers (3)

Answers (3)

JPReyes
Active Contributor
0 Kudos

Can you post errors in SM21, ST22.. just to check that is indeed related to number range issues?...

You can see the current number ranges in SNRO

Regards

Juan

Former Member
0 Kudos

The problem is that the functional team says they have extended the number ranges, but the updates are still terminating. We even reset the No Range buffer in SM56 for all the application servers to no avail. There are no dumps in ST22. SM21 Log listed below:

Time Type Nr Clt User TCode Priority Grp N Text

13:01:02 UP1 036 400 2488394 D0 1 Transaction Canceled M8 185 ( 5105640496 2010 )

13:01:03 UP1 036 400 2488394 R6 5 Update terminated

13:01:03 UP1 036 400 2488394 R6 6 > Update key: 4B42ED19C648010DE10080000A031C2B

13:01:03 UP1 036 400 2488394 R6 7 > Update module: MRM_INVOICE_DOCUMENT_POST

13:05:21 UP1 035 400 90015390 D0 1 Transaction Canceled M8 185 ( 5105640499 2010 )

13:05:21 UP1 035 400 90015390 R6 5 Update terminated

13:05:21 UP1 035 400 90015390 R6 6 > Update key: 4B445D6E931800AAE10080000A031C2B

13:05:21 UP1 035 400 90015390 R6 7 > Update module: MRM_INVOICE_DOCUMENT_POST

13:36:30 UP1 035 400 40002061 D0 1 Transaction Canceled M8 185 ( 5105640608 2010 )

13:36:30 UP1 035 400 40002061 R6 5 Update terminated

13:36:30 UP1 035 400 40002061 R6 6 > Update key: 4B45D676A7CB0093E10080000A031C29

13:36:30 UP1 035 400 40002061 R6 7 > Update module: MRM_INVOICE_DOCUMENT_POST

13:57:24 UP1 036 400 40002061 D0 1 Transaction Canceled M8 185 ( 5105640671 2010 )

13:57:24 UP1 036 400 40002061 R6 5 Update terminated

13:57:24 UP1 036 400 40002061 R6 6 > Update key: 4B44C5D7957E00A5E10080000A031C29

13:57:24 UP1 036 400 40002061 R6 7 > Update module: MRM_INVOICE_DOCUMENT_POST

14:04:08 UP1 035 400 90004221 D0 1 Transaction Canceled M8 185 ( 5105640675 2010 )

14:04:08 UP1 035 400 90004221 R6 5 Update terminated

14:04:08 UP1 035 400 90004221 R6 6 > Update key: 4B425375581E0096E10080000A031C29

14:04:08 UP1 035 400 90004221 R6 7 > Update module: MRM_INVOICE_DOCUMENT_POST

I just want to identify the root cause of this problem. If it is number ranges, table buffering or what else? If there is no proof, it always becomes a basis problem.

Former Member
0 Kudos

Hi,

Check if Note 1264458 - Error M8_2 607 for prepayment with stochastic block is relevant to the issue you are facing.

Cheers.....

Raghu

Former Member
0 Kudos

You may have to contact functional guys to find out the root cause, they can know which number range is in use and with which value that to be extended.

This is not at all BASIS issue, but you can help them in finding roor cause..

before that check system logs and cancelled updates, will tell you exact cause is number range or not?

Regards

Nick Loy

Former Member
0 Kudos

Extending number ranges is in the responsibilty of functional persons.

Also finding out which number ranges to extend is in the responsibilty of functional persons.

I am basis, and so can't help you further, sorry.