Deduct already-reversed prepayment GST on AU sales prepayment credit memos

[Franco111000]

What and why

AU only: a sales prepayment credit memo posted after a partial final invoice reverses the full prepayment GST instead of only the part that has not been deducted yet, so the customer ledger entry and the G/L entries carry too much GST when the order is re-invoiced.

The APAC layer already has a mechanism for exactly this: during final invoice posting, SavePrepmtVATDeducted collects the GST reversed by the prepayment deduction lines into a buffer, and the credit memo read sites subtract Sales Line fields 28006 Prepmt. VAT Amount Deducted and 28007 Prepmt. VAT Base Deducted from the prepaid GST (SalesPostPrepayments 1200-1201 and 1250-1251, gated by Full GST on Prepayment plus the credit memo document type). On the purchase side the mechanism is complete: Purch.-Post drains its buffer onto the purchase lines through DividePrepmtVATDeducted and DistributeAmount (7488-7545, called at 8428). On the sales side only the first half exists: the buffer is filled (SalesPost 7769, called 1156) and nothing ever drains it, so both fields stay at zero for the life of every document and the subtraction never subtracts anything.

This PR completes the sales side by porting DividePrepmtVATDeducted and DistributeAmount from Purch.-Post and calling the former from PostUpdateOrderLine, mirroring the purchase call site. Three deliberate deviations from a verbatim port, each needed for the port to be correct:

1. Sign normalisation in SavePrepmtVATDeducted. The prepayment deduction lines are built with Quantity = -1 on both sides, so their amounts are negative. The purchase saver negates them into positive values (PurchPost 7493-7494); the sales saver did not. Both credit memo read sites subtract the fields, so the stored values must be positive. The sales saver now negates exactly like the purchase one. This edit is inert for existing behaviour: the two buffer fields it feeds had no reader on the sales side until this PR.
2. Per-line reset of DeductedVATBaseAmount in UpdateVATOnLines. The variable is procedure-scoped, assigned only on the Full GST credit memo path, and consumed on every Full GST line. While field 28007 was always zero this was harmless; with the field populated, one line's deducted base would leak into the next line in the same run. Reset to zero at the top of each iteration.
3. Clean cycle on consumption. The credit memo branch of UpdateSalesDocument already rebases Prepmt. Amt. Incl. VAT and Prepayment Amount and clears the other per-cycle prepayment fields (2000-2004). Both deducted fields are cleared there too, so a prepayment that is re-invoiced after a credit memo starts a clean deduction cycle instead of subtracting the previous cycle's deduction again. The purchase side does not do this and keeps document-lifetime accumulators; aligning purchase the same way may be worth a follow-up, but changing purchase behaviour is out of scope here.

One more small deviation: the ported procedure resets the line number buffer before deleting it. The purchase original deletes that buffer while the filter from the last loop iteration is still active, which only clears the last group.

Out of scope: the fix proposed in the issue description (extending RestorePrepmtAmounts with Prepmt. VAT Base Amt.) is not part of this change. That procedure saves and restores a field that UpdateVATOnLines deliberately rewrites per posting, and under Full GST the rewrite keeps the field unchanged from the second prepayment onward, so an unconditional restore would double it. The root cause analysis is on the issue.

Linked work

Fixes #8896

Area label: the issue carries Finance. I do not have label permissions, so a maintainer would need to set it.

How I validated

• Traced the full mechanism on both sides: buffer fill (SalesPost 1156/7769 vs PurchPost 1210/7488), drain (PurchPost 7510/8428, sales previously absent), read sites (SalesPostPrepayments 1200/1250, PurchasePostPrepayments 866/916), and the temp-to-database flush (ModifyTempLine, wholesale TransferFields, so the drained values persist).
• Verified the global Currency used by DistributeAmount is initialised before PostUpdateOrderLine runs (GetCurrency at 346, FinalizePosting at 372), matching the purchase flow.
• Confirmed fields 28006/28007 have no other reader or writer anywhere in the repository, so behaviour changes only on the Full GST prepayment credit memo path.
• Added a regression test (GSTOnSalesPrepmtCrMemoAfterPartialFinalInvoice in ERM GST On Prepayments II): prepayment invoice, paid, partial final invoice, then prepayment credit memo under Full GST on Prepayment. It asserts the deducted GST amount and base on the order line against the posted deduction lines, and that the credit memo GST equals the prepaid GST minus the deducted GST. The existing suite cannot catch this defect: every current Full GST credit memo test posts the credit memo before any final invoice, so the fields are still zero at the read sites either way.
• Full test suite run is pending the workflow approval on this PR; I could not execute the AU suite locally.

Risk & compatibility

• Behaviour radius: posting results change only for APAC builds with Full GST on Prepayment enabled for the line's VAT posting setup, on a sales prepayment credit memo posted after a final invoice. Both read sites are gated by IsFullGST plus the credit memo document type, and nothing else reads these fields.
• Data radius: order lines that deduct a prepayment now carry values in fields 28006/28007 (previously always zero). The fields are Editable = false and appear on no page, report, or API in the repository.
• The existing Full GST tests that post two prepayment invoices or a prepayment credit memo without a prior final invoice are unaffected: on those paths the fields are zero at the read sites, which is exactly today's behaviour.