Italo Giurizzato Junior

Boa tarde Melissa, Por favor leia essa noticia:

Olá Pessoal, Ocorreu uma alteração no salvamento dos arquivos de envio e de retorno dos eventos e da inutilização. O motivo dessa alteração foi que esses arquivos estavam sendo salvos em dois lugares distintos. No caso dos eventos eles estavam sendo salvos na pasta configurada em PathEvento e em PathSalvar. Já os de inutilização estavam sendo salvos na pasta configurada em PathInu e em PathSalvar. Com a alteração os arquivos de envio e de retorno passam a ser salvos somente na pasta configurada em PathSalvar. Por outro lado, o resultado final do processamento dos eventos bem como da inutilização, ou seja, os arquivos *-procEventoNFe.xml (no caso da NF-e) e o *-procInutNFe.xml (no caso da NF-e) vão continuar sendo salvos nas pastas configuradas em PathEvento e PathInu respectivamente. Desta forma fica fácil para o desenvolvedor pegar por exemplo todos os XMLs referente aos cancelamentos (pasta ...\Evento\Cancelamento) compactar e enviar para a contabilidade. Antes era preciso excluir os arquivos de envio e de retorno para que estes não fossem incluídos no arquivo compactado. Quero lembrar a todos que essa alteração foi realizada nos componentes: ACBrBPe (Bilhete de Passagem Eletrônico), ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica), ACBrCTe (Conhecimento de Transporte Eletrônico), ACBrMDFe (Manifesto de Documentos Fiscais Eletrônicos) e ACBrNFe (Nota Fiscal Eletrônica).

Bom dia Leandro, Muito obrigado pela colaboração, já foi enviada para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia Rodrigo, Muito obrigado pela colaboração, já enviei para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia mlspinelli, Muito obrigado pela colaboração, já esta no repositório. Favor atualizar os fontes e faça novos testes.

Boa tarde Marcos, Muito obrigado pela colaboração, já enviei para o repositório.

Olá pessoal, Foi removido dos componentes ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNFe e ACBrNF3e das units que geram o XML a propriedade AjustarTagNro. Essa propriedade foi acrescentada porque ao usar o OpenSSL, os campos string com menos de 3 caracteres geravam erros de validação. A motivação para a remoção dessa propriedade foi: Os componentes listados acima ao gerar o XML se o conteúdo do campo “nro” tiver apenas 1 ou 2 dígitos eram ajustados para 3 dígitos, consequentemente causando problemas na cidade de Barretos/SP, pois nessa cidade existem imóveis diferentes com numeração 10 e 010 (zero a esquerda) na mesma rua. Por incrível que pareça é zero mesmo e não a letra "O". Caso alguém venha ter problemas de validação com o campo nro, favor tratar da seguinte forma: ao alimentar o campo nro: nro := ExecutarAjusteTagNro(True, cNumero); Onde: cNumero é uma variável da sua aplicação que contem o numero do imóvel situado no logradouro. Devemos incluir em uses a unit pcnAuxiliar. A função ExecutarAjusteTagNro vai realizar o ajuste necessário para que o campo nro fique com no mínimo 3 dígitos.

Bom dia Rogério, A mensagem é muito estranha, se você esta enviando o RPS, jamais o webservice deveria retornar essa mensagem de erro e sim, a mensagem que o RPS já foi enviado, logo você tem que enviar o RPS com um numero superior ao que esta sendo enviado. Favor entrar em contato com o provedor e pedir explicações sobre essa mensagem de erro totalmente absurda.

Bom dia Thiago, O certificado digital não esta vencido?

Bom dia, Estou usando o programa exemplo do componente. O DANFSE é o do Fortes Report. Usei o seu XML (anexado na quinta feira - 646RPI-nfse.xml) Segue em anexo do DANFSE em PDF. NFS-e 646.pdf

Bom dia, É bem provável que sim, muitos provedores requerem que seja liberado a emissão da NFS-e via webservice.

Favor atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr e faça novos testes.

Bom dia William, Muito obrigado pela contribuição, já esta no repositório.

Bom dia Leonardo, Notei que você esta enviando segundo a versão 1. Faça um novo teste enviando segundo a versão 2. Anexa o XML do GNRE desse teste que você fez com a versão 1.

Se esta emitindo NF-e com essa configuração não deve ser DLL. Pois o componente ACBrNFSe se utiliza das mesmas rotinas e DLLs usadas pelo componente ACBrNFe. Então tente emitir a NFS-e configurando o componente com o Capicom.

Bom dia, Realizei um teste carregando o XML que você anexou e os valores do tributos federais foram impressos no DANFSE (versão Fortes Report), usei o programa exemplo do componente para realizar o teste. Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr?

Bom dia, Primeiramente muito obrigado pela contribuição, ainda hoje estarei enviando para o repositório o arquivo Cidades.ini com a respectiva cidade incluída. Quanto ao erro, deve ser configuração. Atribua o valor libWinCrypt ao campo SSL Lib e faça novos testes.

Bom dia, Favor entrar em contato com a prefeitura ou com o provedor e solicitar as URLs de homologação e de produção, pois o que tudo indica as URLs mudaram ou a cidade contratou outro provedor.

Bom dia, Qual é a cidade?

Bom dia Wallace, Então use o programa exemplo do componente ACBrNFSe para ver se vai ocorrer o mesmo erro.

Bom dia Kleberson, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr?

Boa tarde Flávio, Os novos campos e grupos só vão ser aceitos pela SEFAZ a partir de 09/03/2020 em ambiente de homologação. Se tentar antes vai ocorrer erros.

Boa tarde Adilson, O manual não ajuda, o webservice que deveria informar qual é o motivo, não informa. Chegou a pesquisar aqui no fórum se alguém anexou um XML que foi recepcionado com sucesso?

Adilson, Que maravilha, assim fica complicado descobrir onde esta o problema.

Bom dia Wallace, Favor atualizar os fontes e faça novos testes. Note que fiz alterações no arquivo INI do provedor.