About Us 

El detalle disponible en las distintas APIs que se quiera integrar incluye toda la información técnica para la integración de cada una:
 

• Riesgos
• Ventas
• Financiación 
• Impagos

Se utiliza JSON, puedes descargar aquí las distintas colecciones Postman necesarias para trabajar en nuestro entorno Sandbox.

En función de la aplicación que se quiera integrar, existen distintos juegos de datos disponibles (Sandbox Model) que pueden utilizarse para confirmar la respuesta esperada antes de dar el paso a datos productivos:
 

• Juego de datos para Riesgos
• Juego de datos para Ventas
• Juego de datos para Financiación
• Juego de datos para Impagos

Sobre los datos de Riesgos, los campos classificationDecisionCode y validityReasonCode comparten los mismos códigos de la tabla 5 aunque se refieren a diferentes aspectos:
 

• classificationDecisionCode describe el motivo del estado de un límite de riesgo y por qué se ha clasificado así.
• validityReasonCode describe el motivo por el que tiene una determinada validityDate, es decir, por qué se ha concedido dicha fecha de validez a esa clasificación.

Sobre los datos de Ventas, las tablas 2-3 de statusCode y reasonStatusCode hacen referencia al API de Ventas, mientras que las tablas 4-5 se refieren al API de Prórrogas. Una prórroga es tratada como una nueva venta, por lo que tiene su propio statusCode y reasonStatusCode.

Es necesario configurar dos elementos para generar el token (API_KEY + SECRET_KEY), puedes revisar cómo hacerlo en nuestros vídeos de soporte.

La llamada tiene una duración de validez por 1 hora y podrá invocarse al API suscrito tantas veces como sea necesario durante ese tiempo. Una vez transcurrida esa hora, deberá volver a llamarse de nuevo al token de autenticación para poder seguir operando.

Al realizar una solicitud individual de clasificación, se genera un número para esa solicitud. Las solicitudes finalmente clasificadas generan un suplemento con ese mismo número, mientras que las denegadas no llegan a generar dicho suplemento ni se muestran en la tabla de cartera de Cesnet.

Ante una solicitud de límite de crédito (creditLimitRequested), el crédito concedido (creditLimitGranted) puede ser igual cuando se conceda la totalidad del importe solicitado o menor si la concesión es parcial.

El API devolverá distintos statusCode según el caso y referidos siempre a la petición de cobertura realizada, no a la póliza contratada:
 

• 66 cuando el límite concedido se ponga en vigor.
• 1 cuando la solicitud quede en trámite y requiera ser procesada manualmente. Esto puede ocurrir en solicitudes de límite superiores a lo habitual, referidas a empresas de reciente creación o que sean de países sobre los que no exista información mínima para el proceso automático. Podrá volver a consultarse más adelante con una llamada GET para confirmar la respuesta final del equipo de Riesgos de Cesce.
• 2 cuando la solicitud de cobertura sea anulada, generalmente tras un proceso manual por parte de Cesce.

Se asignará un número de suplemento (endorsementNo) a cada deudor dentro de la póliza, manteniéndose el mismo durante toda la vigencia de la póliza.

Podrá incorporarse también el código de deudor asignado en el propio sistema ERP del asegurado (customerReference) aunque al ser un código propio, debe ser comunicado a Cesce si se quiere utilizar en la gestión de la póliza.

En el caso de una solicitud de cancelación sobre una cobertura contratada, el API devolverá una respuesta 200 con el campo de código vacío cuando la anulación sea correcta o bien indicará un motivo cuando no sea posible realizar la anulación.

Es necesario realizar una llamada API para declarar cada venta que se desee comunicar de forma individual, incluyendo cada una de ellas su correspondiente importe, vencimiento y código identificativo (salesCesceReference).

Es posible agrupar internamente varias facturas por deudor pero deben remitirse como una venta única a efectos de declaración a Cesce.

En el caso de facturas multivencimiento, es necesario declarar una venta con su correspondiente importe y fecha de vencimiento para cada uno aunque pueden llevar todas ellas el mismo número de factura. No es posible sin embargo agrupar varias facturas como un único pagaré.

A la hora de modificar una fecha de vencimiento, puede modificarse sobre la venta original con una llamada POST si se trata de corregir un error previo o bien utilizar la declaración de prórroga, según establezcan las condiciones y requisitos de la póliza contratada.

El primer caso se utilizará únicamente para corregir posibles errores, mientras que el segundo genera una nueva venta prorrogada con un número saleCesceReferenceNo distinto, prima diferenciada y un nuevo campo maturityAmount, que recogerá el importe impagado de la factura inicial y no podrá ser en cualquier caso mayor a esa factura original.

Existen otros conceptos que deben ser igualmente tenidos en cuenta a la hora de trabajar con ventas:
 

• Venta endosada: se produce cuando se realiza una venta contra un suplemento anulado o con fecha de vencimiento cumplida pero se permite igualmente la tarificación. Sólo se permite en pólizas que tengan contratado el suplemento de Endosos.
• Abonos: se produce cuando hay una factura con importe negativo y tiene implicaciones en prima, ya que ésta debe devolverse al no existir realmente la venta declarada. El abono puede ser total o parcial sobre la venta realizada pero implicará una prima negativa por parte de Cesce cuando la póliza contratada incluya el suplemento de Abonos.

En caso de que lo incluya, también es importante el orden de las declaraciones porque debe haber una venta previa en positivo que poder compensar. Si el abono es total y se da de forma automatizada en el mismo mes que la venta, la prima quedará compensada sin efecto económico para el asegurado..

La fecha de adquisición es obligatoria para este tipo de pólizas, mientras que no es necesario declarar el taxCodeTransferor sin que sólo se requeriría en operaciones de Factoring con responsabilidad.