Nueva forma de envío de CPE de prueba.

Ahora, para poder enviar comprobantes de prueba, puedes usar la URL https://api-testing.facturaselectronicas.biz. De esta forma puedes probar el mismo listado de propiedades en pruebas como en producción. Los comprobantes enviados a esta nueva URL serán inmediatamente enviados a la SUNAT, por lo que podrás comprobar también si pasó su verificación.

Para esto, la propiedad modo_prueba ha sido removida, y su uso generará un error.

Cabeceras HTTP más estándares en la petición a la API.

Para definir el formato de comunicación, ahora se usa la cabecera HTTP “Content-Type“, que puede tener dos valores:

  • text/plain, para usar el formato ‘texto’.
  • application/json, para usar JSON.

El token ahora se envía usando la cabecera HTTP “Authorization“, con el prefijo “Bearer“, seguido de un espacio, seguido del token de seguridad. E.g.:

Authorization: Bearer 1b4b3e18f9b03a483be11aa1aa756ec349467404ba91d0de1f1ec93402234066

Las cabeceras anteriores con sus valores (i.e. “x-token” y “x-formato“) aún siguen siendo válidas.

Mejoras en códigos de errores

Los errores han sido uniformizados. Ahora, todo error devuelve siempre cuatro variables:

  1. estado, con el valor “error“.
  2. codigo_error, con un nombre fijo que identifica al error.
  3. descripcion_error, con una explicación del error. Y
  4. descripcion_extra, con información particular sobre lo que causó el error. Puede tener un valor vacío.

El error será devuelto en el formato que se solicitó en la petición HTTP, salvo que el error suceda al muy inicio de la validación, cuando aun no se ha procesado el formato (e.g. cuando la conexión se realiza por otro verbo HTTP distinto a POST, o el formato consignado es erróneo). En dicho caso, la información siempre será devuelta en JSON.

Los errores han sido divididos en 5 categorías, cada uno con un código HTTP:

  • 400: Errores de sintaxis o valores incorrectos en las propiedades enviadas.
  • 403: Errores de autorización, como UUID o token inválido.
  • 405: Cuando hay una conexión que no es por HTTP POST. El formato de la respuesta a este error siempre será JSON.
  • 406: Errores en los parámetros iniciales de la conexión, o en la configuración de la cuenta. E.g. formato desconocido, envío de comprobante a la URL de producción cuando la cuenta aun no ha sido pasada a producción, etc.
  • 500: Ha sucedido un error inesperado. El administrador del sistema ya habrá sido advertido. Si te comunicas con nosotros, por favor pásanos el valor de descripcion_extra, para poder facilitar la búsqueda de la causa del problema.

Si la operación sucedió correctamente, el código HTTP será 200.

Cambios en los parámetros de la API

  • Emitir:
    • La propiedad bolsa_plastico ha sido marcada como obsoleta, y debes evitar usarla. Ahora está la propiedad total_icbper para la suma de todos los impuestos, y la propiedad icbper dentro de cada ítem, para consignar el impuesto en cada producto gravado, de forma similar a las propiedades total_igv e igv, respectivamente.
    • Debido a un cambio en la entrega de comprobantes a la SUNAT, los ceros a la izquierda en el valor de la propiedad numero ahora serán removidos.
  • Todos:
    • Como indica el primer apartado, la propiedad modo_prueba ha sido removida, y fallará con un error al ser usada.

Corrección de errores internos

  • Hemos reparado un error que no colocaba el Content-Type correcto a la respuesta (siempre respondía con valor text/html).
  • Ahora la SUNAT no genera una observación si no se especifica la propiedad opcional codigo de un ítem.