Jump to content

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png click.png click.png

Matheus Leandro Ferreira

Membros
  • Posts

    18
  • Joined

  • Last visited

Everything posted by Matheus Leandro Ferreira

  1. Boa tarde, Precisei desenvolver o bloco H011 - IDENTIFICAÇÃO DO ESTABELECIMENTO DETENTOR DO INVENTÁRIO para o DRCST conforme a portaria SEF Nº 378/2018 link http://legislacao.sef.sc.gov.br/html/portarias/2018/port_18_378.htm A classe modificada chama-se ACBrEFDBloco_H_Class e ACBrEFDBloco_H. Gostaria, se possível, de uma análise para disponibilizar a função nos fontes oficiais do ACBR. Grato pela compreensão. Matheus Leandro Ferreira ACBrEFDBloco_H.pas ACBrEFDBloco_H_Class.pas
  2. Pessoal, boa tarde. Segue a resposta da SEFAZ via e-mail. O lance é aguardar. Feliz ano novo a todos!
  3. Boa tarde, A rejeição "assinatura difere do calculado" irá acontecer no validador de homologação quando o certificado digital instalado na sua maquina não é igual ao utilizado na montagem do XML (isso não significa que um erro, pois o validador faz apenas um PARSE nas tags do XML). Observei também que você tem duas rejeições no XML, uma relacionada a data e hora (provavelmente por conta do horário de verão) e outra relacionada ao código de barras de um determinado produto. Realize as correções e mande validar o XML.
  4. Boa tarde, Cada CST pode ter 1 ou N códigos de beneficio fiscal. No estado do RS por exemplo, todos os CSTs aceitam NULL e também o texto SEM CEBENEF. Anexei a tabela do dia 05/08/2019 contendo os códigos para você analisar. TABELA cBenef_X_CST 05_08_2019.xlsx
  5. Exatamente. Aqui acontece o mesmo. Estou desconfiado que pode ser alguma atualização do Windows que acabou com tudo... mas e agora né? Só Deus sabe...
  6. Boa tarde, o mesmo erro também acontece com alguns clientes meus... =/
  7. Sem dúvida. A implementação só deve estar em ambiente de produção no dia especificado.
  8. 1- Valerá para todos os UFs. 2- Não deverá ser descontado no valor total da nota, e sim deverá ser posto no campo próprio vICMSDeson do grupo total. 3- Não deverá ser diminuído do item, e sim deverá ser posto no campo próprio vICMSDeson do grupo imposto dos itens. OBS: Estou testando faz um bom tempo em ambiente de homologação e não tive absolutamente nenhum problema. Exemplo da nota gerada: <det nItem="1"> <prod> <cProd>123</cProd> <cEAN>SEM GTIN</cEAN> <xProd>UVA NACIONAL KG</xProd> <NCM>08061000</NCM> <CEST>1700601</CEST> <cBenef>PR810000</cBenef> <CFOP>5102</CFOP> <uCom>KG</uCom> <qCom>1.000</qCom> <vUnCom>9.690000</vUnCom> <vProd>9.69</vProd> <cEANTrib>SEM GTIN</cEANTrib> <uTrib>KG</uTrib> <qTrib>1.000</qTrib> <vUnTrib>9.690000</vUnTrib> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0.41</vTotTrib> <ICMS> <ICMS40> <orig>0</orig> <CST>40</CST> <vICMSDeson>2.13</vICMSDeson> <motDesICMS>9</motDesICMS> </ICMS40> </ICMS> <PIS> <PISNT> <CST>06</CST> </PISNT> </PIS> <COFINS> <COFINSNT> <CST>06</CST> </COFINSNT> </COFINS> </imposto> </det> <total> <ICMSTot> <vBC>0.00</vBC> <vICMS>0.00</vICMS> <vICMSDeson>2.13</vICMSDeson> <vFCP>0.00</vFCP> <vBCST>0.00</vBCST> <vST>0.00</vST> <vFCPST>0.00</vFCPST> <vFCPSTRet>0.00</vFCPSTRet> <vProd>9.69</vProd> <vFrete>0.00</vFrete> <vSeg>0.00</vSeg> <vDesc>0.00</vDesc> <vII>0.00</vII> <vIPI>0.00</vIPI> <vIPIDevol>0.00</vIPIDevol> <vPIS>0.00</vPIS> <vCOFINS>0.00</vCOFINS> <vOutro>0.00</vOutro> <vNF>9.69</vNF> <vTotTrib>0.41</vTotTrib> </ICMSTot> </total>
  9. Bom dia, Recebi a informação diretamente da minha assessoria fiscal. Vou ver se consigo a base legal e postarei assim que possível. A principio estou usando o mesmo calculo para todas as UFs. Att, Você pode baixar a tabela cBenf x CST de cada estado aqui http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=u3vMflqEe6w=
  10. Eu não sabia que essa regra estava validando no ambiente de homologação do RS. Até onde eu vi, apenas no ambiente do PR já estava aplicada.. então meus testes estão sendo feitos para o estado do PR. Abraços,
  11. Pessoal, Tenho observado todos os comentários e farei aqui algumas considerações: - Para alguns estados (como por exemplo o PR) todos os produtos ISENTOS cujo CST é 040 deve-se obrigatoriamente informar o código do beneficio fiscal (Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal). - Quando existir um código do beneficio fiscal preenchido a regra diz que é obrigatório o preenchimento das tags vICMSDeson e motDesICMS. (Rejeição 934: Não informado valor do ICMS desonerado ou o Motivo de desoneração). O calculo do ICMS desonerado deve ser feito de acordo com o CST do ITEM, conforme segue: CST 20 e 70 será: VL_ICMS_DESONERADO = VALOR_ITEM x Redução de BC x ALIQUOTA CST30, CST40, CST41, CST50, CST70, CST90 será: VALOR_ITEM / (1-0.18) * 0.18 OBS: Onde o 0.18 corresponde a 18% destinado a Alíquota Interna. Ainda, deve-se levar em consideração o grupo de totalizadores da nota. Este por sua vez deverá ser a SOMA do ICMS desonerado dos itens. Em alguns casos, o valor total do ICMS desonerado deverá ser subtraído do valor total da nota (mas isso ainda não está em ambiente de homologação e não consegui testar). É isso.... Espero ter ajudado.
  12. Ambos estamos cientes do funcionamento, mas acho que não estamos nos entendendo hehe.. Como faço para a minha tag MOT_INV subir com o valor 02? Estou fazendo dessa forma: MOT_INV := miMudancaTributacao; Segundo a minha cliente o arquivo esta sendo gravado com o 01: |H005|30042019|315358,54|01| Vou fazer novos testes e posto o resultado.
  13. Acredito que você está equivocado. Observe que a tag MOT_INV só aceita o tipo TACBrMotInv. Se eu utilizar a função StrToMotInv passando a constante 02, vai me retornar o valor miMudancaTributacao que automaticamente corresponde ao valor 01. Não posso usar a função MotInvToStr pois a mesma retorna uma String e não poderei atribuir ao MOT_INV. Para finalizar, mais uma prova de que existe o "bug" é a própria função MotInvToStr que ao passar o miMudancaTributacao retorna a constante 02. function MotInvToStr(AValue: TACBrMotInv): string; begin if AValue = miFinalPeriodo then Result := '01' else if AValue = miMudancaTributacao then Result := '02' else if AValue = miBaixaCadastral then Result := '03' else if AValue = miRegimePagamento then Result := '04' else if AValue = miDeterminacaoFiscos then Result := '05' else raise Exception.Create('Valor informado inválido para ser convertido em TACBrMotInv'); end;
  14. Prezados, boa tarde. Acredito ter encontrado um suposto "bug" no que diz respeito ao ACBrEFDBlocos - Motivo do Inventário quando existir uma Mudança de Tributação. Sempre que existir uma alteração de tributação de ST para Tributado, por exemplo, o Bloco H005 tag MOT_INV deverá subir com o código 02. Na classe ACBrEFDBlocos temos a seguinte estrutura: /// Motivo do Inventário TACBrMotInv = (miFinalPeriodo, miMudancaTributacao, miBaixaCadastral, miRegimePagamento, miDeterminacaoFiscos ); TACBrMotivoInventario = TACBrMotInv; Porém se formos observar, o miMudancaTributacao tem índice 01. Dessa forma não poderei utilizá-la para alimentar a tag MOT_INV do Bloco H005. Sugestão: Iniciar a estrutura da seguinte maneira /// Motivo do Inventário TACBrMotInv = (miNenhum, miFinalPeriodo, miMudancaTributacao, miBaixaCadastral, miRegimePagamento, miDeterminacaoFiscos ); TACBrMotivoInventario = TACBrMotInv; Desculpe se este não é o local ideal para postar isso.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.