Document linking error: New CAD versions not updating in document management after check-in

PLM SAP PLM
, , , , , , , ,
1

We have a critical issue with document linking after CAD check-in. When engineers check in new versions of CAD files, the document management system doesn’t update the linked documents. The BOM still references the old CAD version even though the new version exists in the system. Our document versioning rules are configured to auto-increment versions on check-in, and the check-in process triggers appear to be working since files are stored. However, the links between documents aren’t updating.

Error from check-in log:


Document check-in successful: Drawing-12345 Rev B
Version created: 02
Link update failed: Target document not found
BOM reference: Still pointing to Rev A

I suspect there’s an issue with our BAdI or user exit logic that handles document linking during check-in. The check-in process completes but the relationship updates don’t propagate. This causes incorrect BOM references and engineers are working with outdated drawings. Any experience with document versioning rules and check-in triggers?

2

Your issue spans all three configuration areas. Let me address each systematically:

1. Document Versioning Rules: Your version rules configuration is incomplete. Here’s what needs to be checked and fixed:

Transaction: SPRO → Document Management → Control Data → Define Version Rules

Required settings for your version rule:

  • Version Creation: Automatic on check-in ✓ (you have this)
  • Copy Relationships: Active ✓ (you verified this)
  • Relationship Types to Copy: This is likely your problem

The “Copy Relationships” flag is global, but you must specify WHICH relationship types to copy. Check table DRAW_REL_TYPES:

  • DRW (Drawing to Part): Must be included
  • BOM (BOM to Document): Must be included
  • ASS (Assembly relationship): Must be included

If these specific relationship types aren’t in your version rule’s copy configuration, they won’t transfer to new versions.

Verification query:

SELECT * FROM DRAD
WHERE DOKNR = 'Drawing-12345'
AND DOKVR = '02'

If this returns no rows, relationships weren’t copied.

2. Check-in Process Triggers: The check-in process has multiple trigger points where linking can fail:

Standard check-in flow (CV01N):

  1. Document version created
  2. File uploaded to content server
  3. Relationships copied from previous version
  4. BOM references updated (if configured)
  5. Commit database changes

Your error “Target document not found” at step 3 indicates the relationship copy is looking for a document that doesn’t exist yet in the context where the copy logic runs.

Common causes:

  • Custom BAdI implementation commits too early
  • Relationship copy runs before document is fully created
  • Document number range issues causing temporary document IDs

Check transaction SWEL (Business Event Log) to see the sequence of events during check-in. Look for event CHANGED_DOCUMENT and verify the timing of relationship processing.

3. BAdI/User Exit Logic: This is your root cause. You likely have custom code interfering with standard processing.

Check these BAdI implementations (transaction SE18):

  • BADI_DMS_CHECKIN: Custom check-in logic
  • BADI_DOCUMENT_MAIN01: Document change enhancements
  • CV_DOCUMENT_CHG_BEFORE_SAVE: Pre-save modifications

Look for this pattern in your custom code:

METHOD if_ex_badi_dms_checkin~before_checkin.
  " Custom logic here
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
    EXPORTING wait = 'X'.
  " Problem: Commits before relationship copy!
ENDMETHOD.

If you find early COMMIT WORK or BAPI_TRANSACTION_COMMIT calls, that’s breaking the transaction boundary. The relationship copy logic expects to run in the same database transaction as document creation.

Solution Implementation:

Fix the BAdI logic:

METHOD if_ex_badi_dms_checkin~after_checkin.
  " Move custom logic to AFTER_CHECKIN instead
  " This runs after relationship copy completes

  " If you must commit, do it properly:
  CALL FUNCTION 'CV_DOCUMENT_LINK_UPDATE'
    EXPORTING
      iv_doknr = iv_document_number
      iv_dokvr = iv_document_version
      iv_copy_links = 'X'.

  " Now safe to commit
  COMMIT WORK AND WAIT.
ENDMETHOD.

For BOM reference updates, implement automatic synchronization:

" Create a custom program to run after check-in
SELECT * FROM STPO
  WHERE IDNRK = @lv_old_drawing_number
  INTO TABLE @DATA(lt_bom_items).

LOOP AT lt_bom_items INTO DATA(ls_bom_item).
  ls_bom_item-idnrk = lv_new_drawing_number.
  MODIFY STPO FROM ls_bom_item.
ENDLOOP.

Complete Fix Checklist:

  1. Verify version rule includes all relationship types (DRAD, DRAT tables)
  2. Review custom BAdI code for early commits
  3. Move custom logic from BEFORE_CHECKIN to AFTER_CHECKIN
  4. Implement explicit relationship copy call if needed
  5. Add BOM synchronization logic (separate program or BAdI)
  6. Test with transaction CV01N and verify in DC10

Testing Procedure:

  1. Enable database trace (ST05) during check-in
  2. Check in a new CAD version
  3. Review trace for COMMIT WORK timing
  4. Verify DRAD table updated with new version relationships
  5. Check STPO table for BOM reference updates

The issue is definitely in your BAdI logic prematurely committing changes. Once you move custom code to the correct trigger point and ensure relationship copying completes before commit, the linking will work correctly.

3

The “Target document not found” error suggests the document relationship table isn’t being updated correctly. Check transaction DC10 to see if the document relationships exist. If the new version is created but relationships aren’t copied from the old version, you’ll get this linking failure. There’s usually a BAdI that handles relationship copying during version creation.

4

Timing issues are possible if you have custom code in the check-in process. Check if you’ve implemented BAdI CV_DOCUMENT_CHG_BEFORE_SAVE or similar. If your BAdI commits changes before the standard relationship copy logic runs, you’ll get exactly this error - document exists but relationships are missing. The standard SAP flow handles relationship copying within the same database commit, so if custom code breaks that transaction boundary, linking fails.