Unallocated rows and repeated gift IDs in designation-row exports

For GiveCampus reporting.

In the designation-row exporter, each allocation receives its own amount, designation name and backend code while other gift-level values, including the original donation ID, remain shared. Repeated gift IDs across allocation rows are therefore expected; they do not prove duplicate payments.

The exporter also emits a row with blank designation/name when the report's contribution amount exceeds the total allocated amount. Donor-covered fees can contribute to that remainder, but a blank-fund row is not automatically proven to be a processor-fee row. Compare the actual report type, donation total, allocated amounts and separate fee fields. Do not assign it to an arbitrary fund solely to make an import pass.

If an external CRM rejects shared gift IDs, agree a stable allocation-row identifier with that CRM's integration owner in an exported copy or transformation, retaining the original GiveCampus gift ID in a separate field. GiveCampus does not change the original transaction ID for each split. A suffix scheme is a proposed external transformation, not a built-in GiveCampus ID setting or proof that a particular Veracross importer accepts it. Preserve stable mapping across reruns to avoid duplicate imports.

For CRM fundraising-activity mapping, prefer an approved crosswalk keyed by the designation backend code. A designation description is donor-facing when its display option is enabled and is not automatically exported as a private CRM activity code. Check actual supported columns and downstream mapping before repurposing it.