Removed the ReplicateData=false property

[Bardur Knudsen (BardurKnudsen)]

Removed wrongly applied "ReplicateData=false" property on tables.

Fixes AB#644864

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Privacy}$

This PR removes ReplicateData = false; from "Spend Request" (table 6840), "Spend Request Detail" (table 6841), and "Spend Request To G/L Link" (table 6845), and adds all three to the cloud-migration test's expected-table list — enabling OnPrem-to-cloud replication/migration for these tables for the first time. However, most Normal fields in these tables rely solely on the table-level DataClassification = CustomerContent property (e.g. "No.", Type, "Requested By", Status, "G/L Account No.", Purpose, Currency Code, and the various amount/date fields in Spend Request; "Line No.", Description, "Expected Amount" in Spend Request Detail; "Spend Request No.", Amount, "Document No." in Spend Request To G/L Link) instead of an explicit field-level DataClassification. Per BCQuality privacy guidance, a table-level classification does not satisfy the field-level requirement, and migrated/replicated data should have its destination fields explicitly classified. Now that these tables are newly eligible for cloud migration, the previously low-relevance gap in field-level classification becomes a real privacy/compliance concern for data leaving the OnPrem environment.

Knowledge:

• microsoft/knowledge/privacy/table-level-data-classification-cascades.md
• microsoft/knowledge/privacy/migration-destination-classification.md
• microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4}

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR removes the ReplicateData = false property from three Spend Request tables (Spend Request, Spend Request Detail, Spend Request To G/L Link). Without this fix, these tables were excluded from cloud migration, so on-premises Spend Request data would be silently lost when a customer migrated to the cloud. The fix is correct: removing the property restores the default behavior (replication enabled) for all three related tables. The test update directly confirms the new state by adding the three tables to the expected-migration list that CloudMigrationPropertyTest verifies.

Suggestions

No suggestions — the change is clean and complete.

Risk assessment and necessity

Risk: Low. The change is a three-line property removal with no logic or schema change. The only behavioral effect is that cloud migration will now replicate data from these tables. For tenants already on-cloud, there is no effect. For tenants performing a cloud migration, Spend Request data will now be carried over — this is the intended outcome. The updated test guards against the property being re-introduced accidentally.

Necessity: High. Spend Requests store financial commitment data (amounts, G/L links). Losing this data during cloud migration is a data-loss bug with direct financial impact for any customer using the Spend Request feature and migrating to the cloud.

---

[AI-PR-REVIEW] version=1 promptVersion=1 system=github pr=10049 round=1 by=alexei-dobriansky at=2026-08-10T08:20:08Z lastSha=fbc08e15a8a14aacf219ba2f018e7515ac905e2a reviewKey=9268db91b5239a0e207acf15044c659149816790b4a47554bded7fda4a97c9f1 suggestions=