Removed the ReplicateData=false property

[Bardur Knudsen (BardurKnudsen)]

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

Fixes AB#644864

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

This PR's sole change is removing ReplicateData = false; from all three Spend Request tables (6840, 6841, 6845). This silently reverts a deliberate, reviewed

Recommendation:

• PR Exclude spend request G/L link from replication #9887 ("Exclude spend request G/L link from replication") added ReplicateData = false to table 6845 specifically because an internal cloud migration guard flagged it as an unreviewed table for cloud migration, and that PR's own description states the two parent tables (6840, 6841) already had ReplicateData = false since their introduction in PR Deliverable 638799: Spend Requests in Base App #8959 to keep replication behavior consistent. Removing the property from all three tables reintroduces the exact condition Exclude spend request G/L link from replication #9887 was created to resolve, and does so for all three tables rather than just the one originally flagged. The commit message ("Removed the ReplicateData=false property") gives no rationale for reversing this decision, and there is no accompanying explanation (e.g., a change in cloud migration guard policy, or a business need to now replicate this CustomerContent finance data) in the diff. If this is intentional, the PR description/commit should explain why the migration guard concern no longer applies and why enabling replication for these Spend Request approval tables (which carry CustomerContent classification) is now desired; otherwise this change should likely be reverted or reconsidered before merge.

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

[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}