Italo Giurizzato Junior

Bom dia Marcos, Erro 999 pode ser 2 coisas: 1. Erro no próprio webservice da SEFAZ. 2. Informação errada no XML, mas o webservice não possui uma regra de validação especifica logo o documento é rejeitado com o erro 999.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde, Enviado para o SVN uma possível solução para o problema. Essa solução foi aplicada no Fortes, se faz necessário agora fazer algo semelhante para o Fast.

Boa tarde Elisângela, Fiz algumas alterações na sua implementação e mandei para o SVN. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes com o programa exemplo.

Elisângela, Muito obrigado pela colaboração, já inclui na minha lista de tarefa para analise e estando tudo Ok, vamos sim enviar para o SVN. TK-4157

Boa tarde Gledston, Porque você esta gerando e assinado o XML com rotina própria? Sendo que o componente faz isso para você.

Boa tarde Gomes, Muito obrigado pelo retorno, já enviei para o SVN. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Boa tarde, Atualize todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Boa tarde Paulo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4154

Boa tarde Elisângela, O novo componente se utiliza do arquivo ACBrNFSeXServicos. Veja o tópico abaixo.

Boa tarde Patrick, Esta estranho essa alteração no link, pois o link que costa como o novo se refere a versão 1.00 e não 1.01

Boa tarde Luís, Esse erro esta ocorrendo no ambiente de homologação ou de produção? Ele ocorre na sua maquina ou na maquina do seu cliente? Se é na maquina do seu cliente, verifica se na pasta do EXE ou em outra configurada pela sua aplicação não tem o arquivo ACBrCTeServicos.ini antigo. Caso afirmativo delete o arquivo. Cheklist: Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

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

Boa tarde Edmilson, Qual é o formato das datas dos XMLs retornados, seja o XML da nota ou não. Pois podemos tratar isso nas units do provedor, evitando assim um efeito colateral com os demais provedores. Me desculpa mas da forma que você fez passa a impressão da tentativa e erro, ou seja, o componente tenta ler a data em um formato se ocorrer erro tenta com outro formato.

Boa tarde a todos, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde, Já esta no SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Boa tarde Tiago, Já esta no SVN.

Boa tarde Tiago, Já esta no SVN.

Boa tarde Gomes, Por favor anexe aqui a alteração que você fez na cidade em questão, não precisa anexar o arquivo INI inteiro somente as linhas referente a cidade. Desde já muito obrigado pela colaboração.

Bom dia Gibran, Conversando com a Equipe ACBr a remoção dos caracteres #13 e #10 do XML é uma etapa chamada canonicalização, isso é realizado antes do XML ser assinado. No lugar desses caracteres usei a sequencia: ConfigGeral.QuebradeLinha := '
'; Fiz um teste usando o programa exemplo do componente. O XML do Rps que é assinado bem como o de envio do lote que tem 2 assinaturas (do Rps e a do Lote) foram submetidos no site da Receita Federal que valida a assinatura. Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br) Os dos XML (do Rps e de envio do lote) estão com as assinaturas validas. O problema é o webservice do provedor que não aceita essa sequencia escape e acusa que a assinatura esta invalida. Solução para o problema: 1. Usar o caractere ";" (ponto e virgula) mesmo que a impressão do DANFSE via site a discriminação saia bagunçada. 2. Entrar em contato com o provedor, expor o problema, mostrar para eles que o uso dos caracteres #13 e #10 da forma que eles estão usando ao gerar o XML da NFS-e esta fora das normas, quem sabe eles façam as adequações necessárias no webservice. Resumindo: Se ficar o bicho come, se correr o bicho pega.

Bom dia Gledston, Não, porque a assinatura depende do provedor, alguns requer que o Rps seja assinado, outros não. Logo a assinatura é realizada se necessário automaticamente pelo componente.

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

Bom dia Elisângela, Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração

Bom dia Pablo, Muito obrigado pelos arquivos, já inclui na minha lista de tarefas para analise. TK-4152

Bom dia, Muito obrigado, já inclui na minha lista de tarefas. TK-4151