CUA - showing status 53 not 51 for idocs

Question: I know CUA has been done to death but I can't find this exact problem in previous posts.

From the parent system idocs are sending fine. When I check BD87 (in target) there are no failed idocs with 51 but some 53 ones that show record wasn't processed as locked by usermaster (the CPIC ID for CUA).

Firstly they seem to be tripping over each other as all idocs sent at same time (SU10) and nothing in the target locking them - I'll get over this as not unusual for CUA.

Secondly why aren't they as 51 so that I can reprocess them in child system? Instead I have to go back to parent and re-distribute.

Forgot to say we are on ECC 5.0

Answer:
I remeber having the some of the same issues. CUA is kind of funny when there are inconsistencies in the USER data such as USER GROUPS, ADRESS Data, etc. that's one thing to check for and the IDOCS did tend to trip over themselves, where a series would come back locked by usermaster but if I remeber correctly that was due to allocation of resources for processing. Check with your BASIS team for resources available for processing IDOCS. There is an OSS note that talks about that; 399271 - CUA: Tips for optimizing ALE distribution performance

brief synopsys

CUA has a restricted number of work processes available which is smaller than the number of child systems. In this case, it may happen that when sending the IDocs to all systems in parallel, all work processes of the central system are blocked by ALE processing. For further information, see Notes 527481 and 400330.

-------------------------------------------------------
For error code analysis look at OSS Note: 333441

CUA: Tips for problem analysis

A brief synopsis:
Evaluating IDOC status records (table EDIDS)

You can start some interesting evaluations with transaction SE16.

Caution:there may be long runtimes here, therefore always specify a key field if you can.

Field selection:

DOCNUM
LOGDAT
LOGTIM
STATUS
STAPA1
STAPA2
STATYP
STAMID
STAMNO

Selektionen:
LOGDAT > Datum der letzten manuellen Bereinigung
STATUS STAMID STAMNO
51 01 124 User & does not exist
51 01 224 User & already exists

51 01 518 User group & does not exist
51 01 519 Invalid user type &
51 S# 234 Activity group & does not exist

53 01 49 Activity group assignment to user & not executedfully
51 01 263 User & is full. Please enter fewer profiles

51 S# 423 No authorization to change activity group &
51 S# 492 No authorization for user in group & in activitygroups
51 01 492 You are not authorized to change users in group &
51 01 410 Maintenance of user & locked by another user

51 01 22 Inconsistency with address
53 01 59 Company address & not found in the system
53 01 67 Unable to assign company address &1. &2 usedinstead.

53 01 102 User & created
53 01 232 User & deleted
53 01 39 User & has changed
53 01 48 Activity group assignment to user & has changed
53 01 90 Activity group assignment to user & was deleted
53 01 46 Profile assignment for user & has changed
53 01 246 User & unlocked, if this is permitted in thissystem
53 01 245 User & locked

51 S# 14 Error in lock management
53 01 406 Program error occurred