Italo Giurizzato Junior

Boa noite Marcos, Vou analisar o problema.

Boa noite Weverton, Passei o problema para o demais colegas, para que juntos possamos tentar encontrar o problema.

Boa noite, Esse provedor não segue o layout da ABRASF, eu em particular não vou implementar, se desejar fique a vontade. Mas fique sabendo que existe um projeto que visa criar um layout e web service padrão para todas as cidades brasileiras e o projeto piloto esta previsto para iniciar agora em dezembro/2017.

Boa noite Fernando, Após carregar o XML através do método LoadFromFile, porque você esta executando o método Gerar? Você deveria usar o método Enviar (por exemplo).

Boa noite Breno, Favor atualizar todos os fontes de todas as pastas e refaça os testes.

Cleyton, Muito obrigado pela colaboração, já enviei para o repositório.

Boa noite Anselmo, Tanto a UF BA quanto PB se utilizam da SVRS - SEFAZ Virtual do RS que atualizou a cadeia de certificados, favor atualizar a cadeia que vai voltar a funcionar. http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false#484

Boa noite Renato, Você utiliza o componente ACBrCTe ou o ACBrMonitor Plus?

Boa noite Cleyton, Por favor anexe a unit alterada para que possamos analisar.

Boa noite Karine, Todos os fontes de todas as pastas estão atualizados?

Boa noite Eptos, Acredito que não foi claro, preciso ver o XML do RPS gerado pelo componente que foi enviado via Web Services, processado com sucesso e o XML da NFS-e retornado pelo provedor.

Boa noite Cezar, Tem provedores que devemos realizar um cadastro para poder emitir NFS-e via site e um segundo cadastro para emitir via WebServices. Um outro detalhe, no XML o CNPJ e a Inscrição Municipal não contem a formatação, ou seja, só é informado somente os dígitos. Como esta essas informações no cadastro do provedor?

Boa noite Eptus, Existe uma propriedade que contem essa informação, mas ela não esta disponível ao desenvolvedor, é uma propriedade interna do componente.

Boa noite Eptus, Depende do método que esta sendo utilizado. Veja esse fragmento de código: sStat := ''; sMotivo := ''; case rgWSEnvio.ItemIndex of 0: begin // ====> Quando usamos o método Enviar devemos realizar a consulta do lote <======== if ACBrNFSe.WebServices.ConsLote.RetornoNFSe.ListaNFSe.MsgRetorno.Count > 0 then begin sStat := ACBrNFSe.WebServices.ConsLote.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.ConsLote.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Mensagem; end; end; 1: begin // ====> Quando usamos o método EnviarSincrono já costuma retornar as mensagens de erro quando ocorrer <===== if ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Count > 0 then begin sStat := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Mensagem; end; end; 2: begin // Quando usamos o método Gerar, esta também retorna as mensagens de erro quando ocorrem. <===== if ACBrNFSe.WebServices.GerarNfse.RetornoNFSe.ListaNfse.MsgRetorno.Count > 0 then begin sStat := ACBrNFSe.WebServices.GerarNfse.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.GerarNfse.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Mensagem; end; end; end;

Boa noite Gabriel, No meu entendimento se um CT-e é cancelado devemos imprimir o evento através do método ImprimirEvento. O evento impresso deve ser "grampeado" ao DACTE do respectivo CT-e. Como o tomador recebeu por e-mail o XML e o DACTE em PDF do CT-e quando o mesmo foi enviado e autorizado pela SEFAZ, ao efetuar o seu cancelamento devemos enviar por e-mail o XML e o "DAEvento" em PDF do evento de cancelamento através do método EnviarEmailEvento.

Boa tarde Eptus, Respondendo as suas perguntas: 1. Configuracoes.WebService.Visualizar := False; 2. Ler os dados de retorno: sNumero := ACBrNFSe1.NotasFiscais.Items[ x ].NFSe.Numero; sCodVerif := ACBrNFSe1.NotasFiscais.Items[ x ].NFSe.CodigoVerificacao;

Boa tarde Marcos, Todos os métodos do provedor SH3 estão funcionando, ou seja, enviar, consultar, cancelar, etc. ?

Boa tarde Eptus, Os provedores que seguem a versão 1 do layout da ABRASF só possuem o método Enviar. Já os provedores que seguem a versão 2 do layout da ABRASF possuem os 3 métodos: Enviar, EnviarSincrono e Gerar. Mas é bom testar, pois tem alguns que apesar de seguir a versão 2 não implementaram os 3 métodos. No caso do EnviarSincrono, alguns provedores já no retorno temos o XML da NFS-e, mas isso não é regra, pois alguns temos que realizar a consulta ao lote para obter o XML da NFS-e. Infelizmente o jeito é testar.

Boa tarde Eptus, E como que fica o XML do RPS e da NFS-e retornado pelo provedor? Você poderia anexar para que possamos analisar?

Boa tarde Matheus, Você se refere ao Bethav2, correto? Pois o Betha esta funcionando sem problema, já o Bethav2 esta apresentando problemas com a validação da assinatura.

Boa tarde Cezar, Favor verificar junto ao provedor se existe um Usuário/Senha especifico para o ambiente de homologação.

Boa tarde, Ao imprimir um evento seja ele qual for, devemos carregar o XML do MDFe e depois o XMl do Evento conforme já exemplificado acima. Se mesmo assim não esta sendo impresso os dados do emissor, com certeza o arquivo EVENTOS_MDFE.fr3 esta com problemas. Como não tenho conhecimento em Fast Report, não tenho condições de fazer as devidas correções.

Bom dia Gabriel, Primeiro, em qual manual, nota técnica ou ajuste sinief consta que um XML assinado e com o protocolo de autorização deve ser alterado quando o mesmo é cancelado? Isso não existe. No Manual do CT-e versão 3.00 na página 142 no item 12.2 deixa muito claro que o XML do CT-e ao ser compartilhado, ou seja, enviado ao tomador do serviço teve conter os dados do CT-e mais a assinatura digital (grupo <CTe>) e no grupo <protCte> deve constar os dados do Protocolo de Autorização de Uso. No item 12.4 temos o layout do XML referente a um evento (por exemplo: cancelamento) que devemos compartilhar com o tomador do serviço. Isso deixa claro que quando emitimos um CT-e devemos disponibilizar o XML referente ao item 12.2 ao tomador do serviço. Caso esse CT-e venha ser cancelado devemos disponibilizar o XML referente ao item 12.4 ao tomador do serviço. É possível imprimir ou gerar o PDF do DACTE com uma tarja informando que o mesmo esta cancelado, basta, antes de executar os métodos Imprimir ou ImprimirPDF atribuir o valor True a propriedade CTeCancelado. Por fim, a propriedade de configuração do componente ACBrNFe que permite a troca do protocolo de autorização pelo de cancelamento não tem nenhum embasamento legal. No Ajuste SINIEF de 07/05 temos: § 1º Considera-se Nota Fiscal Eletrônica - NF-e o documento emitido e armazenado eletronicamente, de existência apenas digital, com o intuito de documentar operações e prestações, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pela administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. Trocando em miúdos, o XML para ter validade jurídica deve conter a assinatura digital do emitente e o protocolo de autorização.

Bom dia Gabriel, Pelo que entendi, você esta usando o programa gratuito da SEFAZ para emissão do MDF-e, correto? Sendo assim não tempos como lhe ajudar, pois aqui tratamos sobre o componente ACBrMDFe desenvolvido por nós para ser utilizado no Delphi.

Boa tarde Marcos, Favor atualizar os fontes e testar novamente. Note que fiz uma correção no arquivo INI do provedor.