Italo Giurizzato Junior

Bom dia Antonio, Favor atualizar todos os fontes de todas as pastas. Note que foi feita uma alteração no arquivo INI do provedor.

Felipe, A ideia do Substituir é emitir uma nova NFS-e que substituirá uma outra NFS-e que será cancelada. Sendo assim, devemos alimentar o componente com os dados do novo RPS que vai gerar a nova NFS-e, ao executar o SubstituirNFSe devemos informar o numero, serie, etc da nota a ser cancelada. O componente monta um XML contendo o pedido de cancelamento da nota informada, mais o Rps. Alguns provedores exigem que o pedido de cancelamento esteja assinado, o Rps esteja assinado e o pedido de substituição esteja assinado. Para que isso ocorra se faz necessário que os campos RPS, Cancelar e Substituir da seção Assinar tenham o valor 1. No caso do provedor SystemPro os campos RPS e Substituir estão com o valor zero, logo somente o pedido de cancelamento será assinado.

Bom dia, É estranho não esta retornando o motivo do cancelamento. Vou verificar o que deve esta ocorrendo e também a questão da série.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Leandro, Nos XML que você anexou na primeira postagem, um se refere ao retorno da consulta da NFS-e por Rps, note que dentro do grupo <ConsultarNfseRpsResposta> temos o grupo <CompNfse> que é o grupo que contem os demais grupos e tags que Compõe a NFS-e, dai o nome do grupo <CompNfse>. Já o segundo arquivo, nada mais é que o grupo <CompNfse> que é salvo como sendo o XML da NFS-e. A única diferença é que esse provedor coloca o prefixo "tc:" nos grupos e tags de forma errada pois se você notar é declarado os prefixos "tc:" como sendo tipos complexos e "ts:" como sendo tipos simples que por sinal não é utilizado. A tag Nfse que na verdade é um grupo esta certo receber o prefixo "tc:", mas a tag Numero esta errado, pois trata-se de um tipo simples, logo deveria receber o prefixo "ts:". Como você pode ver até o webservice do provedor esta gerando o XML de retorno com prefixos (que não precisam) e além disso de forma errada. O componente ACBrNFSe possui uma deficiência na leitura das tags, não consegue ler corretamente as tags com prefixos, logo ele remove os prefixos. Você disse que o sistema de um contador não consegue ler o XML da NFS-e sem os prefixos, correto? Como vai ficar o dia que a prefeitura fizer uma nova licitação e mudar o provedor e esse novo provedor o XML da NFS-e retornado pelo webservice não possui prefixo? Ele vai continuar reclamando que o XML precisa ter os prefixos ou ele vai entrar em contato com o desenvolvedor desse sistema para que seja feita uma alteração nele?

Bom dia Felipe, Faça o seguinte teste: Abra o arquivo SystemPro.ini e altere o valor para 1 do campo Substituir da seção Assinar, salve o arquivo alterado, execute o programa exemplo e faça um novo teste de substituição.

Bom dia Chaves, O problema também ocorre com o ambiente de produção? Se não ocorre então pode ser o ambiente de homologação que esta com problemas.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, Caso deseje colaboração com o projeto implementando o referido evento ficaremos gratos.

Bom dia Douglas, Já esta no repositório.

Bom dia Guilherme, Já esta quase tudo pronto para migrar o componente ACBrCNAB para o trunk2. Espero que assim mais desenvolvedores possam realizar testes, fazer melhorias e correções necessárias.

Olá pessoal, O componente ACBrNF3e vai sofrer uma alteração para estar em conformidade com a NT. Resumo das alterações: Inclusão do hash do modelo 6 na nota fiscal de ajustes; Inclusão de campos e regras de validação da retenção de tributos federais; Criação do PIS e COFINS efetivos; Inclusão do qrCode do PIX na fatura; Orientação sobre a regra de rejeição por duplicidade da chave natural; Exceção para preenchimento do NIS. O ambiente de homologação só vai estar liberado em 02/05/2021 e o de produção em 07/06/2021. Procure manter os fontes ACBr sempre atualizados. Para quem não conhece o NF3e se refere a Nota Fiscal Energia Elétrica Eletrônica. Encontra-se também em nossa biblioteca a versão 1.01 da Nota Explicativa 2020/001.

Olá pessoal, O componente ACBrMDFe vai sofrer uma alteração para estar em conformidade com a NT. Resumo das alterações: Alterações no MDF-e rodoviário adequando o grupo do vale pedágio às definições da ANTT; Observação sobre a formação da chave de unicidade de um MDF-e ; Tornar a UF da placa opcional em virtude da nova placa padrão Mercosul ; Inclusão do PIX nas formas de pagamento do frete; Ajuste do tamanho da tag TU do modal ferroviário (schema). O ambiente de homologação só vai estar liberado em 05/04/2021 e o de produção em 02/05/2021. Procure manter os fontes ACBr sempre atualizados.

Bom dia a todos, Acabo de enviar para o repositório a alteração do tipo dos campos UF para string. O programa exemplo também foi atualizado. Com certeza vai ocorrer quebra de compilação em suas aplicações nas rotinas que alimentam alguns eventos que necessitam informar a UF.

Bom dia Heronim, O componente esta configurado para pegar os schemas corretos, pois se pegar schemas de outra pasta de schemas esse erro pode ocorrer.

Bom dia, Através do programa exemplo do componente ACBrReinf podemos configurar para a versão 1.05.00 só não sei informar se todas as alterações dessa versão foram aplicadas no componente.

Bom dia Waldemir, Verifique se na tela de configuração do eSocial do ACBrMonitor não possui alguma opção para configurar o ambiente.

Bom dia Eder, Você utiliza o ACBrMonitor? Se sim, veja este link: NFE.ImprimirDanfe (sourceforge.io) Detalhe importante o ACBrMonitor deve estar configurado para imprimir em EscPos.

Boa tarde Douglas, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia Mauricio, Favor anexar o XML de envio que você usou para fazer testes no SoapUI. Pois fiz vários testes e nenhum deu certo.

Bom dia, Favor atualizar os fontes e faça novos testes.