FiscoBridge SDC v3 – Invoice Fiscalization Migration Guide

From Sign Invoice (v2) to Create Invoice (v3) – E-SDC

This document explains how POS systems must migrate from the obsolete v2 Sign Invoice endpoint to the current v3 Create Invoice endpoint used for invoice fiscalization in FiscoBridge E-SDC.

This is the most critical migration, as invoice fiscalization is mandatory for legal compliance.

Official documentation reference (v3)

For the authoritative API definition, refer to the official FRCS documentation:

Create Invoice (v3)
https://tap.sandbox.vms.frcs.org.fj/help/view/1846128515/Create-Invoice/en-US

1. What is being replaced (important)

Obsolete v2 endpoint

The following endpoint is obsolete and must not be used anymore:

POST /api/Sign/SignInvoice

This endpoint is fully replaced in v3.

2. New v3 endpoint (mandatory)

In v3, POS systems must use the following endpoint for invoice fiscalization:

Purpose	Endpoint	Method
Create & fiscalize invoice	`/api/v3/invoices`	POST

The endpoint:

Is a local E-SDC endpoint
Requires no authentication
Uses structured JSON invoice model
Replaces all functionality of Sign Invoice

3. Endpoint migration summary

Old v2 endpoint	Status	New v3 replacement
`/api/Sign/SignInvoice`	Obsolete	`/api/v3/invoices`

POS software must remove the old endpoint completely.

4. Conceptual change (very important)

v2 – Sign Invoice

POS calculated most values
Request fields were abbreviated (IT, TT, BD, etc.)
API focused mainly on signing
Limited validation and structure

v3 – Create Invoice

POS submits a full invoice object
E-SDC performs:
- Validation
- Tax calculation
- Signing
- Journal creation
- QR code generation
Clear domain model with descriptive field names

Create Invoice is not just signing — it is full invoice fiscalization.

5. Request model changes (breaking changes)

5.1 Structural changes

v2 Sign Invoice	v3 Create Invoice
Flat request	Strongly structured object
Abbreviated fields	Descriptive field names
Limited validation	Strict validation
Hash-based search	RequestId header

5.2 Field naming changes (examples)

v2 field	v3 field
`IT`	`invoiceType`
`TT`	`transactionType`
`BD`	`buyerId`
`PaymentType`	`payment[]`
`Items[].Name`	`items[].name`
`Items[].Labels`	`items[].labels`
`TotalAmount`	`totalAmount` (per item)

6. Payment handling changes (major)

v2

Single PaymentType

v3

payment[] array
Supports multiple payment methods per invoice
Each payment includes:
- amount
- paymentType

7. Item & tax handling changes

v2

POS partially controlled tax calculation
Limited tax structure

v3

Each item must include:
- labels[]
- unitPrice
- quantity
- totalAmount
E-SDC calculates:
- Tax items
- Totals
- Tax group revision

This ensures legal accuracy and audit safety.

8. Response model changes

v2 response

Shortened fields (IN, DT, IC, S, ID)
POS needed mapping logic

v3 response

Fully descriptive fields:
- invoiceNumber
- invoiceCounter
- sdcDateTime
- verificationUrl
- verificationQRCode
- journal
- taxItems[]
- signature
- encryptedInternalData

Response is POS-ready and printable.

9. Additional v3 capabilities

Create Invoice introduces:

Multi-language invoice output (Accept-Language)
Optional QR code generation control
Optional textual journal control
Clear audit-package separation
Better retry and search support via RequestId

10. Migration checklist for POS developers

Remove /api/Sign/SignInvoice
Implement POST /api/v3/invoices
Replace invoice request model completely
Implement payment[] array logic
Ensure every item includes tax labels
Handle full v3 response object
Use Accept-Language if supported
Treat Create Invoice as atomic fiscal operation

11. Summary

Sign Invoice is obsolete
Create Invoice is mandatory
Create Invoice performs full invoice fiscalization
Migration requires real development effort
This endpoint is the core of v3 compliance

All POS systems must migrate to /api/v3/invoices.

End of document.