Feature
One way of doing it would be like this:
- Defining validations. So that they are reusable and can be reused by different markets and receipt types.
- Resolving which validations apply for which receipt cases.
This could be grouped like this:
- Specific ReceiptCases in a specific market
- Specific ReceiptCase types (invoice, receipt, protocol, lifecycle) in a specific market
- All receipts in a specific market
- Specific ReceiptCases in all markets
- Specific ReceiptCase types (invoice, receipt, protocol, lifecycle) in all markets
- All receipts
Or kept completely open ended.
- Perform all validations that apply for the tested receipt receipt by resolving which ones are relevant.
Notes
There are already some validation steps done in the sign processor that we could also move into the validations
|
if (queue.IsDeactivated()) |
|
{ |
|
return ReturnWithQueueIsDisabled(queue, receiptResponse, queueItem); |
|
} |
|
|
|
if (request.ftReceiptCase.IsCase(ReceiptCase.InitialOperationReceipt0x4001) && !queue.IsNew()) |
|
{ |
|
receiptResponse.SetReceiptResponseError("The queue is already operational. It is not allowed to send another InitOperation Receipt"); |
|
return (receiptResponse, new List<ftActionJournal>()); |
|
} |
|
|
|
if (!request.ftReceiptCase.IsCase(ReceiptCase.InitialOperationReceipt0x4001) && queue.IsNew()) |
|
{ |
|
return ReturnWithQueueIsNotActive(queue, receiptResponse, queueItem); |
|
} |
|
|
|
if (queue.CountryCode != "GR") |
|
{ |
|
if (request.ftReceiptCase.IsFlag(ReceiptCaseFlags.Refund) && request.cbPreviousReceiptReference is not null && request.cbPreviousReceiptReference.IsGroup) |
|
{ |
|
receiptResponse.SetReceiptResponseError("Refunding a receipt is only supported with single references."); |
|
return (receiptResponse, new List<ftActionJournal>()); |
|
} |
|
|
|
if (request.IsPartialRefundReceipt() && request.cbPreviousReceiptReference is not null && request.cbPreviousReceiptReference.IsGroup) |
|
{ |
|
receiptResponse.SetReceiptResponseError("Partial refunding a receipt is only supported with single references."); |
|
return (receiptResponse, new List<ftActionJournal>()); |
|
} |
|
|
|
if (request.ftReceiptCase.IsFlag(ReceiptCaseFlags.Void) && request.cbPreviousReceiptReference is not null && request.cbPreviousReceiptReference.IsGroup) |
|
{ |
|
receiptResponse.SetReceiptResponseError("Voiding a receipt is only supported with single references."); |
|
return (receiptResponse, new List<ftActionJournal>()); |
|
} |
|
|
|
var receiptReferences = await _queueStorageProvider.GetReferencedReceiptsAsync(request); |
|
if (receiptReferences.IsErr) |
|
{ |
|
receiptResponse.SetReceiptResponseError(receiptReferences.ErrValue!); |
|
return (receiptResponse, new List<ftActionJournal>()); |
|
} |
|
|
|
if (receiptReferences.OkValue is not null) |
|
{ |
|
receiptResponse.ftStateData = new MiddlewareStateData |
|
{ |
|
PreviousReceiptReference = receiptReferences.OkValue |
|
}; |
|
} |
|
} |
We can use FluentValidations for this if it's a good fit.
Open Questions
- Do we need to differentiate between structural validation (e.g. nullability, string lengths, number ranges) and content validation?
Tasks
Feature
One way of doing it would be like this:
This could be grouped like this:
Or kept completely open ended.
Notes
There are already some validation steps done in the sign processor that we could also move into the validations
middleware/queue/src/fiskaltrust.Middleware.Localization.v2/SignProcessor.cs
Lines 177 to 227 in e76d231
We can use FluentValidations for this if it's a good fit.
Open Questions
Tasks