GRC Inbound com LES - Validação de CNPJ do tomador de frete - CTEOUTLE

[former_member227638]

Boa tarde senhores!

Durante a configuração do processo CTEOUTLE com LES no SP14, observamos que durante a etapa de validação de um CTE que referencia um processo de transferência, estamos recebendo a seguinte mensagem:

"CT-e CNPJ tomador do serviço XXXXXXXX/XXXX-XX diferente de NF-e 311312074014360XXXXXXXXXXXXXXXXXXXXXXX CNPJ emissor YYYYYYY/YYYY-YY"

Ao depurar o programa notamos que ele confere se o CNPJ do tomador do serviço é o mesmo do emissor da NFe. Porém nossa realidade demanda que a matriz tome o serviço de todos os CTes, e no caso das transferências, na maioria dos casos o emissor da NFe sao as filiais enviando materiais para outras filiais, logo CNPJ diferente.

Exemplo:

Matriz CNPJ A

Filial 1 CNPJ B

Filial 2 CNPJ C

Matriz toma serviço de CTe de transferência entre filial 1 e 2. Sistema nao permite pois CNPJ da filial 1 é diferente do tomador (matriz)

Erro GRC:

Configuração:

Além do mais, notamos que ao pular tal consistência, o GRC permite atribuir apenas IVAs de serviço para o CTE.

Isso esta correto?

Obrigado pela ajuda!

Abs

[Former Member · Accepted solution]

Ola Ortiz, tudo bem?

Eu queria alerta-lo que o registro de um documento de frete (CTRC e CT-e) é feito pelo tomador do serviço (quem efetua o pagamento) e não por quem recebe mercadoria.

Poderia verificar se esta correto registro do CT-e pela filial que não é o tomador do serviço?

Obrigada,

Karen Rodrigues

[former_member227638 · Accepted solution]

Oi Karen,

Nosso pedido de compras gerado pelo Transportation foi criado para o tomador do serviço (matriz) corretamente conforme gerado no XML do CTe.

Porém, nesse caso o GRC esta indicando que SEMPRE o CNPJ do emissor da NFe de saída de transferência deve ser o mesmo do tomador do serviço do CTe, e ao nosso ver não parece coerente, tendo em vista diversas filiais emitirem NFe com a matriz como tomadora do CTe.

Grato.

[Former Member · Accepted solution]

Oi Ortiz.

Essa é uma restrição do sistema. Não sei lhe dizer porque foi feito dessa forma; acredito que foi para garantir que no conhecimento não haveria notas fiscais que não fossem destinadas ao tomador ou destinatário.

Te confesso que não tinha visto um cenario como este. Em qual SEFAZ você opera?

Não sei nem lhe dizer se isso é caso pra chamado ou para melhoria pois teria que ver a legislação e entender os requisitos.

o que você sugere?

Abraço

Eduardo Chagas

[former_member227638 · Accepted solution]

Olá Eduardo,

Imagino que deva haver um motivo pois facilmente conseguiríamos via Enchancement mudar tal comportamento, porém, não entendemos bem o porque a SAP criou tal restrição.

Operamos em SP, MS, MT, MG

Quanto ao IVA para a fatura, esse mesmo DEVE ser de serviço? Pois o matchode nao propõe IVAs que são usados no CTe via MIRO manual e quando tentamos usá-lo, alguns erros e validações sobre material (mesmo o pedido sendo serviço) são feitas, como origem do material.

Obrigado.

[Former Member · Accepted solution]

Oi Ortiz, tudo bem?

Quando a localização penso que posso te ajudar. O LES não é localizado, é preciso realizar desenvolvimento para atender a legislação brasileira.

Se a empresa optar por tratar o IVA no shipment cost este deve ser um IVA de serviço e referenciar um De/Para para um IVA nao serviço para ser atribuído na MIRO e registrar seu documento de frete adequadamente.

Desenvolvemos uma atribuição automatica de frete para evitar que usuario escolha um IVA incorreto.

Quais erros vocês estão encontrando?

Att.

Karen Rodrigues

[former_member227638 · Accepted solution]

OI Karen, obrigado pelo seu retorno.

Na verdade não temos IVAs de serviço para frete, são IVAs convencionais onde sempre pagamos os CTes, acontece que quando tento usar os mesmos IVAs na automação com LES, ele começa a dar mensagens de erro como "preencher origem do material", como se fosse um material.

Esse DE-PARA que você falou é standard?

Grato.

[Former Member · Accepted solution]

Ortiz,

A empresa realizou uma implantacão do LES com muito desenvolvimento...infelizmente não aconselho seguir a mesma regra

Posso sugerir a automação automatica do IVA, que seria necessário desenvolver.

Recentemente a Claudia Wada cedeu gentilmente um material sobre o CT-e, ali tem um item que fala sobre impostos e detalhes para CT-e entrada e saída.

Compartilhei através do link abaixo:

CT-e_v5.1.pdf - Google Drive

Inclusive menciona algumas novidades que achei muito interessante e sao standard

Mas se ainda tiveres duvida, poste aqui para os colegas poderem ajudar.

Abraços

Karen Rodrigues

[claudia_wada · Accepted solution]

Oi Ortiz,

O cenário de transferência não é suportado. Somente os cenários de entrada e saídas são suportados. Devido a limitação de recurso, ficou fora do escopo.

A recomendação é usar o processo FLEX.

Você pode abrir este tópico no Idea Place para verificar a demanda do tópico para um possível desenvolvimento standard, o desenvolvimento sempre está de olho lá.

Abraços

Ps: Me mandaram um email sobre isso, inclusive com o mesmo texto, acho que se trata da mesma empresa. Respondi para o Bruno Ferrari.

[Former Member · Accepted solution]

Claudia,

Obrigada por dar retorno no SCN.

Abraços!!!!

Karen Rodrigues

[former_member227638 · Accepted solution]

Obrigado pela confirmação!

Abs

[Former Member · Accepted solution]

Oi

Fiquei em dúvida. Sendo a matriz o tomador do serviço não funciona por causa do STO?

Funcionaria se o documento de transporte fosse criado com base na inbound delivery ao invés da outbound delivery no processo de STO?

Abraço

Eduardo Chagas

[claudia_wada · Accepted solution]

Oi Eduardo,

Na época que estávamos discutindo esse desenvolvimento com um consultor de LES (já que não conhecíamos nada de LES), ele havia explicado que para STO, a configuração do LES era diferente das configurações de inbound e outbound.

Não lembro exatamente qual era a diferença, mas ele deixou a entender que era complexa.

Mesmo que o tomador do serviço seja a matriz, e supondo que a gente arrumasse esse ponto do código, eu entendo que não iria funcionar na parte do LES considerando o comentário do consultor (configuração diferente).

Abraços

[Former Member · Accepted solution]

interessante rsrsrsrs. Eu diria que é diferente assim como a de inbound é diferente de outbound.

Vou colocar isso no customer connection. Ok?

[Former Member · Accepted solution]

Claudia

Na verdade ainda estou tentando entender a diferença a que o consultor se referiu? Se encontrar e puder me enviar te agradeço.

Abraço

Eduardo Chagas

[claudia_wada · Accepted solution]

Oi Eduardo,

Antes tarde do que nunca, falei com o consultor, ele me explicou que no caso de Transferência, normalmente não há Folha de Registro de Serviço e consequentemente não há pedido de compra de frete. Assim não há como haver a comparação entre o XML e a PO. Neste caso o custo do frete seria lançado diretamente no pedido de transferência do material (custo para estoque).

Mas agora que entendo um pouco mais de LES, o cenário mencionado acima seria semelhante ao cenário de frete entrada, onde normalmente não há PO/SES do frete pois o frete entra como custo complementar da mercadoria. Porém, no nosso desenvolvimento de frete entrada, o PO de frete tem que ser criado, do contrário não iríamos conseguir fazer as comparações.

Então entendo que no processo de STO, poderíamos fazer o mesmo. O que você acha?

Abraços

[Former Member · Accepted solution]

Oi Claudia

Considerando uma transferência pontual faz sentido... mas por exemplo pensar que muitas empresas possuem um cenário onde o fornecedor é outra filial... ou mesmo um centro pode ser uma fabrica abastecendo um centro de distribuição isso muda bastante o cenário.

Entendo da mesma forma. Acho porém que a solução deveria ser capaz de tratar o STO considerando o documento de frete criado tanto a partir da remessa de saída (OD) quanto da remessa de entrada (ID).

Qualquer dúvida me avise.

Abraço

Eduardo Chagas

[former_member413438 · Accepted solution]

Oi Claudia e pessoal. Após ler esse tópico me deu uma dúvida.

O CT-e inbound não funcionada para compras (CTEINBLE) onde o processo de LES é custo complementar de aquisição?

[claudia_wada · Accepted solution]

Oi Gustavo,

Se no processo de compras com LES não é criado um pedido de compra de frete e o custo do frete fica alocado no pedido de compra da mercadoria - esse cenário realmente não é suportado pelo nosso CT-e Inbound, tem que haver a criação do pedido de compra de frete.

Abraços

[former_member413438 · Accepted solution]

Oi Claudia. Obrigado pelo retorno.

Isso não deveria funcionar? Pois para a grande maioria dos cenários do LES para inbound, é utilizado o custo complementar de aquisição para que o valor do frete agregue o valor do material.

Desta forma não existe pedido de compra de frete nem folha de registro de serviço. Obrigado.

[claudia_wada · Accepted solution]

Oi Gustavo, sem pedido de frete o incoming não consegue comparar os impostos, a alocação dos custos deve ser feita via FI/CO posteriormente.

Abraços

[former_member413438 · Accepted solution]

Oi Cláudia, obrigado novamente pelo retorno.

Existe alguma documentação da SAP sobre o CT-E inbound? A única que encontrei foram os fluxos de entrada e saída.

Obrigado,

[former_member453127 · Accepted solution]

Pessoal

Conforme orientação da SAP no documento CTe Incoming
automation, o processo de recebimento de frete eletrônico para compras

deve ser realizado da seguinte forma: Pedido de compras de
mercadoria -> Inbound delivery -> Documento de transporte -> Custo de
frete -> Pedido de compras de frete -> Folha de registro de serviço ->

Quando o pedido de compras de mercadoria possui uma
classificação contábil, deve-se informar a mesma conta contábil para a despesa
na folha de serviço do pedido de frete. No entanto, quando temos um cenário de
pedido de mercadoria para estoque, não podemos fazer este mesmo procedimento,
pois este não possui conta do razão.

Segundo a DELIBERAÇÃO CVM Nº 575, deve-se realizar a
contabilização da compra do frete na conta do material. No entanto, não se pode
informar uma conta de reconciliação - neste caso, a própria conta do registro
de estoque do material - manualmente no pedido de compras de frete.

Ou seja o GRC não recebe automaticamente os fretes para materiais estocaveis!

Já passaram por esse problema?

Sds

Rodrigo