Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 01-03-2023 em todas as áreas

  1. Bom dia. Foi disponibilizado hoje, 01/03/2023, no Diário Oficial da União, a instrução normativa Nº 2.133/2023, prorrogando as datas para a nova versão do leiaute do Reinf. Disponibilização: 21/09/2023. Eventos a partir de: 01/09/2023. Prazo de envio da primeira competência: 13/10/2023 (dia 15 não é dia útil). Confira a IN na integra aqui. Mais informações sobre as alterações para o novo leiaute no componente neste tópico
    7 pontos
  2. Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/
    2 pontos
  3. Vamos fechar aqui e continuar em um local somente
    2 pontos
  4. Olá pessoal, Mais um presente de grego para nós desenvolvedores, mais uma alteração no layout da NF-e, novos campos, novos ICMS. Vamos a um resumo sobre a Nota Técnica 2023/001: Essa Nota Técnica divulga novos campos e Regras de Validação da NF-e versão 4.0. Como existe a inclusão de novos campos facultativos no Leiaute (Schema XML), algumas Regras de Validação serão ativadas posteriormente, conforme observação em cada uma delas, visando garantir um prazo de adequação para as empresas. Já as regras existentes que não permitiriam a informação dos novos campos, tem o mesmo prazo de entrada do Leiaute (Schema XML). O prazo abaixo, portanto, se refere a entrada das alterações no Leiaute (Schema XML), e das regras que visam permitir a informação dos novos campos sem rejeição. Sobre as Datas de Entrada em Vigor - Mudança de Schemas e Regras N12-20, N12-30, N12-70 e W16-10 Ambiente de Homologação : até 03/03/2023 - Ambiente de Produção: 30/03/2023 Regras de Validação Alteradas Regra de Validação N12-20 - Incluída exceção nesta regra para permitir que o emissor enquadrado no Simples Nacional possa informar os novos Códigos de Situação Tributária criados pelo Ajuste SINIEF Nº 01/2023. Regras de Validação N12-30 e N12-70 - Inclusão do CST 61, criado pelo Ajuste SINIEF Nº 01/2023, na relação de CSTs permitidos na emissão de NFC-e (Regra N12-30) e na relação de CSTs permitidos na operação com Não Contribuinte da NF-e (Regra N12-70). Regra de Validação W16-10 - Inclusão do Valor Total do ICMS monofásico sujeito a retenção (tag: vICMSMonoReten) no somatório do Valor Total da NF-e (campo: W16) Sobre as Alterações de Campos Inclusão do Campo de Índice de Mistura do Biodiesel no Diesel B (tag: pBio) Criação de campo específico no Grupo de Detalhamento de Combustíveis para a indicação do índice de Mistura do Biodiesel no Óleo Diesel B. Este campo tem a finalidade de auxiliar no cálculo do volume do Biodiesel B100 a ser misturado com Óleo Diesel A, nas operações com Biodiesel Puro, ou do volume do Biodiesel B100 misturado nas operações com Óleo Diesel B. Inclusão do Grupo indicador da origem do combustível (tag: origComb) Este grupo deve ser preenchido para as operações com Biodiesel B100, Óleo Diesel B e GLP/GLGN. Serve para identificar as UFs do produtor ou do importador de B100 ou GLGN utilizados na mistura. Além da identificação da UF de Origem, há a necessidade de se informar se o produto é nacional ou importado. Criação do Grupo N02a- Grupo Tributação do ICMS = 02 (tag: ICMS02) Este grupo trata do regime de tributação monofásica própria do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 02) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 15 (tag: ICMS15) Este grupo trata do regime de tributação monofásica própria e com responsabilidade pela retenção do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 15) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 53 (tag: ICMS53) Este grupo trata do regime de tributação monofásica com recolhimento diferido do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 53) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 61 (tag: ICMS61) Este grupo trata do regime de tributação monofásica sobre combustíveis com ICMS cobrado anteriormente nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 61) criado pelo Ajuste SINIEF Nº 1/2023. Criação dos campos de Valor total do ICMS monofásico Campos Valor total do ICMS monofásico próprio (tag: vICMSMono), Valor total do ICMS monofásico sujeito a retenção (tag: vICMSMonoReten) e Valor total do ICMS monofásico retido anteriormente (tag vICMSMonoRet) criados no grupo de Total da NF-e (tag: total). Sobre as Datas de Entrada em Vigor - Novas Regras Ambiente de Homologação: até 03/07/2023 - Ambiente de Produção: 04/09/2023 Novas Regras de Validação Conforme informado em NT, estas regras não serão publicadas ao mesmo tempo que o Leiaute (Schema XML) para permitir uma implementação gradual das empresas e dos autorizadores, possibilitando inicialmente o preenchimento dos novos campos para atender a legislação sem maiores complicações. Regra de Validação I13-20 Apesar desta regra já existir previamente, a sua descrição foi completamente alterada para que ela fique compatível com a Tabela de Combustíveis Sujeitos à Tributação Monofásica. Por isso receberá o tratamento de nova regra, e somente entrará em vigor na data prevista na sua nova descrição. Ela visa garantir o correto preenchimento da unidade tributária exigida por lei para os combustíveis cujos códigos ANP se encontrem na Tabela de Combustíveis Sujeitos à Tributação Monofásica. Regras de Validação LA17-10 e LA17-20 Estas regras visam controlar o correto preenchimento do índice de mistura do biocombustível (tag: pBio) obrigando ou rejeitando o seu preenchimento conforme o combustível informado. Para isso, o código ANP (tag: cProdANP) informado na nota é confrontado com a coluna “cProdANP” da Tabela de Combustíveis Sujeitos à Tributação Monofásica, com a respectiva coluna “pBio” indicando se o índice deve ou não ser preenchido conforme determinado na descrição das regras. Regra de Validação LA18-10 Esta regra visa obrigar o preenchimento do grupo de origem do combustível (tag: origComb) conforme indicador da coluna “origComb”, a partir da correspondência entre o Código ANP do combustível (tag; cProdANP) informado na nota e a coluna “cProdANP” da Tabela de Combustíveis Sujeitos à Tributação Monofásica. Regra de Validação LA21-10 Caso informado o grupo indicador da origem do combustível (tag: origComb), é realizado o somatório dos percentuais originários para a UF (tag: pOrig) informados em cada ocorrência deste grupo para verificar se o total deste somatório é 100. Regras de Validação N12-100 e N12-110 O objetivo destas regras é verificar o correto preenchimento dos novos Códigos de Situação Tributária do ICMS criados pelo Ajuste SINIEF Nº 01/2023. Estes novos códigos somente poderão ser preenchidos quando se tratar de operação com combustíveis sujeitos à tributação monofásica do ICMS. Para isso, é verificado se o código ANP do produto (tag: cProdANP) informado na nota existe na Tabela de Combustíveis Sujeitos à Tributação Monofásica. Caso o código ANP exista na tabela o preenchimento destes CSTs é obrigatório, e caso não exista o seu preenchimento é proibido. Regras de Validação N38-10, N40-10 e N44-10 Estas regras visam validar o valor preenchido para a alíquota adrem do imposto nas diferentes modalidades de tributação monofásica dos combustíveis (próprio, com retenção e retido anteriormente). Para isso, é verificada a correspondência entre o código ANP do produto (tag: cProdANP) informado na nota e a coluna cProdANP da Tabela de Combustíveis Sujeitos à Tributação Monofásica, e a partir daí é validado o valor informado no respectivo campo da alíquota adrem de cada situação tributária com a coluna “adRemICMS” da tabela. Regras de Validação N39-10, N41-10 e N45-10 Estas regras visam garantir a consistência, para cada tipo de tributação monofásica sobre combustíveis, do Valor do ICMS, que deve ser obtido pela multiplicação da quantidade tributável pela alíquota adrem de cada situação tributária. Regras de Validação W06c-10, W06d-10 e W06e-10 O objetivo destas regras é realizar a totalização, respectivamente, do ICMS monofásico próprio, ICMS monofásico sujeito a retenção e do ICMS monofásico retido anteriormente, conforme valores informados nos itens da nota. E como fica o ACBr? Como o layout foi alterado por conta de novos campos, se faz necessário alterar o componente para que ele possa gerar se necessário for os novos campos. Consequentemente vamos disponibilizar uma nova versão do ACBrMonitor e do ACBrLibNFe. O componente ACBrNFe, quanto o ACBrMonitor e ACBrLibNFe vão estar prontos até o dia 03/03/2023 para que vocês possam realizar os testes em ambiente de homologação. Mais sobre esta NT Essa Nota Técnica tem o objetivo de atender o disposto no Convênio ICMS nº 199, de 22 de dezembro de 2022, que dispõe sobre o regime de tributação monofásica do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022, e ao disposto no Ajuste SINIEF Nº 01/2023 em relação aos novos Códigos de Situação Tributária do ICMS. https://www.confaz.fazenda.gov.br/legislacao/convenios/2022/CV199_22 Sobre a Tabela de Combustíveis Sujeitos a Tributação Monofásica Para validação de algumas destas regras foi criada a Tabela de Combustíveis Sujeitos à Tributação Monofásica, que tem por objetivo facilitar a visualização da obrigatoriedade de preenchimento de campos e de alguns valores para cada produto sujeito a tributação monofásica sobre combustíveis. Os produtos presentes na tabela são identificados conforme o seu Código ANP. Além disso, a alíquota adrem de cada produto, será criada uma aba com o histórico de valores e a respectiva data de vigência. A criação desta tabela permite uma melhor parametrização dos ambientes autorizadores e das empresas, e evita que sejam feitas alterações constantes em Notas Técnicas para adequação das regras às novas situações que surgirem. As alterações necessárias na tabela serão feitas via Informe Técnico. A Tabela de Combustíveis Sujeitos à Tributação Monofásica se encontra publicada no Portal Nacional da NF-e, na aba “Documentos” opção “Diversos”. O prazo para entrada destas regras se encontra na descrição de cada uma delas.
    1 ponto
  5. O TratarRetornoConsultaLoteRps é para tratar a resposta do Consultar Lote que você disse estar tendo problema antes. Sim, é isso mesmo. Por favor, faça um novo teste substituindo por esta unit. Nela é feito o override da ConsultaNFSeporFaixa e como a ConsultarLote e a ConsultarNFSe por Faixa devolveram a tag item, acredito ser seguro assumir que a consulta por serviço prestado também vai. Então foi feito o override da TratarRetornoConsultaNFSeServicoPrestado também. IPM.Provider.pas
    1 ponto
  6. Boa Tarde, Sim, segue em anexo... A consulta por faixa não tratou o retorno. Debugando não caiu no método procedure TratarRetornoConsultaLoteRps(Response: TNFSeConsultaLoteRpsResponse); override; Não deveria ser procedure TratarRetornoConsultaNFSeporFaixa(Response: TNFSeConsultaNFSeResponse); override ? 000000000000014000000000000015000001-lista-nfse-fai.xml 000000000000014000000000000015000001-lista-nfse-fai-soap.xml 000000000000014000000000000015000001-con-nfse-fai.xml 000000000000014000000000000015000001-con-nfse-fai-soap.xml
    1 ponto
  7. muito provável você não tem usuário ou senha nesses servidores ou seu certificado não está habilitado neles.
    1 ponto
  8. Boa tarde Marco, Substitua a unit por esta em anexo e testa a consulta ao Lote, Consulta NFSe Por Faixa e Consulta NFSe Serviço Prestado. IPM.Provider.pas Boa tarde @Diego Foliene, Pega essa unit que anexei e acrescanta o TratarRetorno da consulta ao lote para atender a tag <item> Depois anexa aqui para o Marco repetir os testes.
    1 ponto
  9. Boa tarde @dreamsoft_PR, Já mudei o atributo ID. O que não ficou claro é referente ao conteúdo dos grupos nfseCabecMsg e nfseDadosMsg, eles devem ficar ou não dentro do CDATA?
    1 ponto
  10. Boa tarde, Questionei a IPM quanto ao layout do retorno da ConsultarLoteRpsEnvio... A resposta: "Sim, estamos em fase final de desenvolvimento destes retornos e em produção já estarão finalizados pelo padrão ABRASF." Estão em fase final de desenvolvimento?!? Tem data de virada de chave... aff... Pra quê testar né. Obrigado.
    1 ponto
  11. 1 ponto
  12. Bom dia Antonio, Por favor verifique se na unit Fiorilli.Provider na function TratarXmlRetornado esta da seguinte forma: function TACBrNFSeXWebserviceFiorilli200.TratarXmlRetornado( const aXML: string): string; begin Result := inherited TratarXmlRetornado(aXML); if UTF8Decode(Result) = '' then Result := NativeStringToUTF8(Result); Result := StringReplace(Result, '&#xd;', '\s\n', [rfReplaceAll]); Result := StringReplace(Result, ''#$A'', '\s\n', [rfReplaceAll]); Result := ParseText(AnsiString(Result), True, {$IfDef FPC}True{$Else}False{$EndIf}); Result := RemoverPrefixosDesnecessarios(Result); Result := RemoverCaracteresDesnecessarios(Result); Result := StringReplace(Result, '&', '&amp;', [rfReplaceAll]); end; Se não estiver, favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e certifique que agora esta. Por fim repita os testes.
    1 ponto
  13. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
    1 ponto
  14. Os valores estão iguais ou menores que a nota emitida para você? Outra coisa a rejeição é 545 mesmo? Por que Rejeição 545 para NFe/NFCe é Rejeição: Falha no schema XML – versão informada na versaoDados do SOAPHeader diverge da versão da mensagem. https://www.oobj.com.br/bc/article/erros-e-rejeições-na-emissão-de-nfe-e-nfce-mapeados-no-oobj-dfe-453.html https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360016444013-Rejeição-545-Falha-no-schema-XML-versão-informada-na-versaoDados-do-SOAPHeader-diverge-da-versão-da-mensagem
    1 ponto
  15. Bom dia, Estou compartilhando a título de informação, já que pelo visto não teremos nenhum método de solicitação de cancelamento. Após testes sem retornos conclusivos nos cancelamentos entrei em contato com a IPM e recebi o seguinte. sobre os cancelamentos: "...somente é possível cancelar por meio de solicitação de cancelamento (para ser analisada pela fiscalização). Pelo novo modelo utilizado de NFSE (ABRASF 2.04) por integração Webservice não existe modelo disponível para efetuar solicitação de cancelamento. Pela ABRASF só existe modelo para cancelamento, visto que a configuração do sistema não permitirá cancelamento, esta opção não estará disponível. A rotina deverá ser acessada pelo sistema IPM e solicitada para ser analisada pela fiscalização municipal. Para efetuar solicitação de cancelamento através do sistema da IPM é pelo caminho: Nota Fiscal Eletrônica » Nota Fiscal » Gerenciamento de Notas » Solicitação de Cancelamento » Solicitar Deve-se atentar no momento da inclusão desta solicitação aos documentos que são obrigatórios para serem anexados (Vide legislação municipal) Após esta solicitação, deve ser aguardada à análise e parecer da fiscalização municipal e eles vão "Deferir" ou "Indeferir" este pedido. O que pode ser feito via webservice é incluir a TAG anexa nos seus modelos de consulta de NFSE que irá retornar o status da nota (emitida, substituída ou cancelada)." Sendo assim os cliente terão que conectar ao sistema deles e solicitar manualmente os cancelamentos e teremos que implementar alguma consulta para verificar essa situação depois...
    1 ponto
  16. De fato amigo @Juliomar Marchetti, no meu caso a SSLLib que estava funcional foi a libWinCrypt, nessa configuração, gera o arquivo com assinatura digital (se os parâmetros do certificado estiverem preenchidos, claro). Agradeço pela atenção!
    1 ponto
  17. Bom dia. Integração funcionado. Falta cancelamento e consulta ao qual ainda estou em contato com a IPM para maiores informações, pois em meus testes não foi possível concluir, mas vou abrir novo tópico para o assunto, este pode ser fechado; Obrigado.
    1 ponto
  18. Vai ter que fazer um bypass... Isso pode ser característico desse projeto, se 422 for sucesso quem desenhou foi contra as normas do http. 422 é erro! O comportamento default estaria correto. Amanhã verificamos o comportamento Será criada uma TK e alocada ao escopo
    1 ponto
  19. Boa noite, Já está no SVN.
    1 ponto
  20. Está no SVN. https://sourceforge.net/p/acbr/code/28657/ https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrTCP/ACBrIBPTax/tabela
    1 ponto
  21. Boa tarde Leandro, Com certeza você deve ter unit alterada localmente ou cópia de unit do ACBr dentro das pastas da sua aplicação. Delete as units alteradas ou cópias, atualize novamente, reinstale e faça os testes usando o programa exemplo.
    1 ponto
  22. Boa tarde Leandro, Verifique se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone. Caso afirmativo, delete. Atualize todos os fontes de todas as pastas, reinstale o ACBr com a opção de apagar arquivos antigos marcada e por fim compile a aplicação com a opção Build.
    1 ponto
  23. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
    1 ponto
  24. Há esse demo, no nosso SVN http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/Node.js/NFe/lib_test_teste-acbrlibnfe.js
    1 ponto
  25. Olá pessoal, Recentemente foi implementado no componente ACBrNFSeX os provedores: PriMax contratado pela cidade: Serrana/SP Contass contratado pela cidade: Pirapora/MG Observação importante: Todas as correções, melhorias, implementações de novos provedores estão ocorrendo somente no novo componente ACBrNFSeX. Portanto não deixe para amanhã o que você tem que fazer hoje: Migrar para o novo componente.
    1 ponto
  26. Bom dia! Abaixo deixo dois links que podem ajudar no entendimento da Tributação Monofásica do ICMS, que é tratado na NT 2023/001. https://www.ibp.org.br/personalizado/uploads/2022/05/mapa-mental-icms.pdf https://www.ibp.org.br/noticias/icms-monofasico-entenda-essa-medida-estruturante-em-um-infografico/
    1 ponto
  27. https://blog.esimplesauditoria.com.br/tributacao-monofasica-o-que-e-e-como-funciona/
    1 ponto
  28. Boa tarde a todos! Vai haver um evento no LinkedIn com nomes de peso como a Jussana da AFRAC e o Jorge Campos do SPED Brasil. Fiquem ligados para poder participar.
    1 ponto
  29. Vamos supor que você perdeu o XML de um DF-e Documento Fiscal Eletrônico, seja ele uma NF-e, NFC-e, CT-e, CT-e OS, MDF-e ou BP-e. O procedimento é muito simples, basta alimentar o componente com os dados do documento, executar o método Assinar e por fim o método Consultar. Abaixo um exemplo usando o componente ACBrNFe, mas pode ser aplicado para os demais modelos de DF-e. (...) AlimentarComponente; ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.Consultar; (...) E para quem usa o Monitor: NFe.CriarNFe( arqINI ); NFe.AssinarNFe( pathNomeXML ); NFe.ConsultarNFe( pathNomeXML );
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.