Nelson A Sousa

Obrigado pela resposta @Daniel Simoes, É mais por uma questão de limpeza de código no meu ERP. Estou migrando pro WPF e aproveitando pra dar uma faxina. Valeu!!

Boa tarde pessoal, Quando da criação do INI para formação do XMl da NFe, algumas tags ficam sem valor, por exemplo: [ICMS001] sOrigem=0 CST= CSOSN=102 modBC= pRedBC= vBC= Eu poderia informar somente, isso? [ICMS001] sOrigem=0 CSOSN=102 A ACBrLib aceita?

São os pedidos dos clientes que acabam confundindo a gente. Informando o total do icms não valida a NFe mesmo não. Retirei os valores de ICMS da totalização e validou/autorizou. Muito obrigado pela ajuda!!!

Olá @José M. S. Junior, Obrigado pela resposta. Nos totais devo informar o vIcms e a base de calculo?

Bom dia, Estou usando o AcbrMonitorPlus com c#. no VS2019. Estou gerando o arquivo INI da venda e o cálculo do ICMS é informado neste INI. porém quando o AcbrMonitorPlus gera o XML os dados do ICMS não são gerados no mesmo. Alguém pode me dar uma força? 33200320983081000102550010000016011471452682-nfe.xml NFEVenda.INI

Olá Rafael, Obrigado pela resposta! Acabei descobrindo que o erro estava na declaração da LIB. antes, funcionava corretamente e eu declarava assim: _AcbrNFe = new ACBrNFe(NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini"); agora precisei mudar para: _AcbrNFe = new ACBrNFe(NgGlobais.PubPastaEmpresa + @"\Dados\Logs\ACBrLib.ini",""); veja que tive que inserir o segundo parâmetro como string vazia. Antes isso não era necessário para iniciar o constructor!! Agora, uma vez que o INI está sendo localizado, a pasta de schemas configurada também foi localizada corretamente. Verifiquei também que, mesmo agora, está sendo criado um segundo INI com dados padrão, na pasta raiz do EXE. ACBrLib.ini ACBrLibNFE-20200210.log

Olá, bom dia! Estou utilizando a AcbrNFeLib com C# no VS2019. Em meu arquivo AcbrLib.INI a pasta dos schemas está configurada como: PathSchemas=C:\MeuSistema\Schemas\ Acontece que ao validar... _AcbrNFe.Validar(); está retornando o erro de que os schemas não foram encontrados, só que o path, no erro, está descrito como na pasta raiz do executável: "C:\Projetos\...\...\Bin\Debug\Schemas\" Será que esqueci de algo?

.Olá pessoal, Gostaria de deixar uma sugestão para deixar a visualização dos enuns mais amigável. Para carregar numa combobox: //No c# com XAML Private void CarregaNFeLayoutDanfe() { CboNFeLayout.ItemsSource = NgListaEnum.ListarEnum(typeof(TipoImpressao)); CboNFeLayout.DisplayMemberPath = "Value"; CboNFeLayout.SelectedValuePath = "Key"; CboNFeLayout.SelectedValue = TipoImpressao.tiRetrato; } //No C# WinForms private void CarregaNFeLayoutDanfe() { CboNFeLayoutDanfe.DataSource = NgListaEnum.ListarEnum(typeof(TrNFeLayoutDanfe)); CboNFeLayoutDanfe.DisplayMember = "Value"; CboNFeLayoutDanfe.ValueMember = "Key"; CboNFeLayoutDanfe.SelectedValue = TrNFeLayoutDanfe.Normal_Retrato; } Dessa forma os enumeradores assumem a descrição escolhida. TipoImpressao.cs NgListaEnum.cs

Olá @José M. S. Junior, Obrigado pela resposta! Sim o path está gravado. O estranho é que está substituindo a pasta ..\Enviados\... pela pasta ...\Envios\... Acredito que para simular basta passar no parâmetro do xmlEvento apenaso nome do arquivo, sem o path.

Olá, Bom dia! Ao utilizar o método EnviarEmailEvento() eu informava apenas o nome do XML do evento sem o path, por exemplo: "35XXXXXXXXXXXXXXXX550010000000050000000058-ProcEventoNFe.xml" O monitor se encarregava de completar o path. Como este procedimento é muito pouco utilizado, hoje notei que está completando o path só que com a pasta padrão ..\Envios\. Só que, no caso deste cliente, ele alterou o path no monitor para C:\Methodus\Gerente\NFe\Enviados\Autorizados\Eventos, salva no AcbrMonitor.INI Para resolver tive que informar o path completo do xml do evento. Parece que o recurso do Monitor de completar o path não está respeitando o path salvo na guia diretórios. Como eu disse, eu já resolvi informado o path completo, só estou relatando para o caso de uma possível correção.

Olá, Bom dia! Creio que a decisão na abertura do constructor está invertida na classe AcbrETQ.cs: Está assim: public ACBrETQ(string eArqConfig = "", string eChaveCrypt = "") : base(Environment.Is64BitProcess ? "ACBrETQ32.dll" : "ACBrETQ64.dll") { var inicializar = GetMethod<Delegates.ETQ_Inicializar>(); var ret = ExecuteMethod(() => inicializar(ToUTF8(eArqConfig), ToUTF8(eChaveCrypt))); CheckResult(ret); } Creio que deve ser invertida as posições de ? "ACBrETQ32.dll" : "ACBrETQ64.dll" para ? "ACBrETQ64.dll" : "ACBrETQ32.dll"

Olá @Rafael Dias, boa noite! Fiz um "revert" no arquivo (AcbrSessao.cs) e notei que a sessão DANFENFe agora também não está mais na classe. Tem outras pequenas correções no AcbrETQ, mas vou criar outro tópico pra não esticar muito aqui.

Olá, Na classe AcbrSessao do demo c# da AcbrLib.Core tem um nome de sessão DANFECe. No arquivo INI eu encontrei como DANFENFCe. Há algum erro aí ou existem as duas mesmo?

Pessoal, boa tarde! Estou criando um formulário de configurações para a AcbrLib. Na seção [DANFE] tem a TAG ImprimeCodigoEan e na seção [DANFENFe] tem a Tag ExibeEAN. Alguém pode me explicar a diferença entre as duas?

Já tentou mudar o canhoto para o rodapé?

Sistema antigo em Clipper e já com NFce?!?!

Olá @Rafael Dias, Obrigado pela resposta. Quanto a sua sugestão 1, eu entendi. Eu só prossegui no post, para o caso de não se saber a OS do cliente, ou no caso de um cliente com várias máquinas com vários OS's. Então, para não ter que ter várias versões de distribuição, eu pensei em termos apenas uma distribuição que atendesse qualquer tipo de OS. Quanto à sugestão 2 e 3, eu fiz exatamente isso. Modifiquei a classe e ela carrega as dlls nativas na respectiva pasta da OS. Nos testes que efetuei aqui, o funcionamento correto só ocorre quando as dlls de dependências estão na raiz do EXE. Note que falei das dependências, neste caso, quando aciono a LibNFe ela não busca na pasta configurada na classe de alto nível, mas sim na pasta raiz do EXE. Não sei se estou explicando corretamente...rsrsrs...mas a questão está no carregamento das dlls de dependência.

Minha limitação no Delphi não vai permitir que eu faça muita coisa não. O problema é que as dlls nativas do AcbrLibNFe, não importa a plataforma se x86 ou x64, sempre procuram as dlls dependências na pasta raiz do EXE. Como as dlls da pasta dep, apesar de terem o mesmo nome, são de plataformas diferentes e não podem ser copiadas para a pasta raiz do EXE. Para o carregamento das dlls nativas, no caso a ACBrNFFe32.dll e a AcbrNFe64.dll, cada uma em sua respectiva pasta de plataforma, tudo transcorre normalmente. Somente o carregamento das dependências é que não funciona. Como eu disse, meu conhecimento de Delphi é bem limitado, talvez alguém consiga fazer com que as dlls nativas procurem suas dependências na pasta da própria dll e não na raiz do EXE. Dessa forma poderemos construir um único instalador, já com as versões das duas plataformas x86 e x64. Para exemplificar coloquei a estrutura de pasta ideal na primeira imagem abaixo. Na segunda imagem coloquei a pequena modificação que precisei fazer no constructor da classe. Apenas acrescentei o path das pastas. Reparem que as dlls de dependência, apesar de plataformas diferentes, têm o mesmo nome. Isso impede a colocação das mesmas na pasta raiz do EXE, ou se coloca x86 ou se coloca x64. O que torna a verificação de plataforma executada no constructor da segunda foto, de certa forma inútil.

Bom, sobre o Java eu não posso falar. Mas quanto ao C#, VB e VB.net não tem problema não. Vou fazer umas modificações eu mesmo aqui, e, se der certo, eu envio pra averiguação.

Admito que tem um certo grau de paranóia organizacional de minha parte...rsrsrsrs

@Daniel Simoes, Sim, e que as dlls nativas reconhecessem a mesma estrutura de pastas quando do carregamento das dependências. A raiz no caso seria a pasta AcbrLib, esta sim, seria colocada na pasta do executável. Uma vez que a classe de alto nível reconhecesse a plataforma em que está o EXE sendo utilizado. A estrutura de pastas seguiria uma padronização como a sugerida acima. Dessa forma não importaria a plataforma, se x86 ou x64, e o Acbr rodaria sem problemas.

Apenas uma sugestão!

Olá, É uma boa compartilhar a solução com os demais usuários. Alguém pode estar passando ou passar pelo mesmo problema. Dê uma breve descrição do que estava fazendo errado e como solucionou!! Fica a dica!! Um Abraço,

Sim, um bom exemplo pode ser encontrado no carregamento da SqlServerTypes. Só que no caso, será necessária uma mudança nas dlls nativas,, elas que vão decidir em qual pasta procurar as dependências. Ou então, uma mudança geral em como arquivar as dlls nativas do Acbr, ou seja, separadamente, cada uma na pasta de sua respectiva plataforma. Mas essa segunda opção aí talvez seja necessária somente como forma de organizar os arquivos. Não tem tanta necessidade. Loader.cs

Bom, Resolvido!! Forcei a compilação em x86, copiei todas as dlls envolvidas para a raiz do meu EXE, e funcionou!!! Obrigado @Daniel Simoes!!