Map MyData receipt-level Void on non-8.6 cases to refund flow

[StefanKert]

Summary

myDATA's CancelInvoice endpoint is reserved for direct ERP/AADE users and is not callable through the e-Invoice Provider channel (see market-gr#133). The provider-legal equivalent of a cancellation is a credit-note / refund-slip document, which the SCU already produces for ReceiptCaseFlags.Refund.

Until now, receipt-level Void on anything other than Order0x3004 (the 8.6 path) threw "Voiding of documents is not supported for this invoice type. Please use refund." This PR removes that wall: Void on non-8.6 cases now routes through the existing refund flow.

Source case	Resulting myDATA document
Receipt + Void	11.4 retail refund slip (multipleConnectedMarks)
Invoice + Void + prior MARK	5.1 credit note - associated (correlatedInvoices)
Invoice + Void without prior MARK	5.2 credit note - non-associated
PaymentTransfer + Void	8.5 refund payment transfer

In all four cases line amounts, VAT and payment amounts are negated, matching what Refund already produces.

What stays unchanged

• Order0x3004 + Void → 8.6 keeps the dedicated totalCancelDeliveryOrders + multipleConnectedMarks cancellation path (market-gr#116).
• DeliveryNote0x0005 + Void + HasTransportInformation → 9.3 keeps the dedicated /myDataProvider/CancelDeliveryNote endpoint (market-gr#119).
• Providers still cannot call CancelInvoice directly — market-gr#133 stands.

Design

A single IsEffectiveRefund() extension on ReceiptRequest returns true when either Refund is set, or Void is set on a non-Order0x3004 case. Eight call sites swap from IsFlag(ReceiptCaseFlags.Refund) to this helper:

• AADEMappings: type resolution for receipt → 11.4, invoice → 5.1/5.2, payment-transfer → 8.5, and the IncomeClassificationType net-amount sign.
• AADEFactory: correlatedInvoices vs multipleConnectedMarks placement, line and payment amount negation, and 9.3 reverseDeliveryNote.

The two "Voiding not supported" throws stay as defense-in-depth — only reachable if someone overrides Void+Order0x3004 to a non-8.6 invoice type via mydataoverride.

Tests

• New VoidAsRefundTests.cs (8 tests): type resolution for each invoice family, the 8.6 regression guard, amount negation + mark placement, and the helper semantics.
• Updated CancelInvoiceValidationTests.cs Test 11: previously asserted the throw; now asserts an Item114 document with negated amounts and multipleConnectedMarks populated.
• Unchanged: full CancelInvoiceValidationTests (8.6 path) and PartiallyCancelInvoiceValidationTests (per-item recType=7) suites continue to pass.

819/819 unit tests green; build clean.

Related

• Tracking issue: fiskaltrust/market-gr#186
• Constraint context: fiskaltrust/market-gr#133
• Prior 8.6 work: fiskaltrust/market-gr#116
• Prior 9.3 work: fiskaltrust/market-gr#119
• Samples (already in businesscase DB):
  • SignRequestReceipt_VoidReceipt_1
  • SignRequestReceipt_VoidReceipt_2

Test plan

• Local: dotnet test scu-gr/test/fiskaltrust.Middleware.SCU.GR.MyData.UnitTest/ — 819/819 pass
• Sandbox: replay SignRequestReceipt_VoidReceipt_1 (Receipt + Void) → 11.4 retail refund slip with negative amounts and multipleConnectedMarks populated
• Sandbox: replay SignRequestReceipt_VoidReceipt_2 → matching refund-shaped document
• Sandbox regression: existing 8.6 restaurant-order void still emits totalCancelDeliveryOrders=true via SendInvoices
• Sandbox regression: existing 9.3 delivery-note void still calls /myDataProvider/CancelDeliveryNote

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a94b5c94d3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Base effective-refund on resolved type, not only receipt case

IsEffectiveRefund() treats every Void that is not Order0x3004 as refund-shaped before overrides are applied. In CreateInvoiceDocType, 8.6-specific void handling (SetInvoiceHeaderFieldsForVoid) runs before ApplyMyDataOverride, so a Void receipt/invoice with mydataoverride.invoiceHeader.invoiceType = "8.6" now bypasses the old guard, gets refund-negated rows, and can end up as final type 8.6 without the required 8.6 cancellation header/validation path. This is a new inconsistent-output path introduced by the helper condition.

Useful? React with 👍 / 👎.