bnobre

Olá @Daniel Simoes Tudo bem? Segui suas dicas...Vamos aos resultados.. 1º - Eu havia feito contato com o pessoal do Kaspersky sobre os falsos positivos na semana passada, eles me responderam confirmando o falso positivo e disseram que seria resolvido em uma próxima atualização. Eu não acreditei muito, mas hoje estou testando os executáveis e realmente não estão mais surgindo os falsos positivos em https://opentip.kaspersky.com/. Portanto os testes realizados abaixo serão feitos no https://www.virustotal.com/. 2º - Segui essa dica. Criei um bucket SS3 para baixar os arquivos somente usando HTTPS. Sabe o que aconteceu no virustotal.com?!?!? Passou a detectar MAIS falsos positivos... Acredita?!?!? 3º Também segui essa dica, e como no exemplo acima passou a detectar MAIS falsos positivos do que anteriormente. 4º - Gostei de saber que vocês usam o OV. Pois o EV é "inconcebível". Esses resultados me geraram as seguintes dúvidas: 1 - Sinceramente pelos resultados não creio que esse virustotal.com seja efetivo. Já tentou testar seus binários pelo por esse serviço para ver os resultados? 2 - Mesmo não tendo tido nenhum benefício aparente, você continua achando válido usar o HTTPs como canal de transferência desses arquivos em detrimento do HTTP? Se sim, porque? 3 - Mesmo não tendo tido nenhum benefício aparente, você continua achando válido baixar o executável como .zip e só localmente extrair o mesmo? Se sim, porque? 4 - Tentei usar essa classe Synapse, ao invés do idHttp, mas para ser sincero não achei a mesma. Achei diversas classes no diretório Terceiros - synalist, mas essa classe em específica não achei. Tem algum outro local onde possa achar a mesma e algum exemplo de uso? Desde já agradeço a atenção e acho que esse tópico será referência para aqueles que assim como eu precisarem desenvolver algo tão simples (um programa para baixar arquivos, como um atualizador por exemplo) e sejam pegos de surpresa com toda essa questão "extra" de falsos positivos

Seguinte pessoal... Essa situação da presença de códigos para download de arquivos na internet em nossos programas gerar um falso positivo nos antivírus ÀS VEZES me frustrou e acabei achando na internet um exemplo da própria Embarcadero de como criar programas para download de arquivos na internet: https://github.com/Embarcadero/RADStudio11Demos Dentro de Object Pascal -> RTL existem dois exemplos, o HttpAsyncDownload e o HttpDownload e resolvi colocar a prova o código da Embarcadero, pois se o meu está dando falso positivo e o problema é a existência de um código de download de arquivos na internet, então o exemplo deles, que é um programa que faz download de arquivos, também teria dar o falso positivo. Adivinha?!?!? Passou com louvor tanto no https://opentip.kaspersky.com/ quanto no https://www.virustotal.com/. Isso meu deixou mais frustrado ainda!!!!!! Bem, tive que me perguntar... Qual a diferença do código deles para o meu? Porque comigo não dá certo e com eles passa sem problemas no teste de vírus? Reparei que eles usam a biblioteca httpClient, parece que o idHttp ficou no passado ao menos pra eles. Mas como citei no início do tópico já tinha tentado trocar a classe e não deu certo. Um dos meus executáveis até passa no https://opentip.kaspersky.com/ depois da troca, mas no https://www.virustotal.com/ apresentado pelo @Daniel Simoes consta como vírus em 3 de 71. O outro executável mesmo trocando o componente acusa vírus tanto no https://opentip.kaspersky.com/ quanto no https://www.virustotal.com/ (4/71). Como a única diferença restante entre o projeto da Embarcadero e o meu era o fato do deles ser em Firemonkey e o meu em VCL, recriei meu projeto em Firemonkey/httpClient e adivinha?!?!? Passou com louvor tanto no https://opentip.kaspersky.com/ quanto no https://www.virustotal.com/. Agora eu te pergunto... Porque diabos o executável compilado com o Firemonkey não acusa vírus, em detrimento do compilado no VCL? Qual é a "mágica"?

Na verdade o problema não é nem tanto com o cliente ficar desconfiado, é mais o trabalho de colocar o executável na máquina do cliente e o mesmo ser deletado por um falso positivo e com isso gerar demanda de suporte nosso. O tópico que passou é excelente, mas como eu disse o assunto abrangeu mais o Windows em si, não menciona como os antivírus em geral do mercado lidam com esses binários assinados. Fiz uma pesquisa aqui rápida na internet e não achei nada sobre essa questão em relação aos antivírus/binários executados. Como foi a sua experiência COM OS ANTIVÍRUS depois que passou a assinar seus binários? Teve casos em que falsos positivos (referente a códigos de download como o meu) surgiram e depois de assinar o binário pararam?

Oi @Daniel Simoes Tudo bom meu amigo? Pow, bacana isso... Até hoje nunca tinha ouvido falar desse assunto. Pelo que li no seu tópico as mensagens de alerta do Windows irão sumir, beleza... Mas não vi nada no texto que fizesse alusão que o uso desse certificado elimina esses falsos positivos dos antivírus. Elimina? É assim que vocês resolveram esse problema incômodo de colocar um código pra fazer download e pronto, tá lá o alerta de falso positivo?

Olá a todos, Desenvolvi uma pequena aplicação que não faz nada além de baixar um executável em meu site para a máquina do cliente. Mas sempre que vou trabalhar com código pra fazer download de arquivos no Delphi tenho problemas de falso positivo. Tinha isso no Delphi 2010 e estou tendo agora no Delphi 11.2. Vira e mexe o Kaspersky em meu computador acusa que minha aplicação é um malware: HEUR:Trojan-Downloader.Win32.Generic, não é sempre, é só às vezes, mas quando acusa apaga o executável. Mas se eu for testar no https://opentip.kaspersky.com aí toda vez acusa o tal malware. Como estou com o Delphi 11.2 agora decidi, para efeito de teste, deixar de usar o idHTTP e usar um objeto mais moderno do Delphi para tal, o httpClient e simplesmente parou de acusar o falso positivo nesse executável lá no portal do Kaspersky. Aí pensei, que legal... Resolvi, "só que não". Nessa aplicação resolveu, mas em outra que possuo, que também faz download de arquivos e que também está dando falso positivo às vezes, troquei o idHttp pelo httpClient, e continua dando o falso positivo no Karsperky. Como vocês lidam com essa situação? Existe alguma recomendação ou regra na hora de programar quando envolva download de arquivos OU simplesmente é torcer para o antivirus não excluir nossos executáveis? Entrei em contato com o pessoal do Kaspersky, confirmaram que é um falso positivo e que iriam corrigir o problema, mas isso é só uma gota no oceano cheio de antivírus... E isso considerando que realmente resolvam o problema, o que até agora não aconteceu. Desde já agradeço a atenção

Falando em cálculo... Achou algum documento OFICIAL relatando como será feito o cálculo de algumas dessas tags do ICMS Efetivo e/ou Retido? Caso sim, compartilha aqui por favor. Eu achei os seguintes cálculos (Fonte não oficial https://blog.oobj.com.br/icms-efetivo/ ) vBCEfet = vProd * (1 – pRedBCEfet) vICMSEfet = pICMSEfet * vBCEfet Mas como a fonte não é oficial, não sei se será usado tal fórmula no RJ, mas creio isso não deve variar entre os estados. No PDV para emissão de cupom fiscal vou colocar o cálculo automático e pedir para o usuário preencher as alíquotas previamente nas regras de tributação. No que tange o modelo 55 por hora estou colocando todos as tags dos grupos ICMS Efetivo e Retido editáveis na tela de preenchimento da própria NFe, para na pior das hipóteses o usuário poder preencher manualmente e não ficar impossibilitado de enviar o documento. Qualquer novidade aí da comunidade vamos alimentando aqui e melhorando a solução.

Olá @Matheus Marçal... Tudo bom? Contabilmente se são mutuamente exclusivos (o efetivo e o retido) não sei te dizer, mas no XML passa o preenchimento dos dois grupos sem problema aqui nos meus testes: Ressaltando que os testes que eu fiz usando os 2 grupos foi no modelo 55. No modelo 65 só me preocupei de testar o preenchimento do grupo Efetivo, pois no mesmo a validação só contempla os campos do grupo N33 (ICMS Efetivo). Se foi uma forma de tributar o ST eu não sei, às vezes sinto que esses caras do ENCAT nem sabem mais o que fazem e criam essas validações NO AUTOMÁTICO kkkkkkkkkkkkkkkkkkkkkkkk Só não entendi o que você quis dizer no trecho: "agora você pode usar aliquota e FECP e aplicar no 060 e no 0500, como se estivessemos utilizando o ( 00 )". Como assim usar alíquota e FECP? Você fala das alíquotas de ICMS e FECP dos produtos? Se sim, as tags de alíquota de ICMS e FECP ficam em grupos distintos das tags dos grupos Efetivo e Retido, portanto creio que não tem nada a ver!!! Galera, essa NT com as validações 906 e 938 existe desde 2019... Ninguém sabe de nenhum outro estado que já as tenha ativado? Será que o RJ é o pioneiro 4 anos depois???

Outro detalhe: A NT diz que modelo 65 com idFinal = 1 tem que preencher as tags do grupo N33. Acima eu preenchi, mas o vICMSEfet acabou sendo 0.00 devido o baixo valor do produto que coloquei propositalmente como 0.05. Ao meu ver eu preenchi a tag a partir do momento que a mesma aparece no XML (com valor 0) e com isso obedeci a regra em questão. Isso conta? Ou preencher também considera ser um valor diferente de 0?

oi @Juliana Tamizou Já fiz contato com o mesmo, estou no aguardo dele. Obrigado

Fala meu amigo @Italo Giurizzato Junior Tudo bom? Vamos lá... Operações a consumidor final (indFinal = 1) e CST = 60 ou CSOSN = 500 (tanto para o modelo 55 quanto 65). Essa regra acima é redundante no que tange o modelo 65 e o indFinal = 1, afinal todos os modelos 65 tem o indFinal = 1, do contrário levariam a rejeição 716... Correto? Então basicamente se é NFCe e se tem CSOSN 500 vai ser necessário o preenchimento dos campos do grupo N33 ou meu entendimento está errado??? Quanto a percentual a ser utilizado, se é único para todos os produtos ou se depende do produto a pessoa mais indicada a informar isso é o contador dos seus clientes. Então meu amigo, sabe como é a contabilidade, temos que nos virar sem eles na maioria das vezes. Eu na verdade queria que algum desenvolvedor de OUTRO estado em que isso já é obrigatório (afinal deve ter, a NT é de 2019) me relatasse como funciona. É por produto? É por grupo? Não que isso vá ser seguido aqui no RJ, MAS com a visão da prática em outros já posso ter uma ideia e montar a minha tela da melhor maneira possível com as informações que tiver. Desde já agradeço sua atenção

Então pessoal... Conforme vocês viram quem não atender a essas novas regras aqui no RJ, não conseguirá emitir cupons fiscais e NFe. Tal validação já era opcional desde 2019, mas aqui no RJ não era obrigadora, ao menos até agora... "Que legal" kkkkkkkkkkkkkkkkk A minha dúvida agora é a seguinte: Onde no meu programa atribuir tais campos? Vou dar uma visão mais ampla da situação: Aqui no meu sistema eu tenho uma tela de configuração dos impostos, segue abaixo: E aí, usando o exemplo acima, especifico no cadastro dos produtos quem irá usar tais detalhes/regras de tributação: Como a tributação é uma informação repetitiva, usada em GRUPOS de produtos, criei uma tela específica para a mesma e vou no cadastro de produtos associando apenas a tributação que será usada. Fica mais fácil assim para o usuário. Em relação ao Percentual de redução da base e a Alíquota do ICMS efetiva será similar???? Tais valores serão em sua maioria repetitivos entre os produtos OU cada produto terá um valor diferente, assim como é o código de barras, descrição, etc? Alguém aí de outro estado onde esse preenchimento já é obrigatório poderia me esclarecer??? Se forem valores repetitivos eu jogarei na tela de tributação. Se forem valores únicos (como código de barras por exemplo) vou jogar na tela de cadastro de produtos.

E pelo jeito eu ainda dei sorte, pois o prazo ia estourar dia 25/04/2023 e ia ser uma merd... generalizada. http://www.fazenda.rj.gov.br/sefaz/faces/menu_structure/legislacao/legislacao-estadual-navigation/coluna3/Portarias/Portarias-Tributaria?_afrLoop=101068555465901329&datasource=UCMServer%23dDocName%3AWCC42000001955&_adf.ctrl-state=1381ufj9jl_42 De repente seria mais interessante mover esse tópico para a parte de NFCe da área aberta do fórum, pois com certeza assim como eu devem haver outros desavisados aqui do RJ em relação a tais campos. O que acham? Desde já agradeço a atenção

Olá meu amigo... Obrigado pelos esclarecimentos, estamos mal aqui com consultoria contábil. Farei contato com o amigo @marcopoloviana agora. Grato

Olá a todos, Acabo de dar uma lida no tópico abaixo e agradeço ao amigo @Diego Foliene pela postagem: Infelizmente até hoje NUNCA tinha ouvido falar de tais campos/validações, fiz uma pesquisa aqui rápida a respeito e pelo que vi até o momento estou FERRADO, só gostaria de algumas confirmações dos amigos pra ter certeza como devo proceder aqui. Localizei na Nota Técnica 2018.005 - v.1.30 - Publicada em 26/04/2019, discorrendo sobre o mesmo e surgiu algumas dúvidas. 1º - É realmente essa a última NT que fala sobre as validações 906 e 938? 2º - Diz que no modelo 65 com indFinal = 1 a validação 906 entra em vigor. Mas todos os documentos modelo 65 têm o indFinal = 1, para evitar a rejeição 716. Correto? 3º - Se a última NT que discorreu sobre o assunto realmente for a 2018.005 - v.1.30, de acordo com a mesma para evitar a rejeição 906 na NFCe terá que ser preenchido as tags pRedBCEfet, vBCEfet, pICMSEfet e vICMSEfet... É isso mesmo??? 4º - É basicamente na terceira pergunta acima que estou mais preocupado, pois até então nunca tinha ouvido falar nessas tags acima e terei que colocar as mesmas no programa, além disso terei que pedir ao meu cliente que informe tais valores. Daí que vem a minha quarta pergunta, cuja resposta pode me deixar MAIS ou MENOS FERRADO, tais alíquotas costumam variar de produto para produto (pRedBCEfet e pICMSEfet) e o cliente vai ter que ter o cuidado de preencher um a um OU são valores fixos para todos os produtos por estado (pRedBCEfet = X% e pICMSEfet = X% aqui no RJ por exemplo)???? Desde já agradeço a atenção e ajuda de todos

Opa meu amigo... Agora ficou claro kkkkkkkkkkkkkkk Na verdade essa foi a resposta DEFINITIVA ao tópico. Então a OS214 e OS2140 não imprime no ZPLII. Obrigado Abraços

Olá a todos, Obrigado pelo comentário @Daniel Simoes. Só pra documentar... Também consegui a impressão do modelo citado acima (ZPLII) na Elgin L42 Pro. Se algum amigo/amiga tiver os equipamentos da Argox ou outros não citados acima e tiver informações a respeito da possibilidade de imprimir no ZPLII favor comentar aqui. Desde já agradeço a atenção de todos.

Olá a todos, Tudo bom? Eu possuo alguns layouts de etiqueta na linguagem PPLA onde imprimo sem problemas nas impressoras Argox (OS214, OS2140) e Elgin (L42Pro, L42 Pro Full e L42DT). Mas há tempos os clientes cobram um layout mais parecido com o utilizado por outros comércios concorrentes aqui na região... e consegui atingir esse objetivo com o layout abaixo: A questão é que só consegui esse resultado na linguagem ZPLII (que possui mais opções de fontes que a PPLA) e o problema é que fui testar em uma Argox OS214 e simplesmente não imprime quando configuro o componente ACBrEQT com ZPLII. Tive sucesso na linha Elgin (L42 Pro Full e L42DT... A L42 Pro ainda falta testar). Na Argox OS-214 plus e Argox OS-2140 consta no manual que é suportado uma linguagem chamada PPLZ. Eu imaginei que essa linguagem fosse um sinônimo da ZPLII. O amigo @EliasCesar até havia comentado achar que fosse realmente a mesma coisa, pois ele disse que comparou rapidamente o manual que encontrou das duas linguagens (PPLZ e ZPLII) e possuiam os mesmos comandos. Mas infelizmente o fato é que não imprime na Argox OS214 quando coloco ZPLII. Alguém consegue me confirmar se a Argox OS214 e a OS2140 aceita ZPLII? Se sim, devo configurar alguma coisa na mesma pra ativar? Desde já agradeço a atenção de todos

Olá @EMBarbosa Tudo bom? Parece né?!?! Mas na verdade não é... Tanto que no ZPLII ele imprimi normal, como você pode constatar em fotos acima. A saída da função para maiúsculo está correta, mas ao imprimir no PPLA sai errado.

Opa Valeu pelo retorno aí @EliasCesar. Gostaria só de retificar o comentário que fiz sobre o PPLA: Na verdade "catuquei" um pouco mais e consegui resultados de outros estilos de fontes com o PPLA, conforme foto abaixo: Ainda sim, é bom frisar que tenho a impressão que no ZPLII a possibilidade de estilos de fontes é muito maior, visto que vai de 0 à 9 e de A a Z, enquanto no PPLA/PPLB vai só de 0 a 9. Estou certo??? Por fim, minha última dúvida é a seguinte: em todos os testes que fiz até o momento no PPLA, o "Ç" não sai do mesmo tamanho das demais letras. Tem como resolver isso ou é uma limitação da linguagem PPLA? Desde já agradeço a atenção de todos.

Rapaz... "catuquei" o parâmetro fonte do PPLA com diversos valores, em parceria com o Multiplicador H e Multiplicador V. O único resultado que obtive foi uma fonte maior e/ou mais larga, mas o estilo da fonte claramente fica o mesmo. Até o "Ç" zoado fica no PPLA, já no ZPLII não dá isso, conforme você pode observar nas fotos que postei. Fiquei com algumas dúvidas ainda, caso possa me ajudar: 1 - Eu não conheço a história dessas linguagens (PPLA/ PPLB/ ZPLII / etc), mas pelos resultados que obtive e até pelo vídeo que o @Daniel InfoCotidiano me recomendou acima (pois no mesmo é usado o ZPLII nos testes), a impressão que tenho é que o ZPLII tem muito mais possibilidades gráficas, estou certo? 2 - Qual a linguagem de impressão de etiquetas mais usada hoje? 3 - Hoje estou testando nessa Elgin L42 Pro FULL, caso teste em outra impressora que TAMBÉM suporte a linguagem ZPLII terei exatamente o mesmo resultado? 4 - Na Argox OS-214 plus e Argox OS-2140 consta no manual que é suportado a linguagem PPLZ. Que linguagem é essa? Seria um sinônimo da ZPLII? 5 - Normalmente as Software Houses usam esses comandos diretos para impressão nessas impressoras ou fazem o uso do driver de Spooler desenhando as mesmas direto no Fortes Report, FastReport, etc? E qual as vantagens e desvantagens entre essas duas abordagens? Desde já agradeço a atenção

Oi @Diego Foliene Blz? Então... O que eu reparei entre o PPLA e o ZPLII é essa questão de trocar o tipo de fonte só funciona efetivamente no segundo. Você mencionou duas vezes sobre testar outros tipos de fonte, mas no PPLA a fonte é sempre a mesma, o que muda conforme eu altero o parâmetro Fonte ('0' a '9') na função ImprimirTexto é apenas o tamanho do texto. Já no ZPLII, conforme eu mudo a Fonte('A' a 'Z') eu efetivamente tenho uma letra diferente. Com isso minha dúvida é: No PPLA o parâmetro fonte muda apenas o tamanho do texto, enquanto no ZPLII muda efetivamente o estilo da fonte? Seria isso?

PS: Até o Ç ficou melhor no ZPLII... No PPLA ele sai todo "zoado".

Aqui, consegui o efeito praticamente idêntico ao que eu queria: Somente com o ZPLII, mas pra ser sincero eu não entendi muito bem as diferenças entre as fontes (A a Z), hora ficava pequeno, hora ficava grande, hora tinha que usar os multiplicadores... Se alguém puder me dar uma luz de qual a lógica desses valores? O que eles efetivamente mudam no layout? Eu basicamente fui catucando até conseguir o que queria. Segue abaixo como ficou meu código: IniciarEtiqueta; ImprimirTexto(orNormal, 'S', 10, 10, 3 + pmsuperior, pmesquerda1, descricao, 0); ImprimirTexto(orNormal, 'C', 20, 20, 9 + pmsuperior, pmesquerda1, codigo, 0); ImprimirBarras(orNormal, barEAN13, 4, 4, 12 + pmsuperior, pmesquerda1, barras, 6, becNAO); ImprimirTexto(orNormal, 'T', 80, 80, 11 + pmsuperior, 35 + pmesquerda1, FormatFloat('R$ #,##0.00', precovenda)); FinalizarEtiquetaComCopiasEAvanco;

Fala meu amigo Vídeo show de bola... Reparei que tenho mais resultados variados usando o parâmetro Fonte do tipo String, mas reparei que esse parâmetro com o tipo String só funciona no ZPLII, correto? Aí no caso vai de A a Z... Qual a diferença? O A é menor e o Z maior? Fiquei perdido nisso!!! Estou realizando os testes pra descobrir na prática, mas qual seria a lógica nesse quesito?

Olá amigo... Tudo bom? Como eu altero a fonte? Na função ImprimirTexto vi que tem o parâmetro Fonte que creio que serve para alterar o tamanho da mesma, mas não achei como alterar a fonte conforme sua sugestão.