Italo Giurizzato Junior

Bom dia Jakson, Antes ocorria a troca do protocolo de autorização pelo de cancelamento no XML da NF-e. Agora pelo fato do cancelamento ser um evento e seguindo orientação dos manuais devemos manter o XML da NF-e sempre com o protocolo de autorização. Devemos portanto enviar ao cliente o XML da NF-e autorizado ao cliente assim que o mesmo recebe o protocolo de autorização, conforme legislação vigente. Caso a NF-e venha ser cancelada devemos enviar o XML que consta o pedido e o protocolo de registro do evento de cancelamento ( *-procEventoNFe.xml ). Sendo assim os XML das NF-e e de Processamento de Eventos das NF-e ficam separados. A sua aplicação tem que ter um efetivo controle das notas, no banco de dados devemos ter um campo que indique que a mesma esta ou não cancelada. Desta forma com base nessa informação antes de imprimir o DANFE devemos atribuir o valor True ou False a propriedade NFeCancelada. Se a propriedade NFeCancelada receber o valor True, ao executar o comando para imprimir ou imprimirPDF o DANFE terá uma TARJA acusando que a mesma esta cancelada.

Bom dia, Você utiliza o componente ACBrNFSe? Se sim, a cidade Porto Alegre/RS se utiliza do provedor BHISS que por sinal já esta implementado. Todos os fontes de todas as pastas estão atualizados?

Bom dia Heronim, É bem provável que você esta carregando o XML do RPS para imprimir, sendo que o correto é carregar o XML da NFS-e.

Boa tarde Alberto, Fiz uma alteração, por favor atualize os fontes e teste novamente.

Dércio, Essa TAG só é incluída no momento do envio. O XML de um RPS não contem essa TAG. Fiz uma alteração para liberar essa funcionalidade para o provedor Digifred. Por favor atualize os fontes e tente novamente.

Anderson, Mai uma vez muito obrigado, já fiz a alteração e disponibilizei.

Boa tarde Anselmo, O CT-e de Anulação não tem o objetivo de anular um CT-e, algo semelhante a cancelar. Você anula valores e emite um outro CT-e com valores corretos, e o termo correto é Anulação de valores. Veja se este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-anulacao-e-substituicao/

Boa tarde Mauricio, Realize as alterações necessárias e teste. Quando estiver tudo OK, post como anexo aqui mesmo neste tópico somente os fontes que você alterou. Desta forma poderemos realizar um merge e disponibilizar a sua contribuição para a melhoria do componente.

Boa tarde Anderson, Alteração realizada e disponibilizada. Muito obrigado pela colaboração.

Boa tarde a todos, Essa mensagem de erro não especificado ocorre quando o atributo de identificação é escrito todo em minusculo, ou seja, "id" e solicitamos que a assinatura seja realizada. No caso do provedor SimplISS pelo fonte que tenho, esse problema não é para ocorrer, apesar do identificador ser "id", pois esta configurado para que não ocorra assinatura em RPS e Lote.

Boa tarde Dércio, Se eles estão pedindo para incluir a TAG GerarNfseEnvio isso significa que eles querem que você envie apenas um RPS de cada vez e não um lote de RPS. Portanto você deve utilizar o botão [Gerar e Enviar um RPS] do programa exemplo. Esse botão se utiliza do método Gerar e não Enviar. O método Enviar, gera e envia um lote contendo de 1 até 50 RPS. O método Gerar, gera e envia somente um RPS.

Boa tarde a todos, Não se deve executar o Assinar antes de enviar. Tem que deixar o componente realizar essa operação sozinho, pois dependendo do provedor devemos ou não assinar o RPS e devemos ou não assinar o Lote. Os comandos de envio checam se há necessidade de realizar a assinatura ou não e em qual momento.

Boa tarde Sergio, with ACBrCTe1.Conhecimentos.Items[0].CTe do begin for x := 0 to infCTeNorm.infDoc.infNF.count -1 do svalor := infCTeNorm.infDoc.infNF.items[x].propriedade end; propriedade é a propriedade que contem o valor a ser lido (vite estrutura do XML no Manual e Notas Técnicas) Algo semelhante pode ser feito para infNFe e infOutros.

Boa tarde Joemil, Por favor atualize os fontes e tente novamente.

Boa tarde a todos, Régys a alteração que fiz foi para PI e não PA. Mas acabo de fazer essa nova alteração e estou disponibilizando.

Boa tarde, Com essa alteração esta funcionando sem nenhum problema a geração da URL do QR-Code?

Thiago, São as URLs e Namespace padrão mesmo. Para confirmar, abra a unit ACBrProvedorGinfesV3 e veja as function GetConfigCidade e GetConfigURL. No caso das URLs, note que não tem no final o ?wsdl, não se faz necessário, mas se você quer colocar para testar fique a vontade.

Bom dia João, É possível você gerar o XML do RPS, depois importa-lo através do site do provedor que atende a cidade em questão, para que este gere o XML da NFS-e. Caso contrario a resposta é, não.

Thiago, Entre em contato com o Ginfes, e solicite a eles as URLs de homologação e de produção que devem ser utilizadas no caso do Web Services, bem como o NameSpace. Se for o padrão utilizado pela maiorias das cidades atendias pelo Ginfes, com certeza é problema neles e eles tem costume de não assumir os erros. Agora se for diferente, vamos fazer as devidas alterações no componente.

Você esta usando os schemas da pasta ...\Exemplos\ACBrNFSe\Delphi\Schemas\FISSLEX ?

Bom dia Dércio, Se você abrir a unit ACBrProvedorDigifred, note que temos uma function chamada GetConfigCidade e nesta é configurado a Versão do Soap como sendo 1.1 Já na unit ACBrNFSeWebServices por volta da linha 712 temos: if FConfiguracoes.WebServices.VersaoSoap = '1.2' then ContentHeader := Format(ContentTypeTemplate, ['application/soap+xml; charset=utf-8']) else ContentHeader := Format(ContentTypeTemplate, ['text/xml; charset=utf-8']); como você pode ver o ContentType esta recebendo o "text/xml" e não text/html como aparece na mensagem de erro. A não ser que o "s" colocado como prefixo em algumas TAGs do envelope deva ser trocado por "soap". Exemplo, em vez de: <s:Body> deveria ser <soap:Boady> para que o Web Service interpreta corretamente que o soap é 1.1

Bom dia Joemil, Delete os fontes que você alterou e baixe novamente, pois os fontes disponíveis já contempla essa alteração.

Bom dia Ricardo, Para estar ocorrendo esse erro de URL não disponível, ou você não configurou corretamente o ACBrNFeMonitor com a UF desejada, ou ao compilar o ACBrNFeMonitor não foi utilizado a Unit que foi alterada. Você tentou por exemplo consultar o status de serviço, setando o modelo 65 e versão 3.10 ?

Bom dia Germano, As cidades são adicionadas no componente a medida da necessidade. É preciso saber qual é o provedor que atende a cidade Caxias do Sul/RS, se o mesmo já esta implementado no componente, basta saber quais são as URLs de homologação e de produção. Agora se não esta implementado é preciso saber se o mesmo segue o padrão ABRASF, caso afirmativo, basta criar um novo provedor aos moldes dos que já existem e fazer as devidas alterações no componente para que o mesmo reconheça e gere, lê e assina de forma correta o XML.

Bom dia Thiago, Com exceção de Fortaleza/CE, todas as demais cidades atendidas pelo Ginfes possui a mesma URL de homologação e de produção. Você verificou se a cidade Cataguases/MG ainda é atendida pelo provedor Ginfes?