Nuevo administrador de equipos bloqueados

Los servidores de alojamiento web de IcaServer poseen un mecanismo de seguridad para evitar el acceso a sus servicios (como cPanel, envio y recepción de correos, etc) usando «fuerza bruta» para adivinar la contraseña, mecanismo usado por bots y malware para realizar acciones dañinas: Si alguien (o algo) intenta ingresar con una contraseñas erradas 10 veces, el servidor bloqueará totalmente el acceso de dicho equipo o red al servidor afectado.

Qué hacer si mi equipo fue bloqueado

Si sospechas que tu equipo ha sido bloqueado (no puedes ingresar a tu correo, cPanel, o web), ingresa al Panel de Clientes. Al ingresar, si tu equipo está bloqueado, te aparecerá un aviso en la parte superior con un enlace para que obtengas mayor información al respecto.

Si el equipo que sospechas que ha sido bloqueado no es el tuyo, primero obtén la dirección IP pública de él, ingresando (desde ese equipo) a https://ip.x10.pe (u otro servicio de obtención de IP pública), luego en el Panel de Clientes ingresa al apartado Alojamientos web, y elije la opción Equipos bloqueados. En esa página, escribe el IP a verificar, y dale clic al botón «Consultar bloqueo de IP».

En ambos casos aparecerá información sobre el bloqueo:

Pantalla de información de un equipo bloqueado

Antes de solicitar el desbloqueo, asegúrate de haber resuelto el problema que lo causó (un cliente de correo mal configurado, alguien accediendo a una cuenta de FTP con una contraseña errada, etc. En el ejemplo, fue un problema de contraseña en el envío de correo). Solo tienes una cantidad limitada de veces que puedes solicitar el desbloqueo de un IP.

Actualización 202107 de la API de facturación

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.