Saltar al contenido principal
Lerian Consignado publica sus hechos de negocio como CloudEvents 1.0. Los hechos emitidos entran al outbox transaccional antes de la publicación.
Los contratos de payload a continuación describen el objeto data del CloudEvent. Una propiedad marcada con ? puede estar ausente. null es válido solo donde un contrato de payload lo escribe explícitamente.

Contrato de stream de la aplicación

El tema identifica la aplicación que produce el evento, no un evento en particular. Enruta por ce-source, ce-resourcetype y ce-eventtype. Usa ce-type como su compuesto calificado por fuente. Nunca infieras un evento a partir del nombre del tema.

Catálogo de eventos emitidos

Notación del payload

El wire usa JSON con nombres de propiedad en snake_case, excepto consignado.registro_b3.registered, que usa camelCase. Estos alias describen los formatos que usan los esquemas:
En consignado.solicitacao.received, consignado.portability_proposal.received, consignado.proposal.accepted, consignado.migracao.efetivada y consignado.rescisao.revertida, numero_inscricao_empregador es el número del empleador como Dataprev lo envió. Puede ser la raíz de 8 dígitos del CNPJ en lugar del CNPJ de 14 dígitos. En consignado.proposal.accepted, cnpj_empregador_completo false significa que el número es la raíz. originador_ref es el originador cuya oferta produjo el contrato. fundo_ref es el fondo que recibió el contrato en una cesión. El nuevo contrato de un refinanciamiento o de una renegociación que el gateway registró como aceptado hereda una parte de los contratos que reemplazó. Hereda una parte solo cuando todos esos contratos nombran la misma, y solo cuando no tiene esa parte. Un fondo del registro de fondos de Lender aparece con su id de fondo en Lender. En consignado.contract.registered, fund_ref es el fondo al que la averbação atribuye el contrato. En los hechos de averbação, remetente_fundo_ref es el fondo cuya credencial envió la averbação o su documentación. Está ausente cuando ninguna credencial de fondo envió ninguna de las dos, incluso cuando la averbação nombra un fondo.

Contratos de payload

El gateway descubre una solicitud de préstamo abierta en Dataprev.Asunto: id_solicitacao
prazo_cotacao es el plazo de cotización de la presubasta. Solo está presente cuando la solicitud de préstamo abre una ventana de presubasta.
El gateway descubre una oferta de portabilidad M011 activa y la registra con su envelope de outbox.Asunto: id_solicitacao
El gateway lee el margen del trabajador desde Dataprev.Asunto: request_ref
El gateway constata la propuesta aceptada del riel frente a la oferta durable del cliente. El gateway publica este hecho después de consignado.averbacao.confirmed, cuando Dataprev acepta la documentación (Manual 004). consignado.averbacao.accepted no lo dispara, así que puede llegar días después de la averbação.Asunto: proposal_ref
Dataprev acepta la averbação (Manual 003). El mandato de descuento en nómina existe en el riel, y el contrato espera su documentación. Envía la documentación mediante POST /v1/consignado/contracts/{numero_contrato}/ccb-attachment. Este hecho no contabiliza, no desembolsa ni factura. Contabiliza un contrato solo a partir de consignado.contract.registered.Una exclusión todavía puede cancelar la averbação mientras no haya una llamada de documentación a Dataprev en curso y Dataprev no haya aceptado la documentación. Cuando Dataprev confirma la exclusión, llega consignado.exclusao.confirmed, y no se publican ni consignado.averbacao.confirmed ni consignado.contract.registered.Una suscripción limitada a un originador recibe este hecho solo cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo lo recibe solo cuando remetente_fundo_ref nombra a ese fondo. consignado.averbacao.documentation_deadline, consignado.averbacao.confirmed y consignado.averbacao.rejected siguen la misma regla. Un fondo también recibe consignado.averbacao.documentation_deadline cuando fundo_ref lo nombra, lo que cubre a un fondo que heredó un contrato renegociado.La credencial de fondo o de originador que envió la averbação o su documentación la lee con GET .../averbacao. Para cualquier otro contrato, una credencial de fondo o de originador recibe 404. La credencial propia del tenant lee todos los contratos.averbado_at es el instante en que el gateway registró la aceptación del Manual 003. Cuando el gateway comprueba un resultado desconocido leyendo el contrato de vuelta en Dataprev, dataprev_success_code es GW-M005-AVERBADO y averbado_at es el instante de esa lectura.Asunto: contract_id
La documentación de una averbação aceptada vence en 48 horas (approaching), o está vencida (expired). El Manual 004 da a la institución 7 días después de la averbação para enviar la documentación. El gateway cuenta 7 días calendario desde averbado_at. Este hecho es solo una señal. El gateway no excluye ni cambia el contrato cuando el plazo pasa.El gateway publica este hecho solo para una averbação que espera su documentación. Ninguna llamada a Dataprev con su documentación (Manual 004) está abierta. Ninguna exclusión está pendiente o confirmada para ella. No salió del registro. Una documentación que el gateway aceptó pero no envió a Dataprev no impide el hecho. Cada contrato recibe approaching una vez, 48 horas antes de documentation_due_at, y expired una vez, en documentation_due_at. Un contrato que el gateway encuentra por primera vez después de su instante de vencimiento recibe solo expired. El ce-id es estable para cada contrato y etapa. ce-time es el instante en que el gateway escribió el hecho.averbado_at repite el valor de consignado.averbacao.accepted, y documentation_due_at es averbado_at más 7 días. averbado_at_origin es dataprev_response cuando el gateway registró averbado_at al recibir la aceptación de Dataprev. Es recovery_read cuando una lectura posterior en Dataprev comprobó la aceptación. En ambos casos, el plazo de Dataprev puede ser anterior a documentation_due_at. La diferencia puede ser mayor con recovery_read. Un contrato comprado por portabilidad también recibe las dos etapas, sin consignado.averbacao.accepted antes de ellas.Un contrato que una renegociación mediante el gateway creó recibe las mismas dos etapas, contadas 7 días corridos desde la aceptación de la renegociación. En ese hecho, contract_id es el id de la renegociación que lista GET /v1/consignado/rail-commands, averbado_at es el instante en que Dataprev aceptó la renegociación, y remetente_fundo_ref está ausente. fundo_ref nombra al fondo que el contrato tiene o heredó de un contrato cedido que reemplazó. Una averbação nunca lleva fundo_ref.La señal de plazo está desactivada por defecto. Un despliegue publica este hecho solo mientras la señal está activada.Asunto: contract_id
Dataprev acepta la documentación de una averbação aceptada (Manual 004), y la averbação queda completa. El Manual 004 da a la institución 7 días después de la averbação para enviar la documentación. El gateway no controla ese plazo. consignado.averbacao.documentation_deadline señala ese plazo.averbado_at y dataprev_success_code mantienen los valores del Manual 003 del hecho de aceptación. Lee el instante de la averbação en averbado_at, no en la hora de publicación.Asunto: contract_id
Dataprev rechaza la averbação (Manual 003). Cuando el gateway comprueba un resultado desconocido leyendo el contrato de vuelta en Dataprev y Dataprev no tiene ese préstamo, error_code es el código HY del Manual 005. Un envío fallido de la documentación (Manual 004) no publica ningún hecho.Una averbação rechazada libera su numero_contrato. Puedes enviar una averbação corregida para el mismo número con un nuevo contract_id y una nueva clave de idempotencia. El contract_id rechazado queda gastado. Así, consignado.averbacao.accepted, consignado.averbacao.confirmed u otro consignado.averbacao.rejected pueden llegar para el mismo numero_contrato bajo un contract_id distinto. Correlaciona por contract_id en cada intento.Asunto: contract_id
La contabilización del contrato alcanza su límite inmutable. Para una averbação hecha mediante el gateway con el bloque de contabilización, este hecho llega después de consignado.averbacao.confirmed. Una averbação sin el bloque de contabilización nunca lo emite. Una importación de contrato con booking lo emite sin ningún hecho de averbação. Un contrato comprado por portabilidad de entrada con booking lo emite después de que Dataprev acepta la documentación, y consignado.averbacao.accepted no lo precede. Contabiliza un contrato solo a partir de este hecho.El campo dados_cadastrais_digest_sha256 es el digest SHA-256 del cadastro que el gateway almacenó para el contrato. El gateway almacena un cadastro para cada contrato, con al menos nome_trabalhador. El campo solo falta en un contrato que el gateway guardó antes de almacenar un cadastro para cada contrato.El campo signature.signed_at es el data_hora_assinatura de la documentación. Los otros campos de signature y los dos artifacts también vienen de la documentación, excepto signature.binding_method, que siempre es portal_attested. Los campos identity.esocial_category y identity.admission_date describen el vínculo laboral. Cada uno viene del cadastro de la averbação o, si falta, de la lectura de margen más reciente en Dataprev para el mismo trabajador y empleador. Cada uno queda ausente cuando no se conoce.Los campos declared_terms.origination_fee_amount y preparation repiten las declaraciones del cliente en la solicitud de averbação. El gateway verifica su formato y que origination_fee_amount sea menor que principal_amount, y nunca los consulta. Un origination_fee_amount ausente significa cero.En un contrato contabilizado con el bloque de contabilización, principal_amount menos iof_amount menos origination_fee_amount es igual a liberated_amount. La averbação y la importación de contrato rechazan una contabilización que rompe esta regla. Responden 422 DECLARED_TERMS_INCONSISTENT. En un contrato comprado por portabilidad, liberated_amount es principal_amount menos iof_amount: la liquidación de los contratos de origen más el troco.El bloque portability_in está presente solo en un contrato comprado por portabilidad. origins tiene una entrada por cada contrato de origen que la compra liquidó, en el orden de booking.origins. origin_institution es el código COMPE del banco de origen con tres dígitos, por ejemplo 001. external_operation_ref es el número del contrato en el banco de origen. transferred_principal en un origen es la parte que el cliente declaró para ese contrato. En el bloque, es la suma de los orígenes. effective_at es el instante de la exclusión de origen más reciente.El gateway espera mientras el estado de portabilidad de Dataprev muestra solo algunos de los orígenes contabilizados como excluidos. No publica ningún hecho y estaciona el contrato para un operador en dos casos. Dataprev muestra un contrato excluido que booking.origins no nombra, o la espera pasa de 20 días corridos desde la documentación confirmada.Cada monto y cada tasa de este hecho tiene exactamente dos decimales, por ejemplo 1201.20 y 100.00.Asunto: numero_contrato
El cliente confirma que el trabajador recibió los fondos.Asunto: numero_contrato
Un cliente reemplaza un CCB firmado o un pago ya confirmado. El payload apunta al recurso corregido. Los consumidores lo recuperan mediante M2M autenticado y verifican su digest SHA-256. El ce-resourcetype del evento distingue el tipo de corrección.Asunto: numero_contrato
Dataprev acepta la propia exclusión de portabilidad del lado de origen de este gateway. El contrato sale de la institución, por lo que la administración de cartera downstream puede detenerse. Este hecho no reporta el lado de la institución receptora y no lleva ningún monto de liquidación.El hecho también sigue cuando cierras como aceptada una exclusión detenida, después de que una lectura de Dataprev muestre el contrato excluido por portabilidad.Asunto: numero_contrato
Dataprev rechaza la propia exclusión de portabilidad del lado de origen de este gateway. El contrato permanece vigente.El gateway también publica este hecho cuando sabe que la exclusión no se ejecutó. reason_code es GW-NAO-ENVIADO cuando la llamada nunca salió del gateway. Es OZ cuando Dataprev respondió el rechazo por cambio de competencia y ningún otro código. Son los códigos de Dataprev cuando el rechazo comprueba que nada se ejecutó. Es GW-M005-NAO-EXECUTADO cuando una lectura de Dataprev hecha una hora después del plazo de la exclusión todavía muestra el contrato activo. Envía la exclusión de nuevo con una nueva clave. Cuando cierras como rechazada una exclusión detenida, reason_code es GW-BANCO-RECUSADO.Asunto: numero_contrato
Dataprev acepta una renegociación por término de vínculo. El nuevo contrato, numero_contrato, reemplaza al contrato cerrado, numero_contrato_encerrado, en el nuevo vínculo laboral del trabajador. iniciada_por es siempre cliente: toda renegociación viene de la operación de renegociación. numero_contrato es el número que elegiste. matricula y la inscripción del empleador describen el nuevo vínculo. Un campo que el origen no trajo está ausente.Un hecho recuperado, o un hecho de un cierre que haces tú, lleva los términos de una lectura de contrato en Dataprev y ningún hash_operacao. Tampoco lleva dataprev_success_code, el código de éxito de la respuesta de Dataprev a la llamada. Un hecho de la propia llamada lo lleva cuando Dataprev envió uno.Asunto: numero_contrato
Una renegociación por término de vínculo es rechazada. El contrato cerrado sigue cerrado, y no existe ningún contrato nuevo. numero_contrato_tentado es el número de nuevo contrato que la renegociación pidió. iniciada_por es siempre cliente, y refused_by es siempre dataprev.reason_code contiene el código de Dataprev, o varios códigos unidos por coma. El gateway también publica este hecho cuando la renegociación comprobadamente no se ejecutó. reason_code es entonces GW-NAO-ENVIADO cuando la llamada nunca salió del gateway, u OZ cuando Dataprev respondió el rechazo por cambio de competencia y ningún otro código. reason_code es GW-BANCO-RECUSADO cuando cierras como rechazada una renegociación estacionada.Una falla de transporte, un código que el gateway no reconoce u OZ junto a otro código no publica ningún hecho, y el comando sigue estacionado. Lee GET /v1/consignado/rail-commands para conocer su resultado; nunca lo reenvíes con una nueva clave mientras el resultado sea desconocido. Cuando el comando sea rechazado, la misma clave repite el rechazo, así que envía la renegociación de nuevo con una nueva clave.Asunto: numero_contrato_encerrado
La exclusión del contrato alcanza un estado terminal exitoso. La versión del esquema es 1.3.0.El hecho también llega cuando el gateway lee un contrato en Dataprev y lo encuentra ya fuera del registro. No hay detrás una exclusión mediante el gateway. evidence_source es entonces m005_external_exit, y reason_code es contract_left_registry.situacao_<n> o contract_left_registry.situacao_2.origem_<n>. El contrato fue excluido en el portal o por otro origen (situação 2), cerrado (situação 3) o renegociado fuera del gateway (situação 16). El gateway publica este hecho una vez por cada contrato. No tiene provider_reference. motivo_exclusao está presente solo cuando la lectura nombra un motivo. outcome_at es el instante de la exclusión en el registro, o el inicio de la lectura para un contrato cerrado. Esta ruta corre solo donde el seguimiento de documentación o la lectura de conciliación está activado.El gateway no publica ese hecho para estos contratos:
  • Un contrato en situação 15, porque la deuda sigue en pie. El gateway lo lee de nuevo cada semana y publica el hecho si una lectura posterior muestra otra salida.
  • Un contrato que una reversión de refinanciamiento excluyó. consignado.refinanciamento.revertido lo informa.
  • Un contrato que una exclusión o una exclusión de portabilidad de origen mediante el gateway sacó del registro, o está sacando.
  • Un contrato que un refinanciamiento o una renegociación mediante el gateway sustituyó, salvo que una reversión lo haya deshecho. consignado.refinanciamento.efetivado o consignado.renegociacao.efetivada lo informa.
Una exclusión por refinanciamiento (origem 7) publica el hecho solo después de que una segunda lectura, 14 días más tarde, muestra el contrato todavía fuera. Lo mismo vale para una exclusión por el gateway que se cerró como rechazada en una salida de origem 7: con el seguimiento de la documentación activado, el gateway lee el contrato de nuevo cuando pasan 14 días desde el instante de la exclusión, y publica el hecho una vez cuando el contrato sigue fuera. Una salida en situação 16 espera mientras un refinanciamiento o una renegociación del contrato mediante el gateway no tiene respuesta. Se publica si ese comando es rechazado.Cuando excluyes un contrato que una renegociación mediante el gateway reemplazó, el gateway excluye el número vigente en Dataprev. El hecho responde bajo el número que pediste en numero_contrato. numero_contrato_excluido nombra el número que el gateway excluyó, y está ausente cuando los dos números son iguales.Asunto: numero_contrato
La exclusión del contrato alcanza un estado terminal rechazado. La versión del esquema es 1.3.0. Con evidence_source exclude_response, Dataprev rechazó la exclusión. reason_code es ME cuando rechazó el motivo declarado, HY cuando no tiene ningún préstamo bajo la identidad enviada, o los dos códigos unidos por un punto. El rechazo no prueba que el contrato salió del registro. Con evidence_source m005_observation, una lectura de Dataprev mostró que el contrato ya había salido del registro de otra forma, y reason_code empieza con contract_left_registry.. Una nueva exclusión con el mismo motivo_exclusao devuelve el mismo rechazo. La excepción es un rechazo con reason_code contract_left_registry.situacao_2.origem_7: con el seguimiento de la documentación activado, el gateway lee el contrato de nuevo cuando pasan 14 días desde el instante de la exclusión. Si el portal revirtió el refinanciamiento, el mismo motivo_exclusao es un nuevo intento con un nuevo request_ref.Con evidence_source gateway_refusal, el gateway rechazó un comando consignado.exclusao.requested de Lender antes de llamar a Dataprev, y nada llegó a Dataprev. El hecho tiene el numero_contrato que Lender envió, una frase del gateway en message y ningún provider_reference. Su request_ref deriva del tenant y del request_ref del comando, así que cada comando genera un hecho. reason_code es uno de estos valores:
  • renegotiation_underway: una renegociación del contrato todavía no tiene respuesta de Dataprev. Envía un nuevo comando con un nuevo request_ref después de que la renegociación termine. El nuevo comando excluye el número vigente, nombrado en numero_contrato_excluido.
  • contract_left_registry.situacao_2.origem_2, con numero_contrato_excluido: una renegociación dio un nuevo número al contrato, y una exclusión pedida bajo ese número ya lo sacó del registro. El descuento se detuvo. No hay nada que enviar de nuevo.
  • dataprev_credential_unavailable: tu credencial de Dataprev está ausente o revocada en el gateway, y no existe un intento anterior para el comando. Sube la credencial y luego envía un nuevo comando con un nuevo request_ref. Nada corre por cuenta propia después de la subida.
  • contract_left_registry.situacao_<n> o contract_left_registry.situacao_<n>.origem_<m>: el contrato ya estaba fuera del registro cuando llegó el comando. La causa es una salida de Dataprev, una exclusión cuya lectura encontró el contrato ya fuera, una exclusión de portabilidad aceptada, o un refinanciamiento o una reversión hechos por el gateway. message dice que esta exclusión no corrió y que no hay nada que reenviar. Para una salida de origem 7, message dice que una reversión dentro de la ventana restaura el contrato.
Una reentrega del mismo comando no publica un segundo hecho y nunca excluye. Un rechazo del gateway no repite nada: un nuevo comando con el mismo motivo_exclusao es un nuevo intento, evaluado según la situación del contrato en ese momento. Un comando que repite un motivo_exclusao que un intento de exclusión anterior cerró como rechazado, con un nuevo request_ref, recibe el reason_code, el message y el evidence_source guardados. Un comando que repite un motivo_exclusao que el gateway ya confirmó recibe contract_left_registry.situacao_2.origem_2. Un comando que encuentra una llamada de documentación a Dataprev en curso se reentrega hasta que la llamada termina, y entonces excluye. La ruta HTTP de exclusión nunca publica este hecho.Asunto: numero_contrato
El gateway normaliza un registro contable, de repasse o de CSV de portal. El gateway publica un hecho dataprev_escrituracao por cada empleador, contrato y mes. En un mes de despido publica solo el primer registro de nómina o de indemnización que lee para ese empleador, contrato y mes, así que tipo_evento_esocial puede nombrar cualquiera de los dos.Un hecho dataprev_escrituracao y un hecho dataprev_repasse de un contrato llevan originador_ref y fundo_ref en el nivel superior cuando el contrato los tiene. Una parte que el contrato no tiene está ausente. Los hechos portal_csv no llevan ninguna de las dos claves.competencia está presente en todas las fuentes. En un hecho dataprev_repasse, es el mes del repasse esperado que el registro liquida o, si falta, el mes del riel. El registro conserva la propia competencia del riel. El gateway retiene un registro de repasse que no indica empleador ni mes hasta que un repasse esperado los aporta. Un registro de repasse que no indica mes y trae cargos por atraso queda retenido y no se publica hasta que lo liberes con un mes. Un registro de repasse de verbas rescisorias que no indica mes cierra la expectativa de verbas rescisorias de su contrato, y el gateway lo publica bajo el mes de esa expectativa.Asunto: object_ref
El gateway lee un registro de suspensión o terminación de empleo. Para una terminación, reason_code es el motivo de desvinculación de eSocial (Tabela 19) que Dataprev envía, como un entero sin relleno. Agrega un cero a la izquierda para obtener dos dígitos, por ejemplo 2 para 02. Está ausente cuando Dataprev no envía motivo.Cuando Dataprev informa una fecha de desvinculación distinta para un contrato que el gateway ya informó como terminado, el gateway publica un segundo hecho. Esto ocurre, por ejemplo, cuando un contrato es desvinculado de nuevo después de una migración automática. record_id del segundo hecho es el primer record_id más -YYYYMMDD, la nueva fecha de desvinculación. report_ref y status no cambian.Asunto: record_id
Se reporta una alerta de ausencia o terminación del trabajador.Asunto: SHA-256(payload)
Cambia el throughput efectivo de Dataprev de un tenant.Asunto: tenant_id
Un contrato pasa a un fondo. El hecho assignment_receivable.accepted de Lender es el único productor. El hecho identifica el contrato por numero_contrato, y cedido_by es siempre lender_fact. idempotency_key aparece solo cuando el contrato vino de una oferta de subasta. cedido_at es el accepted_at de Lender.El gateway no registra ninguna cesión, y no publica ningún hecho, para un contrato que salió del registro. Esto vale para un contrato que una exclusión confirmada o una exclusión de portabilidad aceptada sacó del registro. Vale también para un original que un refinanciamiento o una renegociación aceptada reemplazó, a menos que una reversión haya deshecho el refinanciamiento. Vale además para un contrato que una lectura de Dataprev encontró excluido, cerrado o renegociado (situação 2, 3 o 16), incluido uno cuya exclusión se cerró como contract_left_registry.*. Un contrato en situação 15 todavía puede cederse.Asunto: numero_contrato
El cliente informa el código del instrumento en B3 (Código IF) de un contrato con averbação confirmada. El gateway no contacta a B3 y no verifica el código contra el CCB. Este hecho usa nombres de propiedad en camelCase. El gateway lo publica una vez por contrato, con el mismo ce-id en cada entrega.El campo numeroCcb es el número del CCB en el cadastro almacenado, o numeroContrato cuando el cadastro no tiene uno. El campo dataRegistro es la fecha de registro en B3, cuando el cliente la envía. El campo registradoEm es el instante en que el gateway almacenó el código. El campo registradoPor indica el subject de quien llamó, cuando la identidad lo lleva.Una suscripción limitada a un originador o a un fondo no recibe este hecho. Solo una suscripción de todo el tenant lo recibe.Asunto: numero_contrato
Un repasse esperado supera su plazo o no tiene un plazo calculable.Una alarma repasse_missing se dispara solo después de que cierre un día hábil ANBIMA más allá del día del plazo. El gateway lo juzga con su última lectura limpia del riel. due_at sigue llevando el plazo, no el instante de la alarma. Una alarma deadline_uncomputable no recibe día extra.En un mes de desvinculación, el gateway sigue dos repasses esperados para un contrato: la cuota de la nómina y el descuento de las verbas rescisorias. Alarma cada uno por separado. El hecho de verbas rescisorias lleva verbas_rescisorias: true, y su object_ref termina en /verbas-rescisorias. El hecho de la nómina omite verbas_rescisorias.Asunto: object_ref
Un movimiento resuelve un repasse vencido. El gateway también publica este hecho para un repasse que ve por primera vez después de due_at, así que puede llegar sin ningún consignado.repasse.overdue antes. No supongas que todo resolved responde a un overdue. En un mes de desvinculación, el repasse de verbas rescisorias lleva verbas_rescisorias: true, como en consignado.repasse.overdue.Asunto: object_ref
El gateway no puede establecer una observación actual del riel para las expectativas.Asunto: object_ref
Se publica una ventana operativa del calendario de descuentos.Asunto: competencia_consulta
Un job programado del gateway recibe el rechazo del cambio de competencia de Dataprev, y el gateway abre una pausa para el tenant. Solo los despliegues en Lerian Cloud emiten este hecho. hold_until es el fin de la primera espera, no el fin del cambio de competencia.Asunto: tenant/<tenant_id>
La pausa del tenant termina. Solo los despliegues en Lerian Cloud emiten este hecho. episode tiene el mismo valor que en el hecho de pausa que cierra. Un ciclo programado que empezó a llamar a Dataprev en el instante en que se abrió la pausa, o después, puede cerrarla. El gateway publica el hecho cuando Dataprev responde ese ciclo sin el rechazo por cambio de competencia (OZ). El hecho nunca llega solo por el paso del tiempo. Cuando hold_until pasa, el sondeo puede reanudarse, y el hecho llega después del primer ciclo que Dataprev responde.Asunto: tenant/<tenant_id>
Dataprev acepta un refinanciamiento. Todo contrato en contratos_refinanciados queda liquidado, y el nuevo contrato, numero_contrato, toma su lugar. El gateway publica este hecho en tres casos. Se acepta la llamada que envías mediante la operación de refinanciamiento. El ciclo de recuperación comprueba que una llamada con respuesta perdida sí se efectuó. Cierras como aceptado un comando estacionado.Un refinanciamiento hecho fuera del gateway no publica nada. Una suscripción limitada a un originador recibe este hecho cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo lo recibe cuando fundo_ref nombra a ese fondo.novo_contrato está presente cuando la solicitud llevó el bloque booking. Lleva contract_id, numero_contrato, identity, declared_terms y margin_snapshot de consignado.contract.registered. declared_terms.liberated_amount es valor_pago más el troco. Lender contabiliza el nuevo contrato solo cuando novo_contrato está presente.Con el bloque de contabilización, el gateway publica este hecho solo con los términos que Dataprev confirmó. Cuando Dataprev muestra otra competencia, otro principal, otra cuota, otro número de cuotas u otra tasa, no llega ningún hecho y el comando sigue estacionado. Un hecho recuperado, o un hecho de un cierre que haces tú, toma los términos de una lectura de contrato en Dataprev y no lleva hash_operacao ni dataprev_success_code. Un hecho de la propia llamada lleva dataprev_success_code, el código de éxito de la respuesta de Dataprev, cuando Dataprev envió uno.Deduplica por tenant_id y numero_contrato. Lee originador_ref y fundo_ref en el nivel superior del payload. Se heredan de los contratos liquidados cuando el nuevo contrato no tiene los suyos.Asunto: numero_contrato
Una reversión excluye el nuevo contrato de un refinanciamiento, y los contratos que consignado.refinanciamento.efetivado listó vuelven a estar activos. El hecho llega cuando una reversión que envías mediante el gateway es aceptada, o cuando la recuperación comprueba una. También llega cuando la lectura diaria de seguimiento descubre que el cliente revirtió el refinanciamiento en el portal de Dataprev. Esa lectura cubre solo refinanciamientos que el gateway aceptó, durante 14 días después del resultado, y solo donde el seguimiento de documentación está activado. Cerrar un comando estacionado nunca produce este hecho.Un revertido puede llegar sin un efetivado antes. El ce-id deriva del tenant y del contrato, así que cada aviso de la misma reversión lo repite. Una suscripción limitada a un originador recibe este hecho cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo lo recibe cuando fundo_ref nombra a ese fondo.Asunto: numero_contrato
Un refinanciamiento es rechazado, o comprobadamente no se ejecutó. Los contratos que nombró siguen activos, y no existe ningún contrato nuevo. numero_contrato_tentado es el número que el refinanciamiento pidió. El número queda libre de nuevo, así que un efetivado posterior puede nombrarlo.reason_code contiene los códigos de Dataprev, unidos por coma cuando hay varios. Es GW-NAO-ENVIADO cuando la llamada nunca salió del gateway, y OZ cuando Dataprev respondió el rechazo por cambio de competencia y ningún otro código. Es GW-BANCO-RECUSADO cuando cierras como rechazado un comando estacionado.Una falla de transporte, un código que el gateway no reconoce u OZ junto a otro código no publica ningún hecho, y el comando sigue estacionado. Lee GET /v1/consignado/rail-commands para conocer su resultado; nunca lo reenvíes con una nueva clave mientras el resultado sea desconocido. Cuando el comando sea rechazado, la misma clave repite el rechazo, así que envía el refinanciamiento de nuevo con una nueva clave. El hecho no nombra a ninguna parte, así que solo una suscripción de todo el tenant lo recibe.Asunto: numero_contrato_tentado
Dataprev mueve un contrato al nuevo vínculo laboral del trabajador por cuenta propia, sin comando tuyo (migración automática, Manual 018). El gateway publica un hecho por cada contrato y nuevo vínculo. Cubre todo contrato que Dataprev devuelve bajo la credencial de la institución, incluidos los contratos que no registraste mediante el gateway. El hecho nunca lleva el CPF ni el nombre del trabajador.data_migracao es el día, en hora de Brasilia, de la ventana de lectura que devolvió primero el contrato. Cuando una lectura de contrato del Manual 005 encuentra la migración, es el día de esa lectura, y guarantee está ausente. Una segunda migración a otro vínculo es un nuevo hecho. El ce-id deriva del tenant y del vínculo, así que es estable en la reentrega. Deduplica por el ce-id, no por los campos del vínculo: las dos lecturas escriben los ceros a la izquierda de forma distinta.La lectura diaria viene desactivada por defecto. Corre solo mientras DATAPREV_MIGRACAO_ENABLED es true, y el primer ciclo después de que la actives también informa las migraciones de los 31 días anteriores. Una lectura de contrato del Manual 005 que el gateway hace, como la del seguimiento de la documentación, publica el mismo hecho para un contrato que encuentra migrado, también con ese valor false. Sale un hecho por cada contrato y vínculo, sea cual sea la lectura que lo vio primero. Una suscripción con una lista de tipos de evento recibe este hecho solo cuando la lista nombra consignado_migracao.efetivada. Edita la lista de una suscripción del tenant, o crea una suscripción que lo nombre. Una suscripción limitada a un originador recibe este hecho cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo lo recibe cuando fundo_ref nombra a ese fondo.Asunto: numero_contrato
Los tres campos de vínculo describen el nuevo vínculo. codigo_inscricao_empregador es 1 para un CNPJ y 2 para el CPF del empleador. guarantee es la garantía que el contrato mantiene después de la migración, en la forma de consignado.contract.registered. Está ausente cuando Dataprev no envía ninguna.
Una terminación fue cancelada. Una lectura de contrato de Dataprev encuentra un contrato que estaba en la situación 15 activo de nuevo, bajo el mismo vínculo de empleo. Una lectura bajo otro vínculo es una migración, y el gateway publica consignado.migracao.efetivada en su lugar. El gateway publica el hecho una vez, desde la lectura que levanta la terminación. El ce-id deriva del tenant, del contrato y de lido_em, así que una reentrega lo repite. Nunca lleva el CPF ni el nombre del trabajador.lido_em es el instante de la lectura. report_ref y record_id nombran el registro de terminación que la lectura levantó, como consignado.employment_status.reported lo publicó. Están ausentes cuando solo existía una lectura de la situación 15. Una suscripción con una lista de tipos de evento recibe este hecho solo cuando la lista nombra consignado_rescisao.revertida. Una suscripción limitada a un originador lo recibe cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo lo recibe cuando fundo_ref nombra a ese fondo.Subject: numero_contrato
El portal revirtió un refinanciamiento que el gateway no hizo. El gateway había visto el contrato salir del registro por un refinanciamiento hecho fuera de él (situación 2, origem 7). Una lectura posterior de contrato de Dataprev, después de que cerró la ventana de reversión, encuentra el contrato de vuelta en el registro. Una lectura que muestra el contrato saliendo de nuevo, con otro excluido_em u otro origen, es una nueva salida y no publica nada aquí. El gateway publica el hecho una vez, a partir de la lectura que muestra el contrato de vuelta. El ce-id se deriva del tenant, del contrato y de lido_em, así que una reentrega lo repite. Nunca lleva el CPF ni el nombre del trabajador.lido_em es el instante de esa lectura. situacao_emprestimo es la situación que devolvió la lectura. excluido_em es el instante de exclusión de la salida que el portal revirtió. Los campos del vínculo son los que mantiene el seguimiento, y están ausentes cuando ninguna lectura los trajo. Una suscripción con una lista de tipos de evento recibe este hecho solo cuando la lista nombra consignado_refinanciamento_externo.revertido.Subject: numero_contrato
El certificado A1 de Dataprev que el gateway guarda para la institución está por vencer. Cada certificado recibe como máximo dos avisos. stage es 30_days cuando quedan 30 días o menos, y 7_days cuando quedan 7 días o menos. Un certificado que el gateway ve por primera vez dentro de 7 días recibe solo 7_days. No existe etapa de vencido, así que un certificado vencido no recibe aviso. Una custodia revocada, o una custodia sin certificado, tampoco recibe ninguno. Un certificado renovado tiene una nueva huella y avisa de nuevo.La verificación corre una vez por hora por defecto, así que un aviso puede salir hasta una hora después de su umbral. Viene activada por defecto. El ce-id es estable para cada tenant, certificado y etapa, así que puedes deduplicar por él. ce-time es el instante en que el gateway escribió el hecho, no el vencimiento. El hecho no lleva material del certificado y no nombra a ninguna parte, así que solo una suscripción de todo el tenant lo recibe.Asunto: cert_fingerprint
La ventana de ejecución de la garantía de FGTS del contrato de un trabajador despedido se abrió, o cierra en 48 horas. El hecho es solo una señal: el gateway no ejecuta la garantía por sí mismo y nunca rechaza ni modifica un contrato por causa de él. Tu back office ejecuta la garantía con la ejecución de garantía de FGTS.Cada registro de despido recibe como máximo dos etapas. opened sale en la primera pasada en execution_from o después. closing sale una vez, en la primera pasada desde las 00:00 en hora de Brasilia del día 29 después del despido, 48 horas antes de que termine la ventana. Un registro que el gateway ve por primera vez ese día o después recibe solo closing. execution_from es la fecha del despido, o 20 días después cuando perc_verba_rescisoria_garantia es mayor que 0. execution_until es 30 días después del despido, inclusive.El hecho sale solo para un contrato cuya lectura de término de vínculo nombra una garantía de FGTS con saldo o multa distinto de cero. No sale cuando una ejecución del contrato está solicitada, ejecutada o con resultado desconocido, cuando una exclusión está solicitada, cuando una lectura posterior muestra que el contrato ya no está terminado por término de vínculo, cuando el gateway registra la salida o la migración del contrato, ni después de una renegociación aceptada. El ce-id deriva del tenant, del registro de despido y de stage. ce-time es el instante en que el gateway escribió el hecho, no un plazo. Una verificación corre una vez por hora por defecto, y viene activada por defecto. Solo una suscripción de todo el tenant recibe este hecho.Asunto: numero_contrato
Los tres campos de fecha llevan una fecha civil a medianoche UTC. reason_code es el código eSocial de despido sin cero a la izquierda (2, 5 o 27). Los dos montos y el porcentaje vienen de la lectura de término de vínculo, y cada uno está ausente cuando Dataprev no envió ninguno.
El bloqueo de FGTS de un contrato en Dataprev falló (código 2) o fue rechazado (código 4), de modo que el FGTS no garantiza el contrato. El hecho es solo una señal: el gateway nunca rechaza ni modifica el contrato.El gateway ve el bloqueo en la lectura de testigo de la averbação. Con el seguimiento de la documentación activado, también lo ve en una relectura diaria de cada contrato con garantía, hasta que el código de bloqueo sea definitivo. El hecho sale una vez por contrato, la primera vez que el código almacenado es 2 o 4. Nunca se retracta, aunque Dataprev reprocese el bloqueo después. El ce-id deriva del tenant y del contrato. Una suscripción de todo el tenant recibe este hecho. Una suscripción limitada a un fondo también lo recibe cuando fundo_ref nombra a ese fondo. Una suscripción limitada a un originador no lo recibe.Asunto: numero_contrato
situacao_bloqueio_garantia lleva el código 2 o 4 y el texto que Dataprev envió junto a él. observed_at es el instante de la lectura de Dataprev que vio el bloqueo.
El bancarizador desactivó o reactivó a un originador o a un fondo. Cada cambio real publica un hecho. Desactivar un registro desactivado, o reactivar un registro activo, no publica nada. Streaming Hub no entrega nada a las suscripciones de un socio desactivado mientras su registro está inactivo. Tras la reactivación, entrega los hechos publicados desde ese momento. El gateway se niega a arrancar cuando STREAMING_EVENT_POLICIES deshabilita este hecho. Solo una suscripción de todo el tenant lo recibe.Asunto: <kind>/<registry_id>
registry_id es el id que devuelven las operaciones de registro de originador y de fondo. ativo es el estado después del cambio. Guarda, para cada kind y registry_id, el estado que lleva el changed_at más reciente.
Una presubasta se resolvió con al menos una cotización. Sale un hecho por cada cotización, incluidas las not_elected, cuando se resuelve la presubasta. Una presubasta que se resuelve sin cotización no publica nada. Streaming Hub lo entrega a una suscripción de todo el tenant. Una suscripción limitada a un originador también lo recibe cuando originador_ref nombra a ese originador. Una suscripción limitada a un fondo no lo recibe.Asunto: id_solicitacao
originador_ref está ausente en una cotización de la cuenta propia del bancarizador. outcome es accepted cuando Dataprev aceptó al menos una propuesta de la cotización. Es refused cuando Dataprev o el gateway rechazó la cotización, not_elected cuando la ventana cerró sin enviar la cotización y no_answer cuando el gateway envió la cotización y no supo de respuesta. codigo guarda el código o los códigos de rechazo de Dataprev, separados por coma, y solo está presente cuando Dataprev rechazó la cotización. Los dos números de propuesta son los números que el gateway dio a las propuestas al recibir la cotización. criterio es el criterio de la ventana.

Comandos consumidos desde Lender

Estos son comandos entrantes, no eventos emitidos por Consignado. Llegan en lerian.streaming.lender.commands con ce-source: lender y ce-type: studio.lerian.lender.<resource>.<event>. La averbação y su documentación no son comandos de Lender. Envía ambas mediante las operaciones HTTP autenticadas. La lectura de margen del trabajador tampoco es un comando de Lender. Usa POST /v1/consignado/workers/margin.

Hechos consumidos desde Lender

El gateway también actúa sobre cuatro hechos de Lender. Llegan en lerian.streaming.lender con ce-source: lender. El gateway omite todos los demás hechos de Lender en ese tema y todo hecho de un tenant que no atiende. Un hecho que el gateway no puede leer termina en el DLQ del consumidor.

Reglas de entrega y compatibilidad

  • Deduplica por (ce-source, ce-id) y haz que los handlers sean idempotentes.
  • ce-id es un UUID versión 7. Trátalo como opaco y ordena por ce-time. Algunos hechos derivan un ce-id estable de su clave de negocio, por lo que cada anuncio del mismo hecho lo repite y el ce-id no lleva ningún instante.
  • Lee ce-schemaversion antes de decodificar. El header lleva la versión del esquema, y el tema nunca la lleva.
  • El dinero y las tasas son cadenas decimales. Los timestamps están en UTC, en formato RFC 3339. Los valores de solo fecha usan YYYY-MM-DD, y las competências usan YYYYMM.
  • Las claves de comando entrantes desconocidas o no admitidas terminan en el DLQ del consumidor de Consignado.
  • La falta de un identificador de negocio obligatorio impide la publicación o la ejecución del comando. Consignado nunca lo genera.