Italo Giurizzato Junior

Bom dia, A impressão do Evento pode ocorrer a qualquer momento depois do seu envio. Para que seja impresso o cabeção é preciso carregar o XML do MDF-e em seguida carregar o XML do Evento e por fim Imprimir o evento. Verifica se na sua rotina quando você carrega o XML do MDF-e e imprime se antes de carregar o XML do evento, não esta limpando do componente o MDF-e.

Bom dia a todos, Rodrigo, no seu XML você não ADD nenhum documento (CTe / NFe) mas no grupo totais você informou que a quantidade de CTe é 1, isso esta errado, atribua o valor zero para que a tag não seja gerada. Outra coisa vamos as regras da SEFAZ. 5. WebService – Recepção – Regras de Validação para tpEmit = 3 G016a: Se tipo emitente informado for igual a Transportador que emitirá CT-e Globalizado (tpEmit=3): O grupo de documentos CT-e não pode ser preenchido. G016b: Rejeitar se tipo emitente informado for igual a Transportador que emitirá CT-e Globalizado (tpEmit=3) e operação interestadual ou com exterior. O seu XML satisfaz a regra G016a, mas não a G016b, porque? O seu MDF-e se refere a um transporte interestadual, ou seja, de MG para SP. No meu entendimento um MDF-e cujo tpEmit = 3 não devemos incluir o grupo de documentos CT-e e nem de NF-e por se tratar de uma transportadora e por fim o transporte tem que ser intermunicipal, ou seja, dentro do Estado.

Boa noite Rauber, O conteúdo da tag InformacoesComplementares só é retornado pelo provedor no XML da NFS-e?

Boa noite Matheus, Por favor anexa o XML do Lote original que faz com que uma das assinaturas se torna inválida e o modificado que faz com que as duas se tornem validas.

Boa noite Rodrigo, Favor anexar o XML do MDF-e que foi rejeitado ao informar que o tpEmit = 3.

Boa noite Luis, Se não atualizar as cadeias de certificado não vai funcionar, essa atualização ocorre uma vez por ano.

Boa noite Karine, Favor atualizar os fontes e refaça os testes.

Boa tarde Matheus, Quando o RPS é assinado é levado em consideração o conteúdo do grupo <InfDeclaraoPrestacaoServico> pois é nesta Tag que temos o atributo Id. Ao assinar o Lote é levado em consideração o conteúdo do grupo <LoteRps> pelo mesmo motivo é nessa Tag que temos o atributo Id. É de se esperar que o conteúdo da tag <X509Certificate> seja igual para ambas as assinaturas, por outro lado as tags <DigestValue> e <SignatureValue> não (se não me falha a memória).

Bom dia Ricardo, Já passei a sua colaboração para os demais moderadores para avaliarem. Desde já muito obrigado.

Bom dia a todos, Existe um projeto em andamento que vai definir um layout e web service único para todas as cidades brasileiras, inclusive o projeto piloto com meia duzia de cidades esta previsto para começar agora em dezembro/2017. Se eles tiverem o bom senso de utilizar o layout da NF-e como foi o caso da NFC-e, praticamente mudando o numero do modelo de 55 para 65, todos os problemas estarão resolvidos, pois o layout da NF-e já prevê itens de serviço. Quando foi lançado a versão 3.10 da NF-e foi acrescentado nada mais nada a mesmos do que uma duzia de campos novos no XML a pedido da ABRASF. Para mim, seria uma burrice e perda de tempo criar um novo layout para a NFS-e, pois o da NF-e atende 99%. O que esta faltando é os dois campos referente a construção, são eles CodigoObra e Art. Que em um primeiro momento poderiam ser informados da seguinte forma: <obsCont xCampo="CodigoObra"> <xTexto>123</xTexto> </obsCont> <obsCont xCampo="Art"> <xTexto>456</xTexto> </obsCont> Vamos aguardar os próximos capítulos.

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.