Z-report, fiscal z report submit document issue

[lbodel]

Other Development Issue

Summary

GetReceiptServiceRequest executed before GetFiscalDocumentDocumentProviderRequest

Hi,

I got an issue with the whole z-report, fiscal z-report requests. My problem is that I need to get a digital signature from the fiscal printer before an z-report is printed and it worked on mPos but doesnt in Store commerce app and the new csu.

In mPos i got the following

the z-report issued an GetFiscalDocumentDocumentProviderRequest (this is the place where the fiscal printer was generating the signatures), i returned an GetFiscalDocumentDocumentProviderResponse with the needed data and then i got GetFiscalTransactionExtendedDataDocumentProviderRequest where i stored the signature.

After all that steps I got GetReceiptServiceRequest where I could fetch the previously stored signature and add it to the report

(the customer uses mPos (on one market) with the new csu retail server and claims it works there, so this must be an issue with store commerce app)

In Store Commerce app

In the new app after I execute z-report or fiscal-z-report I get GetReceiptServiceRequest regardless of GetFiscalDocumentDocumentProviderRequest, I get GetFiscalTransactionExtendedDataDocumentProviderRequest only on Sale event, not on ZReport/FiscalZReport so I must save the signature on SaveRegistrationResultFiscalIntegrationServiceRequest which is ok.

The problem in the store commerce app is that GetReceiptServiceRequest doesnt wait for the while GetFiscalDocumentDocumentProviderRequest flow.

In all two apps i have a fiscal driver which implements INamedRequestHandler/INamedRequestHandlerAsync and handles SubmitDocumentFiscalDeviceRequest and returns SubmitDocumentFiscalDeviceResponse

Any ideas how to solve this issue?

King regards, LB

Version and Error Info Store Commerce for Windows, 9.48.24145.7, 9.50.24248.3

[lbodel]

Here is some log from the console

Executing a POS runtime request of type 'GetDeviceConfigurationClientRequest' for extension in package 'ebbbExtensions'.
Diagnostics.TypeScriptCore.js:612 POS runtime request of type 'GetDeviceConfigurationClientRequest' for extension in package 'ebbbExtensions' completed successfully.
Diagnostics.TypeScriptCore.js:612 Trigger execution completed for trigger type PreOperation, trigger name ebbb_D365-6308_AdyenXZReports/Triggers/PreOperationTrigger_D365_6308. Time elapsed 1.6000000089406967 ms.
Diagnostics.TypeScriptCore.js:612 Next number sequence value for when feature is enabled is: '1725356929622'.
Diagnostics.TypeScriptCore.js:612 The Retail Server Request with request id '735fddc6-7212-1d79-9a4b-2fd3087b37a2' and request url '/RetailServer/Commerce/Shifts/GetZReport(transactionId=@p1,hardwareProfileId=@p2)?%40p1=%271306050090-130605009B-1725356929622%27&%40p2=%27HP-TH%27' started.
Diagnostics.TypeScriptCore.js:612 The Print Receipt dialog was not shown and skipped to print directly.
Diagnostics.TypeScriptCore.js:612 The PrintReceiptDialog has been successfully rendered. Correlation ID: 7e9ba8f7-8cf1-9b53-a91c-9ac20672365a.
Diagnostics.TypeScriptCore.js:612 DeviceConfig was not set because Driver Type is not Network. Peripheral type:'Printer'; Device name:'MockOPOSPrinter'; Device driver type:'OPOS'; Hardware Station Profile ID:'HP-TH'.
Diagnostics.TypeScriptCore.js:612 Pos initiated a hardware station request to uri: IPC://LOCALHOST/Printer/Print. The activityId is: 33fa1717-6028-97a6-4267-bcf6d9dee83c.
Diagnostics.TypeScriptCore.js:612 POS initiated the HW station request to Android through outgoing task. Correlation Id: 33fa1717-6028-97a6-4267-bcf6d9dee83c, HW Station Url: 'IPC://LOCALHOST/Printer/Print'.
Diagnostics.TypeScriptCore.js:612 Pos successfully completed a hardware station request to uri: IPC://LOCALHOST/Printer/Print. The activityId is: 33fa1717-6028-97a6-4267-bcf6d9dee83c.
Diagnostics.TypeScriptCore.js:612 The receipts were printed.
Diagnostics.TypeScriptCore.js:612 The PrintReceiptDialog has been successfully hidden. Correlation ID: 7e9ba8f7-8cf1-9b53-a91c-9ac20672365a.
Diagnostics.TypeScriptCore.js:612 Fiscal event registration started. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 Fiscal integration pending registration process started. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 Fiscal integration pending registration process succeeded. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 Fiscal integration registration process started. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 Fiscal integration get registration process started. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 Executing the fiscal registration process line started. The process line sequence number: 1, priority: 1. Event type: '3'. Connector type: 0. Is optional step false. Correlation ID: '095fec13-7748-334b-302b-cf22f5e453bd'.
Diagnostics.TypeScriptCore.js:612 The Retail Server Request with request id '7a3ffa71-a330-7e5b-a719-ffe044d693b4' and request url '/RetailServer/Commerce/GetFiscalIntegrationFiscalDocument' started.
Diagnostics.TypeScriptCore.js:612 The Retail Server Request with request id '7a3ffa71-a330-7e5b-a719-ffe044d693b4' and request url '/RetailServer/Commerce/GetFiscalIntegrationFiscalDocument' succeeded. Status code 200, Time elapsed 2389.2999999970198 ms.
Diagnostics.TypeScriptCore.js:612 Pos initiated a hardware station request to uri: IPC://LOCALHOST/FiscalPeripheral/SubmitDocument. The activityId is: a49de363-dcc1-e459-5a33-a232373b98a2.
Diagnostics.TypeScriptCore.js:612 POS initiated the HW station request to Android through outgoing task. Correlation Id: a49de363-dcc1-e459-5a33-a232373b98a2, HW Station Url: 'IPC://LOCALHOST/FiscalPeripheral/SubmitDocument'.
Diagnostics.TypeScriptCore.js:612 Pos successfully completed a hardware station request to uri: IPC://LOCALHOST/FiscalPeripheral/SubmitDocument. The activityId is: a49de363-dcc1-e459-5a33-a232373b98a2.
Diagnostics.TypeScriptCore.js:612 The Retail Server Request with request id 'bd511838-4d6b-1121-e727-3f948c2f40df' and request url '/RetailServer/Commerce/SaveFiscalIntegrationRegistrationResult' started.

[FedyukovDA]

@lbodel

I did a brief look at the fiscal report printing processes.

Speaking about regular XZReport printing, I did not able to found any difference in the orders of execution. Seems like fiscal process always started after the Printing. Same behavior in the CPOS. If you can tell me the exact build where it work otherwise, I may try to test it internally and check what was changed.

In terms of FiscalZXReport operation. We've got an example in this sample. As I get it, this operation is used in case fiscal device or service requires specific report format. It it should not trigger Printing operation automatically, only fiscal process. So, it may work for you. On GetFiscalDocument you generate a report and sign if needed, on Submit you send it to a printer.

It will be good to know details of your context. What fiscal device you are using, requirements and country of implementation

[lbodel]

Hi @FedyukovDA

It was working with modern pos i will give you the exact version tommorow but it worked for 10.0.35.* The second case is that GetFiscalTransactionExtendedDataDocumentProviderRequest isnt triggered for FiscalZReport nor ZReport, in the older versions it was. So, something has changed. And i`m pretty sure that GetZReport was launched after GetFiscalIntegrationFiscalDocument.

I`m using FES32USB for Cyprus - the fiscal requirement is that it generates a serial and signature which are then added to GetZReport And the client is using it with close shift (z-report)

Btw. the FiscalIntegrationEventType.ZReport is useless in case GetZReport is requested before - it prevents for adding any new information to z-report printing

mPOS version: 10.0.37.271

[FedyukovDA]

@lbodel It will take some time for me to test the old version. I'll return a bit later with the results of investigation.

Does it require to sign XReport as well? If not, maybe it worth to test FiscalIntegrationEventType.CloseShift instead of FiscalIntegrationEventType.ZReport or FiscalIntegrationEventType.FiscalZReport

[lbodel]

@FedyukovDA thanks very much.

The CloseShift acts the same as ZReport, and on CloseShift a ZReport is triggered before anyway

[FedyukovDA]

@lbodel I did some a bit more testing. 10.0.35 POS got the same behavior as the current actual versions. Fiscal process triggered after XZReport.

If you believe it is different in your case, please provide a screenshots from Devtool Network tab (or Fiddler logs) where it will be visible that Fiscal process triggered before Zreport printing.

And I tested CloseShift operation and can confirm that for this type of operations fiscal process happens after Close() shift, but before ZReport printing.

[lbodel]

Hi @FedyukovDA thanks, i will test it against only close shift - unfortunely i dont have access to the older versions.

[lbodel]

Hi @FedyukovDA you where right, it has the expected flow only for closeshift - it resolves my task. Btw. I dont quite understand what is the purpose of triggering Z-report fiscal event type after the close shift and GetZReport

Thanks for the help.