Italo Giurizzato Junior

Boa tarde a todos, Favor atualizar os fontes e realizar novos testes.

Boa tarde Luciano, A alteração que você fez no arquivo INI do provedor esta errada. Pois a URL de homologação é igual para todas as cidades. Favor utilizar os arquivos INI que estão no repositório. Atualize todos os fontes de todas as pastas, pois acrescentei a cidade desejada.

Boa tarde Dorneles, Não necessariamente, apenas temos a certeza que a URL esta correta.

Boa tarde Lucas, Pode sim o problema de formatação, pois no componente é informado somente os dígitos e no provedor o CNPJ pode estar formatado. Volto a frisar no que diz respeito ao login, se via site ao realizar o login é solicitado o CNPJ do emitente, acredito que via Web Services ao informar o login este deve estar pegando o primeiro CNPJ da filial em vez da matriz dai o erro. É por isso que sugeri login diferente para cada uma.

Fábio, Cuidado ao usar o ADD pois este cria um item na lista de notas. Em vez de ChaveAcesso use Senha. with ACBr.NotasFiscais.Add.NFSe do begin (...) Prestador.Senha := 'c1250o70-6462-431b-b458-2oo563730087'; (...) end; ***************************** Em tempo, favor atualizar os fontes e deixar a propriedade ChaveAcesso e vez de Senha como mencionado acima.

Boa tarde, O erro ocorre ao assinar o XML do RPS ou o XML do Lote? Uma vez que o provedor Betha exige que ambos sejam assinados.

Boa tarde Alexandre, Foi necessário realizar mais alguma alteração em cima dos fontes que disponibilizei hoje de manhã? Pois não encontrei nada de novo nos fontes que você anexou agora. Esses últimos testes foram feitos segundo os fontes disponibilizados no repositório?

Fábio, Pelo fato desse provedor não seguir o padrão ABRASF fica difícil emitir uma opinião.

Boa tarde Fábio, Fiz a correção e envie para o repositório. Muito obrigado pelos testes.

Boa tarde Tailan, Muito obrigado pela contribuição. Tive que fazer alguns ajustes pois alguns dos seus fontes estavam desatualizados. Já enviei para o repositório, favor atualizar os fontes e realizar novos testes. Caso todas as funcionalidades agora estejam funcionando 100%, favor nos dar um retorno.

Boa tarde Cristiane, Posso então considerar que o provedor Ábaco esta funcionando 100%?

Cristiane, Maravilha, peço desculpas em não atentar sobre o fato do SoapAction ser diferente dependendo da quantidade de RPS no Lote. Por outro lado agradeço pelos seus testes. Acredito que os demais que estavam com o mesmo problema agora vai ficar mais rápido.

Bom dia, Se o seu cliente segue a legislação e envia para o tomador de serviço o XML do CT-e assinado e protocolado, basta solicitar aos tomadores os XMLs. Lembre-se que tanto o emitente quanto ao tomador do serviço tem que possuir e guardar os XMLs pelo período legal. Agora se o envio do XML aos tomadores não foi realizado a unica solução que vem a minha mente é entrar em contato com a SEFAZ e pedir de joelho todos os XMLs referente ao período perdido. Desculpe pelas palavras a seguir: Perder os XMLs dos CT-e que conforme a legislação diz que são documentos com validade jurídica é uma tremenda irresponsabilidade. Com menos de 500 reais podemos comprar um HD externo e realizar cópias diárias desse arquivos.

Bom dia Izabel, Seria de grande ajuda se você anexar o XML cuja nota foi rejeitada por Falha no Schema XML e o que foi Autorizado. Essa rejeição pode ser um erro na SEFAZ ou na geração do XML, mas a SEFAZ acaba retornando um erro genérico. Com os XML temos mais condições de dizer com mais certeza onde esta a fonte do problema.

Bom dia a todos, Que eu saiba as DLLs do Capicom e OpenSSL continuam as mesmas. Acredito ter encontrado o problema, no Trunk o componente alterava o SoapAction quando a quantidade de RPS era menor que 4, já no Trunk2 estava usando sempre o mesmo SoapAction. Fiz uma alteração visando realizar a troca dependendo da quantidade de RPS. Por favor atualizem os fontes e façam novos testes.

Bom dia Zunker, Muito obrigado. Alexandre, faça uma copia da sua implementação e atualize todos os fontes de todas as pastas. Por fim inicie os testes caso aja necessidade de mais alguns ajustes faça nesses fontes atualizados. Fico no aguardo dos resultados dos testes, estando tudo OK, ou seja, todas as funcionalidades (Enviar, Consultar, Cancelar) funcionando vamos incluir esse provedor na lista dos provedores que estão funcionando 100%. Desde já agradeço pela colaboração em tornar o componente cada dia mais robusto e completo.

Bom dia Alexandre, O problema é que segundo o layout da ABRASF não existe a TAG Cidade e sim CodigoMunicipio. Alguns provedores resolveram alterar o nome da TAG de CodigoMunicipio para Cidade, dai o motivo do código que você postou. O problema é que esse provedor não fez a troca, ou seja manteve a TAG CodigoMunicipio, mas acrescentou a TAG Cidade, dai o problema. Vou ver o que eu consigo fazer aqui com a sua implementação. Esta faltando os Schemas (arquivos XSD) usados para validar o Lote antes do envio. Favor entrar em contato com o provedor e assim que você obter favor anexa-los aqui.

Bom dia Dorneles, As configurações que costumamos mencionar aqui no fórum, sobre revogação de certificados, TLS e SSL.

Bom dia Cristiane, Vamos a algumas propriedades de configuração: AguardarConsultaRet => permite definir um tempo em milisegundos entre o Envio e a primeira Consulta (para os provedores que seguem a versão 1 da ABRASF essa consulta é Consultar Situação do Lote, já os que seguem a versão 2 é Consultar Lote). IntervaloTentativas => permite definir um tempo em milisegundos entre uma Consulta e outra (a consulta aqui se refere a Consultar Situação do Lote). Tentativas => permite definir a quantidade de consultas que serão realizadas (a consulta aqui se refere a Consultar Situação do Lote). Temos que tomar cuidado com os tempos informados nas duas primeiras propriedades, pois tive conhecimento de um provedor que esta bloqueando o emitente por uso abusivo, ou seja, assim que envia o lote já realiza a consulta para saber a situação do lote. Sendo assim é interessante deixarmos um intervalo de tempo de pelo menos uns 2 segundos antes de consultar a situação do lote pela primeira vez e depois uns 3 segundos entre uma tentativa e outra. Quanto ao numero de tentativas não vejo nenhum problema ser 10 ou mais. Já a propriedade AjustaAguardaConsultaRet para o componente ACBrNFSe não tem função nenhuma, pois nenhum retorno dos provedores retornam um tempo médio de processamento. Essa propriedade se torna interessante para quem utiliza o ACBrNFe, ACBrCTe, ... pois a SEFAZ retorna o tempo médio. Resumindo, se tratando de NFS-e temos que realizar testes alterando os valores das 3 propriedades acima (em negrito) a fim de encontrar a melhor performasse. Devemos lembrar que uma configuração pode ser ótima para um provedor e não ser para outro e também o que é bom para o ambiente de homologação não necessariamente será para o de produção. Espero ter ajudado.

Bom dia Volmir, Isso é estranho pois pelo controle que tenho o provedor Betha já estava funcionando 100%. Você esta com todos os fontes atualizados e esta usando o arquivo INI do provedor que esta no repositório?

Boa tarde, Com certeza o problema é na SEFAZ.

Bom dia Walter, É preciso saber inicialmente se existe algum item na lista de mensagens antes ler, caso contrario pode ocorrer sim o erro de AV.

Alexandre, Notei que no XML de retorno não existe o grupo <InfDeclaracaoPrestacaoServico> provocando essa diferença de níveis entre o grupo <InfNfse> e os demais. Fiz uma alteração no pnfsNFSeR.pas a fim de detectar a ausencia desse grupo e definir o nível correto para cada situação. Favor atualizar os fontes.

Bom dia Rodolfo, Com os fontes que estão no repositório você diz que o correu o erro, mas me diga você usou o arquivo Pronimv2.INI que esta no repositório? O arquivo Pronimv2.INI disponível diz que a versão do XML é 2.00 sendo assim as alterações feitas nos fontes que você anexou não faz nenhum sentido. Só faria sentido se no arquivo INI do provedor a versão do XML estiver como 2.02

Bom dia Rogério, No caso da NFS-e lembre-se que o componente gera o XML do RPS e não da NFS-e, este é gerado e retornado pelo provedor. Se você se refere ao XML do RPS, no que se refere aos dados do Emitente só consta o CNPJ e a IM mesmo, por outro lado temos todos os dados do Tomador. Você configurou o componente para consultar o lote após o envio? Você configurou o componente com os dados do Emitente (vide programa exemplo) ?