bnobre

1 Abril

Olá a todos,

Quem está acompanhando o tópico sabe que o assunto ficou em aberto desde Janeiro/2024.

Fazendo um breve resumo, a SEFAZ-RJ havia determinado a aplicação da Resolução Sefaz Nº 578 nos DF-e a partir de 01/01/2024. A data chegou e nenhuma crítica forçando o preenchimento das tags relacionadas a Resolução foi ativada, tanto em ambiente de homologação quanto em ambiente de produção. Então em teoria o preenchimento ficou obrigatório(dado a a existência da Resolução), mas tecnicamente opcional (pela falta de críticas do servidor).

Fiquei acompanhando o cenário, para ver se algum cliente iria aparecer recebendo algum tipo de sansão por parte da SEFAZ-RJ pela falta de preenchimento dessas tags, até que em 27/03/2024 o nosso amigo abre o seguinte tópico:

Eu não estava sabendo dessa prorrogação que ocorreu em 15/02/2024 pela Resolução Sefaz Nº 617 até ler o tópico acima, obrigado pelo aviso @Diego Foliene.

Mas, adivinha... Dia 01/04/2024 e novamente nenhuma crítica foi ativada obrigando o preenchimento dessas tags, tanto em ambiente de homologação quanto em ambiente de produção.

Então voltamos a estaca zero: em teoria o preenchimento ficou obrigatório(dado a a existência da resolução), mas tecnicamente opcional (pela falta de críticas do servidor).

Se alguém tiver alguma novidade sobre o assunto, favor postar.

11 Janeiro

Olá meu amigo,

Tudo bom?

Até onde sei, a obrigatoriedade do GTIN só existe nos documentos modelo 55 para operações de venda da indústria e alguns grupos de mercadorias específicos.

Então como seu cliente não produz, só tem que ficar de olho no NCM desse produtos importados para confirmar se encaixa nesse tal grupo de mercadorias específicas, se fizer parte dessa lista terá que especificar GTIN. Observar que o nosso amigo @Italo Giurizzato Junior divulgou em dezembro/2023 a ampliação desse grupo conforme segue abaixo:

Abraços

10 Janeiro

5 minutos atrás, LuanParanhos disse:

Eu me expressei errado! O que eu quero dizer é o seguinte: alguns contadores entraram em contato falando dessa situação; eu não sei se eles vão analisar esses arquivos XMLS para verificarem se estão com essas tags, acredito eu que não, deve acontecer algo mais parecido com o que você disse. Meu receio é esse... Os contadores receberem esses arquivos xmls e reclamarem que não estão com a TAG. Se acontecer de reclamarem, imagina, vários dias, centenas e centenas de notas emitidas sem essas informações... Não sei se me fiz entender, mas espero que sim!

Então @LuanParanhos, se os contadores ou os seus clientes (por orientação dos contadores dos mesmos) entraram em contato solicitando o preenchimento desses campos, informando inclusive como preencher (que foi uma das indagações que fiz ao longo do tópico) e o teu programa não tem como preencher, a responsabilidade será SUA. Aqui, até então, nenhum contador/cliente solicitou tal preenchimento.

Sobre analisar arquivo XML, o contador não faz isso, o processo é mais simples. Os programas contábeis que fazem essa tal análise, traduzindo as informações presentes no XML de forma que o contador possa fazer a Escrituração Fiscal do cliente da forma que ele achar devida. Nessa caso, se o contador te pediu e ensinou como preencher tais campos, mas o teu programa não preencheu, obviamente quando ele for fazer a Escrituração Fiscal do cliente esperando tais informações e não ver, vai dar falta.

Quero reforçar o que disse no último post de forma resumida, na minha visão não devemos orientar/sugerir o preenchimento de tais campos, isso é da competência contábil!!! ***Porém o programa tem que estar apto a receber tais campos caso o contador ou o cliente orientado pelo contador queira preencher.***

10 Janeiro

1 minuto atrás, LuanParanhos disse:

Meu receio é o seguinte: virou o mês, vem um monte de cliente reclamando que o sistema não estava usando de tais tags. Você quer dizer disponibilizar essas tags já de agora, ou só disponibilizar caso o cliente venha a pedir?

Meu caro,

Cliente nenhum vai reclamar para você que tag X ou Y não estava funcionando, comerciante usa o nosso sistema pra vender, ponto!

Até o momento não soube de nenhum cliente em que o contador tenha orientado o preenchimento desses campos e o que pode acontecer é no futuro o cliente sofrer alguma penalização por não ter preenchido tais campos. Supomos que o cliente leve uma multa (que é aí que ele grita o contador e o contador começa a se preocupar kkkkkkkkkkkkkk), o contador vai ter que entender e explicar o motivo dessa multa, como eu disse, ao meu ver é um problema contábil e não devemos nos meter nisso. É o contador que tem que dizer o que deve ou não ser preenchido.

Nós teremos responsabilidade SE E SOMENTE SE a partir do momento que o contador informar que devem ser preenchidos tais campos em nosso programa o mesmo não estiver apto pra isso.

Bem, essa é a minha visão da coisa, não sei quanto aos demais colegas.

10 Janeiro

Olá a todos,

Resolvi seguir a dica do amigo @Diego Foliene e perguntei direto para a SEFAZ-RJ. Segue a resposta:

Citar

Prezado(a),

deve ser observada a obrigatoriedade da Resolução 578/2023, ainda que não haja rejeição técnica na validação do documentos fiscal.

Sobre as penalidades, a dúvida deve ser encaminhada para o setor de legislação.

ATENÇÃO! A informação prestada tem caráter de orientação e não possui os efeitos próprios da consulta formal, prevista nos artigos 150 a 165 do Decreto Estadual n° 2.473/79.

Atenciosamente,

Coordenadoria de Documentos e Declarações Fiscais (CDDF/SUCIEF)
Subsecretaria de Estado da Receita
Secretaria de Estado de Fazenda do Estado do Rio de Janeiro

Agora ao meu ver cabe uma importante ressalva sobre essa situação. Apesar de sabermos que os campos devem ser preenchidos, ao meu ver, nós como Software House, não devemos comunicar isso aos nossos clientes, pois estaríamos abrindo um precedente perigoso.

Isso é uma orientação contábil que terá consequências contábeis e portanto deve vir da contabilidade. Cabe a nós, no entanto, disponibilizarmos em nossos programas a possibilidade de envio de tais informações quando assim quiser e orientar a contabilidade do cliente.

10 Janeiro

1 minuto atrás, Antonio Carlos L disse:

Creio que você esteja se referindo a essas questões :

1 - Então o vBCEfetivo seria simplesmente igual ao vProd?!?! Se sim estou fazendo errado, pois estou usando a seguinte fórmula para obter o vBCEfetivo: vProd * (1 - (pRedBCEfet / 100))

2 - O pICMSEfet é simplesmente o pICMS + pFCP?!?! Se sim vai ser uma maravilha, pois será um valor único para todos os produtos!!! Alguém aí pode confirmar quais seriam os percentuais do pICMS e pFCP usado no Rio?!?!?

Se você ler em um post anterior a esse seu, eu disse : " ... Sobre o vBcEfetivo. Imagina que é uma operação tributada normalmente ( mesmo do simples ) a vBcEfetivo é o valor do produto. E o percentual pela regra do RJ é o percentual de ICMS do estado acrescido do percentual do FCP." O MARCO POLO fala exatamente disso no vídeo e ainda tece criticas ao infame "SERIA".

Mas você quer algo mais explicito : vBCEfet é o valor do produto, pICMSEfet é o valor do ICMS normal + FPC, e vICMSEfet é (vBCEfe x pICMSEfet )

Obrigado meu amigo, eu tinha lido sim, mas você captou bem que eu queria algo mais específico kkkkkkkkkkkkkkkkkkkkkkk

Mas eu acho, até pelo próprio vídeo que você mencionou, que o vBcEfetivo não é simplesmente igual ao vProd, creio que deve ser considerado o pRedBCEfet na fórmula, obviamente quando o pRedBCEfet for igual a 0, o vBcEfetivo será simplesmente igual ao vProd.

10 Janeiro

2 minutos atrás, Antonio Carlos L disse:

Caro @bnobre voltei ontem do recesso. Creio que essa explicação do cara que é contador va dirimir suas dúvidas.

Olá meu amigo,

Tudo bom?!?!

Ajudou a confirmar algumas interpretações sim, mas as duas questões acima em particular não. Como você está fazendo em relação a elas?!?!

9 Janeiro

1 minuto atrás, LuanParanhos disse:

Boa pergunta! Bem, obrigando não está pois como você mesmo disse, está passando sem essas TAGS! Um contador de um cliente me cobrou dia 02/01 eu respondi dizendo que o sefaz não está criticando essa informação, o que aparenta que não entrou em produção. Ele ao menos não disse mais nada.

Olá meu amigo,

Só toma cuidado ao dizer que não está obrigando.

Pois tecnicamente existe a resolução 578 e ela é clara no que tange a obrigação do preenchimento, independente dos servidores estarem ou não criticando.

Mas vamos continuar acompanhando, agradeço os comentários de todos e da minha parte qualquer novidade lanço aqui.

9 Janeiro

10 minutos atrás, olinad1993 disse:

Boa Tarde!

MarcoPolo do SAC Fiscal acabou de soltar um vídeo explicando um pouco essa resolução. Vale a pena conferir.

Boa tarde,

Obrigado pela dica @olinad1993

Mas a grande questão ainda está em aberto: A SEFAZ-RJ está obrigando ou não o envio dessas informações?!?!

Parece uma resposta simples, todos diriam NÃO, já que os documentos estão passando sem essas tags. Mas será que futuramente nossos clientes não terão problemas junto a SEFAZ-RJ pelo fato de não estarem preenchendo?!?!

5 Janeiro

Olá a todos,

Achei um tópico, ironicamente meu, de anos atrás onde os amigos já me elucidaram tal mistério:

Abraços a todos

5 Janeiro

Bom dia a todos,

Estou com um erro bem inusitado aqui e de fácil reprodução. Estou usando o Delphi 11.2.

Se os colegas criarem um simples executável, adicionarem um botão e acrescentar o seguinte código abaixo:

procedure TForm1.Button1Click(Sender: TObject);
var
  valorDouble: Double;
  valorCurrency: Currency;
begin
  valorDouble := 123.99;
  valorCurrency := 123.99;
  if 123.99 > valorDouble then
    ShowMessage(FloatToStr(123.99 - valorDouble));
  if 123.99 > valorCurrency then
    ShowMessage(FloatToStr(123.99 - valorCurrency));
end;

Irão ter o comportamento que está me enlouquecendo. kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

Simplesmente na primeira condição, onde uso a variável do tipo Double, o compilador afirma que 123.99 é maior que valorDouble, que em teoria é 123.99.

Se usar a variável do tipo Currency funciona normal.

Já li em alguns tópicos sobre o assunto, dizem que é algo sobre precisão, mas não entendi direito. Para entender melhor tentei extrair o conteúdo da variável valorDouble para visualizar essa tal diferença de precisão, pra mim sempre é exibido que a variável tem o valor 123.99, aí fico perdido ao tentar entender porque somente na subtração o valor é diferente de 123.99, menor, consequentemente entrando na condição acima.

Alguém saberia explicar o porque desse comportamento?

Desde já agradeço a atenção de todos

3 Janeiro

8 minutos atrás, DevCriare disse:

Boa tarde á Todos.

@bnobre, voce conseguiu alguma informação clara quanto ao Calculo da tag vBCEfet?

Nas pesquisas por aqui, e também com contadores do RJ, me informaram que deve ser sobre o Valor Bruto do produto, ou seja, (QTD X UNITARIO) - %pReDBCEfet.

è isso mesmo pessoal?
Obrigado á todos.

Boa tarde meu amigo,

Uma resposta clara não, mas em todas as pesquisas que fiz na internet achei a mesma fórmula e é essa que estou usando:

vBCEfetivo = vProd * (1 - (pRedBCEfet / 100))

Creio que é a mesma que você sugeriu, pois o Valor Bruto do produto é informado em vProd.

2 Janeiro

Bom dia senhoras e senhores,

Como todos puderam notar o dia se iniciou sem gritos e desesperos por parte dos clientes aqui no RJ. kkkkkkkkkkkkkkkkkkkkkkk

O preenchimento dos campos das regras 16E e 16F citadas acima não está sendo obrigatório em ambiente de produção, os documentos fiscais estão autorizando sem problemas independente do preenchimento dos mesmos. Alguém sabe porque e até quando vai ficar assim???

PS: Até o presente momento, em ambiente de homologação o preenchimento de tais campos também não está sendo obrigatório.

30 Dezembro, 2023

4 minutos atrás, Antonio Carlos L disse:

Bom dia @bnobre estou no recesso mas vou tentar te ajudar.

Algo que pode não ser claro para programadores é algo juridicamente chamando de Responsabilidade Solidária.

A não ser que o programador seja contador essas questões tributárias não devem sair de nosso entendimento, sempre devemos buscar o auxílio de um profissional qualificado da área.

Contador que manda o cliente resolver com o "cara da nota" não adianta.

Por isso pela total falta de resposta de contadores, eu busquei a consultoria do SAC FISCAL e recomendo. Pelo risco de você se ver arrolado em um processo o custo é irrisório.

Com base nos que me foi passado:

A regra se aplica a produtos com ST ou que tenham CEST portanto variam os valores.

Para você saber preencher a 16E você precisa saber como é calculada a ST pois é desta conta que sai às informações. TODAS as informações saem deste cálculo inclusive o vIcmsSubstituido

Sobre o vBcEfetivo. Imagina que é uma operação tributada normalmente ( mesmo do simples ) a vBcEfetivo é o valor do produto. E o percentual pela regra do RJ é o percentual de ICMS do estado acrescido do percentual do FCP.

Espero ter te ajudado.

Abraço feliz ano novo.

Fala meu amigo, tudo bom?!?!

Obrigado por interromper o seu recesso e nos ajudar.

1 - Então o vBCEfetivo seria simplesmente igual ao vProd?!?! Se sim estou fazendo errado, pois estou usando a seguinte fórmula para obter o vBCEfetivo: vProd * (1 - (pRedBCEfet / 100))

2 - O pICMSEfet é simplesmente o pICMS + pFCP?!?! Se sim vai ser uma maravilha, pois será um valor único para todos os produtos!!! Alguém aí pode confirmar quais seriam os percentuais do pICMS e pFCP usado no Rio?!?!?

Feliz ano novo @Antonio Carlos L

29 Dezembro, 2023

Boa tarde meu amigo,

Tudo bom?

Tenho as seguintes dúvidas sobre o preenchimento das tags. Será que você poderia me ajudar?

1 - Qual fórmula está usando para calcular o vBCEfet???

2 - Para atender a regra 16E, deverá ser preenchido os campos vBCSTRet (N26), vICMS-Substituto (N26b) e vICMSSTRet (N27). Quais valores você está colocando nesses campos?!?! E tais valores são os mesmos para todos os produtos (o que seria o melhor dos cenários) ou depende?!?! Se depende, depende do que?!?!?

3 - Para atender a regra 16F, deverá ser preenchido os campos vBCEfet (N35), pICMSEfet (N36) e vICMSEfet (N37).. Quais valores você está colocando nos campos pICMSEfet (N36) e vICMSEfet (N37)?!?! E tais valores são os mesmos para todos os produtos (o que seria o melhor dos cenários) ou depende?!?! Se depende, depende do que?!?!?

Desde já agradeço a sua atenção

27 Dezembro, 2023

58 minutos atrás, IFSOFT disse:

16E - Todo o produto com CST/CSOSN referente a ST vendido através de NF-e para contribuinte de ICMS deverá preencher os campos vBCSTRet (N26), vICMS-Substituto (N26b) e vICMSSTRet (N27).

16F - Todo o produto com CST/CSOSN referente a ST vendido através de NF-e marcada para Consumidor Final e NFC-e deverá preencher os campos vBCEfet (N35), pICMSEfet (N36) e vICMSEfet (N37).

Foi o meu entendimento também. No caso a NFC-e entrará no 16F, visto que é venda para consumidor final. Ou seja, a NFC-e quando estiver usando CSOSN ou CST referente a ST, vai entrar o ICMS Efetivo.

Quanto a 16E que fiquei na dúvida, mas no caso quando for contribuinte de ICMS automaticamente vai passar a ser o ICMS Retido. vBCSTRet (N26), vICMS-Substituto (N26b) e vICMSSTRet (N27).

Lembrando só que as regras 16E e 16F podem ocorrer simultaneamente em um mesmo documento fiscal.

Aí vai ter que preencher essa galera toda: vBCSTRet (N26), vICMS-Substituto (N26b), vICMSSTRet (N27), vBCEfet (N35), pICMSEfet (N36) e vICMSEfet (N37).

27 Dezembro, 2023

12 minutos atrás, LuanParanhos disse:

O problema não é o Sefaz colocar algo em funcionamento, implementar algo, o problema é a falta de informação, a complicação que é passar as informações de maneira clara e objetiva para os desenvolvedores poderem trabalhar. Quando faz a consulta com o contador, o mesmo nem sabe da existência disso.

Sobre a parte da contabilidade não só concordo como foi o que citei anteriormente, mas sobre a SEFAZ-RJ achei falta de tato deles implementar uma mudança em pleno feriado, independente da mudança em si, pois o cliente que tiver problemas nesse dia não terá como pedir ajuda nem para a Software House e nem para o contador.

27 Dezembro, 2023

38 minutos atrás, LuanParanhos disse:

Honestamente, li e reli, ainda não entendi essa situação, na mesma dúvida que você mencionou.

Olá meu caro amigo... Blz?

O que você tem que entender é o seguinte: Se isso continuar, dia 01/01/2024 vai ser o caos.

Imagina o cenário, mesmo você preparando o sistema para receber esses novos campos, você resolveu parte do problema. A segunda parte é preencher esses campos. Aí entram algumas questões, tais como:

Agora com quais valores eles serão preenchidos?!?!
Será o mesmo valor pra todos os produtos (cenário bom) ou cada produto terá um valor diferente (cenário problemático e demorado para o cliente preencher)?!?!?!?
Qual cálculo aplicar no vBCEfet?!?!

E os contadores que consultei nem fazem idéia do que se trata o assunto!!!

Se no dia 01/01/2024 continuar essa validação aí, todo mundo que emitir, por exemplo, NFC-e, ao constar um produto de CST/CSOSN referente a ST e tais campos não estiverem preenchidos SIMPLESMENTE vai dar erro.

Não sei se você estará disponível nesse dia para ajudar seus clientes (pois alguém na SEFAZ-RJ teve a brilhante ideia de ativar essa validação em um feriado MUNDIAL), do contrário se fosse você já iria avisando eles sobre essa possível (pois a SEFAZ-RJ tem um histórico de voltar atrás nos 45 minutos do segundo tempo) situação.

8 Dezembro, 2023

2 horas atrás, Daniel InfoCotidiano disse:

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

@bnobre
Acredito que o ideal é o sr Consultar o contador da empresa para evitar problemas de preenchimento incorreto por uma interpretação equivocada.
Entendi o mesmo, mas nada como consultar o profissional que foi formado para isso.

Olá @Daniel InfoCotidiano, tudo bom?

Sabemos que esse seria o cenário ideal, mas ao mesmo tempo sabemos que a realidade é bem diferente.

Não sei nos outros estados, mas aqui no RJ a grande maioria dos contadores não estão preparados e nem atualizados em relação as mudanças fiscais e nós, empresas de desenvolvimento, no final das contas acabamos incorporando essa expertise, visto que é em nosso sistema que o ERRO vai aparecer impedindo a venda de ser realizada, portanto é nosso suporte que acaba sendo acionado.

O passo seguinte é informar ao cliente para entrar em contato com o contador, que vai empurrar o problema e será uma bola de neve. Acho que vários dos amigos passaram, passam e passaram por isso, infelizmente. Creio que é uma dor nossa, empresas de desenvolvimento.

Então na falta de um cenário ideal, a minha única alternativa, assim como creio para maioria de nós, acaba sendo acionar os amigos do fórum.

Obrigado @Daniel InfoCotidiano por confirmar que o seu entendimento foi o mesmo que o meu. Peço a todos que puderem que colaborem com informações sobre o tema e confirmem o entendimento que tiveram dessa resolução. Quanto a mim, estarei noticiando vocês aqui das novidades que descobrir a respeito.

PS: Nenhum contador contatado por mim até o presente momento tem noção dessa resolução e ninguém conseguiu me informar uma fonte oficial que indicasse o cálculo a ser usado no vBCEfet.

7 Dezembro, 2023

Bom dia a todos,

Em Abril/2023, a SEFAZ-RJ tento ativar o uso desses campos, mas acabaram desistindo em Junho/2023.

Mas parece que agora voltaram com isso e vão ativar daqui há um mês.

Só não sei se entendi muito bem os artigos em questão.

Segue meu entendimento:

16E - Todo o produto com CST/CSOSN referente a ST vendido através de NF-e para contribuinte de ICMS deverá preencher os campos vBCSTRet (N26), vICMS-Substituto (N26b) e vICMSSTRet (N27).

16F - Todo o produto com CST/CSOSN referente a ST vendido através de NF-e marcada para Consumidor Final e NFC-e deverá preencher os campos vBCEfet (N35), pICMSEfet (N36) e vICMSEfet (N37).

Vocês concordam?!?!

Desde já agradeço a atenção de todos

2 Outubro, 2023

Olá a todos,

Sei que o tópico abaixo está concentrando todas as questões sobre soluções alternativas para o ACBrConsultaCNPJ:

Minha dúvida é: Nessa altura do campeonato, o ACBr pretende manter o componente ACBrConsultaCNPJ?

Desde já agradeço a atenção

12 Agosto, 2023

Olá a todos,

Eu precisei modelar uma tabela hoje e reparei em um comportamento que até então nunca tinha percebido no MySQL, até pelo fato de raramente usar índices compostos, pra ser sincero nunca. kkkkkkkkkkkkkkkkkk

No MySQL, sempre que criou um campo FK, automaticamente o banco cria também um índice do tipo KEY associado a esse campo FK, inclusive se eu tentar apagar esse índice do tipo KEY criado automaticamente recebo um erro do MySQL, portanto ele é obrigatório existe para toda a FK. Acho que até aí não é novidade para ninguém.

Só que hoje eu precisei criar um índice composto do tipo UNIQUE na seguinte estrutura abaixo:

O primeiro campo eu deixei como chave primária e autoincrement, como rege a boa prática, pois com uma chave primária simples facilito relacionamentos futuros (além de outros benefícios) e consigo o mesmo efeito da chave composta com um índice do tipo UNIQUE.

O segundo e terceiro campos (destacados em amarelo) são respectivamente FKs para a tabela "tbl_produtos" e "tbl_tabelaprecos" que possuo em meu banco de dados. Portanto como explicitado no início do tópico o MySQL criou também índices do tipo KEY associado aos mesmos que inclusive não podem sem excluídos... Até aí tudo certo.

Porém eu preciso criar a chave composta do tipo UNIQUE com esses campos, e deu certo, mas o que me intrigou e fez eu abrir esse tópico é que ao criar com esses campos uma chave composta do tipo UNIQUE o MySQL apagou a chave do tipo KEY associada ao campo id_produtos. Manteve só a do outro (id_tabelaprecos). Porque??????

Interessante que ao criar a chave composta do tipo UNIQUE, se eu alterar a ordem dos campos na chave, o MySQL também altera o campo do tipo KEY que ele apaga, por exemplo:

O comando usado foi esse:

Citar

UNIQUE INDEX `id_produtos_id_tabelaprecos` (`id_produtos`, `id_tabelaprecos`) -> id_produtos vem primeiro

Mas se eu usar:

Citar

UNIQUE INDEX `id_produtos_id_tabelaprecos` (`id_tabelaprecos`, `id_produtos`) -> id_tabelaprecos vem primeiro

Nesse caso ele apaga o índice do tipo KEY associado a FK id_tabelaprecos.

O mesmo comportamento se dá na criação de PKs compostas usando campos FKs, já testei.

Tentei pesquisar na internet o porque dessa comportamento do MySQL, mas não achei nada. Alguém saberia me explicar?

Desde já agradeço a atenção

9 Julho, 2023

Boa noite pessoal...

Parece que abortaram em definitivo a ativação das regras 906 e 938 aqui no estado do RJ (PORTARIA SUCIEF Nº 137 DE 04 DE JULHO DE 2023).

http://www.fazenda.rj.gov.br/sefaz/faces/menu_structure/legislacao/legislacao-estadual-navigation/coluna2/menu_legislacao_resolucoes/Resolucoes-Tributaria?_afrLoop=108008881159018309&datasource=UCMServer%23dDocName%3AWCC42000046232&_adf.ctrl-state=7qta60h6b_59

Na leitura de vocês da portaria acima, vocês confirmam essa minha afirmação?

Desde já agradeço a atenção de todos

PS: Toda essa correria pra atualizar nos clientes e no final das contas eles voltam atrás. Putz... Pelo menos dessa vez não foram nos 45 do segundo tempo!!!

18 Junho, 2023

Oi @EdmarFrazao

Tudo bom?

Citar

Ou adicionar um timer com atraso de 2seg

Sim, coloquei um atraso de 5seg, nada!

Citar

outra opção RestauraFoco @Rafael L. Costa

Pra garantir que não tinha nenhum código atrapalhando, executei o RestauraFoco em um timer depois de 10s, mas nada. O ícone da aplicação até pisca na barra de tarefas, mas ela fica escondida das demais.

Mistério isso!!!

18 Junho, 2023

Bom dia meu amigo @Renato Rubinho

A luta continua kkkkkkkkkkkkkkkkk

Citar

Primeiro de tudo, se você tem alguma rotina rodando direto no create ou no onShow, pode ser por isso que não traz a aplicação para frente, para teste, coloque em um timer ou no final do OnActivate.

Pensei ser isso também... Aí coloquei um Timer com 5 segundos só por garantia e executei os comandos Application.BringToFront e o Application.ProcessMessages... Nada!!!

Citar

1. Realmente no link da devmedia não li direito e achei que fosse o mesmo por ele ter citado outro exe, em todo caso, como ele faz uma abordagem diferente, teste para ver se eventualmente traz sua segunda aplicação para frente.

Como já estava sem opção tentei a tal abordagem. E acontece um comportamento interessante, mas que infelizmente não atende a minha necessidade... Trouxe a aplicação para a frente, mas em primeiro lugar sem o foco estar nela, aí o usuário tem que clicar na mesma pra poder escrever... Mas até aí tudo bem, pois eu só queria que ele visse que está aberta. O problema é que ela fica na frente SEMPRE kkkkkkkkkkkkkkkkkkkkkkkk Só preciso que ela fique na frente quando abrir para o usuário ver que ela está aberta e não abrir a toa novamente, se ficar sempre na frente vai atrapalhar o usuário usar o computador.

Citar

2. Outro teste, na sua aplicação 2, no início do OnActivate, coloque este código e veja se a cada 5 segundos ela vai para frente das demais.

Nada também... Não sei qual o mistério, porque o Application.BringToFront não funciona, de acordo com a documentação a finalidade dele é simplesmente trazer a aplicação para a frente das demais, conforme eu preciso: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Forms.TApplication.BringToFront

Entrar

Sobre nós...

Blocks

Notes ACBrLibNFe

Fóruns

Downloads

Calendário

Posts postados por bnobre

Sobre nós...

Informação Importante