Por que estamos fazendo isso?

Declaração do problema

Situações não atendidas atualmente. 

• A transmissão das informações necessita de uma ação manual de parametrização e monitoramento do retorn das informações de dados. 
• Não temos o preenchimento automatico de campos ( F6_TIPOGNU e F6_DOCORIG ) o que impede a automação
• A transmissão é feito Estado a Estado o que também impede a transmissão. 

Por que estamos fazendo isso?

Declaração do problema

O módulo Fiscal Backoffice Protheus gera a obrigação acessória EFD ICMS/IPI (SPED FISCAL) em sua amplitude. Porém algumas informações complementares exigem dos usuários processos manuais, que oneram de forma significativa a operação nos clientes com grande volume de notas fiscais.

Um exemplo é o Registro  C113 Documentos Fiscal Referênciado, este registro tem por objetivo informar, detalhadamente, outros documentos fiscais que tenham sido mencionados nas informações complementares do documento que está sendo escriturado no registro C100, exceto cupons fiscais, que devem ser informados no registro C114.

Automatizar este processo será importante na redução de custos operacionais e aumento da produtividade dos nossos clientes da base. 

Situações não atendidas atualmente. 

Para alguma situações a geração do registro C113 já ocorre de forma automática, porém existem cenários em que as chaves de busca do Protheus não identificam o documento originário e nestas situações para que o registro seja gerado corretamento é necessário o preenchimentos das informações dos documentos de origem manualmente. Abaixo será relacionados alguns exemplo de vinculos de documentos automaticamente. 

• Operações por conta e ordem: Consiste na venda da mercadoria para um determinado cliente com entrega em outro. Dentro no normativo tributário estadual esta operação pode ser documentada por um único documento fiscal, normalmente em casos de operações estaduais, mas é muito comum a existência de dois documentos para acoberta esta operação. No segundo caso o vendedor remetente deverá emitir um documento em favor do destinatário para acobertar a operação, como "Remessa por conta e ordem de terceiros", e outra nota em nome do adquirente originário como "Remessa simbólica - venda à ordem". Neste caso temos que referênciar no documento de remessa simbólica  a nota de remessa por conta e ordem crindo o vinculo das operações. 

  1. Documentos do tipo normal
  2. Emitida para participantes distintos. 
• Operações de remessa e retorno para industrialização: Quando a empresa encomendante envia insumos, produtos intermediários e/ou embalagens para a empresas ou empresas que executarão os processos de industrialização. O normativo estadual prevê situações em que a mercadoria poderá transitar por mais de um indutrializador neste caso o documento de envio de mercadoria de um industrializador a outro será necessário referenciar o documento original do encomendante (Artigos 526 á 534 da parte geral do Decreto 4.676/01-PA).
• Operações em consignação: A operação de remessa de mercadoria em consignação ocorre quando uma empresa (denominada consignante) envia mercadorias para outra empresa (denominada consignatária) para efetuar a revenda. A consignatária somente adquire efetivamente as mercadorias se a revenda se realizar.Caso contrário, a consignatária devolverá a mercadoria à consignante sem nenhum prejuízo ou vantagem. No entanto, se a venda acontecer, ocorrerá, simultaneamente, a venda pela consignante e assim o negócio estará concluído,
• O consignatário no retorno simbolico da mercadoria deverá referenciar o documento de saída desta mercadoria. 
• O consignatário no simples faturamento da mercadoria deverá referência o documento de remessa da mercadoria em consignação. 
O consignamente na nota de venda da mercadoria deverá referenciar o documento fiscal pelo qual recebeu a mercadoria em consignação.

Como julgamos o sucesso?

x

• x

O que estamos fazendo?

x

x

Por que um cliente quer isso?

• x

Visualizar a solução

Link para os detalhes:

Escala e escopo

As alterações devem garantir que o CDD_IFCOMP seja informado com o campo F4_CODINFC 

Hoje o SPED tem um tratamento considerando o formulário próprio. Devemos considerar a importancia desta informação pois o código do participante a ser tratado é o do emissór do documnto fiscal juntos a SEFAZ. 

Seria importante identificar o comportamento do Transmite para esta busca de documentos e como o importador do XML 

Hoje os módulos de compras e faturamento trazem os valores e quantidades de dos documentos de origem depois que o sistema apresenta vincula a nota original pelos campos de documento origem, série origem e item origem. No solução que for apresentada este conceito não pode ser perdido. 

Devemos considerar que o registro C113 é filho do C110 então para o que processo seja 100% automatizado é necessário que esta hierarquia seja respeitada. 

Todos os estudo foram focados na deficiencia do sistema de vinculação do documento referênciado, porém é importante descatar que para a automação completa a vincula de informações de todos os campos é necessária, como por exemplo CDD_IFCOMP que originalmente vem do campo da TES F4_CODINFC

Entender as limitações de controle e baixa de estoque de poder terceiros para entender que  nossa solução não seria limitado por este item. o caso de envio de mercadoria para mais de um industrializador 

Quais as rotinas que serão envolvidas com a inclusão ou adequação de telas. 

Será importante adequar as seguintes rotinas: 

• Solicitação de compras (MATA120)
• Pré-Nota (MATA140)
• Documento de entrada (MATA103)
• Pedido de venda (MATA410)
• Documento de entrada (MATA460)
• Documento manual de entrada (MATA910)
• Documento manual de saída (MATA920)

Esta rotina já possue Schedule para transmissão automatica

• Como está hoje

  : Existe a rotina de complemento de documentos (MATA926) que permite ao usuário o preenchimento dos códigos de informações complementares a serem utilizados pelo sistema no momento da geração do registro

  : Atualmente usuário precisa ir até ao módulo fiscal, navegar pelo menu: Miscelânea / Arq. Magnéticos / GNREWS (FISA095), preencher parâmetros de estado, transmitir a GNRE, depois monitora-la.

  O processo é moroso, principalmente quando o fluxo de GRNE é muito grande.

• O que pode mudar:

  Por meio de um critério de decisão incluído no cadastro de TES - Tipo de Entrada ou Saída ou outro cadastro com a mesma funcionalidade automatizar as informações que serão geradas para este registro. 

  Fazer o processo de transmissão e monitoramento automático, como ocorre com a transmissão de NF-e. Pois hoje temos o processo de transmissão e monitoramento de NF-e automático, entretanto o fato de ter que ficar transmitindo as guias gera um trabalho manual que poderia ser evitado.

• Valor da entrega (benefícios ou problemas a serem resolvidos com essa melhoria):

  Eliminação de uma etapa manual para emissão de documentos fiscal que possuem documentos referenciados.

• Como está hoje: Esta um processo de trabalho demorado ainda possibilita erros de digitação manual de modo que o preenchimento automático dos campos ( F6_TIPOGNU e F6_DOCORIG ) iria proporcionar grande eficiência nos trabalhos do dia-dia evitando erros desnecessários e otimizar o modo como esse processo funciona hoje fazendo com ele esse processo fique rápido.

  A totvs criou dois novos campos para atender as regras da GNRE 2.0, F6_TIPOGNU e F6_DOCORIG, só que segundo a totvs o preenchimento destes campo deve ser feito de forma manual pelo usuário, isso até funciona para quem tem poucas guias e não usa o AUTOFAT com geração das guias de forma automática.

  No meu caso tenho um volume de 1500 guias por dia, como que o usuário vai preencher guia a guia este campos é inviável, no meu entendimento não é nem uma melhoria e sim um erro no produto já que a totvs fornece as ferramentas para gerar a guia e transmitir de forma automática só que sem o preenchimento dos novos campos a guia vai ser rejeitada, forçando assim o usuario entrar guia a guia e preencher as informações nos campos, então considero uma falha no produto e que deveria ser corrigida urgente devido ao prazo da GNRE 2.0.

  Eu mesmo não estou usando a versão 2.0 pois é inviável ficar preenchendo estes novos campos manualmente, acho que vários outros cliente devem estar enfrentando o mesmo problema.

• O que pode mudar: 

  A totvs criar 2 parametros e no momento da geração da guia preencher as informações nos campos F6_TIPOGNU e F6_DOCORIG de acordo com os parâmetros igual já é feito hoje com outros campos exemplo código da receita.

  Exemplo de novos parâmetros

  PARAMETRO 1 - MV_TIPOGNU CONTEUDO (AL00000,AM00001,CE000002 etc)

  PARAMETRO 2 - MV_F6_DOCORIG CONTEUDO (AL1,AM2,CE1 etc)

• Valor da entrega (benefícios ou problemas a serem resolvidos com essa melhoria): Poder continuar usando as rotinas de automatização da geração / transmissão da GNRE de forma automática.

• Como está hoje: Temos que transmitir a GNRE WS individualmente para cada UF pois na rotina de transmissão da GNRE só é possível informar a UF uma única vez, logo se temos que transmitir GNRE de vários estados precisamos fazer várias transmissões pois não é possível transmitir vários estados preenchendo como BRANCO a ZZZZZZ.Em contato com a TOTVS no chamado Solicitação #10388267 informaram que atualmente só é possível fazer uma única transmissão por vez da GNRE sendo uma para cada UF, porém isto não é viável devido ao volume das transmissões. No caso da Nota Fiscal Eletrônica não precisamos selecionar para qual UF foi emitida a nota fiscal e preenchendo apenas os parâmetros de numeração como BRANCO a ZZZZZZ podemos transmitir diversas notas ao mesmo tempo independente do estado.

• O que pode mudar: Criar mais um parâmetro na rotina FISA095 com o código da UF para que possa ser informado de BRANCO a ZZZZZZ.

• Valor da entrega (benefícios ou problemas a serem resolvidos com essa melhoria): Esta melhoria é importante pois se tivermos várias guias para vários estados o processo de transmissão precisa ser feito várias vezes o que toma um tempo desnecessário da pessoa responsável pelo processo de recolhimento das guias.