Tabela CFOP de para

[rubens]

Bom dia...

Alguém teria ou sabe onde posso encontrar uma tabela de relacionamento de para CFOP para ser usada no SPED Fiscal?

Eu tenho umas regras de negócio e vou acrescentando mais a medida que vou me deparando com as situações novas, só que ficou uma teia muito grande e cheia de gambiarras.
Preciso de algo como:

CFOP:
5102,6102 -> 1102,2102
5401,5403,5405 -> 1403,2403
5655,6655 ->1652,2652

Obrigado
Rubens

[Kiko Fernandes]

Boa tarde Rubens!
Veja se o conteúdo deste link te ajuda. Não sei se entendi direito o que vc precisa.
http://www.ean-es.com.br/ckfinder/userf ... _DE_NF.pdf

[rubens]

Obrigado Kiko...
Já vai ajudar bastante...

Rubens

[Jairo Maia]

Olá Pessoal,

Rubens, veja também se essa ajuda. Acho mais facil você usar o CFOP de entrada de acordo com a finalidade da compra da mercadoria: CFOP Entrada

[JoséQuintas]

Eu acabo tendo uma dessas, mas deixo por conta do usuário.
É usada pra importar XMLs de fornecedores.

Minhas regras de negócio faço encima do código de transação, acabou virando algo como meu próprio CFOP.... rs
O máximo que faço com CFOP é confirmar se é entrada ou saída.
O aplicativo acaba nem dependendo de lei do governo pras regras, podem alterar a tabela de CFOP à vontade... rs

Eu nem tinha percebido isso antes.
Por isso altero fácil as mudanças de lei que acontecem, porque o aplicativo segue suas próprias regras.

[rubens]

Bom dia...

Pois eh Quintas o ideal seria isso, mas se eu não tentar travar ao máximo aqui as opções, o programa "começa a dar um monte de erros" e a culpa é de quem???? Minha claro....
Olha o que tive que fazer por conta de um cliente que não sabia olhar na nota e definir se o produto era com ou sem st. E o cliente tá no lucro presumido caminhando pro lucro real.

Jairo essa tabela aí eu tenho, mas eu quero é fazer tudo automático sabe, quando o cliente baixa o xml e manda o sistema importar, Eh para cadastrar o fornecedor automaticamente, e buscar no cadastro de produtos se aquele produto já está cadastrado, se tiver já associa também, e para os produtos que não forem encontrados basta o usuário selecionar o grupo e alterar a descrição e qtdes conforme a sua visão, para o próprio sistema cadastrar automaticamente o produto, gerando inclusive preço de venda através de regras e parâmetros pré-definidos. Daí para o usuário que tem que gerar o SPED já relaciona automaticamente o CFOP de entrada para o SPED. Aqui nos meus clientes que tem que gerar o SPED eu já até fiz um relatório filtrando os cfops das nfe de compra e são poucos, então dá para relacionar.. daí se vem na nota um CFOP diferente do que está relacionado, aí sim o sistema solicita do usuário a informação de qual é o CFOP de entrada daquele produto. E como eu sempre reviso e importo no validador o SPED se houver uma inconsistência eu corrijo antes de enviar para o contador.

Obrigado,

Rubens

[fladimir]

Rubens e se o produto vem de vários fornecedores?

Exemplo Produto XPTO... pode ser comprado de:

Fornecedor A de MG
Fornecedor B de AM
Fornecedor C de SP
Fornecedor D de PR
Fornecedor E de SC
Fornecedor X de ETC

Ou seja pode ser o mesmo produto mas com diferenciações oriundas dos regimes tributários x UF do fornecedor, não afetaria a lógica q vc esta imaginando?

Hj faço algo similar ao q o Quintas falou, tipo minhas regras de negócio... mas ainda esta engessado no código, tenho q mudar para Tabela etc q ai da pra ir alterando independente de recompilar.

Agora baseado no exemplo acima... eu ainda deixo na ficha do produto tipo q nem vc o fornecedor... mas acaba sendo o ultimo fornecedor q comprou e vou ter q mudar isso pq tenho clientes q compram um mesmo produto de vários lugares e não posso deixar amarrado 1 fornecedor para 1 produto... penso em modificar pra aparecer o ultimo fornecedor (q é o q já existe) e mostrar na ficha do produto os diversos ou ultimos 10 fornecedores q o produto foi adquirido...

[]´s

[JoséQuintas]

Aí é que está.
No final, o seu cadastro precisa de você pra ser feito, ou do contador.
Contém informação que o usuário não conhece, e nem o contador, por isso a culpa será sua... rs

No meu cadastro tem apenas um código:
Código de Tributação do produto.

Fica mais fácil pro usuário decidir, mais difícil dele cometer erros, e só será problema se houver alguma tributação nova.
Aí sim... a culpa vai ser do usuário.... rs

Acaba deixando a parte complicada para casos eventuais.
Não é infalível, nem a prova de erros, mas descomplica um pouco o uso normal e o aplicativo.

Já mostrei por aqui como faço tudo isso.
Também deixei claro que atende as situações atuais, e não sei sobre o que pode aparecer depois.

No cadastro de produtos: código de tributação de produto
No cadastro de clientes/fornecedores: código de tributação do cadastro
No pedido: código de transação
Para o usuário, para o dia a dia, só isso. Dá pra dizer que ele tem que saber disso, que se estiver errado é porque ele preencheu errado.

Já para as regras de tributação, que ficam dependentes de legislação, aí sim, acabo fazendo a intermediação entre contador e usuário, pras traduções, quando precisa.
Mas isso está na linguagem do contador, daria pra ele se virar, se quiser.

O que acontece na prática é o seguinte:

- o contador alega que não conhece o sistema, de certa forma ele está correto
- o usuário alega que não conhece essas coisas, de certa forma o usuário está correto
- nós alegamos que é responsabildiade do contador informar e do usuário preencher, de certa forma estamos corretos

Então temos que trabalhar nessa intermediação, tentar deixar o aplicativo na linguagem deles, pra deixar bem claro que o erro é deles.
Não pensei nisso quando criei minhas regras, mas acabou dando certo nisso tudo.
Pensei só em facilitar a parte de programação.
Como diria o chaves.... "foi sem querer querendo" ... rs


Só recapitulando:
- tem o código no produto, de tributação
- tem o código no cadastro, de tributação
- tem o código de transação
- tem o código no cadastro de UF (que atualmente pode compensar separar por UF)

Isso forma este conjunto, que é minha chave pra regra
Note que esse conjunto é conhecido pelo usuário e pelo contador.

regra.png (6.37 KiB) Exibido 3881 vezes

O usuário vai ligar pro contador e perguntar:
Como que eu preencho uma nota de venda, dentro de São Paulo, para um cliente do tipo geral, e produto do tipo revendido?
E os dois vão se falando com o que aparece na tela.

O resultado disso fica relacionado a eu ter criado essas tabelas de código bem descritas pra evitar erro, e com o máximo de variações possíveis.
As regras vão sendo cadastradas conforme cada situação for aparecendo.

[JoséQuintas]

Complemento:

No tipo de cadastro, so inventar conforme precisar: pessoa física, não contribuinte, simples nacional, etc. etc.
No tipo de produto idem: produto com substituição tributária, produto de plástico, produto de metal, combustível S10, derivado de borracha, etc.
Na transação: venda pra revenda, venda pra fábrica, venda pra consumidor final, etc.

Só imaginar o usuário e o contador conversando:
Como eu preencho uma compra, de uma fábrica do simples nacional, de produto derivado de borracha?
Como eu preencho uma devolução de venda, para uma pessoa física, de produto derivado de borracha?
Como eu preencho uma simples remessa, pra uma empresa lucro real, de um equipamento de informática?

As regras podem se multiplicar com as variações, mas fazer o que.
É algo como traduzir a legislação.

O contador não vai precisar conhecer o sistema, só responder as perguntas.
O usuário não vai precisar ter conhecimento profundo, só ver o que está na tela e perguntar pro contador.

Produto novo?
Pergunta pro contador: aonde ele se encaixa? em nenhum, então vamos criar um tipo novo.
E ao fazer isso, e digitar o pedido, o aplicativo vai procurar pela regra dele com a combinação que acontecer no pedido.
E liga pro contador, diz a combinação, e o contador vai orientando...

[Jairo Maia]

Olá Pessoal,

Rubens, quando você disse Nota de entrada, imaginei a relação CFOP de Entrada e a Escrituração da nota de entrada. Na verdade o que você quer é a relação de entrada e saída de produtos.

Agora... Porque então não orientar o cliente a cadastrar o produto para saída com base no CST? Claro que estabelecendo o critério que vale sem exceção para produtos adquiridos dentro do próprio estado [veja Nota abaixo], que é a imensa maioria das vezes (pelo menos no meu caso) e diminuir muito a probabilidade de erros?

Produtos tributados com substituição:
CST entrada = 010, 060, 070 => CFOP: 5405

Tudo que for tributado sem substituição ou isento:
CST entrada = 000, 020, 030, 040, 041, 050, 051, 090 => CFOP: 5102

Nota: Isso vale se o Emitente da nota for do mesmo estado do Destinatário, porque operações interestaduais caberia orientação, uma vez que podem ser tributadas com ou sem substituição e a comercialização interna no estado destino é isenta, ou isenta na origem e tributada no destino.

Exemplo: Tenho um cliente que compra carne de um frigorífico do Paraná, a nota de entrada chega com CST 020 (tributada e com redução), porém, comercialização interna de carne em SP é isenta, como também sempre oriento para definir o CST ou CSOSN pelo CST de entrada, faria diferença na definição do CST/CSOSN de saída, mas o CFOP nada mudaria. Salvo exceções desse tipo, os demais vira padrão.

Me parece mais simples, na minha opinião...

[rubens]

Bom dia...

O velho e bom Fórum Clipper on Line... você faz uma perguntinha simples e ganha uma aula !!! obrigado...

Mato Grosso a legislação é um pouco mais simplificada, "resumida"... Embora esteja acabando temos uma modalidade chamada carga média, onde a empresa é enquadrada em uma categoria e paga um percentual fixo na entrada do produto. No meu caso Informática e papelaria, independente do estado eu pago uma 7.5% de imposto na entrada. Material de construção paga 11.20%. Isso já simplifica muita coisa. Tenho um cliente no Lucro Real e outro no Lucro Presumido o restante tudo é no Simples Nacional. A maioria dos clientes ainda usa o método antigo de jogar uma porcentagem no preço de custo para chegar ao preço sem final, sem fazer cálculos. Então nunca fui obrigado e nem tive necessidade de preocupar com muitos detalhes na composição do preço de venda do produto. No meu sistema básico só cadastra no produto as informações necessárias para emissão de nfe ou nfce. Agora com tantas obrigatoriedades o negócio tem que ir evoluindo. Mas o sistema é flexível para o usuário alterar o que for preciso, dentro de umas regras de negócio é claro.

Jairo não aparece na tela por questão de espaço e Layout (na versão minigui já está aparecendo) a informação de Fornecedores, permanecendo o último, mas tenho uma consulta que mostra um browse com os dados das últimas compras daquele produto, trazendo fornecedor, data da compra, qtde e valor.

AS regras que o Quintas usa parecem ser o certo, mas por diversos motivos fui obrigado a ir "moldando" o sistema conforma a necessidade. Comecei a trabalhar com um colega para migrar para o mysql, e tivemos um trabalho danado para modelar o banco e criar os relacionamentos. Paramos o projeto. Um sistema onde sempre foram criados e excluídas informações conforme a urgência do momento, é muito difícil de ser padronizado. Daí resolvi tentar melhorar ao máximo esse sistema para começar um novo, esperando que os erros cometidos nesse não voltem a ocorrer no novo.

Quanto a entrada de dados automatizada pelo XML tem dado certo e tem me trazido clientes. Quando veem a facilidade de cadastrar os produtos ficam satisfeitos. É lógico que depois que faz o cadastro do produto o usuário tem que entrar e corrigir alguns detalhes como o preço, mas já é bem melhor do que digitar um a um. Quando você pega uma nota com mais de 100 itens e o sistema já associa com o banco de dados pelo menso 80% disso, é um economia de horas de serviço. Tenho um cliente que cometia erros no Código de barras !!! É tão pão duro que não tem coragem de comprar um leitor de código de barras... digita manual... e cria caso comigo que o programa dá erro na hora de ler o código de barras que ele digita... não deixa passar falando que o código de barras tá errado.

Quanto a compra de diversos fornecedores, pelo motivo que já mencionei acima, não faz diferença o estado que vem. As regras basicamente são as mesmas... Se existe algum convênio com alguma redução, aí já depende do contador informar para o cliente, mas não sei se os contadores não sabem ou eu não tenho nenhum cliente que tem algum benefício, até hoje não foi solicitado nada a esse respeito.

Jairo essa idéia de relacionar pelo CST/CSOSN vou dar uma estuda nisso, mas a questão é que alguns CFOP mudam, não posso fixar em 1102 ou 1403 automaticamente. Um exemplo o CFOP 5655 ou 6655. ele vai mudar para 2652 ou 1652, dessa forma não posso simplesmente trocar os 5 ou 6 iniciais para 1 ou 2. E aí onde falo que vira um teia o relacionamento automático. Tem que ir lá e colocar se for CFOP tal vai virar CFOP tal na hora de informar o SPED.

Obrigado...

Rubens

[Jairo Maia]

Olá Rubens,

Li tudo que você colocou e apenas alguma observações:

Onde você disse: Jairo não aparece na tela por questão de espaço e Layout, leia-se: Fladimir não aparece [...]

Onde você disse: não posso fixar em 1102 ou 1403 automaticamente, leia-se: não posso fixar em 5102 ou 5405 automaticamente

Já quanto a isso:

Um exemplo o CFOP 5655 ou 6655. ele vai mudar para 2652 ou 1652

Realmente, é que não levei em conta que você fornece para revendedores, não apenas para consumidor final. No caso de fornecer combustíveis e lubrificantes para consumidor final nada mudaria, seria 5102, mas para revenda o bicho pega mesmo... Na saída tem que ser 5655 para mesmo estado ou 6655 para operação interestadual para que a nota seja escriturada corretamente na Entrada pelo contribuinte adquirente. Isso ai...

[JoséQuintas]

Pequena correção:

No caso de combustível, tem CFOP próprio pra tudo, pra consumidor, pra revenda, pra devolução, até mesmo pra venda no mesmo estado com pagamento fora dele.

No meu caso a conversão é semi-automática, fica por conta do usuário definir o de/para a cada nova combinação de CNPJ/CFOP e de código de produto.
Mostro a descrição do XML, e ele seleciona o código correspondente, isso na primeira ocorrência.
Os próxmos passam a ser automáticos com base no que ele já definiu antes.

A nota fica gravada já convertida e depois vai ser só gerar, sem precisar converter nada.

Senão... vai ter que converter pra gerar o SIMPI, o GRF/CTB, Sped, e tudo mais relacionado.

De quebra, aproveito essa mesma informação pra gerar o pedido de compra com os próprios códigos do fornecedor.

Não digo que fiz certo, apenas criei desse jeito e até agora tem atendido as necessidades.

Nota: importo os XMLs do fornecedor. Ou ele digita, ou ele configura, então ele fica feliz em configurar.... rs