Skip to Content

STO é um processo ‘intracompany’ para transferência de materiais entre plantas da mesma empresa.

** Inter/Cross Company é um processo não localizado, portanto não suportado. 

 

O cenário mais comum é feito da seguinte forma:

  1. ME21N                 STO
  2. VL10B                  Criação da Delivery
  3. VL02N                  Saída com o movimento 862
  4. MIGO                   Entrada com o movimento 861

 

Notas Importantes:

123124 – LSA BR:5th v. Customizing of Brazilian movement types

    • Essa nota contém o report que atualiza todos os movimentos para suas configurações standard.

199233 – Transfer with stock transfer order

888805 – CBT: Stock transfer with stock transport order

 

Customizações:

    • As plantas tem que ser configuradas sendo que uma é o cliente e a outra é a fornecedora.
    • Na view J_1BIM02V os movimentos 861, 861, 863 e 864 tem que estar marcados como relevantes para NF com a opção U.
    • Transação OMJJ possui várias configurações para movimentos específicos.
    • O posting string (J1BTAX>>>NF>>>Inventory Management>>>IM Posting Strings) campo line item ID deve ser configurado com a opção T ou D.

 

Incidents:

  • Impostos não batem (entrada x saída).
    • Muitos clientes abrem incidentes perguntando, porque os valores não batem. Como isso não é algo hard coded os valores podem sim ser diferentes.  Portanto é necessário averiguar suas configurações de impostos para entender o porquê os valores não batem.

 

Pontos de DEBUG:

  • SE80>>>Function Group>>>J1BN>>>Function Module>>> J_1B_IM_TX_CALCULATE_TAX_NEW
    • Nesse FM é onde começa a interface com FI.
  • SE37>>>Function Module>>> CALCULATE_TAX_ITEM
    • Nesse ponto a KOMP e KONK é preenchida.
  • SE80>>> Function Group>>>J1BF>>>Include LJ1BFF01
    • Nesse include a NF é criada
  • SE80>>> Function Group>>>MBGB>>> Subroutine>>> FORM AUSGABE (INCLUDE LMBGBFSU)
    • Nesse include você pode verificar problemas com relação ao documento contábil e os famosos erros de balanço.

 

 

Maiores informações consulte:

 

Stock Transport Order – STO – Localization Latin America – SCN Wiki

Stock Transfer Order (STO) with Full or Partial Return of Transit Stock – Localization Latin America – SCN Wiki

 

SCN STO de Retorno

Abs,

Patricia

To report this post you need to login first.

44 Comments

You must be Logged on to comment or reply to a post.

  1. Gustavo Gonçalves

    Como eu gostaria que este post tivesse sido escrito há 2 anos atrás! 🙂

    Sensacional Patrícia!

    Obrigado pela colaboração e compartilhamento de conhecimento.

    Atenciosamente,

    Gustavo Gonçalves

    (1) 
  2. Gizela Ferreira Mendes

    Patricia,

    Você tem o processo de retorno (em transito) e devolução da transferencia / intercompany?

    Aqui temos somente a saida. Estamos para implementar o retorno e a devolução.

    Gizela

    (0) 
      1. MARCELO SANTOS

        Boa tarde Patrícia,

         

        Nunca implementei o processo de STO e agora estou em um projeto onde precisarei configurar tal processo. Serão transferências de SP para outros estados.Saberia me informar por gentileza as configurações necessárias no SPRO customizing?

        Atte.

        Marcelo

         

        (0) 
        1. Patricia Eidelwein Post author

          Olá Marcelo,

          Infelizmente não é tão simples assim.

          Sugiro dar uma olhada na nossa WIKI que mostra os processos de STO e a principais configurações.

          Tentar ler as notas referente ao cenário para ajudar com as customizações.

          Se tiver alguma dúvida especifica me avise.

          Abs,

          Patricia

           

           

          (0) 
  3. Metin OZMADENCI

    Ola Patricia,

    Não estou conseguindo determinar o CFOP num STO de Poços de Calda para uma planta nova (Manaus).

    Num STO saindo do mesmo lugar e mesmo material para uma planta já existente (no Ceara) o CFOP é determinado.

    Creio que o problema é na planta de destino, certo? Voce tem alguma dica de onde possa estar o erro?

    Atte.

    Daniel

    (0) 
    1. Patricia Eidelwein Post author

      Olá Daniel,

      Você chegou a olhar o meu post sobre determinação de CFOP?

      CFOP em branco

      Seguinte esse post você consegue ver exatamente qual configuração que está faltando para a determinação de CFOP sair corretamente.

      Qualquer dúvida me avise.

      Atenciosamente,

      Patrícia

      (0) 
      1. Metin OZMADENCI

        Ola Patricia,

        Consegui identicar o problema atraves do seu post do CPOF, faltava ajusar os CFOPs para saída de Free Trade (Destinations 3 e 4).

        Muito obrigado.

        Atte.

        Daniel

        (0) 
      2. Kelly Gaspar

        Olá Patrícia,

         

        Ao efetuar a VL02N, o CFOP não determina, já coloquei break-point em ambas as FM’s e nada. Estou utilizando o movimento 862 para o intracompany. Tem alguma sugestão do que fazer ou debugar para saber qual é o problema?

         

        Obrigado

         

        (0) 
        1. Patricia Eidelwein Post author

          Oi Kelly,

          Cenário 1: 

          O CFOP não determinou na delivery, ou seja você cria na VL10B e quando checa na VL02N o CFOP está em branco?

          Solução:

          Solução cenário 1: nesse caso como a delivery é criada do lado de SD as funções mencionada no KBA CFOP em branco não vão funcionar mesmo porque o CFOP é determinado no lado do código de SD. Nesse ponto aqui: J_1B_SD_CFOP.

          Se no debug o sistema não entrar nesse ponto é muito provável que o tipo de SD doc type não tem NF type assignado na view J_1BTVAKV. Olhe o KBA 2435722 – Error 8B148 – Enter CFOP for line 000001 during STO process.

          Se não TVAK estiver tudo correto, muito provável que deve ser algo referente a configuração na tabela J_1BSDICA.

          OU

          Cenário 2: Você criou a delivery sem problemas e quando posta a delivery na VL02N e check a Nota Fiscal de saída o CFOP está em branco?

          Solução: Nesse cenário os sistema deveria passar pelos pontos do KBA CFOP em branco. Se não estiver passando é porque o sistema está caindo fora antes. Teria que ver via debug porque isso está ocorrendo.

          Abs,

          Patricia

           

           

          (0) 
  4. Assis Brandao

    Fiquei com Dúvidas.

    Na Minha Empresa fazemos ASSIM;

    • Criação pedido pela ME21N;
    • Criação da remessa VL04;
    • Edição da remessa na VL02N e saída da mercadoria;
    • Impressão da nota pela J1B3N;
    • Entrada da NF no centro receptor pela MB0A com indicação da remessa.


    Nosso processo tem o mesmo valor deste aqui citado ou fazemos errado?


    (0) 
    1. Patricia Eidelwein Post author

      Olá Assis,

      O processo que foi feito pela localização segue as transações mencionadas no post.

      Não tem problema você fazer o processo da forma que faz hoje. Se está tudo funcionando não tem porque mudar.

      É só importante lembrar que se houver qualquer erro específico de Brasil nesse processo, na VL04 ou MB0A, talvez não seja possível corrigir.

      Att,

      Patricia


      (0) 
  5. Assis Brandao

    Muito obrigado Patricia.

    Queria conhecer qual cenário padrão mais usado para processos de Intercompany (Centros de empresas diferentes). Hoje trabalhamos como venda normal entre plantas com fatura. É feito processo via RC e Pedido de compras como se fosse um cliente normal.

    (0) 
  6. Matheus Caldeira

    Boa tarde Patricia,

    tudo bom?

    Meu cenário está praticamente pronto, mas quando tento fazer a MIGO com o tipo de movimento 861, recebo um erro para colocar um número de Delivery Note, o único campo que acho é o próprio no cabeçalho, que, por sinal está preenchido.

    Grato,

    Matheus

    (0) 
    1. Patricia Eidelwein Post author

      Olá Matheus,

      Tudo bem?

      Primeiramente de uma olhada se o campo delivery note está como obrigatório na OMJX.

      Depois olhe se você tem a nota 2012645 – STO: Goods Receipt error on MIGO using Inbound Delivery aplicada.

      Att,

      Patricia

      (0) 
      1. Matheus Caldeira

        Oi Patricia!

        Tudo bom e contigo?

        Então, olhei o campo e realmente não está como obrigatório, de qualquer forma, eu coloquei informações nele. Com relação a nota, estamos no EhP 13 e essa nota já está nela, não é aplicável….

        Consegui utilizar o movimento 861 pela transação MB0A, mas o estranho é que o ICMS contabilizado ficou diferente, 18% na saída e 12% na entrada. Tem ideia do que pode estar errado?

        Obrigado de novo,

        Matheus

        (0) 
        1. Patricia Eidelwein Post author

          Oi Matheus,

          Tudo certo! 🙂

          Muito provável que ele está pegando alguma exceção na hora da entrada.

          Para confirmar, faz o seguinte:

          Entra na NF antes de postar ela.

          Vai na aba impostos

          Clica no botão análise

          Mais uma vez análise

          Lá vai ser possível ver da onde (qual grupo) ta vindo essa rate do ICMS.

          Segue um print dessa tela. analysis pricing.png

          Abs,

          Patricia

          (0) 
    1. Patricia Eidelwein Post author

      Olá João,

      O estoque especial ‘E’ não foi entregue pela localização, então não é possível dizer como esse estoque funcionaria, e se funcionaria junto com os cenários de localização.

      Já vi alguns problemas serem reportados, então se precisar usar o estoque E sugiro que rode vários testes para garantir que o cenário funcione de acordo com o esperado.

      Att,

      Patricia 

      (0) 
  7. Edson Magalhaes

    Olá Patrícia,

    Surgiu a necessidade de configurar esse cenário para materiais que são administrados somente em quantidade.

    Quando faço a saída na VL02N aparece o erro:

    Verificar tabela T156SY: entrada 862 _ X _ L X   não existe

    Se eu consultar a tabela T156SY vi que só tem registro para administração de quantidade e valor.

    Daí eu pensei em criar um movimento Z como cópia do 862, mas pelo que tenho lido, não é recomendável que a tabela T156SY (visão V_T156SY) seja alterada.

    Tem alguma sugestão para me ajudar?

    Att.

    (0) 
  8. Patricia Eidelwein Post author

    Olá Edson,

    Técnicamente falando você tem essas duas opções criar um movimento com cópia no standard ou inserir a configuração de acordo com o cenário de negócio de vocês.

    Porém  qualquer dessas opções deve ser bem testada, pois esse cenário pode não ser coberto pelo suporte, se descoberto que essa configuração específica esta causando algum problema no sistema de vocês.

     

    Att,

    Patricia

    (0) 
      1. Eduardo Oku

        Oi Patrícia,

        O meu caso é semelhante mas o recebimento é com a VL32N;

        Quando tento fazer o Recebimento com a VL32N com Inbound Delivery já criada automaticamente pelo output type SPED, o sistema mostra a seguinte mensagem de erro:

        Reference could not be split into NF number, series and subseries Message No. 8B112

        A NFe criada pelo movimento 862 é eletrônica e a NFe que estou tentando registrar como entrada também está com flag para eletrônica.
        Encontrei a oss note 2367847 – STO: Source Document Reference is not Determined Correctly – SAPKH61713, mas o Basis confirmou que já está aplicada no ambiente.

         

        Então os passos que estou tentando fazer são os seguintes:
        a) ME21N – Pedido UB

        b) VL10B – Para criar Outbound Delivery

        c) VL02N – Saída de Mercadorias com NFe / MvT 862 / Output Type SPED para criar Inbound delivery Automaticamente

        d) VL32N – Recebimento de Mercadorias com NFe / MvT 861 – Onde está ocorrendo o erro 8B112

         

         
        Muito Obrigado!!!

         

        (0) 
        1. Patricia Eidelwein Post author

          Olá Eduardo,

          Tu chegou a abrir um incidente a respeito?

          Eu peguei um caso uma vez e era problema de configuração onde a nota era eletrônica e o sistema colocava como não eletrônica (ou vice versa). Com isso dava erro de referência 8b112.

          Seu basis chegou a debugar o ponto do erro? Ali com certeza é possível ver o porque do erro.

          Se tu tiver maiores informações me avisa.

          Att,

          Patricia

          (0) 
  9. Denis Vieira da Silva

    Ola, Patricia
    tudo bem?

    Estou tentando configurar o processo de Custo de frete em STO, aplicando a relevância do tipo de remessa a criação de transporte na VT01N, e consecutivamente realizar a criação do calculo do custo de frete na VI01.

    Minha pergunta é a seguinte, é possivel fazer essa configuração onde o custo entrado na VI01, seja inserido como debito posterior ou entrada de fatura no pedido de STO?

     

    att

    Denis

    (0) 
    1. Patricia Eidelwein Post author

      Olá Denis,

      Eu nunca testei esse cenário.

      Mas já vi outros clientes usando essas transações, mas não sei se era para a mesma finalidade.

      Talvez seja interessante abrir um fórum aqui no SCN para ver se alguém pode ajudar.

      Via standard não sei se é possível,

      Att,

      Patricia

       

      (0) 
  10. Fabiana Rocha Pereira

    Oi Patricia,

    Tudo bem?

    O meu caso, é que algumas vezes o usuário comete o erro de dar entrada no cenário de transferência com o tipo de movimento 101 quando o correto é o 861. Você conhece alguma maneira de bloquear o tipo de movimento 101 para pedidos de transferência? Alguma customização ou alguma user-exit?

    Obrigada,

    Fabiana

     

     

    (0) 
    1. Patricia Eidelwein Post author

      Oi Fabiana,

      Se você usa inbound delivery você pode na OMJJ tirar a transação VL31N da opção “allowed transactions”.

      Agora se vocês usam a MIGO não tem como bloquear o uso dessa transação com o movimento 101 pois é usado para vários outros cenários então nesse caso a melhor opção é criar um enhancement.

      Abs,

      Patricia

      (0) 
  11. Matheus Caldeira

    Bom dia Patricia,

    estou com uma dúvida, veja se consegue me ajudar, por favor.

     

    Percebi que quando faço a NF de Saída, na MB51 ele gera um movimento 862 de saúda da planta emissora e um movimento 862 de entrada na planta receptora, mas sem Storage Location, como se fosse o “em trânsito”, quando faço a entrada, via MIGO, ele gera mais um movimento, dessa vez 861 de entrada. No final eu fico com 2 movimentos de entrada e 1 de saída, isso está causando dúvida nos nossos usuários e em nós de IT também.

     

    Isso está certo? Esse estoque “em trânsito” não deveria ser eliminado? Lembrando que na MMBE ele faz correto, tirando do On-Order Stock e jogando para o Unrestricted use

    (0) 
    1. Patricia Eidelwein Post author

      Oi Matheus,

      No processo de transferência não há figura de estoque em trânsito para que a mercadoria fique enquando não chega na planta de destino.

      Com isso uma vez que você sai com o material da planta de origem, esse material entra na planta de origem como se já estivesse lá. E depois quando a mercadoria de fato chega  e você da entrada você ababa vendo o movimento duplicado. 

      Esse comportamento é standard.

      Abs,

      Patricia 

       

      (0) 
    1. Patricia Eidelwein Post author

      Ola Gilmarcos,

      Não tenho certeza o que é essa entrada partilhada. Talvez você possa inserir uns screen shot para que eu possa entender melhor.

      Você já tentou usar a MIGO?

      Como a transação MB0A está obsoleta se já não existe um nota pra isso só fazendo um desenvolvimento ou utilizar a MIGO.

      Att,

      Patricia

      (0) 
  12. Francismar Carvalho Nepomuceno

    Oi Patricia.

    Veja se pode me ajudar:

    Utilizamos o cenário STO há anos na empresa, nunca tivemos o problema que estamos observando agora. E para complementar a informação, implementamos em nosso ambiente SAP HANA em abri/2016.

    Problema:

    No recebimento da transferência (861) feito através de call transaction na MB0A em background, alguns documentos de material estão sendo lançados sem o código de imposto. A crítica standard de preenchimento do campo quando fazemos manualmente a transação não está impedindo estes lançamentos em background. Isso faz com que não seja gerado o documento contábil para compensação das contas de ICMS.

    Análise:

    • Só ocorre em alguns documentos (número representativo, mas minoria);
    • Independe de plantas origem/destino ou códigos de materiais;
    • Temos documentos de ago/2016 com o problema (não é possível checar antes disso devido ao arquiving dos dados (estrutura de docs arquivados tb não contém to campo cód. imposto da MSEG para fazermos esta conferência em período anterior);
    • Realizamos lançamentos manuais e todos pararam na crítica quando o campo está vazio;
    • Por não ser sempre que ocorre, tentamos receber através dos objetos customizados e também não conseguimos simular em QA (ambientes e cenários idênticos ao que apresentam problema em produção).
    • Na tabela j_1bt007 onde a FM j_1b_im_tf_check entra com cód imposto SD para encontrar o Cod. imposto MM para entrada existem vários registros possíveis para seleção.

    Enfim, não consigo reproduzir o problema e nem cheguei a conclusão sobre causa provável. Tem uma ideia sobre o que pode ser?

     

    Obrigado,

    Francismar

    (0) 
    1. Patricia Eidelwein Post author

      Ola Francismar,

      Eu iria sugerir exatamente esse ponto que você já olhor para ver se o sistema estava conseguindo encontrar o código de imposto de MM. Mas se até esse ponto o sistema encontra só acompanhando no debug para ver onde o tax code está sendo apagado.

      Eu sugiro olhar no FM J_1B_IM_TX_CALCULATE_TAX_NEW

      Nesse ponto abaixo:

      Att,

      Patricia

      (0) 

Leave a Reply