A motivação para escrever este blog é que ele sirva de introdução para quem necessita entender um pouco mais de TM, no momento em que o LES-TRA está saindo de cena e o TM tornou-se a ferramenta formal da SAP para os macroprocessos de planejamento, programação e execução de transporte.
Inclusive, a partir da versão 1709 o TM já está no S/4 Core, ou seja, rodando na mesma máquina do ERP.
O Transportation Management não é uma aplicação nova, mas uma evolução do APO TP/VS que existe desde 2000. Em 2007 foi o Ramp Up do Transportation Management 6.0 e desde então a solução não parou de evoluir. Esta menção é para passar a primeira importante mensagem do texto; sim, o Transportation Management já está estável e em produção para centenas de grandes clientes ao redor do mundo.
Antes de qualquer coisa: o TM roda no NWBC e neste caso, consultores raiz já se preparem para ficar longe do SAP GUI. Depois que você se acostuma nem é tão ruim assim; mas para acostumar demora um tempo
Abaixo a tela do TM.
Exemplo do fluxo de documentos.
a. Arquitetura da aplicação
Existem duas formas de se utilizar o Transportation Management:
1-) Em uma máquina isolada, só para o TM.
Neste caso a integração de dados mestres com o ERP dar-se-á por meio da CIF, e dados transacionais por output messages.
Para quem não conhece a CIF, e vier a necessitar de informações, consultar o blog do Eduardo Chagas – Transferindo Dados Mestres para o TM que todas as informações relevantes estarão lá.
Neste link pode ser consultado de forma detalhada toda a estrutura de integração de processos inbound e outbound do TM. Apesar do conteúdo ser da versão 9.2, ainda está bem atual.
2-) Na mesma máquina, compartilhando o core do S/4 a partir da versão 1709.
Neste caso a CIF não é mais necessária, mas aqui cabe uma informação importante. existem diferenças do TM no S4, e do TM rodando em máquina stand alone. Se tiver interesse neste detalhe consulte a nota 2514203 – SAP S/4HANA Supply Chain for Transportation Management -1709 – Release information
b. Dados Mestres
No TM quase tudo é dado mestre, e não há exagero nesta frase. Mas, para seguir o processo de construção de entendimento, vamos falar primeiro dos dados mestres que utilizávamos no LES.
Importante mencionar que no TM você consegue conviver com o mínimo possível de dados mestres cadastrados previamente, sendo neste caso os cadastros atualizados em tempo de execução — por exemplo endereços, fornecedores e materiais, criados manualmente durante a execução do processo
1-) Cliente e Fornecedor
Basicamente, cliente e fornecedor são baseados em BP, sem grandes novidades. Existe uma role específica e pronto, nada além disso
2-) Unidade Gerencial
Unidade gerencial é, fisicamente, um ponto de origem, destino, transbordo, ou seja lá o que for, que exista fisicamente e deva ser considerado na estrutura de logística. Quanto se cria o BP (Clientes e Fornecedores), seja por meio da CIF, seja manualmente. o TM pergunta se o usuário deseja criar uma unidade gerencial junto ao registro mestre.
Exemplo de uma unidade gerencial.
2-) Estrutura Organizacional
Lembra que falei que quase tudo é dado mestre? Pois bem, a estrutura organizacional que o TM vai utilizar é baseada na criação de estrutura via transação PPOCE — mesma utilizada por exemplo em HR, APO e outras aplicações que assumem estrutura como dado mestre.
Basicamente aqui você vai criar os De-Para da estrutura do TM para a estrutura do S/4 no tocante a compras e vendas (Org. Compras / Grupo de Compradores e Organização de Vendas).
Exemplo da Estrutura criada.
Atente que a construção da área de compras e vendas, neste caso, acontece com a criação das Funções da unidade organizacional.
É razoável imaginar que muitos estão tendo o primeiro contato com a transação PPOM, mas isto é bem simples e basicamente passa pela criação de uma estrutura em árvore para montagem de toda a estrutura organizacional da companhia. No SCN tem bastante conteúdo como como utilizar as transações PPOM
3-) Recursos
Tudo aquilo que se utiliza para a movimentação de carga é um recurso no TM, e dependendo dos cenários, em que é necessário gerenciar frota própria, existe integração standard do TM com o PM. Mas no momento, vou me ater a conceito simples de recursos, sem avaliar frota própria ou especificidades.
Existem diversas classes de recursos que devem/podem ser cadastradas de modo a acobertar todos os processos de movimentação possíveis.
Sendo que para cada recurso existe um cadastro específico, com campos que refletem o maior nível de detalhe de cada unidade. Isto é muito relevante para as atividades de planejamento, porque o otimizador utiliza todas as informações de volume, disponibilidade de preço, recursos, unidade gerencial, entre outros, para poder encontrar o ponto ótimo econômico do transporte.
4-) Rotas e Itinerário
Rede de transporte: a determinação de rota no TM em nada tem a ver com a TZONE / 0VRF / 0VTC do LES. A determinação de rotas e itinerários é muito mais complexa e basicamente considera os seguintes aspectos:
É bem detalhada, e se cadastra inclusive as coordenadas geográficas e o nível de granularidade da zona de transporte.
Existem também a linha de transporte para fluxo contínuo de movimento, mas não é obrigatório o uso e atende algumas demandas específicas.
c. Processos suportados e fluxo de documentos
Podemos considerar que o TM suporta uma enormidade de processos de transportes, sendo três grandes pilares de negócios:
1-) Embarcadores, que consomem o transporte
Cenário mais comum, da empresa que compra o serviço de frete, carrega o caminhão, e paga o fornecedor. E quando digo caminhão, entenda qualquer modal possível — incluindo a multimodalidade.
2-) Provedores de serviços de transportes
Cenários de venda de transportes para clientes finais; e aqui considerando os diversos modais e integrações de transporte possíveis (integração com operadores aéreos, marítimos, seguradoras, etc etc).
3-) Cenários híbridos
Cenários que se opera compra e venda de serviço de transporte e, no final do dia, o TM vai gerar uma ordem de compra para pagar o fornecedor de transporte, e uma ordem de venda para receber do cliente. Como resumo, é isto.
E para atender estes cenários, o TM possui tipos de documento específicos. Entenda tipos de documento neste caso, como transações, e não como diversos tipos de documento na mesma transação. Imagine, para efeito de entendimento, que existe um ítem de menu para cada documento deste.
Existem outros documentos, dado que o TM é bem extenso, mas para um primeiro contato, estes seriam os principais.
d. Vantagens imediatas que podemos capturar
Não adianta tentar fazer um De-Para do LES-TRA para o TM, até porque olhando com o foco em funcionalidades, são muitas as funcionalidades adicionais que podem ser utilizadas. Mas, de uma forma bem genérica e simplista, existem um pacote de ganhos que podem ser facilmente capturados e que trazem um benefício enorme para o negócio, tais como:
d1. Possibilidade de planejar o transporte com base em divisão de remessa, sem a remessa criada
Na minha opinião, esquecendo o planejamento avançado e a flexibilidade de custeio de frete, esta é a maior vantagem do TM.
Sempre existiu o problema de fluxo no LES em que a criação da remessa, para posterior planejamento do transporte, bloqueava estoque. Criar remessa sem bloqueio de estoque trazia outros problemas, também indesejáveis. E para negócios de giro muito rápido, em que o transporte leva um tempo para ser planejado, não justifica ficar com estoque preso em uma remessa que será expedida apenas daqui há dias.
Pois bem, o TM permite fazer todo o planejamento do transporte sem necessariamente ter a remessa criada, visto que é possível que se utilize a linha da divisão de remessa como base para o planejamento e programação do transporte. E, tão logo o transporte esteja confirmado, aí sim o TM retorna a mensagem de transporte para criar a remessa.
Agora, imagine tipos de negócio que “se envia o que tem no estoque”, como algumas empresas de varejo, onde quando não há a quantidade completa se envia a parcial e permite vários envios por dia, sendo o estoque o gatilho para a remessa e carregamento.
Com o TM, se consegue acompanhar a estratégia de agilizar giro de estoque, planejando e, formatando a carga com tudo que existe disponível, criando a remessa apenas após o caminhão carregado. Quase que um fluxo constante de movimento.
d2. Combinar cenários de transporte Inbound e Outbound no mesmo veículo
Aqui é simples de entender. Venda, transferência, vários tipos de frete… tudo no mesmo veículo, e sem a preocupação de como ratear custos a posterior. Bom né?
d3. Ferramentas de interação e seleção de transportador (tendering)
As ferramentas de seleção de transportador são muito flexíveis e completas, cabendo a utilização de workflow, regras de seleção, e níveis de decisão de transportador. Em resumo, o portal do transportador do TM é um mundo a parte e que permite viabilizar acesso externo para o transportador aceitar ou não ofertas de frete. Tudo que se fazia em portal Z, agora é standard e funciona muito bem.
Em tempo, nem tudo aqui está disponível na versão embedded da 1709.
d4. Planejamento avançado de transporte
No TM existe um cockpit de planejamento avançado em que é possível encontrar o ponto ótimo de volume, rota ou outras variáveis pré definidas. Ao contrário do que se imagina, o TM não trabalha com otimizador do tipo NP-completos (basicamente, desafio da mochila, ou TSP que é o paralelo em inglês). O otimizador do TM é baseado em VSR, o que tem diversas vantagens em relação ao NP-completo, entre elas a performance, visto que NP-completo pode levar dias, (até anos) para executar otimizações não tão complexas.
Existem diversas atividades de planejamento no TM, tais como:
Encontrando a estratégia de otimização certa, o TM permite que se economize bastante tempo e dinheiro não carregando peso morto de material desnecessariamente.
d5. Simulação de custo em vários momentos do processo
No LES uma grande desvantagem é que o cálculo do custo acontece a posterior da execução do transporte; ou no mínimo acontece em outro documento que normalmente é processado em momento diferente da execução do transporte. Apesar disso não ser uma regra, por diversos motivos esta é normalmente a solução adotada.
No caso do TM, o processamento do custo pode acontecer inclusive durante o planejamento e programação do transporte. Ou seja, os processos decisórios, quando não forem automáticos — já falei disso no ítem “c” — acontecem com dados reais de processamento das tabelas de frete.
d6. Pricing muito mais flexível
A pricing de frete do TM não é a mesma –nem contém a mesma lógica– da pricing de SD, LES e MM. Apesar do conceito de sequência de acesso e técnica de condição ser bem parecido, existem diferenças estruturais que possibilitam um melhor gerenciamento e flexibilidade no TM.
Apenas para ilustrar, imagine que a pricing do TM é toda baseada em dados mestres, e além disso, dado que solução já foi pensada nos grandes volumes das tabelas de frete, existem ferramentas que permitem integrar a pricing do TM com arquivos Excel.
Já imaginou gerar uma planilha com a estrutura da pricing, entregar para os usuários, e eles mesmos preenchem os valores para posteriormente só fazer upload? Pois bem… com TM isso é possível de forma standard.
d7. Integração Visual Business
No TM existe um ponto de ampliação /SCMTMS/ES_MAP_ADAPT_SCENE que permite fazer melhorias na apresentação dos Mapas de rotas, além da utilização de diversas fontes para se utilizar como base para os mapas.
O Marcus Zahn criou um artigo só tratando do Visual Business no TM. Você pode ver detalhes clicando aqui. (a imagem abaixo eu retirei do artigo dele; vale a pena visitar).
Marcus Zahn; thank you for publish a content regarding Visual Business; clear and very usefull. I include a link to your content here from my blog. Thank you.
f. Customizações
Aqui está outra mudança de conceito muito grande: todas as customizações são baseada em BOPF, ou Business Objects. Não adianta ficar procurando tabela com SE16 e especificar lógicas procedurais sem entender o conceito de objetos de negócio.Toda a aplicação foi escrita utilizando conceitos de orientação ao objeto e objetos de negócio.
Aqui eu recomendo fortemente que se estude este tema, dado que sem este entendimento sequer uma especificação funcional vai fazer sentido. Um resumo de todos os conteúdos introdutórios e exercícios sobre BOPF podem ser consultados no link abaixo.
Introduction to Business Object Processing Framework (BOPF)
g. Localização
Uma preocupação normal que existe quando falamos de novas soluções logística é a localização Brasil, e o TM está localizado para a maioria dos cenários de embarcadores, mas demanda algum esforço de customização quando estivermos falando de cenários para provedores de serviços de transportes. Neste caso, existem GAPS importantes que sem pequenos desenvolvimento, a ferramenta não atende a legislação.
Bom, acho que para um entendimento inicial, que permite caminhar alguns passos da longa estrada que vem por aí, este artigo já vai ajudar. O próximo blog será sobre pricing.
Innovation for thought!
Fausto Motter
Okumaya devam et...
Inclusive, a partir da versão 1709 o TM já está no S/4 Core, ou seja, rodando na mesma máquina do ERP.
O Transportation Management não é uma aplicação nova, mas uma evolução do APO TP/VS que existe desde 2000. Em 2007 foi o Ramp Up do Transportation Management 6.0 e desde então a solução não parou de evoluir. Esta menção é para passar a primeira importante mensagem do texto; sim, o Transportation Management já está estável e em produção para centenas de grandes clientes ao redor do mundo.
Antes de qualquer coisa: o TM roda no NWBC e neste caso, consultores raiz já se preparem para ficar longe do SAP GUI. Depois que você se acostuma nem é tão ruim assim; mas para acostumar demora um tempo
Abaixo a tela do TM.
Exemplo do fluxo de documentos.
a. Arquitetura da aplicação
Existem duas formas de se utilizar o Transportation Management:
1-) Em uma máquina isolada, só para o TM.
Neste caso a integração de dados mestres com o ERP dar-se-á por meio da CIF, e dados transacionais por output messages.
Para quem não conhece a CIF, e vier a necessitar de informações, consultar o blog do Eduardo Chagas – Transferindo Dados Mestres para o TM que todas as informações relevantes estarão lá.
Neste link pode ser consultado de forma detalhada toda a estrutura de integração de processos inbound e outbound do TM. Apesar do conteúdo ser da versão 9.2, ainda está bem atual.
2-) Na mesma máquina, compartilhando o core do S/4 a partir da versão 1709.
Neste caso a CIF não é mais necessária, mas aqui cabe uma informação importante. existem diferenças do TM no S4, e do TM rodando em máquina stand alone. Se tiver interesse neste detalhe consulte a nota 2514203 – SAP S/4HANA Supply Chain for Transportation Management -1709 – Release information
b. Dados Mestres
No TM quase tudo é dado mestre, e não há exagero nesta frase. Mas, para seguir o processo de construção de entendimento, vamos falar primeiro dos dados mestres que utilizávamos no LES.
Importante mencionar que no TM você consegue conviver com o mínimo possível de dados mestres cadastrados previamente, sendo neste caso os cadastros atualizados em tempo de execução — por exemplo endereços, fornecedores e materiais, criados manualmente durante a execução do processo
1-) Cliente e Fornecedor
Basicamente, cliente e fornecedor são baseados em BP, sem grandes novidades. Existe uma role específica e pronto, nada além disso
2-) Unidade Gerencial
Unidade gerencial é, fisicamente, um ponto de origem, destino, transbordo, ou seja lá o que for, que exista fisicamente e deva ser considerado na estrutura de logística. Quanto se cria o BP (Clientes e Fornecedores), seja por meio da CIF, seja manualmente. o TM pergunta se o usuário deseja criar uma unidade gerencial junto ao registro mestre.
Exemplo de uma unidade gerencial.
2-) Estrutura Organizacional
Lembra que falei que quase tudo é dado mestre? Pois bem, a estrutura organizacional que o TM vai utilizar é baseada na criação de estrutura via transação PPOCE — mesma utilizada por exemplo em HR, APO e outras aplicações que assumem estrutura como dado mestre.
Basicamente aqui você vai criar os De-Para da estrutura do TM para a estrutura do S/4 no tocante a compras e vendas (Org. Compras / Grupo de Compradores e Organização de Vendas).
Exemplo da Estrutura criada.
Atente que a construção da área de compras e vendas, neste caso, acontece com a criação das Funções da unidade organizacional.
É razoável imaginar que muitos estão tendo o primeiro contato com a transação PPOM, mas isto é bem simples e basicamente passa pela criação de uma estrutura em árvore para montagem de toda a estrutura organizacional da companhia. No SCN tem bastante conteúdo como como utilizar as transações PPOM
3-) Recursos
Tudo aquilo que se utiliza para a movimentação de carga é um recurso no TM, e dependendo dos cenários, em que é necessário gerenciar frota própria, existe integração standard do TM com o PM. Mas no momento, vou me ater a conceito simples de recursos, sem avaliar frota própria ou especificidades.
Existem diversas classes de recursos que devem/podem ser cadastradas de modo a acobertar todos os processos de movimentação possíveis.
Sendo que para cada recurso existe um cadastro específico, com campos que refletem o maior nível de detalhe de cada unidade. Isto é muito relevante para as atividades de planejamento, porque o otimizador utiliza todas as informações de volume, disponibilidade de preço, recursos, unidade gerencial, entre outros, para poder encontrar o ponto ótimo econômico do transporte.
4-) Rotas e Itinerário
Rede de transporte: a determinação de rota no TM em nada tem a ver com a TZONE / 0VRF / 0VTC do LES. A determinação de rotas e itinerários é muito mais complexa e basicamente considera os seguintes aspectos:
- Zona de transporte
É bem detalhada, e se cadastra inclusive as coordenadas geográficas e o nível de granularidade da zona de transporte.
- Itinerário, repare que o itinerário é com base na unidade gerencial (aproveito para agradecer ao colega @rodrigosilva que criou o registro que eu utilizei para ilustrar o blog).
Existem também a linha de transporte para fluxo contínuo de movimento, mas não é obrigatório o uso e atende algumas demandas específicas.
c. Processos suportados e fluxo de documentos
Podemos considerar que o TM suporta uma enormidade de processos de transportes, sendo três grandes pilares de negócios:
1-) Embarcadores, que consomem o transporte
Cenário mais comum, da empresa que compra o serviço de frete, carrega o caminhão, e paga o fornecedor. E quando digo caminhão, entenda qualquer modal possível — incluindo a multimodalidade.
2-) Provedores de serviços de transportes
Cenários de venda de transportes para clientes finais; e aqui considerando os diversos modais e integrações de transporte possíveis (integração com operadores aéreos, marítimos, seguradoras, etc etc).
3-) Cenários híbridos
Cenários que se opera compra e venda de serviço de transporte e, no final do dia, o TM vai gerar uma ordem de compra para pagar o fornecedor de transporte, e uma ordem de venda para receber do cliente. Como resumo, é isto.
E para atender estes cenários, o TM possui tipos de documento específicos. Entenda tipos de documento neste caso, como transações, e não como diversos tipos de documento na mesma transação. Imagine, para efeito de entendimento, que existe um ítem de menu para cada documento deste.
- Unidade de frete (em inglês o acrônimo é FU): grupo de produtos que são transportados juntos. Uma unidade de frete contém itens, e para efeito de entendimento, assuma uma unidade de frete como a menor unidade de transporte do TM. Você nunca vai carregar 1/2 unidade de frete, ou itens de uma unidade de frete. Uma unidade de frete se movimenta inteira. Por exemplo, uma unidade de frete pode ser uma remessa (inbound ou outbound), ou linhas do schedule delivery da ordem de venda.
O TM permite configurar regras para criar as unidades de frete, de modo a identificar as quebras e quantidades das mesmas.
- Ordem de Frete (em inglês o acrônimo é FO): é um documento que agrupa unidades de frete / veículos / nas etapas / considerando o custo determinado. Basicamente, é o documento de execução do transporte, em que estão agrupadas todas as variáveis e constantes que determinarão “Oque” está sendo transportado (ou as unidades de fretes), “Quem” está transportando (ou o provedor de serviço), “Quanto” custa o transporte (pricing de frete / acordos), “Por onde” esta transportando (etapas), “Quando” ocorrerá o transporte.
- Faturamento de frete (em inglês o acrônimo é FSD): é o documento de faturamento de frete contra o fornecedor, ou seja, a fatura a pagar de frete. No TM tem que ter clareza desta distinção porque pode em um mesmo processo haver uma fatura a pagar, e/ou uma fatura a receber para o caso de vendas de serviço de frete.
- Ordem de expedição de frete (em inglês o acrônimo é FWO): É uma demanda de transporte, que pode ser referente a uma compra ou uma venda. Imagine para efeito de entendimento que uma FWO pode ser considerada uma ordem de coleta. E dentro de uma FWO existem FUs.
- Faturamento de expedição de frete (em inglês o acrônimo é FWSD): Está vendendo serviço? Precisa gerar uma fatura de frete — que no caso do Brasil ou vai gerar um CT.e ou uma NFS.e? Aqui é o documento do TM que integra com a fatura de SD.
- Remessas (em inglês acrônimo DTR) – representa as remessas que serão expedidas
- Necessidade de transporte (em inglês acrônimo OTR) – é a necessidade de transporte de transferência, venda ou compra.
Existem outros documentos, dado que o TM é bem extenso, mas para um primeiro contato, estes seriam os principais.
d. Vantagens imediatas que podemos capturar
Não adianta tentar fazer um De-Para do LES-TRA para o TM, até porque olhando com o foco em funcionalidades, são muitas as funcionalidades adicionais que podem ser utilizadas. Mas, de uma forma bem genérica e simplista, existem um pacote de ganhos que podem ser facilmente capturados e que trazem um benefício enorme para o negócio, tais como:
d1. Possibilidade de planejar o transporte com base em divisão de remessa, sem a remessa criada
Na minha opinião, esquecendo o planejamento avançado e a flexibilidade de custeio de frete, esta é a maior vantagem do TM.
Sempre existiu o problema de fluxo no LES em que a criação da remessa, para posterior planejamento do transporte, bloqueava estoque. Criar remessa sem bloqueio de estoque trazia outros problemas, também indesejáveis. E para negócios de giro muito rápido, em que o transporte leva um tempo para ser planejado, não justifica ficar com estoque preso em uma remessa que será expedida apenas daqui há dias.
Pois bem, o TM permite fazer todo o planejamento do transporte sem necessariamente ter a remessa criada, visto que é possível que se utilize a linha da divisão de remessa como base para o planejamento e programação do transporte. E, tão logo o transporte esteja confirmado, aí sim o TM retorna a mensagem de transporte para criar a remessa.
Agora, imagine tipos de negócio que “se envia o que tem no estoque”, como algumas empresas de varejo, onde quando não há a quantidade completa se envia a parcial e permite vários envios por dia, sendo o estoque o gatilho para a remessa e carregamento.
Com o TM, se consegue acompanhar a estratégia de agilizar giro de estoque, planejando e, formatando a carga com tudo que existe disponível, criando a remessa apenas após o caminhão carregado. Quase que um fluxo constante de movimento.
d2. Combinar cenários de transporte Inbound e Outbound no mesmo veículo
Aqui é simples de entender. Venda, transferência, vários tipos de frete… tudo no mesmo veículo, e sem a preocupação de como ratear custos a posterior. Bom né?
d3. Ferramentas de interação e seleção de transportador (tendering)
As ferramentas de seleção de transportador são muito flexíveis e completas, cabendo a utilização de workflow, regras de seleção, e níveis de decisão de transportador. Em resumo, o portal do transportador do TM é um mundo a parte e que permite viabilizar acesso externo para o transportador aceitar ou não ofertas de frete. Tudo que se fazia em portal Z, agora é standard e funciona muito bem.
Em tempo, nem tudo aqui está disponível na versão embedded da 1709.
d4. Planejamento avançado de transporte
No TM existe um cockpit de planejamento avançado em que é possível encontrar o ponto ótimo de volume, rota ou outras variáveis pré definidas. Ao contrário do que se imagina, o TM não trabalha com otimizador do tipo NP-completos (basicamente, desafio da mochila, ou TSP que é o paralelo em inglês). O otimizador do TM é baseado em VSR, o que tem diversas vantagens em relação ao NP-completo, entre elas a performance, visto que NP-completo pode levar dias, (até anos) para executar otimizações não tão complexas.
Existem diversas atividades de planejamento no TM, tais como:
- Vehicle Scheduling and Routing (TVSR)
Planejamento da Unidade de Frete, Ordem de frete e agendamentos
- Proposta (TVRG)
Busca encontrar alternativas para transportar a unidade de frete em uma rede de transporte
- Carrier/Service-Provider selection (TSPS)
Identifica o melhor transportador utilizando custo e alocação
- Load Optimization (TVSO)
Otimiza o carregamento do veículo com base em peso ou volume de carregamento.
Encontrando a estratégia de otimização certa, o TM permite que se economize bastante tempo e dinheiro não carregando peso morto de material desnecessariamente.
d5. Simulação de custo em vários momentos do processo
No LES uma grande desvantagem é que o cálculo do custo acontece a posterior da execução do transporte; ou no mínimo acontece em outro documento que normalmente é processado em momento diferente da execução do transporte. Apesar disso não ser uma regra, por diversos motivos esta é normalmente a solução adotada.
No caso do TM, o processamento do custo pode acontecer inclusive durante o planejamento e programação do transporte. Ou seja, os processos decisórios, quando não forem automáticos — já falei disso no ítem “c” — acontecem com dados reais de processamento das tabelas de frete.
d6. Pricing muito mais flexível
A pricing de frete do TM não é a mesma –nem contém a mesma lógica– da pricing de SD, LES e MM. Apesar do conceito de sequência de acesso e técnica de condição ser bem parecido, existem diferenças estruturais que possibilitam um melhor gerenciamento e flexibilidade no TM.
Apenas para ilustrar, imagine que a pricing do TM é toda baseada em dados mestres, e além disso, dado que solução já foi pensada nos grandes volumes das tabelas de frete, existem ferramentas que permitem integrar a pricing do TM com arquivos Excel.
Já imaginou gerar uma planilha com a estrutura da pricing, entregar para os usuários, e eles mesmos preenchem os valores para posteriormente só fazer upload? Pois bem… com TM isso é possível de forma standard.
d7. Integração Visual Business
No TM existe um ponto de ampliação /SCMTMS/ES_MAP_ADAPT_SCENE que permite fazer melhorias na apresentação dos Mapas de rotas, além da utilização de diversas fontes para se utilizar como base para os mapas.
O Marcus Zahn criou um artigo só tratando do Visual Business no TM. Você pode ver detalhes clicando aqui. (a imagem abaixo eu retirei do artigo dele; vale a pena visitar).
Marcus Zahn; thank you for publish a content regarding Visual Business; clear and very usefull. I include a link to your content here from my blog. Thank you.
f. Customizações
Aqui está outra mudança de conceito muito grande: todas as customizações são baseada em BOPF, ou Business Objects. Não adianta ficar procurando tabela com SE16 e especificar lógicas procedurais sem entender o conceito de objetos de negócio.Toda a aplicação foi escrita utilizando conceitos de orientação ao objeto e objetos de negócio.
Aqui eu recomendo fortemente que se estude este tema, dado que sem este entendimento sequer uma especificação funcional vai fazer sentido. Um resumo de todos os conteúdos introdutórios e exercícios sobre BOPF podem ser consultados no link abaixo.
Introduction to Business Object Processing Framework (BOPF)
g. Localização
Uma preocupação normal que existe quando falamos de novas soluções logística é a localização Brasil, e o TM está localizado para a maioria dos cenários de embarcadores, mas demanda algum esforço de customização quando estivermos falando de cenários para provedores de serviços de transportes. Neste caso, existem GAPS importantes que sem pequenos desenvolvimento, a ferramenta não atende a legislação.
Bom, acho que para um entendimento inicial, que permite caminhar alguns passos da longa estrada que vem por aí, este artigo já vai ajudar. O próximo blog será sobre pricing.
Innovation for thought!
Fausto Motter
Okumaya devam et...