BigWings

Testei pelo programa exemplo e gerou normal: Lendo os fontes nem tem como gerar o obsCont sem o atributo xCampo, mesmo que esteja vazio.

A operação tpPIXCriar é para gerar a cobrança PIX em um boleto já registrado anteriormente. Para registrar um boleto já retornando o QrCode use a operação tpInclui, lembrando de ativar a propriedade IndicadorPIX.

Atualize a pasta de schemas.

No modo síncrono de envio só se envia um MDFe por vez, então não existe mais o grupo "enviMDFe" na estrutura.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

GLP é ICMS monofásico, se não foi comprado direto do importador ou da indústria, será CST = 61, e preenchido as tags qBCMonRet, adRemICMSRet e vICMSMonoRet. Leia a NT 2023/001 para mais detalhes, porque é bastante coisa pra entender.

Pode informar o CPF no campo destinado ao CNPJ.

Para uma mesma NFe recepcionada no ambiente nacional podem ser gerados vários NSU, dependendo da quantidade de interessados (destinatário, transportador, terceiros). Cada interessado (CNPJ ou CPF) tem a sua própria sequência de NSU. Além disso, existe o NSU do resumo que só o destinatário recebe e outro NSU para a NFe completa que é disponibilizado a todos os interessados. Então depende de como está sendo feita essa consulta. Se informou o mesmo CNPJ ou CPF do interessado na consulta e recebeu documentos diferentes com o mesmo NSU, tem algo errado sim. Teria que abrir um chamado no Ambiente Nacional para verificação.

Precisa atualizar o Fortes Report. https://github.com/fortesinformatica/fortesreport-ce Lembrando que tem que ser feito por um cliente GIT, o github removeu suporte a clientes SVN como o Tortoise.

Para o Sicoob defina a propriedade Banco.TipoCobranca = cobBancoob:

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Provavelmente é CNPJ novo que ainda não está no banco de dados do receitaws. Talvez no plano pago eles retornem a informação.

Veja que está tendo rejeição por falha no schema, e não na validação local. Então o problema é do lado da SEFAZ, abra um chamado lá.

Acho que é isso aqui:

Está "envelopando" o XML no envio para o webservice?

Para suporte abra um tópico na área do ACBr Pro. Aqui é área da comunidade, como você já teve respostas vou manter o tópico aqui. Veja também o tópico abaixo, da base de conhecimento, se te ajuda:

A SEFAZ entende que o emitente já tem o XML, afinal foi ele que gerou, e é obrigado por lei a armazenar o arquivo em local seguro por no mínimo 5 anos. Então o serviço é para que os demais interessados na operação recebam a NFe. Acima a tabela de quem recebe cada tipo de documento retornado pelo DistribuicaoDFe.

Precisa manifestar como ciência, confirmação ou operação não realizada, para que o serviço gere o novo NSU com a nota completa (NFeProc). Sugiro a leitura da Nota Técnica 2014.002, vai te tirar as dúvidas quanto ao fluxo do serviço, limitações e regras de utilização.

O XML da NFe completa, sim. O XML do evento de manifestação de própria autoria, mas enviado por outra aplicação, não. Os eventos que você recebe são os eventos de autoria de terceiros, por exemplo os destinatários das tuas notas, ou do fisco.

Não é possível saber a situação da manifestação que foi feita por você, você pode apenas capturar as manifestações feitas por terceiros referentes as notas que você emitiu.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tem erro de digitação na chave da primeira NFe informada.

A URL do erro é do retorno do envio / consulta de recibo, quando usando o modo assíncrono, que já não existe mais, desde o início do mês. Altere a sua rotina para usar o envio e tratamento do retorno no modo síncrono.

As DLLs da ACBrLibNFe que você fez o download aqui, copiou pra lá também, na arquitetura correta da sua aplicação (32/64 bits) e convenção de chamada (cdecl), junto com as dependências (OpenSSL, LibXML2, Schemas)?