BigWings

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.

Já foi enviada correção para esse problema, na rev. 19893 do svn. Com a ressalva que usar xsMsXML ou xsMsXMLCapicom continua não recomendado, por ter problemas graves com certificado A3 já reportados aqui no fórum. O recomendado é usar xsLibXML2 (padrão libWinCrypt).

Veja se o tópico abaixo é o mesmo caso teu:

Anexe log do ACBrInstall.

O XML do tópico original está com estrutura errada, com o grupo impostoDevol fora do grupo <det>. Outra coisa, caso esteja informando a tag vIPI não deve informar a vIPIDevol. Esta última deve ser usada por não contribuintes do IPI que não desejam destacar a vIPI. Informando as duas vai causar diferença no total da nota, já que ambas devem ser somadas ao total da NFe.

Teste com o .ini anexo. GovDigital.ini

Por favor, veja a citação, minha mensagem tinha sido para o @DouglasGV. Você fez teste usando a unit que o Daniel anexou, ou atualizou novamente os fontes?

Apenas atualize os fontes, a unit já está disponível no repositório. E pela mensagem de erro os teus estão desatualizados.

Sim, o próprio evento já retorna a situação da NFe, e você pode também consultar a chave pelo método de consulta. As notas de emissão própria, que seria o caso de uma devolução de uma NFe recebida de terceiros, não são retornados pelo método. Afinal a empresa que está fazendo a consulta deve saber se gerou a nota de devolução ou não.

Se você está usando o componente de impressão para Fast Report - ACBrMDFeDAMDFEFR - vai ser um pouco diferente mesmo. O post citado é sobre o componente para Fortes Report - ACBrMDFeDAMDFEFortes. Tem uma contribuição em análise com novos FR3, que talvez possa lhe interessar, aqui: Sim... com a diferença que o componente para Fortes dispensa o uso do FR3.

Veja: