Italo Giurizzato Junior

Boa noite Edmar, Primeiramente desculpa pela demora, mas analisamos e esta tudo ok, já foi enviado para o repositório.

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, Vou verificar. Comente a linha que contem o "break;" dentro do loop que salva o XML da guia. E faça novos testes.

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.

Boa tarde, Após o envio é retornado um XML contendo o numero do recibo. Que deve estar salvo com o seguinte nome: *-rec.xml Você obtém ele depois do envio da seguinte forma: nRecibo := ACBrGNRE1.WebServices.Retorno.numeroRecibo; De posse do numero do recibo se faz necessário realizar uma consulta. Como fazer essa consulta sugiro que você estude o programa exemplo, mais precisamente o botão referente a [Consultar Recibo Lote]. É através dessa consulta que você vai ter os XMLs referentes as guias para poder imprimir.

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

Bom dia Valdir, Para resolver esse problema basta trocar essa porcaria de A3 pelo A1.

Bom dia Osvaldo, As informações referente ao veiculo e motorista deixaram de ser geradas no XML a partir da versão 3.00 do CT-e, essas informações passaram a constar no XML do MDF-e a partir da versão 3.00 do mesmo. Essa alteração ocorreu em Julho/2016, como você pode ver já faz um bom tempo.

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.

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

Bom dia, Esses 2 XML se refere ao GNRE a ser enviado, logo não se deve ser carregado para poder imprimir a guia. Se o processamento do GNRE enviado ocorrer com sucesso o componente vai salvar um outro XML com o seguinte nome: *-guia.xml É esse XML que você vai carregar para poder imprimir a guia.

Luiz, Por favor atualize os fontes, reinstale a suíte ACBr e faça novos testes.

Boa tarde Luiz, Esta ocorrendo erro de validação ou rejeição?

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.