BigWings

Pode gravar, depende das configurações do componente.

Sim, no programa exemplo o método que alimenta o componente já chama o GerarNFe, depois disso é feito a assinatura, validação e gravação em disco do XML agora já assinado e validado. Nesse botão após alimentar e executar o GerarNFe, é executado o método ACBrNFe.Enviar, este já se encarrega de assinar, validar, enviar, capturar o retorno e dependendo do parâmetro informado, imprimir o DANFE da NFe.

Já tentou ler os fontes? Que me lembre o método GerarNFe percorre as propriedades alimentadas no componente e gera o XML básico (não assinado), atribuindo o mesmo na propriedade ACBrNFe.NotasFiscais.XML. Outros métodos como o de assinatura podem a propriedade. O método GravarXML grava essa propriedade em arquivo, da forma que estiver.

Vai depender só de alguém implementar... Quer contribuir?

O prazo diferenciado pra SP, MG, GO e SVAN é para entrada em vigor da NT 2020.006, a diferença sendo apenas na data de início em homologação que é 01/03/2020 em vez de 01/02/2020 para as demais autorizadoras. Os prazos especiais para as regras de validação são os mesmos para todas as UF. Esse é o meu entendimento.

Acha isso com base em quê?

Apesar da NT 2020.006 entrar em vigor em produção no dia 05/04/2021, essa regra de validação em especial só vai ser aplicada em produção a partir de 01/09/2021, conforme consta na observação da RV:

O componente não faz isso... verifique como está alimentando a tag dEmi.

Ok, mas o produtor rural está vendendo pra essa empresa (seu cliente) e quer que a empresa emita a nota? Ou a empresa está vendendo para o produtor rural e este quer a nota fiscal?

Tem a mensagem de validação completa? Os código de pagamento 16 a 19 foram adicionados na NT 2020.006, os schemas pra validação já estão atualizados no ACBr, então verifique se a sua pasta de schemas está atualizada. Apesar da validação funcionar pelo ACBr, é provável que a SEFAZ rejeite já que a NT só deve entrar em vigor em produção a partir do dia 05/04/2021. Como o Juliomar mostrou, nem o validador da SEFAZ-RS foi atualizado.

Sim, muda só o CPF como emitente e a série específica 920-969. Mas o produtor rural vai ter a sua própria IE vinculada ao seu CPF. Mas quem vai emitir a nota, a empresa que está comprando ou o produtor rural?

Mesmo com as tuas configurações, não ocorreu problema no .ini, nos meus testes. Vi algumas coisas estranhas no arquivo, você fez alguma alteração no programa exemplo? E está com os fontes atualizados?

O arquivo que ele anexou parece ser uma versão simplificada do ACBrCargaBal.pas, não vejo qualquer motivo pra substituir. Veja o programa exemplo que acompanha os fontes. https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDiversos/ACBrCargaBal Vou encerrar o tópico, qualquer dúvida favor abrir um novo.

Não consegui replicar essa situação. Anexe o teu arquivo ACBNFe_Exemplo.ini pra eu verificar se é alguma configuração específica.

Se me lembro tem a configuração SepararPorCNPJ que se ativada vai tentar acessar o certificado pra obter o CNPJ, se não tiver a configuração do certificado nesse momento vai ter o erro. Então é verificar se está informando os dados do certificado antes das demais configurações.

Essa propriedade tanto na remessa quando na leitura do retorno vai considerar apenas a parte sequencial do nosso número e não o nosso número formatado completo. O mais indicado seria salvar apenas o sequencial no banco de dados para comparação. Mas você pode chamar novamente o método MontarCampoNossoNumero que deve ter o mesmo resultado do gerado no momento da remessa.

A última versão do plugin usando libxml2: https://github.com/morbac/xmltools/releases/tag/2.4.11.0

Sim, atualizei o plugin aqui e vi que passaram a usar MSXML:

É um bug na libxml2. A validação da parte modal do XML é feita contra o schema mdfeModalRodoviario_v3.00.xsd, este tem uma diretiva xsd:include para o tiposGeralMDFe_v3.00.xsd. Já o XML completo é validado contra o arquivo mdfe_v3.00.xsd, que tem um xsd:include para mdfeTiposBasico_v3.00.xsd que por sua vez tem um xsd:include para tiposGeralMDFe_v3.00.xsd. O problema ocorre ao tentar carregar o segundo include. Se você validar pelo Notepad++ que também usa a libxml2 isso fica claro: --------------------------- XML Tools plugin --------------------------- Unable to parse schema file. Parsing error at line 5: Element '{http://www.w3.org/2001/XMLSchema}include': Failed to load the document '/SERVIDOR/Schemas/MDFe/tiposGeralMDFe_v3.00.xsd' for inclusion. --------------------------- OK ---------------------------

Se você quer fazer download e manifestação de NFe vai usar a ACBrLibNFe. MDFe é outra coisa. Já baixou a biblioteca e os demos? Tem exemplo de uso em C# com os métodos DistribuicaoDFe (download de documentos) e envio de eventos (manifestação). Não esqueça de estudar a documentação pra entender como configurar e gerar os arquivos .ini com os comandos.

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

Sim, precisa informar item por item e a soma no total.

Geralmente o valor do frete é rateado entre os itens da nota, proporcionalmente por peso ou valor. Que saiba não há obrigatoriedade de se fazer isso, mas se você por exemplo informar valor do frete num item isento de ICMS, pode indicar sonegação, já que frete geralmente é tributado. O ideal é conversar com um contador de sua confiança.

Significa que você é obrigado a dizer se a operação teve intermediador ou não. Sim. Essa aqui eu não sei dizer...

Pode ser só algo no debug mesmo... Você tem o componente frxBarCodeObject no seu Delphi? Quanto ao erro, veja os dados que está passando, já houve relatos de gerar um caractere não numérico no código de barras.