Italo Giurizzato Junior

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

Boa tarde Patrick, Já esta no SVN.

Bom dia, Não, eu preciso do XML de retorno que contem o numero do protocolo.

Bom dia Danilo, A cidade de Montes Claros/MG se utiliza do provedor Pronim versão 2.02 (ABRASF) que é da GovBr. Você precisa pegar o manual da ABRASF versão 2.02 e verificar se existe alguma campo para informar essa tal de Origem da Alíquota. Eu trabalho no desenvolvimento do componente ACBrNFSe e agora o ACBrNFSeX a muito anos e nunca vi esse campo no layout da ABRASF. Tome cuidado, uma coisa é emitir a nota via site e outra é emitir via webservice. O primeiro link se refere a imagens da emissão da nota via site. O segundo não consegui abrir (ocorreu erro), mas me parece que ele apresenta o DANFSE da nota.

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

Bom dia Edevair, Não tem como comparar a NF-e com a NFS-e, uma vez que no caso da NF-e temos um padrão nacional onde todas as SEFAZ-Autorizadoras seguem risca. Infelizmente a NFS-e é a nível municipal e os mesmos não aceitam que seja implementado um WebService Nacional, o motivo você já sabe. O componente da NF-e não faz milagre, apenas segue o que esta no manual e notas técnicas e a coisa funcionado, e quando ocorre algum problema, com certeza absoluta é a SEFAZ que esta passando por algum problema técnico. Por outro lado o componente da NFS-e, esse sim faz milagre, pois os mais de 100 provedores que ele suporta não seguem a risca os manuais da ABRASF e sem contar os provedores que tem o seu próprio layout. Não seguem a risca a geração do XML bem como o retorno. É uma verdadeira zorra. Diariamente recebemos relatos de problemas e contribuições de correções, visto que nós Equipe ACBr não temos pelo menos um certificado de uma empresa das mais de 1300 cidades que o componente reconhece. Sendo assim se torna impossível realizarmos testes completos. É por isso que agradecemos imensamente todos os relatos e contribuições vindas de vocês. Se a participação de vocês não sabemos se o componente esta funcionando ou não para um determinado provedor. Por fim converse com o pessoal que desenvolve aplicações para emissão de NFC-e, mais precisamente para MG.

Bom dia Guilherme, Muito obrigado, já inclui na minha de tarefas. TK-2354

Boa tarde Danio, Favor anexar o XML de retorno da consulta que contem as tags de cancelamento para que eu possa fazer os devidos ajustes no componente.

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

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

Boa tarde, Você poderia anexar o XML de retorno que tem o protocolo, pois me parece que existe um caractere antes do primeiro digito.

Boa tarde Douglas, Atribua o valor LT_TLSv1_2 para o campo SSLType e faça novos testes.

Boa tarde, A cidade Luz/MG se utiliza do provedor Betha - WebService baseado na versão 1 do layout da ABRASF. Sendo assim a única forma de envio é em Lote e no modo Assíncrono. Pelo retorno noto que esta usando o novo componente, portanto o meu conselho não só para esse provedor e sim para todos é utilizar o método Emitir com o parâmetro de modo de envio em automático. Exemplo: { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario, meTeste] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // como não foi informado o segundo parâmetro o método assume o valor // meAutomatico, isso faz com que ele se ajusta ao provedor selecionado ACBrNFSeX1.Emitir(vNumLote); Seu retorno: Método Executado: Gerar NFSe (...) Erro(s): Código : X001 Mensagem: Serviço não implementado pelo Provedor. Você esta forçando para esse provedor o modo de envio: meUnitario e o componente lhe esta informando que esse serviço (envio unitário) não foi implementado pelo provedor. Com o modo de envio: meAutomatico o componente vai enviar para o WebService do provedor Betha um Lote de Rps (que pode até ter apenas um Rps) no modo Assíncrono, que é o serviço que esta implementado no WebService para recepcionar os Rps. Tome muito cuidado, pois existem outras cidades que também se utilizam do provedor Betha, mas os WebServices dessas cidades se utilizam da versão 2 do layout da ABRASF, esta versão tem 3 serviços para recepcionar o Rps, se eles: EnviarLoteRps (modo assíncrono), EnviarLoteRpsSincrono (modo síncrono) e GerarNfse (envio unitário e modo síncrono).

Boa tarde Carlos, O provedor Ginfes segue a versão 1 do layout da ABRASF, e se tratando da versão 1 o fluxo correto é: 1. Enviar o Lote de Rps; 2. Consultar a Situação do Lote; 3. Se a Situação for 2, aguardar alguns segundos e consultar novamente; 4. Se a Situação for 3 ou 4, Consultar o Lote; 5. Se a Situação for 3 será retornado as rejeições, se for 4 será retornado o XML da nota. Observação: o numero do Rps deve ser um numero sequencial e controlado pela aplicação.

Marcelo, Ao atualizar, atualize tudo, geral e não somente a pasta dos fontes dos componentes. Acredito que agora esta faltando realizar um cadastro para que o contribuinte possa emitir nota via WebService.

Bom dia Ramboli, O arquivo ACBrNFSeXServicos.ini não deve constar na pasta do executável. Esse erro que consta imagem, acredito que se faz necessário um cadastro para que o contribuinte possa emitir nota via WebService.

Bom dia Marcelo, Pelas imagens notei que os seus fontes estão desatualizados. Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2353

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

Bom dia Danny, Muito obrigado pela contribuição, já inclui na minha lista de tarefas. TK-2353

Bom dia Danilo, Se essa informação aparece no Portal da Prefeitura e não consta no XML do Rps enviado para o WebService do provedor, o que o componente tem haver com isso? Se essa mensagem esta errada, você precisa entrar em contato com a prefeitura.

Bom dia Luiz, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2352

Bom dia Anadilson, Abra a Unit ACBrXmlBase e faça a seguinte alteração: if xData = '' then Result := 0 else begin xData := StringReplace(xData, 'Z', '', [rfReplaceAll]); <=== incluir esta linha xData := StringReplace(xData, '-', '/', [rfReplaceAll]); Salve a unit alterada, reinstale o ACBr e faça novos testes.

Bom dia, Note que no programa exemplo temos dois botões, um chamado [Consultar] onde devemos informar somente o numero do protocolo (é esse que você esta usando) e o outro chamado [Consultar Recibo] que permite informar o tipo de evento entre outras coisas. O numero do protocolo que você esta passando esta correto?

Bom dia Bruno, Esse erro ocorre com o programa exemplo? Se não ocorre, o problema é configuração errada do componente na sua aplicação no que se refere a Schemas. O problema também pode estar na configuração referente ao certificado digital. Quais os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType ?

Boa tarde André, O componente gera o conteúdo dessa tag conforme consta no manual da ABRASF. A questão não é essa. Outra coisa, apesar da tag ser opcional no manual o provedor pode exigir ela. O problema se encontra no webservice do provedor que esta pegando do XML a informação sem a formatação e comparando com a que tem só que formatada. Exemplo: No XML consta: 12345 e no banco de dados do provedor esta 1.234-5 e o webservice simplesmente compara um com o outro, neste caso com certeza vai acusar que não existe ou esta errada. Como lhe disse, me recordo de algo semelhante, bastou o provedor corrigir a informação no banco de dados que o problema foi resolvido.