Los documentos tributarios electrónicos deben cumplir con un formato definido por el SII, este formato se llama el esquema del DTE, específicamente, es el esquema del XML del DTE. El XML es el archivo con el DTE, que incluye todo el documento, también el timbre y la firma.

Existe un esquema para todos los DTE menos boletas y otros esquema para las boletas.

Cuando un documento que se genera no cumple con el esquema, se produce un error y el DTE no se genera.

El error ocurre, por lo general, por documentos emitidos vía API, esto ya que vía API se procesan los datos como vienen y se hacen algunos ajustes del proceso de normalización, pero en general se asume que quien emite vía API, envía los datos correctos.

A pesar de lo anterior, existe un proceso de verificación de datos, el cual incluye algunas validaciones de problemas o errores típicos para evitar que un documento llegue a ser rechazado por esquema.

Si un documento es rechazado por esquema en la aplicación web, su folio queda sin usar y no se recupera de manera automática.

Para entender esto hay que explicar cómo se emite un DTE en la aplicación web:

1. El usuario genera un DTE temporal (vía web o API):
   • Los datos pasan por un proceso de validación general, que verifica algunos problemas comunes.
   • Se trata de validar cosas que podrían generar errores o rechazos, pero que no se pueden validar por esquema.
   • Por ejemplo una nota de crédito sin referencia o que el DTE de exportación hotelero venga con pasaporte
   • Si ocurre un error, el DTE temporal no se crea, se reporta al usuario el error y nunca se pidió un folio.
2. El usuario crea el DTE real (vía web o API):
   • Se debe crear el XML real del EnvioDTE con el DTE que se está generando, con su timbre y las 2 firmas (firma DTE y firma EnvioDTE).
   • Es necesario usar el folio real que el DTE tendrá, por lo tanto aquí se solicita un folio al sistema en una transacción (para asegurar que el folio sólo se usa una vez y se actualiza el folio para pasar al siguiente).
   • Con el XML del EnvioDTE generado se hace una última validación antes de enviar al SII, la del esquema. Si todo está ok el XML se envía al SII. Si hay un error el DTE real no se genera (queda como temporal) y el folio se pierde (ya que ya se avanzó al siguiente folio).

Cuando el DTE real falla por esquema, no es posible retroceder el folio, ya que se arriesga la parte principal de la emisión, que el folio sea único y no se repita.

Se explican 2 alternativas que aparentemente podrían solucionar el problema de la pérdida del folio, pero que generan otro problema:

• Solicitar folio y no actualizar el siguiente a menos que pase la validación de esquema: el problema sería que desde que se pide el folio hasta que se valida el esquema del DTE, no se podría emitir otro DTE del mismo tipo, ya que la transacción quedaría bloqueada en la base de datos. Perdemos paralelismo.

• Retroceder folio perdido, actualizando el folio siguiente al folio que se perdió de manera automática: el problema sería que si mientras se validaba el esquema, se emitió otro DTE del mismo tipo, el folio siguiente avanzo uno más (o sea 2 en realidad), por lo cual si se retrocediese uno, se quedaría en el folio que si se emitió, o si se retrocede 2 (asignando el folio que falló) ese quedaría bien, pero al emitir el DTE y avanzar, el siguiente quedaría en un folio que ya se uso.

El problema de la asignación de folios tiene que considerar:

• Asignación única
• Asignación en paralelo

Por las razones anteriores, en LibreDTE al ocurrir un error de esquema, el folio simplemente se salta. El usuario puede luego consultar qué folios tiene saltados y anularlos en el SII.

En general, los problemas de esquema en la aplicación web están resueltos, si hubiese alguno que se detecte, por favor informar abriendo un ticket para revisar.

Los problemas de esquema por emisión vía API son responsabilidad del software que emite el DTE, LibreDTE hace el esfuerzo en el proceso de normalización, pero considerando todos los posibles casos, se recomienda que sea quien emite el DTE vía API quien valide los datos que envía de acuerdo a los instructivos del SII.