bnobre

Obrigado amigo... Ficou perfeito!

Oi Rafael... Tudo bom? Nas opções do componente de DANFE do Fortes Report?

Olá amigo... Grato pelo retorno... Funciona, mas corta a direita... Já mexi em várias opções do driver, mas continua cortando

Bom dia a todos... Peguei um cliente com essa impressora que nunca ouvi falar e ao tentar imprimir via Esposs não sai o qrcode da NFCe... O ACBrEscPos é compatível com a mesma? Desde já agradeço a atenção de todos

Oi Juliomar... Tudo bom? Legal cara, não sabia sobre essa questão do Delphi e seu crescimento no mobile. Eu concordo contigo sobre a questão da programação ser diferente, a experiência que eu tive com o Delphi Mobile só foi ruim no aspecto "feedback". Eu gosto de programar em Delphi para desktop porque o Delphi já existe há anos, e qualquer problema que tiver OU já foi resolvido OU alguém já passou e tem uma solução. Em relação ao mobile, quando EU programei ao menos, tive um problema com o DataPicker, não lembro agora exatamente qual, mas tive grande dificuldade em achar algo sobre até que finalmente descobri que era um bug do Delphi e nada mais restava a não ser aguardar uma solução. Isso gera uma frustração, sabe? Eu quero ter essa COMUNIDADE GRANDE que tenho com o Delphi para a solução Mobile que for escolher, pois isso que sempre me motivou em programar com o Delphi e isso me motivará a programar com mobile. Estou vendo que as soluções há mais tempo no mercado e mais usadas seriam o Xamarin, React Native e Flutter, cada uma com seus prós e contras.

Oi... Tudo bom? Então meu amigo, eu até desenvolvi um app mobile há um tempo atrás em Delphi 10, com o REST também em Delphi. Ficou até legal, mas creio que não é o que o mercado de desenvolvimento mobile usa e portanto creio que não tem tanta ajuda como o próprio delphi em si na internet, se procurarmo "como fazer tal coisa" para delphi achamos muita documentação, o mesmo não ocorre com o mobile. Por isso quero conhecer uma ferramenta que seja mais utilizada, se possível logo A MAIS UTILIZADA, para não perder tempo. Com isso espero ter mais exemplos, ajuda e possibilidade em relação ao que eu tive com o Delphi Mobile. Desde já agradeço a sua atenção

Olá a todos, Programo há 20 anos com Delphi e minha experiência de programação é toda voltada para o mesmo. Agora (e já tarde) estou precisando fazer com que minhas aplicações Windows comecem a se comunicar com apps mobile. Existem centenas de curso em dezenas de plataformas e estou perdido em qual iniciar... SÃO TANTAS OPÇÕES. Alguém poderia me dar uma luz? Desde já agradeço a atenção de todos

Olá Daniel, Testei aqui... Compilei o Demo na versão antiga (18549) e na versão nova (19026) citadas acima. Observei que o Demo do ACBr não contempla o comando DadosPFX que eu uso, e sim o ArquivoPFX. No Demo a lentidão apareceu na versão nova e na antiga ficou normal, assim como no meu programa, mas a lentidão apareceu em outro ponto. Na linha ArquivoPFX não ocorre lentidão, mas logo em seguida se eu tentar usar um dos botões de informações do certificado, por exemplo o Data de Validade, leva cerca de 1 segundo para exibir a mensagem, isso na versão nova, já na antiga é instantâneo. Depois dessa primeira lentidão fica normal a velocidade (instantâneo) se eu tentar por exemplo exibir a Data de Validade novamente. Eu observei esse comportamento também no meu aplicativo, na primeira vez que é executado a linha do DadosPFX tenho a lentidão dos 2 segundos, mas com o programa já em memória se eu executar novamente esse comando a velocidade fica normal (instantânea). Agora usando o Demo, observo algo em comum entre ele e o meu programa na hora da "lentidão". Sabemos que se eu não possuir o RunTime do Visual Studio C receberei o erro "VCRuntime140.dll não encontrado". Esse erro no meu programa aparecia exatamente na linha do DadosPFX onde noto a lentidão, antes de eu instalar o Runtime do Visual Studio C. Agora testando o ACBrDemo na versão nova (19026), com as DLLs OpenSSL antigas (1.0.2.13), em uma VM Windows 7 32 bits esse erro não apareceu e apresentou a lentidão. Logo em seguida coloquei as DLLs novas (1.1.1.4) para conferir se sumia a lentidão e esse erro simplesmente surgiu, bem na hora que eu cliquei para ver a Data de Validade (onde surge a lentidão no Demo) e apesar do erro a validade foi exibida, ao clicar novamente no botão a validade foi exibida instântaneamente e sem erro. Enfim, coincidentemente a lentidão é na hora que o componente tenta usar essas DLLs do Visual Studio, que você disse ser necessária para o OpenSSL 1.1.1, pode ser algo aí. Estamos falando de tempos irrelevantes, 2 e 1 segundos, não é nada grave... Mas não pude deixar de observar isso. Se achar válido tenta reproduzir aí e vê se nota isso também. Abraços

Não efetuei o teste, mas posso fazer. Na verdade assim que vi essa lentidão no cliente, eu testei em uma máquina virtual minha Windows 7 64 bits com o meu aplicativo e o certificado de outro cliente, para ter certeza que não era algo isolado. E também nesse cenário que eu montei com outro certificado/maquina a lentidão se fez presente. Só frizando que o termo "lentidão" (1 à 2 segundos) é ao comparar como era antes (instântaneo). Ainda quer que eu envie o certificado?

Olá Daniel, tudo bom? Já tinha efetuado esse teste e não houve diferença, também tentei com as DLLs que costumo usar (1.0.2.13) e também permaneceu a lentidão. Com certeza lhe envio meu amigo e agradeço aí a atenção ao problema. Abraços

Em um primeiro momento sim, versão de DLLs 1.0.2.13. Logo após me toquei disso e usei apenas as DLLs da versão 1.1.1, conforme até orientado nessa nova revisão em um arquivo TXT presente. Até os nomes das DLLs diferenciam na 1.1.1. Infelizmente não senti nenhuma diferença. Eu entendo que são muitas revisões para se ter uma idéia, mas achei pertinente reportar esse comportamento que eu percebi.

Olá a todos, Vou tentar detalhar ao máximo todo o processo que ocorreu comigo. Eu desenvolvo a minha aplicação emissora de NFCe/NFe em Delphi 2010 + Windows XP. O certificado em meus testes é um PFX carregado direto do banco com as configurações a seguir: Até então estava usando a revisão 17394 dos componentes, mas dado a mudança das URLs no ACBrConsultaCNPJ foi necessário realizar a atualização dos componentes. Ao fazer a atualização meus componentes foram para a revisão 19026. Inicialmente ao executar o instalador dessa revisão (19026) recebi o erro "Function not found: mscoree.dll.CLRCreateInstance", que foi rapidamente sanado efetuando a instalação do Microsoft Net FrameWork 4.0 (graças a ajuda do pessoal do Chat ACBr). Logo em seguida ao compilar meu aplicativo no Delphi recebi o erro "VCRuntime140.dll não encontrado". Reparei que o erro surgia bem na linha que carregava o PFX do certificado que está gravado no banco de dados para o componente (ACBrNFe1.Configuracoes.Certificados.DadosPFX). Mais uma vez o erro foi rapidamente sanado com a ajuda do Chat ACBr instalando o Runtime do Visual C Studio presente na pasta ACBr (DLL\Diversos\VC_redist.x86.exe). O Daniel me informou que a causa dessa dependência são as novas DLLs do OpenSSL 1.1.1. Com isso o programa rodou normal e conseguir emitir as notas, MAS... Eu coloquei o executável compilado nessa nova versão em um cliente e logo percebi uma certa lentidão que não existia anteriormente na hora que o usuário faz o login, analisei um pouco mais a fundo e descobri que essa lentidão ocorre na linha que carrega o PFX do certificado que está gravado no banco de dados para o componente (ACBrNFe1.Configuracoes.Certificados.DadosPFX). Antes carregava instantaneamente, agora leva uma média de 2 segundos. Esse cliente usa 5 máquinas com Windows 7 32 bits e 64 bits. Resolvi então atualizar apenas para a revisão na qual foi corrigido o ACBrConsultaCNPJ (18549) e na mesma tal lentidão sumiu e voltou a carregar instantaneamente, além de também não receber o erro do "VCRuntime140.dll não encontrado". Enfim, não sei a origem disso e nem sei se mais alguém observou tal lentidão, mas resolvi reportar isso aqui no fórum. Desde já agradeço a atenção de todos.

Aparentemente está resolvido. Abraços a todos

Oi Juliana, tudo bom com você? Desculpe a demora, atualizei agora os componentes e farei testes... Reporto assim que possível! Obrigado pelo retorno e abraços

Oi Daniel, tudo bom? Dei uma olhada agora no ACBrMonitorPLUS, nessa parte do Terminal de Consulta... Você mencionou sobre esse BuscaPreco, mas eu não entendi muito bem. Eu consigo através dessa aba alimentar o Terminal de Consulta com meus produtos?

Olá a todos, Um cliente meu acaba de comprar um terminal de consulta de preços. Quero saber se o ACBr possui algum componente que se comunique com tal equipamento para o envio dos produtos/preços/código de barras dos produtos cadastrados em meu sistema. Desde já agradeço a atenção de todos

De acordo com os mesmos, deve-se usar o valor de 0,01.

Oi EMBarbosa, Obrigado pelo retorno. Nunca fiz contato com o pessoal da SEFAZ-RJ, vou pesquisar um canal de atendimento aqui na web e retorno com novidades. PS: Se alguém souber o contato pode postar aqui

Olá EMBarbosa, tudo bom? Ocorreu uma falta de comunicação. Anteriormente eu disse o seguinte: Aí nessa frase que você citou eu complementei, dizendo que sou obrigado a colocar o vICMSDeson = 0,01 quando o mesmo está zerado, pois zerado recebo rejeição. O problema é que esse vICMSDeson utiliza uma fórmula em cada estado, e uma das variáveis de tal fórmula é o valor do produto. Se o mesmo for muito baixo, 0,02 por exemplo, o vICMSDeson acaba ficando igual a 0,00 e com isso levamos rejeição

Oi BigWings... Tudo bom? O problema é que ao tentar enviar 0,001 ele até gera a tag como você falou, mas arredonda para 0,00... E com o valor zerado volta rejeição aqui no RJ.

Bom dia Juliana... Sim, com duas casas passa (0,01)... No momento estou utilizando essa solução, mas gostaria de saber se o resto dos colegas está aplicando outra solução.

Na verdade a MINHA sugestão foi passar para 0,01... A tag não aceita 3 casas decimais

Mas de acordo com a Nota Técnica 2016.002 a tag vICMSDeson aceita apenas duas casas decimais.

Olá a todos, Como sabem aqui no RJ se faz necessário o preenchimento da tag vICMSDeson para os produtos que usem o CST 20, 30, 40 ou 70. O problema é que quando o valor do produto é muito baixo temos um vICMSDeson igual a 0,00 e ocorre rejeição por parte do servidor da SEFAZ ao tentar enviar a nota. A princípio a solução mais óbvia é sugerir o vICMSDeson igual a 0,01 nos casos em que o mesmo seja zerado. Estou correto? Os amigos estão utilizando outro procedimento? Desde já agradeço a atenção de todos

Perfeito meu amigo... Essa dica para capturar o protocolo é show. Abraços