...
ID | Solucionado? | Crítico | API / Sessão | Endpoint | Campo | Como está? Qual o problema? | Como deveria ser? | Orientação até publicação do ajuste | Responsável | Dicionário OK? | Swagger OK? | Comentário | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
BCLOG-F02-198 |
| Sim | Todas da Fase 2 | Todos da Fase 2 | O campo self dentro do objeto links | Não existe uma definição clara de como este campo deve ser utilizado | O atributo self no caso de uso do methodo GET deverá retonar o link para a propria pagina. No caso do methodo Post deverá retonar o link para o recurso criado | O atributo self do objeto link: | Força Tarefa | SimParcialmente | Sim | Precisa ser ajustado no portal do desenvolvedorParcialmente | A solução definitiva foi incoporada no swagger apenas para as API Contas, Cartões de Crédito, Empréstimos, Dados Cadastrais, Consentimentos e Recursos. | ||||||
BCLOG-F02-199 | Sim | Sim | Credit-card-accounts | /accounts/{creditCardAccountId}/bills/{billId}/transactions | /data/ chargeIdentificator | Campo está como obrigatório | Condicionado (opcional + restrição) ao pagamento ter parcelas Descrição: [Restrição] O campo deve ser preenchido quando houver parcelas relacionadas a transação. | Identificador da parcela que está sendo informada. Campo de livre preenchimento quando existir parcelas. | GT Especificações | Não | Não | BCLOG-F02-200 | Sim | Sim | API Recursos | /resources- | A previsão de resposta 202 não está contemplada A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||
BCLOG-F02-200 | Sim | Sim | API Recursos | /resources | - | A previsão de resposta 202 não está contemplada no Swagger | A resposta 202 deveria ter sido declarada | A instituições receptoras devem aceitar o http Status 202 body vazio e adotar o comportamento descrito nas páginas 68, 74 e 88 do Guia de Implementação das APIs da Fase 2: | GT Especificações | Sim | Não | O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | |||||||
BCLOG-F02-201 | Sim | Todas as APIs de crédito | /contracts /contracts/{contractId} | /ipocCode | Hoje o pattern ( ^\d{22,67}$ ) aplicado inviabiliza a utilização de caracteres alfabéticos, na composição do ipocCode | O REGEX precisa ser corrigido levando em consideração as regras do IPOC | Utilizar o pattern ^[\w\W]{22,67}$ | GT Especificações | NãoParcialmente | Não | BCLOG-F02-202 | Parcialmente | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos. | ||||||
BCLOG-F02-202 | Sim | Todas as APIs de crédito | /contracts | /contractNumber | Hoje o pattern ( ^\d{1,100}$ ) aplicado inviabiliza a utilização de caracteres alfabéticos, na composição do contractNumber | O REGEX precisa ser corrigido para que viabilize o preenchimento com caracteres alfabéticos e especiais | Utilizar o pattern ^[\w\W]{1,100}$ | GT Especificações | Não | NãoParcialmente | Parcialmente | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos. | |||||||
BCLOG-F02-203 | Sim | Todas as APIs de crédito | /contracts/{contractId}/scheduled-instalments | /paidInstalments /dueInstalments /pastDueInstalments | Atualmente o tamanho máximo dos atributos paidInstalments, dueInstalments e pastDueInstalments, está em 999, porém existem cenários de parcelas que podem chegar até 4 dígitos,. | Revisar os três campos para levar em consideração maximum do campo /totalNumberOfInstalments | Considerar maximum: 999999999 | GT Especificações | NãoParcialmente | Não | BCLOG-F02-204 | Parcialmente | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos. | ||||||
BCLOG-F02-204 | Sim | Não | API Consents | - | Descrição do Swagger | Alteração obrigatória do status AWAITING_AUTHORISATION para REVOKED após 60 minutos | Alteração obrigatória do status AWAITING_AUTHORISATION para REJECTED após 60 minutos | Seguir o diagrama de estados de consentimentos, descrito no Guia de implementação da v2.0 das APIs de Dados Cadastrais e Transacionais | GT Especificações | Sim | Sim | O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | |||||||
|
|
|
|
|
|
|
|
|
|
| Este problema conhecido foi substituído pelo BCLOG-F02-217 | ||||||||
BCLOG-F02-206 | Sim | Sim | Credit-card-accounts | /transactions | /billPostDate | O Campo billPostDate é obrigatório da API de Cartão de crédito, ENDPOINT /accounts/{creditCardAccountId}/transactions, porém, as transações são enviadas de forma online, conforme uso do cliente, antes da postagem na fatura, portanto, nesse momento, não há a Data em que a transação foi inserida na fatura ainda | O campo deveria ser opcional | Preencher o campo com a data dummy: 0001-01-01, apenas para os casos nos quais ainda não houver a data de inserção na fatura | GT Especificações | Não | NãoSim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||||||
BCLOG-F02-207 | SIM | Não | Credit-card-accounts | /limits | pagination-key (parâmetro) | O endpoint limits prevê o uso do parâmetro pagination-key, entretanto, não possui os parâmetros page e pagesize, o que inviabiliza o seu uso | O parâmetro pagination-key não deveria existir ou ele poderia existir complementado pelos parâmetros page e pagesize | Não utilizar o parâmetro pagination-key para este endpoint | GT Especificações | Sim | Não | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||||||
BCLOG-F02-208 | Não | Accounts | /transactions /transactions-current | /partieCompeCode | A descrição do campo indica a possibilidade de informar NA porém o pattern não permite | A descrição do campo não deveria indicar a possibilidade de informar NA no campo | Não informar NA | GT Especificações | Não | Não | BCLOG-F02-209 | Não | Accounts | /accounts/{accountId} | /compeCode | A descrição do campo indica Sim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | |
BCLOG-F02-209 | Não | Accounts | /accounts/{accountId} | /compeCode | A descrição do campo indica a possibilidade de informar NA porém o pattern não permite | A descrição do campo não deveria indicar a possibilidade de informar NA no campo | Não informar NA | GT Especificações | Não | Não | BCLOG-F02-210 | Sim | Accounts | Sim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | |||
BCLOG-F02-210 | Sim | Accounts | /accounts/{accountId} /accounts/{accountId}/balances /accounts/{accountId}/transactions /accounts/{accountId}/transactions-current /accounts/{accountId}/overdraft-limits | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e API de Contas (Accounts) página 73, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, não foi definido um código de erro para o cenário: Com consentimento autorizado (conta inexistente) | Deveria existir um código de erro padronizado para esta situação | Utilizar o Status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | ||||||||
BCLOG-F02-211 | Sim | Credit-card-accounts | /accounts/{creditCardAccountId} /accounts/{creditCardAccountId}/bills /accounts/{creditCardAccountId}/bills/{billId}/transactions /accounts/{creditCardAccountId}/limits /accounts/{creditCardAccountId}/transactions /accounts/{creditCardAccountId}/transactions-current | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e API de Cartões de Crédito (Credit-card-accounts) (Análoga ao caso de Accounts) página 83, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (conta inexistente) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | ||||||||
BCLOG-F02-212 | 0 | Sim | Todas as APIs de crédito | /contracts/{contractId} /contracts/{contractId}/warranties /contracts/{contractId}/scheduled-instalments /contracts/{contractId}/payments | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e as APIs de Operações de Crédito na página 105, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (recurso inexistente) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | |||||||
BCLOG-F02-213 | Sim | Todas as APIs de crédito | /contracts/{contractId} /contracts/{contractId}/warranties /contracts/{contractId}/scheduled-instalments /contracts/{contractId}/payments | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e as APIs de Operações de Crédito na página 103, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (aprovado múltipla alçada) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere | ||||||||
BCLOG-F02-214 | Sim | Accounts | /accounts/{accountId}/balances | /data/automaticallyInvestedAmount/amount | O pattern do campo não permite valores negativos e por regra de negócio será um cenário possível | O pattern deveria aceitar valores negativos | Instituições Financeiras devem considerar: string($double)pattern: ^-?\d{1,15}\.\d{2,4}$maxLength: 21 | GT Especificações | Não | Não | BCLOG-F02-215 | Sim | Accounts Customers Credit-cardSim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||||
BCLOG-F02-215 | Sim | Accounts Customers Credit-card-accounts | Todos (exceto listagem) | errors/code (quando ocorre um erro 403) | Nas págs 70, 77 e 101-106 temos o código definido fora do padrão contendo letras maiúsculas e minúsculas, conforme abaixo: status_RESOURCE_PENDING_AUTHORISATION status_RESOURCE_UNAVAILABLE status_RESOURCE_TEMPORARILY_UNAVAILABLE | Os códigos deveriam ter apenas letras maiúsculas, conforme abaixo: STATUS_RESOURCE_PENDING_AUTHORISATION STATUS_RESOURCE_UNAVAILABLE STATUS_RESOURCE_TEMPORARILY_UNAVAILABLE | Utilizar o formato com letras maiúsculas | GT Especificações | Sim | Sim | |||||||||
BCLOG-F02-216 | Sim | Customers | /personal/identifications /business/identifications | /data/contacts/phones/number | O pattern ^([0-9]{8,11})$ do campo data/contacts/phones/number não é adequado para telefones de alguns países (ex: Alemanha), que podem ter a quantidade de números inferiores a 8 ou superiores a 11 | O pattern deveria contemplar a quantidade de dígitos de telefone de todos os países | Neste momento não devem ser compartilhados telefones de outros países além do Brasil, ou seja, não compartilhar telefones com DDI diferente de 55 | GT Especificações | NãoSim | NãoSim | |||||||||
BCLOG-F02-217 | Sim | Loans Unarranged-accounts-overdraft | /contracts/{contractId} | /preFixedRate /postFixedRate | Nas APIs Loans e Unarranged-accounts-overdraft, os campos preFixedRate e postFixedRate estão como obrigatórios, porém, os contratos possuem características de possuir somente uma das taxas, ou pré-fixada ou pós-fixada. Anteriormente, era permitido o envio de NULL | Os campos deveriam ser opcionais ou condicionais | Preencher o campo não aplicável ao contrato com zeros, seguindo o pattern (0.000000) | GT Especificações | Não | Não | BCLOG-F02-218 | Sim | Unarranged-accounts-overdraft | Sim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | |||
BCLOG-F02-218 | Sim | Unarranged-accounts-overdraft | /contracts/{contractId} | /instalmentPeriodicityAdditionalInfo /amortizationScheduledAdditionalInfo | Na API Unarranged-accounts-overdraft, os campos instalmentPeriodicityAdditionalInfo e | Os campos deveriam ser opcionais ou condicionais | Preencher os campos com string vazia ("") | GT Especificações | Não | Não | |||||||||
BCLOG-F02-219 | Sim | Customers | /business/identifications | /data/contacts/postalAddresses | A lista de objetos /data/contacts/postalAddresses que está no Endpoint /business/identifications da versão 2.0.1 exige no mínimo um objeto, ou seja, um endereço que nem sempre existe para os cadastros PJ | Deveria ser adotada a mesma proposta do endpoint /personal/identifications, que permite uma lista vazia | Caso não exista um endereço a ser comunicado, criar um objeto "Dummy" com os seguintes valores para seus atributos: | GT Especificações | Não | Não | BCLOG-F02-220 | Sim | Customers | /business/identifications | /Sim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||
BCLOG-F02-220 | Sim | Customers | /business/identifications | /address /townName | O REGEX ('^\w{2}[\w\W\s]*$') dos campos não permite o uso de abreviaturas no início do nome | O REGEX deveria permitir abreviaturas | Utilizar o pattern [\w\W\s]* | GT Especificações | Não | Não | BCLOG-F02-221 | Sim | Accounts | /transactions /transactionsSim | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | |||
BCLOG-F02-221 | Sim | Accounts | /transactions /transactions-current | - | Regras para consulta de lançamentos futuros não são claras | Regras de lançametos futuros devem ser revistas | Conforme descrição, os endpoints /transactions e /transactions-current devem retornar às transações realizadas e os lançamentos futuros. Desta forma, para se obter os lançamentos futuros, deverá ser fornecido o intervalo de datas contemplando as datas do lançamento futuro. A consulta de lançamentos futuros estará restrita a 12 meses no futuro. | GT Especificações | Sim | Sim | Sim |
|
|
A A orientação até publicação" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do cliente para discussão futura. | |||||
|
|
|
|
|
|
|
|
|
|
| |||||||||
BCLOG-F02-223 | Sim | Customers | /business/identifications | /data/parties/civilName | A restrição está orientando o preenchimento obrigatório quando o person type for PESSOA_JURIDICA | O correto deveria ser PESSOA_NATURAL | [Restrição] O campo civilName deve ser obrigatoriamente preenchido quando personType for PESSOA_NATURAL. | GT Especificações | NãoSim | Não | BCLOG-F02-224 | Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||||||
BCLOG-F02-224 | ID utlizado para criação de um item na planilha de problemas conhecidos da v1.x da fase 2 | ||||||||||||||||||
BCLOG-F02-225 | Não | Invoice Financings | /contracts/{contractId}/payments | paymentId | O pattern aplicado para paymentId diverge do utilizado para o mesmo campo em outros endpoints das demais APIs de operações de crédito | O correto deveria ser ^[a-zA-Z0-9][a-zA-Z0-9-]{0,99}$ | Considerar o pattern ^[a-zA-Z0-9][a-zA-Z0-9-]{0,99}$ | GT Especificações Dados do cliente | Não | Não | |||||||||
BCLOG-F02-226 | ID utlizado para criação de um item na planilha de problemas conhecidos da v1.x da fase 2 | ||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
| Problema conhecido substituído pelo BCLOG-F02-228 | ||||||||
BCLOG-F02-228 | Não | Todas da Fase 2 | Todos | x-fapi-interaction-ID | Na documentação atual de segurança, o x-fapi-interaction-ID não tem geração obrigatória pelo consumidor do serviço, entretanto a IN306, na sua seção 5.2, determina que o seu envio seja obrigatoriamente feito pelo consumidor do serviço (receptor). Esta informação necessita ser enviada pelo consumidor e pelo provedor à Plataforma de Coleta de Métricas – PCM e também é necessária na abertura de tickets bilaterais no Service Desk | O x-fapi-interaction-ID é de geração e envio obrigatório pela receptora (client) e o seu valor deve ser "reproduzido" pela transmissora (server) no cabeçalho de resposta | Para a receptora (client)
Para a transmissora (server)
| GT Especificações Dados do cliente | Sim | NãoParcialmente | Parcialmente | A solução definitiva foi incoporada no swagger apenas para as API Contas, Cartões de Crédito, Empréstimos, Dados Cadastrais, Consentimentos e Recursos. | |||||||
BCLOG-F02-229 | Não | API Accounts | Existe a possibilidade de alguns tipos de conta não possuírem limites associados. Para esses cenários o endpoint espera que nenhum dado seja preenchido no objeto “data” (objetos internos opcionais), porém não existem instruções detalhadas sobre esse cenário e isto gerou dúvidas sobre qual o comportamento correto para algumas instituições | A descrição da API deveria explicitar o comportamento para este cenário | Para as instituições financeiras transmissoras que tenham contas nessa situação a orientação é retornar HTTP Status 200 com o objeto “data” vazio, sem nenhum atributo interno | GT Especificações Dados do cliente | Sim | NãoSim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | ||||||||||
BCLOG-F02-230 | Não | API Credit Cards Accounts | GET /credit-cards-accounts/v2/accounts | name e creditCardNetwork | Para algumas instituições os campos “name” e “creditCardNetwork” podem retornar nomes de bandeira distintos para o cenário de troca de bandeira de conta cartão. Por exemplo: name=”INSTITUIÇÃO MASTERCARD” , (herda o nome da conta cartão com a nova bandeira) e creditCardNetwork=”VISA” (herda a bandeira do cartão físico em uso e quando a ativação do novo cartão é feita a bandeira assume a da conta cartão). | Em cenários ideais, o nome da bandeira contido no nome do cartão de crédito deveria ser coerente com o nome da bandeira informada no campo “creditCardNetwork”. | As instituições financeiras receptoras de dados devem estar cientes de que em situações específicas podem haver divergências entre o nome do cartão e a bandeira. Está no backlog do GT o levantamento de regras de negócio que impliquem nesse cenário. | GT Especificações Dados do cliente | Sim | Não | BCLOG-F02-231 | Todas de Operações de Crédito | Warranties | - | A documentação da API não dá Sim | A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro. | |||
BCLOG-F02-231 | Todas de Operações de Crédito | Warranties | - | A documentação da API não dá clareza de como tratar produtos nos quais não se aplica o produto de garantia | Nos casos em que não haja garantia para o produto deve se enviar lista vazia para o campo data | Enviar lista vazia para o campo data caso não haja garantia | NãoParcialmenteNão | Parcialmente | Desconsiderar a orientação dada no BCLOG-F02-222 | BCLOG-F02-232 | Dados Cadastrais | GET /personal/ identification GET /business/ identification | /data/contacts/emails/email | O pattern do campo é muito abrangente e não válida características de padrão de e-mail pattern: [\w\W\s]* | Considerar o pattern abaixo na validação do conteúdo do campo pattern: ^[a-z0-9.!#$&'*+\/=?^_`{|}~-]+@[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?(?:\.[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?)*$ | A instituição transmissora deverá retornar um padrão válido de e-mail, conforme coluna “como deveria ser?”A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos. |