New Slice 611704: Tax Transaction Value ID field changed to BigInteger to prevent IDENTITY exhaustion

[Tabrez Ajaz (v-ajaztabrez)]

AB#611704
Slice 611704: [Repair Item][IN] Change "Tax Transaction Value".ID to be BigInteger

Issue:
The primary key field ID of table Tax Transaction Value (20261) was Integer with AutoIncrement. On a production environment (IN localization, ~525 GB database) the SQL IDENTITY sequence exceeded the integer limit (2,147,483,647), causing the error: "Arithmetic overflow error converting IDENTITY to data type int." The actual row count (~285M) was well below the limit, but Posting Preview and failed/rolled-back transactions kept consuming AutoIncrement IDs without committing rows, exhausting the sequence far beyond the actual data.

Cause:
SQL Server IDENTITY (AutoIncrement) is non-transactional — every insert attempt permanently increments the counter, even when the transaction is rolled back (Posting Preview, validation errors). Heavy use of Posting Preview consumed the integer range over time. The Integer type has a maximum of only 2,147,483,647.

Solution:
Changed field ID from Integer to BigInteger, extending the range to 9.2 × 10¹⁸ (practically inexhaustible for this workload). Removed AutoIncrement and moved ID assignment to the platform NumberSequence API, which is natively BigInteger. Centralized ID generation in the existing helper Transaction Value Helper (20236) as GetNextTransactionValueID() — no new object introduced. The sequence is lazily seeded from the current MAX(ID) on first use (collision-free even on an upgraded database), with a TryFunction + ClearLastError guard for concurrent creation. The table OnInsert trigger assigns the ID from the sequence (skipping temporary records and explicitly-set IDs). Live-table insert call sites (TaxRateComputation, TaxDocumentGLPosting) use Insert(true) so the trigger fires. The temp-table NextID variable in TaxPostingBufferMgmt was changed to BigInteger to match the field type. Temporary table inserts manage their own IDs via simple counters and are unaffected by this change.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

The table now assigns "ID" only from OnInsert(), and the PR had to change internal callers from Insert() to Insert(true) to keep inserts working. Any dependent extension that previously inserted "Tax Transaction Value" with the parameterless Insert() and relied on AutoIncrement will now skip ID assignment and can fail with duplicate or zero primary-key values. Preserve the legacy insert contract or introduce a staged compatibility/deprecation path before removing the old behavior.

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