BigWings

Se apareceu o OK com o nome do arquivo gerado, ele devia estar lá... O certificado que usei no meu teste foi este: http://www.flexdocs.com.br/DL/uploads/Associacao.pfx Como disse antes, a chave é gerada a partir do conteúdo do XML. Por exemplo, a chave que você gerou e informou no nome do arquivo inicia em 35, isso indica um documento de um emitente de SP, mas a UF do emitente dentro do XML é: <cUF>33</cUF>

Pelo PDF anexado você está usando o componente ACBrNFeDANFEFR para impressão. Ele deve ser usando apenas para NFe. No caso da NFCe deve ser usado o componente ACBrNFeDANFCEFR.

A alteração teve efeito colateral de não mais ajustar a margem direita... No caso do DANFE não se nota diferença porque o .fr3 não está ajustando a largura das bandas para a largura da página (o que seria desejável), mas no caso do DACTE com DACTE_Retrato.fr3 dá pra notar. Acredito que o problema reportado neste tópico podia ser resolvido apenas ajustando as margens para uma largura de página padrão...

Vejam se estão consultando a nota no mesmo ambiente (produção/homologação) em que ela foi enviada.

33200599999090910270580010000000011000000018-mdfe.xml

Testei com teu XML e o certificado "Associacao" e assinou e gerou o arquivo normalmente:

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

Pode ter estourado a cota, você pode apagar anexos já enviados por aqui: https://www.projetoacbr.com.br/forum/attachments/

Me parece que está usando o componente ACBrCargaBal, estou correto?

Está abrindo o XML informado na linha "OK"? Veja que o nome mudou, o ACBr gera o nome do arquivo de acordo com a chave, e a chave é a composição dos dados do documento. Se desejar anexe os arquivos.

Posso estar enganado, mas que saiba o ACBrBAL apenas faz leitura de peso da balança conectada na porta local, e não permite o envio de comandos pra mesma... Tem o log do componente/ACBrMonitorPLUS?

Você pode deixar a geração do XML a cargo do ACBrMonitorPLUS, enviando os comandos no formato de arquivo .ini: https://acbr.sourceforge.io/ACBrMonitor/MDFeCriarMDFe.html Pela mensagem de erro, o seu arquivo ACBrMDFeServicos.ini está desatualizado. Na versão atual já se encontram as URL: [MDFe_SVRS_H] [...] URL-QRCode=https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode URL-ConsultaMDFe=https://dfe-portal.svrs.rs.gov.br/MDFe/consulta

Uma observação sobre essa tag: O percentual de devolução não é a alíquota do IPI. Na tag pDevol deve ser informado o percentual que está sendo devolvido em quantidades, em relação à nota de venda. Ex.: Venda de 10 peças, e devolução de 5 peças, pDevol deve ser 50.

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

Quem tem que emitir o MDFe é o responsável pelo transporte da mercadoria. Se o destinatário da NFe é quem vem buscar, na minha opinião, é ele quem tem que emitir o MDFe. Caso o emitente da nota fiscal emita um MDFe e informe um veículo de terceiro, isso configura uma contratação de serviço de transporte, e o veículo deve possuir registro RNTRC. Caso o emitente do MDFe não seja uma transportadora e informe um veículo próprio, não é necessário o RNTRC. Não conheço nenhuma legislação que obrigue software emissor de NFe a emitir também o MDFe. Se você tem que desenvolver, se pode cobrar ou não, depende apenas do contrato entre você e seu cliente.

A contribuição deste tópico que havia sido aplicada no repositório foi revertida em parte, nas rev. 19887 e 19898, por estar causando efeito colateral em outros provedores. Para reaplicar esta alteração favor abrir novo tópico anexando o XML da NFSe.

Alguns pacotes de impressão (DANFE, DACTE...) dependem do Fast ou Fortes Report instalados. Você pode desmarcar no instalador os que não deseja usar.

Se baixou os fontes está na pasta .\ACBr\Exemplos\ACBrDFe\Schemas\NFe. Os schemas devem ser distribuídos junto com a aplicação.

As duas formas. Limitado aos eventos que a SEFAZ retorna na consulta.

É o mesmo problema, falta de informar no total a soma do valor informado nos itens, mas agora com relação a tag vTotTrib.

Realmente não seria um XML válido, mas em se tratando de NFSe não dá pra esperar que os padrões sejam seguidos. O método de assinatura realmente vai falhar com esse XML. O que você pode fazer é orientar o componente a não assinar, alterando o arquivo SmarAPD.ini, no grupo [Assinar] definir ConsNFSe=0. Você ainda vai ter erro dizendo que o método de consulta não está disponível pra esse provedor, então ou ele realmente não disponibiliza a consulta por webservice, ou não está implementado no componente. Seria interessante entrar em contato com o provedor pra obter essa informação.

Se estiver usando WinCrypt, além da configuração, depende do Windows estar atualizado para ter suporte ao nível de criptografia exigido. Com OpenSSL independe da versão do Windows ou de configuração do mesmo, pois ele usa DLLs próprias. Então com certificado A1 é sempre melhor usar OpenSSL.

Pra mim a regra está bem clara. Se informar o CST 10, 30, 60, 70 ou os CSOSN 201, 202, 203, 500, é obrigatório informar o CEST. Se informar o CST 90 ou o CSOSN 900, é obrigatório informar o CEST caso a tag vICMSST seja maior que zero.

Não existe versão trial e paga da DLL. O binário é o mesmo. Você só não conseguirá baixar novas versões do arquivo, se a sua assinatura SAC trial expirou. A mensagem de erro parece indicar algum bloqueio no acesso à porta de comunicação. Talvez ela já esteja em uso?

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