Changelog - Consentimento - v2.0.0

Descrição macro das alterações aplicadas às APIs de Dados Cadastrais e Transacionais em relação aos payloads:

  • Nenhum campo poderá receber o valor NA. Seguem regras de acordo com os casos:

    • Obrigatórios: foram revistas as mandatoriedades a fim de atender as regras de negócios de cada um dos produtos;

    • Opcionais: para estes casos basta não enviar o campo;

    • Condicionais: se comportam como opcionais, exceto quando o cenário se encaixar na restrição incluída na descrição;

    • Enums: Retiradas as opções com valor NAO_APLICA e similares;

    • Removidos todos os atributos Nullable dos campos, que foram analisados obedecendo critérios de mandatoriedade e cenários de negócio.

  • Com o objetivo de normalizar o formato dos dados entre as pontas, foram acrescentados patterns em todos os campos elegíveis.

  • Foram normalizados os atributos dos campos de acordo com o seu tipo de dado.

  • Todas as ocorrências de campos additionalInfo foram alteradas para opcional ou condicional de acordo com suas características de negócio. Para os campos condicionais foram acrescentadas restrições de cenário de uso.

  • Foram alterados todos os campos numéricos do tipo double para string com format double, com isso garantimos que exista um formato de dados padrão, tornando possível que todas as casas, considerando suas peculiaridades sistêmicas, consigam realizar o tráfego das informações.

  • Revista a mandatoriedade dos arrays, considerando os seguintes cenários:

    • Obrigatórios, passam a receber minItems: 0. Considerando que caso as informações não existam, o array precisa ser enviado vazio. Nesse cenário atendemos ao conjunto de informações relativas a um produto, onde um cenário específico não pode ser atendido mesmo existindo como característica do produto, é como quem está enviando dizer “não tenho essa informação para este produto”.

    • Opcionais e condicionais, passam a receber minItems: 1. Caso não exista a informação basta não enviar o array, existindo, deve ser preenchido pelo menos 1.

  • Inserção e remoção de campos atendendo às especificidades de cada produto (API).

  • Removidos os campos totalPages e totalRecords dos exemplos de response codes de exceção.

  • Adicionados novos response codes.

 

Campo

O que foi feito?

transactionFromDateTime

Removido campo

transactionToDateTime

Removido campo

Propriedade de extensibilidade

Removida a explicitude do additionalProperties

Response code

Adicionado o status code 529

 

Campo

O que foi feito?

transactionFromDateTime

Removido campo

transactionToDateTime

Removido campo

rejection

Campo criado

Propriedade de extensibilidade

Removida a explicitude do additionalProperties

Response code

Adicionado o status code 529

 

Campo

O que foi feito?

Response code

Adicionado o status code 529