Mudanças entre as edições de "Discussão:Calculo Frete Peso total e ranger -ANHAMBI"
(→Mapeamento do campo **ID_COMPOE_CALC_FRETE**: nova seção) |
|||
Linha 1: | Linha 1: | ||
− | == Mapeamento do campo | + | == 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.