BigWings

As URL para homologação NFCe em SP constam no arquivo. [NFCe_SP_H] NfeInutilizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeinutilizacao2.asmx NfeConsultaProtocolo_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeconsulta2.asmx NfeStatusServico_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfestatusservico2.asmx NfeConsultaCadastro_3.10=https://homologacao.nfe.fazenda.sp.gov.br/ws/cadconsultacadastro2.asmx RecepcaoEvento_1.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/recepcaoevento.asmx NfeAutorizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeautorizacao.asmx NFeRetAutorizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nferetautorizacao.asmx URL-QRCode=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaQRCode.aspx URL-ConsultaNFCe=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaPublica.aspx EventoEPEC_1.00=https://homologacao.nfce.epec.fazenda.sp.gov.br/EPECws/RecepcaoEPEC.asmx NFeAutorizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeAutorizacao4.asmx NFeRetAutorizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeRetAutorizacao4.asmx NFeInutilizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeInutilizacao4.asmx NFeConsultaProtocolo_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeConsultaProtocolo4.asmx RecepcaoEvento_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeRecepcaoEvento4.asmx NfeStatusServico_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeStatusServico4.asmx URL-QRCode_4.00=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaQRCode.aspx URL-ConsultaNFCe_4.00=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica Apenas as de produção que não. Está com os fontes atualizados?

Ele já é incluído no executável, como recurso. Tente configurar o componente para modo NFe e não NFCe ao executar o método de consulta de cadastro.

O governo muda as regras do horário de verão o tempo todo, e os usuários não instalam as atualizações. A MS é quem menos tem culpa.

Nesse caso fica por tentativa e erro mesmo. Acredito que a forma mais fácil e rápida seria por tentativa de inutilização de numeração, onde pode se usar faixas de até 10.000 números, até que se retorne o protocolo. A desvantagem é que você vai perder toda a numeração de faixa inutilizada.

Isso é regra de negócio da aplicação? Pois nada te impede de usar outras séries.

E ela está atualizada e compilada? Veja que na primeira mensagem você atualizou a pasta C:\frce e não a C:\frce\trunk. No arquivo RLReport.pas existe a propriedade UnlimitedHeight na classe TRLCustomReport? Existe algum outro arquivo RLReport.pas ou RLReport.dcu no disco que pode estar no library path do Delphi?

Se o emissor da NFe não sabe, e a SEFAZ diz que não fornece a informação, não é possível saber a última nota. Reiniciar a contagem pode ser feita usando uma série diferente.

Aparentemente você removeu ambos.

Veja pelo log que você tem mais de uma instalação do Fortes no library path do Delphi: D:\FRce\Binary\LibD14 D:\FRce\trunk\Binary\LibD14 Mantenha apenas uma, atualizada.

Você está falando do Manifesto de Documentos Fiscais Eletrônico (MDFe): https://mdfe-portal.sefaz.rs.gov.br/ Ele não tem nada a haver com a Manifestação do Destinatário da NFe. O ACBr tem o componente ACBrMDFe para emissão do MDFe. Veja o exemplo em ACBr\Exemplos\ACBrDFe\ACBrMDFe.

Você recebeu o protocolo de autorização ao emitir em contingência, correto? Nesse caso, não é preciso fazer mais nada. Não é preciso enviar novamente. Os próprios webservices se encarregam de sincronizar as notas entre eles.

Em produção a SEFAZ deve habilitar a contingência SVC para ser possível emitir com esse tpEmis. E ela só faz isso em caso de problemas com o modo normal. O modo normal está fora do ar?

É uma propriedade que foi retirada. Abra o formulário no Delphi e quando mostrar o erro da propriedade, mande ignorar, e salve para atualizar o .dfm.

Os Schemas não interferem na versão ou layout do XML gerado. Eles são usados para validação do mesmo, após a geração do arquivo.

Verifique se hora e fuso horário do terminal estão corretos. Caso o Windows esteja desatualizado ele pode ter alterado o fuso horário automaticamente achando que o horário de verão já encerrou. Se necessário você pode usar a configuração DFe->Geral->TimeZone e definir como tzPCN (ACBr) ou manual.

O manual é claro no que o QRCode deve conter, e as dimensões mínimas do mesmo (25x25mm). Fazer dessa forma estaria em desacordo com o manual e o emissor estaria sujeito a sanções, acredito eu. Se a impressora térmica não consegue imprimir o QRCode legível, ela não pode ser usada para a impressão da NFCe.

De qual DANFE NFCe está falando? Fast, Fortes, EscPos? Não é permitido fazer o que quer, conforme manual: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=QK/Drpb/k7Y= A NFCe nem será autorizada caso a URL do QRCode seja diferente do publicado pelas SEFAZ.

Se quer sugerir correções, favor anexar o arquivo alterado para análise.

Apenas para consumidor final não contribuinte. Quando o consumidor final é contribuinte do ICMS é o próprio que deve fazer a apuração do diferencial de alíquota na entrada da nota. Em operações internas como na NFCe não existe diferencial de alíquota, já que ela já deve ser calculada cheia.

Também usa o arquivo .ini? Com o componente ou o ACBrMonitorPLUS? Anexe o arquivo .ini.

Tente desta forma: ACBrNFe1.EnviarEvento(nLote); ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat;

A mensagem indica a falta de um dos campos ou grupos no XML. Verificando os schemas xsd do provedor IssDF você pode ver que o grupo de lista de Itens é obrigatório: <xs:element name="Itens" type="tipos:tpListaItens" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation>Lista de Itens.</xs:documentation> </xs:annotation> </xs:element> Os demais campos informados na mensagem não são obrigatórios.

A correção foi aplicada na rev. 14658 do repositório, verifique se está realmente atualizado. Se o problema continuar, use o debug e verifique em qual parte do fonte está acusando o erro. Ou anexe aqui o arquivo .RET para análise.

Também não encontrei nada de errado no XML. O validador da SEFAZ-RS também não acusou a rejeição de chave inválida. Talvez seja um problema com a SEFAZ-GO, entre em contato com eles e questione a rejeição.

Atualize os fontes e faça novo teste.