Problema de contabilização mesmo imposto retido e não retido
Rinaldo
Olá pessoal,
Como para implementar a minha nota de serviço na versão 4.1 e na versão 5.1 tive que alterar org.idempierelbr.tax.provider.DefaulttaxProvider (provider da nfe tb tem o problema)
e antes de demonstrar a alteração necessária (que já havia demonstrado em post anterior) e submeter para o projeto as alterações, abri esse tópico para discussão para ver se conseguimos avançar juntos nesse assunto, no intuito de que todos que usam o Idempierelbr possam tirar proveito disso no futuro.
Sobre retenções, o Alan já comentou em outro post meu que existe um plugin para isso. Pelo que estudei esse plugin é desnecessário, se essas alterações forem realizada dentro do próprio projeto lbr.
Estou preocupado com isso pois deixar isso para mais avante no projeto pode significar um trabalho a mais na questão contábil brasileira que poderia usar de forma natural o que já existe no Idempiere gravando certo nessas tabelas.
Problema:
O que eu considerei como problema:
Quando o mesmo imposto é retido e não retido (serviços) o sistema lança de forma incorreta a contabilização no Idempiere (contas não corretas ou falta lançamentos)
Tabelas afetadas: C_InvoiceTax, C_OrderTax, C_Rmatax e LBR_Nfstax
Situação contábil quando do faturamento de serviço que apresentou-se os problemas:
Lucro Real para Lucro real : IR Retido de 1,5%(pago pelo tomador) IR - Contabilizado depois (a pagar pelo emissor) 3,3%
Lucro Real para Lucro real : CSLL Retido de 1% (pago pelo tomador) CSLL - Contabilizado depois (a pagar pelo emissor) 1,8%
Lucro Real para Governo : IR Retido de 4,8%
Lucro Real para Governo : CSLL Retido de 1% CSLL - Contabilizado depois (a pagar pelo emissor) 1,8%
Lucro Real para Simples: IR não retido 4,8%, CSLL não retido 2,8% (pago pelo emissor de forma posterior), ISS retido ou não retido
Considerações:
1) Para criar esses impostos é necessário no cadastro de impostos do Brasil (lbr_taxname) criar um IR retido e outro não retido( o mesmo para o CSSL e ISS) pois o parâmetro de retenção pertence a cada nome de imposto.
2) Esse parâmetro de retenção não existe em Ctax mas nesse cadastro também deve estar repetido esses impostos para se contabilizar em contas diferentes (cadastro de um retido e um outro de não retido ISS, IR, CSLL ), apontando o grupo (lbr_taxgroup - grupo que está nomeado no sistema como 'IR", 'ISS', 'ICMS'...e os novos INSS, CSLL ). -> Acho que esse é o ponto inicial a ser discutido.
3) Sei que quando o valor do (amt) é negativo seria retido e quando positivo seria não retido. O problema é que ambos os impostos são necessários a serem contabilizados no mesmo lançamento contábil.
Localização do problemas no código da versão atual:
Localize a linha: iTaxList.put(new Integer(cTax.get_ValueAsInt("LBR_TaxGroup_ID")), newiTax); (método calculateInvoiceTaxTotal em DefaulttaxProvider)
Observe que se alimenta um Map hash pela chave com um ID de lbr_taxgroup.
Assim sendo quando o sistema possui cadastrado em CTax o mesmo imposto duas vezes (Retido e não retido, cfe consideração 2) o sistema irá manter em memória nesse hash somente o último objeto (que contem a chave de um C_Tax), matando se já existir algum anterior (contabilizando certo ou errado, cfe a ordem) e ainda eliminando a possibilidade de contabilizar em separado os impostos retidos e não retidos.
Exemplo de problemas lançou IR retido na conta do IR não retido, ou vice versa, e nunca contabilizando quando as situações exigem ambos os impostos. Ou seja mesmo que em lbr_taxline esteja tudo correto em c_InvoiceTax, C_orderTax, lbr_nfstax vai estar errado.
O mesmo acontece se cadastrar duas vezes um ISS retido e outro não retido (C_Tax) o sistema escolherá somente um e vai lançar nessa código de imposto conforme a ordem do cadastro em C_Tax
Para o ISS você até pode cadastrar uma única vez em C_Tax como regra (existe uma situação fiscal no Brasil que a nota tem ISS Retido e não retido - ISS Duplo), mas para o IR e CSLL isso não é possível (a menos que se crie um processamento para contabilizar os 3,3% de IR e 1,8% do CSLL de forma posterior, o que não é uma boa prática contábil cfe o cfc.org)
Proposta de alteração:
Para resolver isso adotei a seguinte saída usar o C_Tax_Id como chave do hash e trocar onde busca o dado do grupo por como iTaxList.get(MLBRTax.getTaxGroupID(MLBRTax.TAX_GROUP_??????)) por essa chave.
Alterei a linha de exemplo (exemplo da Invoice, idem para Order e Rma)
de: iTaxList.put(new Integer(cTax.get_ValueAsInt("LBR_TaxGroup_ID")), newiTax); //(método calculateInvoiceTaxTotal em DefaulttaxProvider)
para: iTaxList.put(new Integer(cTax.getC_Tax_ID()), newiTax); // (método calculateInvoiceTaxTotal em DefaulttaxProvider)
// Abaixo do loop que busca os itens
for (int i = 0; i < lines.length; i++) {
MInvoiceLine line = lines[i];
MLBRDocLineDetailsTax details = MLBRDocLineDetailsTax.getOfPO(line);
if (details != null) {
+ /**
+ * Calculate Tax Lbr -
+ */
+ MLBRTax mlbrTaxlines = new MLBRTax(invoice.getCtx(), details.getLBR_Tax_ID(), invoice.get_TrxName()); //
+ for (MLBRTaxLine mlbrTaxLine : mlbrTaxlines.getLines()) {
+ int C_Tax_ID = line.getC_Tax_ID();
+ Integer C_Tax_Id_valid = mlbrTaxLine.getChild_Tax_ID(C_Tax_ID);
+ if (C_Tax_Id_valid <= 0)
+ continue;
+ else if (iTaxList.containsKey(C_Tax_Id_valid)) {
E onde tinha TAX_GROUP_XXXXXXXXXX, foi alterado como abaixo (vários locais)
de: MInvoiceTax newITax = iTaxList.get(MLBRTax.getTaxGroupID(MLBRTax.TAX_GROUP_ICMS_NAME));
para: MInvoiceTax newITax = iTaxList.get(C_Tax_Id_valid);
+ } End If
+ } // End for MLBRTaxLine
Alan Lescano
--
Você recebeu essa mensagem porque está inscrito no grupo "iDempiereLBR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para idempierelbr+unsubscribe@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/idempierelbr.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/idempierelbr/b82481f5-2da8-4799-aff7-303f2380c7b1%40googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.
Rinaldo
Obs.: Peço desculpas para os colegas de forum por escrever esses textos longos, mas eu utilizo-os como forma de eu mesmo lembrar e aprender mais sobre o idempierelbr.
Alan o LCO para as entradas de retenção funcionou perfeitamente, mas para saídas de serviços propus esse post para ver se vamos usa-lo (ou não) e torna-lo obrigatório para o desenvolvimento das notas de serviço para os vários municípios, digamos, que eu queira entender o norte que o projeto vai assumir para justamente não gastar recurso onde não deveria. Eu também quero entender se o LCO está gerado alguma dificuldade para os demais colegas ou não.
Vou expor aqui os caminhos que podem ser seguidos, acho esse o ponto principal, digamos que seja a definição do possíveis nortes que o projeto pode assumir.
Para quem não conhece o assunto das retenções:
Consideração importante, temos que ter em mente que o cliente tomador do serviço pode ter retenção total, parcial ou não ter retenção (não paga parte do serviço ao fornecedor) . Sempre a retenção vai destacada no documento fiscal de serviço. Na nota sem retenção ou retenção parcial a alíquota residual é paga pelo fornecedor de forma posterior e esse resíduo não vai na nota de serviço. Eventualmente o resíduo pode ser uma observação da nota. Cada nota fiscal emitida pode ter alterado esse comportamento conforme o tomador e o tipo serviço.
Situações possíveis:
1) Vamos contabilizar somente os impostos retidos. Então teremos criar um processo contábil brasileiro para apurar os 3,3% restantes depois. (Pois essa contabilização existe de forma posterior pela contábilidade)
1.a) Vamos parametrizar em ambos, no LBR marcado como retido somente e no LCO, mas não cadastraremos em Ctax esses impostos que pode ter retenções ou não?
1.b) Vamos parametrizar somente no LCO as retenções então os plugins das notas de serviços irão tratar os negativos que existirem nas tabelas lbr_nfstax, c_invoicetax .(criados pelo LCO) e buscarão esses dados para a emissão?
1.c) Vamos parametrizar somente no LCO as retenções então os plugins das notas de serviços irão fazer um import do "plugin" do LCO para buscar esses valores das tabelas do LCO para a emissão?
1.d) Parametrizamos somente no LBR e não usamos o LCO (Obriga cadastro de retenções em C_tax), criando um parâmetro informando que não 'LBR_WITH_LCO' é falso. Várias mudanças necessárias, entre elas aquela que coloquei, mas existe outras, como descontar quando retido esse valor da fatura e isso forçaria tb uma alteração na rotina Doc_Invoice.java (tratar os negativos da tabela c_invoicetax pois vai provocar uma diferença contábil)?
2) Vamos parametrizar ambos, o imposto retido e o não retido já dentro da transação?
2.a) Parametrizaríamos o IR não retido normalmente no LBR e retenções parametrizamos somente no LCO (Nesse caso existe dois caminhos: usar os valores negativos (c_invoicetax, c_nfstax) ou buscar das tabelas do LCO)? (Então gravaríamos na tabela lbr_docline_other somente o imposto não retido. Para a emissão das notas buscaríamos os dados gerados pelo LCO. Não teria alteração pois iriamos gravar somente IR não retido em lbr_doclines_others.)
2.b) Parametrizaríamos em ambos, tanto no LBR quando LCO o IR retido e no LBR também o não retido?
2.b.1 Caso se cadastre as retenções em C_Tax, além das alterações citadas no item 1.c é necessário também em DefaulTaxProvider (e NFTaxProvider). É necessário que evitar que em iTaxList (tratar put) se alimente impostos retidos pois isso causa um erro de contabilização dos não retidos.. Essa tratativa é obrigatória pois você tem que cadastrar ambos em C_Tax pois como eu disse, cfe o documento pode existir ou não retenção.(Não é aconselhável que no item da invoice o usuário tenha que escolher um C_TAX pai diferente, mas isso é uma saída).}
2.c) Parametrizaríamos somente no LBR e não usamos o LCO? (Obriga cadastro de retenções em C_tax, além das alterações citadas temos as citadas no item 1.d.)
Alan
1) Pelo que vi o caminho hoje proposto do idempierelbr seria do item 1.a ou o item 2.a e os plugins de serviço de municípios dependerão sempre do LCO para destacar as retenções corretamente na contabilidade?
2) Hoje você nunca cadastra dentro de c_tax as retenções, correto?
3) Você cadastra as retenções dentro dos impostos do LBR (definição de impostos) ou vc está fazendo isso somente dentro do LCO?
Pergunto aos demais colegas de forum para que opinem?
1) Será que devemos adotar a contabilização das notas fiscais de serviço de saída de forma que contabilize a retenção e o restante da alíquota (resíduo) na transação, ou iremos fazer isso depois em outro processo (Exemplo IR: 1,5% Retido + 3,3% Não retido)?
2) Você está usando o LCO?
3) Devemos amarrar as notas de serviço de saída do LBR a existência do LCO? (Se optarmos por não usa-lo seria para ambos entrada e saída)
4) Quais das situações expostas você acha mais adequada?
Desde já agradeço a todos pela atenção.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para idempierelbr...@googlegroups.com.
