Italo Giurizzato Junior

Bom dia a todos, E os Schemas dessa nova versão?

Boa noite, Temos um problema, no manual da NF-e a palavra "anteriormente" continua, já no CT-e foi removida. Se for feita essa alteração, alguém poderá reclamar da ausência da palavra no DANFE, uma vez que a função que retorna o texto referente ao CST do ICMS é usado por ambos os documentos.

Boa tarde Allan, Analisando o código do componente notei que se o MDF-e esta autorizado, ou seja, status = 100 e se o valor da propriedade MDFeEncerrado for True será impresso a tarja: "MDF-e ENCERRADO". Por outro lado se o valor da propriedade MDFeCancelada for True será impresso a tarja: "MDF-e CANCELADO" Logo essas tarjas só são impressas no DAMDFE se uma dessas duas propriedades de configuração do componente estiverem com o valor True. No banco de dados devemos ter 1 campo que diz qual é a situação do MDF-e. Esse campo pode ser do tipo Char tamanho 1 com os seguintes valores: A - Autorizado E - Encerrado C - Cancelado Antes de imprimir o DAMDFE ou gerar o seu PDF devemos ver qual é o valor desse campo. Se for A devemos atribuir o valor False as propriedades MDFeCancelada e MDFeEncerrado. Se for E devemos atribuir o valor True somente a propriedade MDFeEncerrado. Se for C devemos atribuir o valor True somente a propriedade MDFeCancelada. Recomendo que após a impressão ou gerar o PDF, atribua o valor False para as propriedades MDFeCancelada e MDFeEncerrado.

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.

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.

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 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.

Bom dia a todos, Acabo de enviar para o repositório as alterações no componente, no DAMDFE (Fast e Fortes Report), Schemas e Programa exemplo. Alterações estas que visando a Nota Técnica 2018/002 que mencionei no inicio desse tópico. Favor atualizar todos os fontes de todas as pastas, reinstalem a Suite ACBr com o ACBrInstall_Trunk2. Qualquer problema favor reportar para que possamos efetuar as devidas correções. Observação: no grupo do emitente o campo CNPJ agora se chama CNPJCPF, como já informado anteriormente.

Bom dia Rafael, Favor anexar o XML de envio e de retorno para que eu possa verificar.

Bom dia Roberto, Em qual momento ocorre esse erro, pois o XML que você anexou esta assinado e com o protocolo de autorização. Isso me faz crer que o XML foi gerado, assinado, validado, enviado para SEFAZ, esta por sua vez processou os dados e conclui-o que os dados são validos, uma prova disso é que retornou o protocolo de autorização.