Matheus Leandro Ferreira
-
Total de ítens
23 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Matheus Leandro Ferreira
-
-
Pessoal, boa tarde.
Estou tentando fazer a recepção do CTe na versão 4.0 e nada dá certo. A única coisa que consegui realmente foi consultar o status (https://cte-homologacao.svrs.rs.gov.br/ws/CTeStatusServicoV4/CTeStatusServicoV4.asmx).
Quando tento fazer a operação (CTeRecepcaoEventoV4 ou CTeRecepcaoSincV4) utilizando as URL https://cte-homologacao.svrs.rs.gov.br/ws/CTeRecepcaoEventoV4/CTeRecepcaoEventoV4.asmx ou https://cte-homologacao.svrs.rs.gov.br/ws/CTeRecepcaoSincV4/CTeRecepcaoSincV4.asmx eu tenho o retorno de:
O método cteRecepcaoEvento do Serviço da Web é inválido
O método cteRecepcao do Serviço da Web é inválidoAlguém sabe o que isso pode ser? Qual o método é esperado por essa versão 4.0?
-
Em 20/04/2022 at 14:56, lucimauro disse:
Pena que pelo que vi aqui não mudou nada com relação a anterior.
Realmente não mudou absolutamente nada. É uma vergonha. Eu mandei a tabela corrigida, mandei e-mail avisando e nem se quer fui retornado. Sem contar que a API deles também está errada.
Sobre a THREAD PRINCIPAL, gostaria de deixar meus parabéns aos responsáveis! Sem dúvida passarei a utilizar. Se precisarem de algo, só chamar.
-
1
-
1
-
-
Muito bom. Obrigado!
-
Olá, boa tarde.
Recentemente fiz uma alteração que foi adicionada em produção e agradeço muito por isso:
Citar-- ACBrSPEDFIscal --
[+] Adicionado Registro H011. Por Matheus Leandro Ferreira. Veja: https://www.projetoacbr.com.br/forum/topic/63371-drcst-o-bloco-h011-identificação-do-estabelecimento-detentor-do-inventário-portaria-sef-n°-3782018/?tab=comments#comment-414066Já faz um tempo que precisei fazer uma outra modificação para a implementação do DRCST Perfil D (Extrato consolidado de lojas). Por isso estou adicionando as classes alteradas para sua revisão.
Modificações:
- ACBrEFDBloco_0_Class.pas: Apenas a inclusão do Perfil D na variável IND_PERFIL.
- ACBrEFDBlocos.pas: Fazendo uso da variável criada acima.
- ACBrEFDBloco_H_Class.pas: Modificação na procedure TBloco_H.WriteRegistroH005 para enviar outras informações quando o perfil utilizado for o D.Especificação técnica/legislação:
https://legislacao.sef.sc.gov.br/html/portarias/2018/port_18_378.htm
Grato,
Matheus Leandro FerreiraACBrEFDBloco_0_Class.pas ACBrEFDBloco_H_Class.pas ACBrEFDBlocos.pas
-
Em 29/07/2021 at 17:59, EMBarbosa disse:
Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão 22491.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.Mais uma vez obrigado.
Boa tarde! Deu certo! Muito obrigado!
-
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-
2
-
1
-
-
Pessoal, boa tarde.
Segue a resposta da SEFAZ via e-mail. O lance é aguardar. Feliz ano novo a todos!
CitarEm relação ao Erro 1003, identificamos que sua origem está na integração de alguns serviços do Sistema S@T com sistemas de responsabilidade da Secretaria da Receita Federal do Brasil. Um dos componentes do cadastro de contribuintes do ICMS de Santa Catarina acessa, para fim de validação, o sistema da SRFB que há alguns dias retorna erro devido a sua indisponibilidade. Observou-se ainda que esta intercorrência afeta outros serviços do Sistema S@T, além dos componentes do Sistema SIV que recebem, validam e processam os arquivos eletrônicos XML do Bloco X.
Durante esta tarde os técnicos responsáveis pela manutenção e suporte do Sistema S@T tentarão implementar solução de contorno a fim de remover essa validação de dados realizada com base nos sistemas de responsabilidade da Secretaria da Receita Federal do Brasil.
Assim, em relação aos bloqueios previstos na legislação aplicável aos requisitos técnicos do Programa Aplicativo Fiscal PAF-ECF solicitamos não implementa-los nos pontos de venda em razão da rejeição dos arquivos do Bloco X estar ocorrendo indevidamente conforme descrito.
-
3
-
2
-
-
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.-
1
-
-
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.-
2
-
-
Agora, welsoncj disse:
Tenho alguns clientes com o mesmo problema da assinatura, o interessante é que em algumas empresas tenho filiais que esta dando o erro e outras esta transmitindo normalmente.
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...
-
Boa tarde, o mesmo erro também acontece com alguns clientes meus... =/
-
1
-
-
3 horas atrás, Alexandre Mrus disse:
Atualizamos alguns clientes essa manhã no RS e a SEFAZ RS no momento da erro nas notas se tu envia os dados na tag cbenef.
Ou seja tem que por 1 teste no código para enviar somente no dia 02/09/2019 e em diante
Sem dúvida. A implementação só deve estar em ambiente de produção no dia especificado.
-
1
-
-
4 minutos atrás, Augusto Knirsch disse:
Bom Dia, por que o CST70 está nos dois cálculos?
Desculpa. Errei na digitação. O CST70 é calculado da mesma forma que o CST20.
-
9 minutos atrás, alinepolan disse:
Pessoal para o cálculo do valor desonerado vai ser uma regra geral por CST do Item ? a resolução do RJ postada nos comentários acima vai valer para todas as UFs?
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.E como ficaria então o cálculo do ICMS Desonerado para os CSTs 41 e 50 que agora na NT passaram a exigir para alguns estados? Esse valor desonerado deve sempre diminuir do valor total da nota? esse valor desonerado deverá ser diminuído do Item? na NT não fala nada sobre cálculo de valor desonerado de como fazer isso...
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>
-
Em 19/08/2019 at 11:21, alinepolan disse:
Olá, tudo bem? Você poderia me passar a base legal que tirou essas informações referentes ao cálculo do ICMS Desonerado? Esses cálculos valem para todas as UFs? Qual é o ICMS Desonerado com o motivo Suframa, esse cálculo se altera? Alguem tem mais informações sobre essa rejeição 934?
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,
12 minutos atrás, Alexandre Mrus disse:No momento na SEFAZ RS o erro é o seguinte todas as CST que tem o tal do cbenef tão exigindo que informe um código não consegui ainda mandar em branco, vou tentar mandar sem a tag
Você pode baixar a tabela cBenf x CST de cada estado aqui http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=u3vMflqEe6w=
-
4 minutos atrás, Alexandre Mrus disse:
Como conseguiu essa informação? faz todo sentido porque a regra está toda errada. Ele não ta exigindo cbenef está exigindo a apenas a conta do icms desonerado que inclusive passa sem informar o cbenef
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,
-
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.
-
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.
-
1
-
-
14 minutos atrás, EMBarbosa disse:
Olá Mateus,
A alteração não é necessária. Você não deve converter o tipo enumerado diretamente para inteiro ou vice-versa. Se fizer isso, vai ter problemas com outros tipos.
Use as funções declaradas nessa mesma unit como:
function StrToMotInv(const AValue: string): TACBrMotInv; function MotInvToStr(AValue: TACBrMotInv): string;
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;
-
-
Sim. Fiz a alteração e funcionou.
Att,
-
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.
O método cteRecepcaoEvento do Serviço da Web é inválido
em ACBrCTe
Postado
Boa tarde,
Sim, eu uso o componente. E já deu certo, fiz a reinstalação e resolveu! Tive um pequeno problema que cabe citar aqui:
Em ambiente de homologação retorna o seguinte: Rejeição 646: CT-e emitido em ambiente de homologação com Razão Social do remetente diferente de CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL
Na minha tag xNome estava exatamente assim: CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL
Após tanto procurar, descobri que o ambiente de homologação de SC a tag xNome não pode ter o traço no CT-e e deve ficar: CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL
Obrigado! pode encerrar o tópico!