Mudanças entre as edições de "Discussão:Calculo Frete Peso total e ranger -ANHAMBI"

De GeoSales
Ir para navegação Ir para pesquisar
 
 
Linha 1: Linha 1:
== Mapeamento do campo **ID_COMPOE_CALC_FRETE** ==
+
== Mapeamento do campo '''ID_COMPOE_CALC_FRETE''' ==
  
 
Essa coluna deveria ser simplesmente auto-contida. Do jeito que está, o funcionamento dela depende de outra informação, que deveria ser paralela, que é o tipo de frete padrão do cliente.
 
Essa coluna deveria ser simplesmente auto-contida. Do jeito que está, o funcionamento dela depende de outra informação, que deveria ser paralela, que é o tipo de frete padrão do cliente.

Edição atual tal como às 20h06min de 5 de julho de 2018

Mapeamento do campo ID_COMPOE_CALC_FRETE

Essa coluna deveria ser simplesmente auto-contida. Do jeito que está, o funcionamento dela depende de outra informação, que deveria ser paralela, que é o tipo de frete padrão do cliente.

Como está escrito, as duas colunas não tem funcionalidades ortogonais. Sugiro, então, fazer não um pareamento tosco 1:1 da fonte dos dados para cá. Sugiro fazer uma mineração semântica dessa coluna, assim então não entraremos com gambiarras absurdas no sistema as quais deveremos desfazer e manter a compatibilidade no futuro, quando for detectada a questão da ortogonalidade das informações.

Então, como atualmente quem está como frete padrão de FOB não compõe o cálculo de frete, que se traga assim da integração. Isso é um mapeamento semântico dos dados. Fazendo a mineração correta dos dados, teremos menor dor de cabeça, implementação mais simples, direta, aferível, automaticamente testável através de unidades menores de código e, também, menos manutenção e problemas futuros.

Não se esqueça de algo: o cliente não vai usar a nossa base, ele irá usar o sistema. Para ele, a questão semântica precisa fazer sentido, não a paridade 1:1 dos dados.