Skip to main content
O Lerian Consignado publica seus fatos de negócio como CloudEvents 1.0. Os fatos emitidos entram no outbox transacional antes da publicação.
Os contratos de payload abaixo descrevem o objeto data do CloudEvent. Uma propriedade marcada com ? pode estar ausente. null é válido apenas onde um contrato de payload o escreve explicitamente.

​
Contrato do stream de aplicação

O tópico identifica a aplicação produtora, não um evento único. Faça o roteamento por ce-source, ce-resourcetype e ce-eventtype. Use ce-type como o composto qualificado por source desses três. Nunca infira um evento a partir do nome do tópico.

​
Catálogo de eventos emitidos

​
Notação do payload

O wire usa JSON com nomes de propriedade em snake_case, exceto consignado.registro_b3.registered, que usa camelCase. Estes aliases descrevem os formatos usados pelos esquemas:
originador_ref é o originador cujo lance produziu o contrato. fundo_ref é o fundo que recebeu o contrato em uma cessão. O novo contrato de um refinanciamento ou de uma renegociação que o gateway registrou como aceito herda uma parte dos contratos que ele substituiu. Ele herda uma parte apenas quando todos esses contratos nomeiam a mesma, e apenas quando ele não tem essa parte. Um fundo do cadastro de fundos do Lender aparece com seu id de fundo no Lender. Em consignado.contract.registered, fund_ref é o fundo ao qual a averbação atribui o contrato. Nos fatos de averbação, remetente_fundo_ref é o fundo cuja credencial enviou a averbação ou sua documentação. Ele fica ausente quando nenhuma credencial de fundo enviou nenhuma das duas, mesmo quando a averbação nomeia um fundo.

​
Contratos de payload

O gateway descobre uma solicitação de empréstimo aberta no Dataprev.Assunto: id_solicitacao
O gateway descobre uma oferta de portabilidade M011 ativa e a registra com seu envelope de outbox.Assunto: id_solicitacao
O gateway lê a margem do trabalhador no Dataprev.Assunto: request_ref
O gateway constata a proposta aceita do trilho em relação à oferta durável do cliente. O gateway publica este fato depois de consignado.averbacao.confirmed, quando o Dataprev aceita a documentação (Manual 004). consignado.averbacao.accepted não o dispara, então ele pode chegar dias depois da averbação.Assunto: proposal_ref
O Dataprev aceita a averbação (Manual 003). O mandato de desconto em folha existe no trilho, e o contrato aguarda sua documentação. Envie a documentação por POST /v1/consignado/contracts/{numero_contrato}/ccb-attachment. Este fato não contabiliza, não desembolsa e não fatura. Contabilize um contrato apenas a partir de consignado.contract.registered.Uma exclusão ainda pode cancelar a averbação antes do envio da documentação. Quando o Dataprev confirma a exclusão, consignado.exclusao.confirmed vem em seguida, e nem consignado.averbacao.confirmed nem consignado.contract.registered são publicados.Uma subscription restrita a um originador recebe este fato apenas quando originador_ref nomeia esse originador. Uma subscription restrita a um fundo o recebe apenas quando remetente_fundo_ref nomeia esse fundo. consignado.averbacao.documentation_deadline, consignado.averbacao.confirmed e consignado.averbacao.rejected seguem a mesma regra.A credencial de fundo ou de originador que enviou a averbação ou sua documentação a lê com GET .../averbacao. Para qualquer outro contrato, uma credencial de fundo ou de originador recebe 404. A credencial do próprio tenant lê todos os contratos.averbado_at é o instante em que o gateway registrou a aceitação do Manual 003. Quando o gateway comprova um resultado desconhecido lendo o contrato de volta no Dataprev, dataprev_success_code é GW-M005-AVERBADO e averbado_at é o instante dessa leitura.Assunto: contract_id
A documentação de uma averbação aceita vence em 48 horas (approaching), ou está vencida (expired). O Manual 004 dá à instituição 7 dias após a averbação para enviar a documentação. O gateway conta 7 dias corridos a partir de averbado_at. Este fato é apenas um sinal. O gateway não exclui nem altera o contrato quando o prazo passa.O gateway publica este fato apenas para uma averbação que aguarda sua documentação. Ela está em attachment_pending, nenhuma tentativa de documentação está aberta, nenhuma exclusão está pendente ou confirmada para ela, e ela não saiu do registro. Cada contrato recebe approaching uma vez, 48 horas antes de documentation_due_at, e expired uma vez, em documentation_due_at. Um contrato que o gateway encontra pela primeira vez depois do seu instante de vencimento recebe apenas expired. O ce-id é estável para cada contrato e etapa. ce-time é o instante em que o gateway gravou o fato.averbado_at repete o valor de consignado.averbacao.accepted, e documentation_due_at é averbado_at mais 7 dias. averbado_at_origin é dataprev_response quando o gateway registrou averbado_at ao receber a aceitação do Dataprev. É recovery_read quando uma leitura posterior no Dataprev comprovou a aceitação. Nos dois casos, o prazo do Dataprev pode ser anterior a documentation_due_at. A diferença pode ser maior com recovery_read.O sinal de prazo vem desabilitado por padrão. Um deploy publica este fato apenas enquanto o sinal está habilitado.Assunto: contract_id
O Dataprev aceita a documentação de uma averbação aceita (Manual 004), e a averbação está completa. O Manual 004 dá à instituição 7 dias após a averbação para enviar a documentação. O gateway não controla esse prazo. consignado.averbacao.documentation_deadline sinaliza esse prazo.averbado_at e dataprev_success_code mantêm os valores do Manual 003 do fato de aceitação. Leia o instante da averbação em averbado_at, não no horário de publicação.Assunto: contract_id
O Dataprev rejeita a averbação (Manual 003). Quando o gateway comprova um resultado desconhecido lendo o contrato de volta no Dataprev e o Dataprev não tem esse empréstimo, error_code é o código HY do Manual 005. Uma falha no envio da documentação (Manual 004) não publica nenhum fato.Assunto: contract_id
A contabilização do contrato atinge seu limite imutável. Para uma averbação feita pelo gateway com o bloco de contabilização, este fato vem depois de consignado.averbacao.confirmed. Uma averbação sem o bloco de contabilização nunca o emite. Uma importação de contrato com booking o emite sem nenhum fato de averbação. Contabilize um contrato apenas a partir deste fato.O campo dados_cadastrais_digest_sha256 é o digest SHA-256 do cadastro que o gateway armazenou para o contrato. O gateway armazena um cadastro para todo contrato, com pelo menos nome_trabalhador. O campo só fica ausente em um contrato que o gateway salvou antes de armazenar um cadastro para todo contrato.O campo signature.signed_at é o data_hora_assinatura da documentação. Os outros campos de signature e os dois artifacts também vêm da documentação, exceto signature.binding_method, que é sempre portal_attested. Os campos identity.esocial_category e identity.admission_date descrevem o vínculo empregatício. Cada um vem do cadastro da averbação ou, na falta dele, da leitura de margem mais recente no Dataprev para o mesmo trabalhador e empregador. Cada um fica ausente quando desconhecido.Os campos declared_terms.origination_fee_amount e preparation repetem as declarações do cliente na requisição de averbação. O gateway verifica o formato deles e que origination_fee_amount seja menor que principal_amount, e nunca os consulta. Um origination_fee_amount ausente significa zero.Todo valor e toda taxa deste fato têm exatamente duas casas decimais, por exemplo 1201.20 e 100.00.Assunto: numero_contrato
O cliente confirma que o trabalhador recebeu os recursos.Assunto: numero_contrato
Um cliente substitui uma CCB assinada ou um pagamento já confirmado. O payload aponta para o recurso corrigido. Os consumidores o recuperam por M2M autenticado e verificam seu digest SHA-256. O ce-resourcetype do evento distingue o tipo de correção.Assunto: numero_contrato
O Dataprev aceita a exclusão de portabilidade do lado de origem deste gateway. O contrato deixa a instituição, então a gestão da carteira downstream pode parar. Este fato não reporta o lado da instituição de destino e não carrega valor de liquidação.Assunto: numero_contrato
O Dataprev rejeita a exclusão de portabilidade do lado de origem deste gateway. O contrato permanece em vigor.O gateway também publica este fato, com reason_code GW-M005-NAO-EXECUTADO, para uma exclusão que não recebeu resposta. Ele faz isso quando uma leitura do Dataprev feita uma hora após o prazo da exclusão ainda mostra o contrato ativo. Envie a exclusão de novo com uma nova chave.Assunto: numero_contrato
O Dataprev aceita uma renegociação por término de vínculo. O novo contrato, numero_contrato, substitui o contrato encerrado, numero_contrato_encerrado, no novo vínculo empregatício do trabalhador. iniciada_por é cliente para uma renegociação que você envia pela operação de renegociação. Ele é gateway para uma renegociação automática, e o gateway criou numero_contrato. matricula e a inscrição do empregador descrevem o novo vínculo. Um campo que a origem não trouxe fica ausente.Em uma renegociação automática, competencias_puladas lista as competências do contrato encerrado do mês do desligamento até a anterior à competência atual. O novo contrato não as cobre. Ele fica ausente quando não há nenhuma.Assunto: numero_contrato
Uma renegociação por término de vínculo é recusada. O contrato encerrado continua encerrado, e nenhum novo contrato existe. numero_contrato_tentado é o número do novo contrato que a renegociação pediu. iniciada_por indica quem começou a renegociação, como em consignado.renegociacao.efetivada. Quando refused_by é dataprev, reason_code contém o código do Dataprev, ou vários códigos unidos por vírgula.Quando refused_by é gateway, o gateway devolveu o contrato sem um envio, e iniciada_por é gateway. reason_code contém um motivo de devolução. numero_contrato_tentado é o número que o gateway criou, e ele nunca chegou ao Dataprev. O gateway publica no máximo uma devolução para cada contrato encerrado.Assunto: numero_contrato_encerrado
A exclusão do contrato atinge um estado terminal de sucesso.Assunto: numero_contrato
A exclusão do contrato atinge um estado terminal de rejeição. A versão do esquema é 1.1.0. Com evidence_source exclude_response, o Dataprev recusou a exclusão, e o contrato continua no registro. Com evidence_source m005_observation, uma leitura do Dataprev mostrou que o contrato já tinha saído do registro de outra forma, e reason_code começa com contract_left_registry.. Uma nova exclusão com o mesmo motivo_exclusao retorna a mesma rejeição.Assunto: numero_contrato
O gateway normaliza um registro de escrituração, repasse ou CSV do portal.competencia está presente em toda origem. Em um fato dataprev_repasse, ela é o mês do repasse esperado que o registro liquida ou, na falta dele, o mês do trilho. O registro mantém a própria competencia do trilho. O gateway retém um registro de repasse que não indica empregador ou mês até que um repasse esperado os forneça. Um registro de repasse que não indica mês e traz encargos de atraso ou verbas rescisórias fica retido e não é publicado até que a Lerian o resolva.Assunto: object_ref
O gateway lê um registro de suspensão ou desligamento do vínculo empregatício.Assunto: record_id
Um alerta de afastamento ou desligamento do trabalhador é reportado.Assunto: SHA-256(payload)
O throughput efetivo de um tenant no Dataprev muda.Assunto: tenant_id
Um crédito ou contrato passa para um fundo. Dois produtores escrevem este fato. A operação de cessão identifica o crédito pelo idempotency_key do lance, com cedido_by: bancarizador_command. O fato do Lender assignment_receivable.accepted identifica o contrato por numero_contrato, com cedido_by: lender_fact, e também carrega o idempotency_key do lance para um contrato de leilão. O campo cedido_at é o instante da operação ou o accepted_at do Lender. A operação de cessão recusa um crédito com 409 CESSAO_CREDIT_NOT_WITNESSED até que sua averbação esteja confirmada.Assunto: numero_contrato quando presente, senão idempotency_key
O cliente informa o código do instrumento na B3 (Código IF) de um contrato com averbação confirmada. O gateway não contata a B3 e não confere o código com a CCB. Este fato usa nomes de propriedade em camelCase. O gateway o publica uma vez por contrato, com o mesmo ce-id em toda entrega.O campo numeroCcb é o número da CCB no cadastro armazenado, ou numeroContrato quando o cadastro não tem um. O campo dataRegistro é a data de registro na B3, quando o cliente a envia. O campo registradoEm é o instante em que o gateway armazenou o código. O campo registradoPor indica o subject de quem chamou, quando a identidade o carrega.Uma subscription restrita a um originador ou a um fundo não recebe este fato. Só uma subscription do tenant inteiro o recebe.Assunto: numero_contrato
Um repasse esperado ultrapassa seu prazo ou não tem prazo calculável.Assunto: object_ref
Uma movimentação resolve um repasse em atraso.Assunto: object_ref
O gateway não consegue estabelecer uma observação atual do trilho para as expectativas.Assunto: object_ref
Uma janela operacional do calendário de descontos é publicada.Assunto: competencia_consulta
Um job agendado do gateway recebe a recusa da virada de competência do Dataprev, e o gateway abre uma pausa para o tenant. Apenas deploys na Lerian Cloud emitem este fato. hold_until é o fim da primeira espera, não o fim da virada de competência.Assunto: tenant/<tenant_id>
A pausa do tenant termina. Apenas deploys na Lerian Cloud emitem este fato. episode tem o mesmo valor do fato de pausa que ele encerra.Assunto: tenant/<tenant_id>

​
Comandos consumidos do Lender

Estes são comandos de entrada, não eventos emitidos pelo Consignado. Eles chegam em lerian.streaming.lender.commands com ce-source: lender e ce-type: studio.lerian.lender.<resource>.<event>. A averbação e sua documentação não são comandos do Lender. Envie as duas por meio das operações HTTP autenticadas.

​
Fatos consumidos do Lender

O gateway também atua sobre quatro fatos do Lender. Eles chegam em lerian.streaming.lender com ce-source: lender. O gateway ignora todos os outros fatos do Lender nesse tópico e todo fato de um tenant que ele não atende. Um fato que o gateway não consegue ler cai na DLQ do consumidor.

​
Regras de entrega e compatibilidade

  • Deduplique por (ce-source, ce-id) e torne os handlers idempotentes.
  • ce-id é um UUID versão 7. Trate-o como opaco e ordene por ce-time. Alguns fatos derivam um ce-id estável da sua chave de negócio, então todo anúncio do mesmo fato o repete e o ce-id não carrega nenhum instante.
  • Leia ce-schemaversion antes de decodificar. O header carrega a versão do esquema, e o tópico nunca carrega.
  • Valores monetários e taxas são strings decimais. Os timestamps estão em UTC, no formato RFC 3339. Valores apenas de data usam YYYY-MM-DD, e competências usam YYYYMM.
  • Chaves de comando de entrada desconhecidas ou sem suporte caem na DLQ do consumidor do Consignado.
  • Um identificador de negócio obrigatório ausente impede a publicação ou a execução do comando. O Consignado nunca o sintetiza.