Three things to check in the staging table first

Sample post. Written to test the site. Replace or delete it before launch.

A data management import runs in two hops: file → staging table → target tables. Most failures are visible in staging, long before you need a debugger.

1. Transfer status per row

Open the job in Data management → Job history → View staging data. The TransferStatus column tells you which rows failed the copy to the target. Filter on Error and read the message.

2. Mapping of the source file

A column that is unmapped, or mapped to the wrong field, imports as empty. Check View map on the entity. A header with a trailing space is a classic.

3. Set-based processing

If the entity runs set-based, insert() and validateWrite() on the target table are skipped. Business logic you expected may never run. Turn it off on the entity to compare.

// Quick check in a runnable class: how many rows failed for one job?
SalesOrderHeaderV2Staging staging;

select count(RecId) from staging
    where staging.DefinitionGroup == 'MyImport'
       && staging.TransferStatus == DMFTransferStatus::Error;

info(strFmt("%1 rows failed", staging.RecId));

For extensions that should still run, see Extending SalesLine with Chain of Command.