Certification

Before a company can issue electronic tax documents in production, it applies to the SII as an electronic issuer (postulación) and passes a certification process in the SII's certification environment. dte-sdk covers that process from the test set the SII generates for you to the declaration of compliance: it reads the test set, issues the documents and books it asks for, drives the SII portals through every stage, answers the exchange, uploads the printed samples and, only when you say so, makes the declaration. The certification of receipts (boletas) is a separate application, and the SDK covers it as pieces you chain.

Everything on this page lives in dte-sdk/portal (the printed samples also use dte-sdk/pdf) and needs Node.

Nothing here has been run against the real certification portals yet. The tests use synthetic SII answers, so every page shape, wire format and wording is still unproven. The first real run should keep every artefact the store writes (every portal answer is there) as fixtures. dte-sdk 0.8.0 is on npm, the latest release. It is not recommended for production yet: most areas have not met the real SII, and until 1.0.0 the API can change in any release. See Status.

The declaration of compliance is the sworn statement of the legal representative and cannot be undone. The runner makes it only when you pass declareCompliance: true; without that option it stops at compliance. The receipts declaration is just as final.

Downloading the test set again regenerates it at the SII. The SII assigns the cases anew, so everything you sent for the earlier set becomes void. The runner downloads it once; a run that already holds a plan and downloads again starts over.

The state holds CAF private keys. CertificationState.cafs keeps the CAF files the run obtained, each with its private key. The directory store writes them readable by you only. Keep the store out of version control and treat it as a secret. See Security.

What the SII certification is#

The SII generates a test set for the applicant: a text with an attention number and a list of cases, each describing a document to issue (an invoice, a credit note, a guide) with its items and references. You issue those documents with your own CAFs and certificate, send them, and declare the track ids on the SII portal. The SII reviews each envelope, then asks for the books built from them, a simulation, an exchange and the printed samples. The stages, in the order the runner keeps them (CERTIFICATION_STAGES):

Stage	What happens
`testSets`	You download the test set and issue the four sets: basic (invoices 33, credit notes 61, debit notes 56), exempt (34, 61, 56), guide (52) and purchase (46, 61, 56). Each goes in its own envelope; you declare their track ids. The SII approves each set (`REVISADO CONFORME`).
`books`	You send the purchase book, the sales book and the guide book (and the purchase book for exempt taxpayers when the test set brought one), built from the sets and from the supplier documents the test set lists. You then ask the portal for the next stage.
`simulation`	You issue every case of the four sets again, with fresh folios, in one envelope. You send it, declare its track id, wait for the approval and confirm it.
`exchange`	The SII sends your company a set of documents addressed to it. You answer with three signed files: the reception response, the receipts of Ley 19.983 and the commercial approval, and you confirm the exchange.
`printedSamples`	You upload the PDF of every document the sets and the simulation issued, as a review the SII's automatic validator checks.
`compliance`	The legal representative declares compliance.
`done`	The certification is complete.

The certification of receipts is a different application. It has its own portal, its own test set (a plain text of cases, each one receipt of type 39), its own envelope (EnvioBOLETA), its own folio consumption report (RCOF) and its own declaration. The SII validates the receipts set on its own time and answers by e-mail. See Receipts.

How dte-sdk covers it#

Test sets

The deterministic half, all data: parse the test set text, plan what each set issues, issue the four sets and the simulation, and build the books. Nothing is sent.

The runner

runCertification: the whole HTML side, resumable from a store, with every step also available on its own. Folios, uploads, declarations, waits.

Exchange and samples

The three signed exchange answers, the printed samples review and the GWT-RPC portals beneath them.

Receipts

The separate certification of receipts: set, issue, send, report, declare and verify, as pieces to chain.

The deterministic half (parseTestSetText, planCertificationSets, createFolioAllocator, issueTestSet, issueSimulation, createCertificationSalesBook, createCertificationPurchaseBook, createCertificationGuideBook) turns text into signed XML. It sends nothing, reads no clock but the one you inject and needs no portal. You can use it alone, for instance to inspect what a test set will issue.
The runner (runCertification and the step functions beneath it) sends, waits and declares. It keeps its progress in a CertificationStore and resumes from it, so a run that stops can be repeated after a fix without repeating what already stands.
The exchange and the printed samples are the last two stages: createExchangeAnswers and the exchange portal operations, writePrintedSamples and the samples portal operations.
Receipts have no runner: the SII's validation of the receipts set takes its own time, so you chain the pieces yourself and read the status again later.

Prerequisites#

A company enrolled in the certification process at the SII. Without it the test set download is refused (SII_PORTAL_REJECTED with notEnrolled). Enrolling is done at sii.cl, not with the SDK.
The activity verification, to issue with VAT. The SII requires a positive on-site verification of the company's activities, or one in progress, before the company issues documents with VAT (its requirements); without it, a CAF request for a type that needs it is refused with activityVerificationPending. Read where it stands with unstable_fetchActivityVerification, still unstable (see Portal and the API reference).
A digital certificate enabled as a login method on the SII portal. Otherwise the login throws SII_PORTAL_CERT_NOT_ENABLED. The portal guide (Portal) explains the session. The receipts declaration is made as the owner of the session (see Receipts). Passwords come from your environment (process.env.PFX_PASSWORD!), never from code.
The CAFs. The runner obtains them for you through the folio registry and the portal's quota (see Folios); the pieces take the CAFs you give them. The simulation never reuses the CAFs of the four sets.
The store. createDirectoryCertificationStore({ dir }) for a script, createMemoryCertificationStore() for tests, or your own CertificationStore. Plus a folio registry (createDirectoryFolioRegistry from dte-sdk/node, which must survive restarts) for the runner.
Issuer data. RUT, business name and address; the line of business, activity code, commune and city have defaults in the runner.
dte-sdk/pdf and its optional peers pdf-lib and bwip-js for the printed samples.

Where each function lives#

You want to	Use	Page
Read the SII test set text	`parseTestSetText`, `planCertificationSets`	Test sets
Issue the sets, the simulation and the books	`issueTestSet`, `issueSimulation`, `createCertification*Book`	Test sets
Run the whole HTML side	`runCertification`	The runner
Do one step after a rejection	`sendTestSet`, `declareTestSets`, `runBooks`…	The runner
Answer the exchange	`createExchangeAnswers`, `runExchange`	Exchange and samples
Upload the printed samples	`writePrintedSamples`, `uploadPrintedSamples`	Exchange and samples
Certify receipts	`downloadReceiptsTestSet`… `declareReceiptsCompliance`	Receipts

Next steps#

Start with Test sets to see what the SII asks for without touching a portal.
Read The runner before your first real run, in particular the warnings on folios and on the declaration.
Printing the PDFs is covered in Printed samples.

← PreviousErrors and Status Codes Next →Test Sets and Books