Italo Giurizzato Junior

Bom dia Simons, Fiz uma alteração que acredito que vá corrigir esse problema. Ainda hoje vou enviar para o repositório.

Bom dia Vanderson, Muito obrigado pela informação, ainda hoje estarei enviando para o repositório.

Bom dia Mateus, Não é nessa unit que devemos fazer essa alteração. Já fiz a alteração no lugar correto e ainda hoje estarei enviando para o repositório.

Bom dia Allan, Os seus fontes estão desatualizados. Favor atualizar todos os fones de todas as pastas, reinstale a suíte ACBr com o ACBrInstall_Trunk2 e faça novos testes.

Bom dia Paulo, No Manual do CT-e versão 3.00 temos na página 169 o grupo <infNF>, na página171 o grupo <infNFe> e na página 173 o grupo <infOutros>. Nos 3 grupos na coluna Tipo temos CG que significa: indica que o campo é um Elemento de Grupo que deriva de uma Escolha (Choice). Conforme consta na página 144. Portanto devemos escolher UM dos 3 grupos. Resumindo um CT-e poderá ter até 2000 documentos, mas todos deverão ser NF (Nota Fiscal de Papel) ou NFe (Nota Fiscal Eletrônica) ou Outros (Outros tipos de documentos). Em hipótese nenhuma podemos misturar os tipos.

Boa tarde Simons, Configure o programa exemplo para usar o libCapicom e repita o teste.

Boa tarde Wilson, Muito obrigado pela informação, já fiz a alteração no arquivo INI do provedor e ainda hoje estarei enviando para o repositório.

Boa tarde Natanael, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Uma observação, os seus fontes estão desatualizados.

Boa tarde Sandro, Desculpe, acabei esquecendo. Acabei de enviar para o repositório.

Boa tarde Cicero, Favor atualizar os fontes e tente novamente realizar a instalação.

Sergio, Se a propriedade Configuracoes.Arquivos.IniServicos esta vazia na sua aplicação, isso significa que ela não utiliza o arquivo ACBrNFeServicos.ini e sim o ACBrNFeServicos.res que é carregado e compilado. Portanto faz parte do seu executável. A principio o programa exemplo funciona da mesma forma, ou seja, a propriedade de configuração também deve estar vazia. Se no programa exemplo e na sua aplicação a propriedade IniServicos esta vazia, mas no programa exemplo funciona e a sua aplicação não, chego a conclusão que algo esta errado na sua aplicação.

Boa tarde Liliane, O idCSRT é um numero sequencial: 001, 002, .... Por outro lado o CSRT - Código de Segurança do Responsável Técnico que eles chamam de forma errada de token, será fornecido pelo Fisco, conforme consta na Nota Técnica. Nesse primeiro momento você não precisa se preocupar, pois o grupo <infRespTec> é opcional, podendo ser obrigatório se a UF do emitente do CT-e assim desejar. Se isso vir a ocorrer, que acredito que venha, os campos idCSRT e hashCSRT são opcionais e depende de uma implementação futura, ou seja, primeiro o Fisco tem que estar pronto para fornecer o CSRT do Responsável Técnico, caso contrario não tem como incluir essas informações no XML. Quero chamar a atenção referente a palavra token, pois ela nos remete ao certificado digital A3 em formato de pen-drive, chamado pelas certificadoras de token. O token que a Nota Técnica se refere neste caso é o CSRT, ou seja, trata-se de um código alfanumérico que será fornecido pelo Fisco. Quando for publicado a Nota Técnica sobre o idCSRT e CSRT bem como o calculo do hashCSRT, com certeza vamos fazer uma alteração no componente visando atender essa NT.

Boa tarde Jonathan, Se o evento foi assinado e não foi enviado e quando ele é enviando o certificado foi trocado pois o outro venceu, se você não remover o grupo <Signature> do XML do evento em questão ao carregar para o componente como dito antes o XML não será assinado novamente.

Boa tarde Aristarco, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Elmo, O que esta sendo enviado, NF-e ou NFC-e? Você utiliza o componente ACBrNFe ou o ACBrMonitor? Se a SEFAZ esta retornando que o Lote esta em processamento, isso significa que o seu lote esta na fila para ser processado, logo devemos aguardar e consultar novamente.

Sergio, Pelo programa exemplo funciona tanto com certificado A1 quanto A3? Você não esta carregando na sua aplicação o arquivo ACBrNFeServicos.ini desatualizado?

Bom dia, Pelo que entendi o que você deseja é imprimir 2 DACTE de dois CT-e em uma mesma folha A4, correto? Não conheço o Fast Report, portanto não sou a pessoa mais indicada para resolver essa questão, mas pelo nome do arquivo FR3 (DACTE2Vias.fr3) me leva a crer que a ideia é imprimir duas vias do DACTE de um mesmo CT-e em uma única folha A4, que por sinal nem isso esta funcionando. Logo não temos um FR3 que faça o que você deseja.

Simons, Favor anexar os XMLs de envio e de retorno. Arquivos Soap, facilita a analise.

Jonathan, Peguei o XML que você anexou e removi o grupo <Signature> usando o bloco de notas. Depois através do programa exemplo através do botão [Carregar XML] carreguei o XML, ele foi assinado sem nenhum problema, nenhum erro ocorreu. Quando carregamos um XML através do método LoadFromFile ou LoadFromString, o componente checa se o mesmo já esta assinado, se não estiver, ele será assinado e validado.

Jonathan, Não entendi o motivo de reassinar o XML? Assinatura vencida?

Bom dia Sergio, É muito estranho, se o envio e a consulta funciona sem nenhum problema com o certificado A3 no seu cliente, deveria funcionar no envio de eventos. Faça um teste com o evento de cancelamento.

Bom dia Jonathan, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a Suite ACBr usando o ACBrInstall_Trunk2?

Roberto, E como você explica o fato do XML estar com o protocolo de autorização? Se ele esta com o protocolo de autorização, significa que a SEFAZ recebeu, processou e retornou o protocolo de autorização. O componente por sua vez atualizou o XML assinado com o protocolo de autorização. Logo podemos concluir que o problema não é o método Enviar. Você deve estar fazendo algo a mais que esta provocando esse erro.

Bom dia Simons, Fiz uma pequena correção no arquivo INI do provedor. Favor atualizar os fontes e faça um novo teste.

Bom dia Roberto, A unit pnfsNFSeW_GIAP.pas tem como finalidade gerar o XML do RPS do respectivo provedor. Antes de embarcar nessa aventura você precisa entender como tudo funciona e para que serve cada linha do arquivo INI do provedor bem como a unit que gera o XML. Se você não tem esse domínio vai ser muito complicado a implementação. Como disse antes não é só essas duas Units a serem alteradas, pois será necessário realizar alterações em várias outras, para que o envio ocorra de forma correta bem como o tratamento do retorno do envio, consultas e cancelamento. Não quero te desanimar, mas tenha consciência que vai perder varias horas de sono.