1. Problema/dúvida em questão (na perspectiva do desenvolvedor):
   Campos produzidos pelo SQL Processing (sql pipeline) com case diferente do que especificado no Datamodel estavam tinha seus valores ignorados no parse de informações.
2. Causa raiz do problema (Caso não se aplique, informe "NA"):
   No dia 15 fizemos uma correção relacionada ao card
   CAPL-5504:SQL Processing: it should not create the field on "elasticsearch mapping" whe...Done
   onde pipelines SQL estavam retornando campos que não existiam no Datamodel e com isso fazendo com que o mapping desse novo campo fosse criado no Elasticsearch. Isso trazia problemas nas instalações do CaroApp pois ao tentar criar o campo efetivamente o Elasticsearch já informava que o campo já existe. Como parte da solução do card mencionado anteriormente começamos a validar o resultado do SQL Processing, ignorando valores de colunas retornadas no SQL Processing onde não existisse um field com o mesmo nome no Datamodel justamente evitar a criação do mapping no Elasticsearch desse atributo campo inexistente. O problema é que temos algumas pipelines retornando campos ex: STATUS quando no Datamodel esse attributo está definido como ex: status. O case é diferente e por conta disso os campos não eram considerados iguais fazendo com que o valor da coluna STATUS do SQL Processing não fosse transportada para a coluna status do Datamodel.
3. Solução dada ao tema/dúvida:
   Fizemos uma melhoria na nossa regra de validação onde a busca para saber se o atributo existe ou não vai ser case insensitive.
4. Orientações gerais para validação (Caso não se aplique, informe "NA"):
   Processar SQL Pipelines afetadas (que traziam valores nulos em atributos que deveriam ser preenchidos) e validar que os valores estão sendo propagados.
5. Versão de correção e previsão de lançamento:
   Já em Produção

Message thread link on #red-phone channel:

https://totvscarol.slack.com/archives/C03NT4US9J9/p1708110033559409

@Robson Thanael Poffo ,
@Geny Isam Hamud Herrera ,

This issue was planned to be delivered until 2024-03-01. You can check that by consulting the issue in the Due Date field.

Dates already planned for this issue: 2024-03-01

If External Issue Link field is filled, customer was also informed on JIRA TOTVS.