Non-destructive Z-report counter read + autonomous midnight Z-closure detection for СУПТО compliance

[vr46-tech]

Hello,

We are building a СУПТО-compliant POS backend for a Bulgarian venue operator, using ErpNet.FP as the fiscal abstraction layer against a Datecs FP-700MX (firmware 3.00 22Jul25, protocol bg.dt.x.isl.com, serial DA023700).
We are designing the Z-report / fiscal day close flow, and hit a specific compliance problem around the FP-700MX's automatic midnight Z-report (required by Н-18 amendments 2022).
The problem:
If our POS fails to close the fiscal day before midnight, the Datecs FP-700MX autonomously issues a Z-report at 23:59:59. Our СУПТО software has no way to know this happened: no push notification, no status flag change visible via GET /status. We need to detect the drift between our last recorded Z-report number and the printer's current Z-counter in order to synthesize the closure record and maintain a gapless Appendix 29 audit trail.
What we have tested, we confirmed via live probe that:

• POST /rawrequest is exposed in our build (HTTP 405 on GET → POST works)
• Command 64 ({"rawRequest": "64\t"}) is accepted with ok: true
• On our current device the rawResponse data field is empty because the FM was just formatted (no fiscal days closed yet, no UIC set — this is a pre-production unit)

We therefore believe that on a production-commissioned unit with at least one closed fiscal day, Command 64 should return the last Z-report number and closure date, which would give us the non-destructive read we need.
Our questions:

• Is our assumption correct: will POST /rawrequest with {"rawRequest": "64\t"} return the Z-report sequence number on a live, fiscalized FP-700MX unit with the bg.dt.x.isl driver?
• What is the exact field layout of Command 64's rawResponse on a live unit? (We need to know which tab-delimited field position contains the Z-counter, so we can write a parser in our Fiscal Abstraction Layer.)
• Is there a cleaner, first-class GET endpoint planned or already available in a newer build that exposes the last Z-report number without printing? Something like GET /printers/{id}/fiscalDayInfo would be ideal for our use case.
• Is the autonomous midnight Z-report a known pattern that other СУПТО integrators have solved via ErpNet.FP? If so, what is the recommended approach?

Thank you in advance for your support on.

regards,

[wqweto]

For protocol bg.dt.x.isl.com you can test Command: 123 (7Bh) Device information, Option - '3' - Last fiscal receipt which returns Answer(3) {ErrorCode}<SEP>{BonFiscal}<SEP>{DateBonFiscal}<SEP>{Znumber}<SEP>{Zdate}<SEP> where

• BonFiscal - Number of last sales receipt in current Z report ( 1...9999 );
• DateBonFiscal - Date and time of last sales receipt ( format "DD-MM-YYYY hh:mm:ss" );
• Znumber - Number of last Z-report ( 1..???? );
• Zdate - Date of last of Z-report ( format "DD-MM-YYYY hh:mm:ss" );

Btw, you don't need to do anything similar for "gapless Appendix 29 audit trail" as Z-reports from fiscal devices are not logged there.

I'm wondering what the exact use-case could be. Your POS is used in a night bar and at exactly midnight the fiscal device spawns an extra report which takes operators by surprise?

[vr46-tech]

For protocol bg.dt.x.isl.com you can test Command: 123 (7Bh) Device information, Option - '3' - Last fiscal receipt which returns Answer(3) {ErrorCode}{BonFiscal}{DateBonFiscal}{Znumber}{Zdate} where

• BonFiscal - Number of last sales receipt in current Z report ( 1...9999 );
• DateBonFiscal - Date and time of last sales receipt ( format "DD-MM-YYYY hh:mm:ss" );
• Znumber - Number of last Z-report ( 1..???? );
• Zdate - Date of last of Z-report ( format "DD-MM-YYYY hh:mm:ss" );

Btw, you don't need to do anything similar for "gapless Appendix 29 audit trail" as Z-reports from fiscal devices are not logged there.

I'm wondering what the exact use-case could be. Your POS is used in a night bar and at exactly midnight the fiscal device spawns an extra report which takes operators by surprise?

Thank you for the Command 123 / option '3' pointer: that's exactly what we needed. We'll probe it via rawrequest on our production unit once it's commissioned.

On the Appendix 29 point: you're right, and we appreciate the correction. We mixed two separate concerns. Z-report sequences are the printer's fiscal memory domain, not a СУПТО export table. Our actual concern is purely operational:

The venue is a trampoline park, open until around 22:00. If for any reason the staff forgets to close the fiscal day before midnight, the FP-700MX auto-closes at 23:59:59. The next morning, our database still shows the fiscal day as open and shifts as active. When the operator tries to start a new session or print a Z-report, things break in confusing ways.

So our use case for Command 123/3 is a shift-open guard: poll the printer's current Znumber, compare it against our last recorded Z-report number, and if there's a drift of +1 we know an autonomous closure happened overnight. We then close the stale fiscal day record in our DB, close any orphaned shifts, and alert the manager before the operator hits a confusing printer error.

Does that use case make sense to you? And is Command 123/3 via rawrequest the right tool for this, or is there a cleaner path in ErpNet.FP we're missing?

[wqweto]

So our use case for Command 123/3 is a shift-open guard: poll the printer's current Znumber, compare it against our last recorded Z-report number, and if there's a drift of +1 we know an autonomous closure happened overnight.

Yes, this sounds possible.

I'll leave original devs chime in on ErpNet.FP current features and future plans.