bnobre

Também achei que fosse dinâmico, mas na verdade foi vendo o vídeo que você me recomendou que fiquei mais ainda com essa dúvida. Durante o vídeo vocês informam que é possível gerar um QRCode Estático com valores diferentes... Então fiquei pensando: Será que é isso que a maquininha POS faz isso?!?! Pois se posso informar o valor, então tecnicamente é possível a maquininha fazer isso. E como ela não está integrada ao meu sistema, ela não está associada a venda DO meu sistema. Como agora em 01/07/2024 teremos duas categorias de PIX em produção, não tenho pra onde correr, tenho que me decidir. A princípio vou escolher a 17 - Dinâmica, pois creio que a maquininha deve usar nesse formato para facilitar os relatórios internos da mesma.

Então pessoal, Após pesquisas, descobri que esse erro é devido a regra YA04-10 que está para entrar em vigor nos ambientes de Produção, de maneira FACULTATIVA, em 01/07/2024. Para mais detalhes ver NT 2023.004.v1.11. Realmente meu programa não está gerando o grupo cartões para PIX. Só tem um porém: Se repararem nesse tópico, caso eu não tenha entendido errado, o amigo @Fabrício G. Araújo sugere que algumas UFs que ativaram essa regra em homologação não devem manter a mesma em produção. E aí... Entendi corretamente??? O que acham?!?! Desde já agradeço a atenção de todos

Olá @Daniel Simoes Tudo bom com você?!? Excelente vídeo, mas na verdade ainda estou com uma dúvida... O PIX das maquininhas TEF e POS geram o QR-Code dinâmico ou o estático?!?! Desde já agradeço a atenção

Olá a todos, No Informe Técnico 2024.002 - v.1.01 - Publicado em 07/06/2024 foi incluído o item 20: “Pagamento Instantâneo (PIX) – Estático” e alterado o item 17 para acrescentar a palavra “Dinâmico”. De acordo com o texto, o objetivo é separar o os pagamentos de PIX com o “QR-Code Dinâmico” do tipo “QR-Code Estático”. Isso me gerou três dúvidas: 1º - Em quais casos é usado um ou outro?!?! 2º - Qual é o usado nas máquinas POS? 3º - Qual é o usado nas máquinas TEF? Desde já agradeço a atenção de todos

PS: Essa rejeição ocorre somente no NFC-e... Em NF-e está passando.

Olá a todos, Aqui no RJ, em ambiente de homologação, ao tentar finalizar o pagamento com o código tpag = 17, recebo a seguinte rejeição: Rejeicao: Nao informados os dados do cartao de credito/debito nas Formas de Pagamento da Nota Fiscal Ao usar o tpag = 20 funciona. Na Tabela de Meios de Pagamento - Vigente a partir de 01/07/2024 - Publicada em 07/06/2024 no Portal da NFe, consta o seguinte: 1ª dúvida - Será devido a essa exigência que estamos estamos recebendo essa rejeição?!?! 2ª dúvida - Se sim, então dia 01/07/2024 começará a criticar em produção também?!?! 3º dúvida - Nos clientes com PIX em máquinas POS, devo usar o 20?!?! Desde já agradeço a atenção de todos

Olá meu amigo... Obrigado pela lembrança em postar sua resolução aqui no fórum de um problema que aconteceu em 2022 com a gente, isso é de extrema importância. Vou encerrar o tópico finalmente como resolvido! Ao longo desse tempo todo e desde que trabalho com os componentes do ACBr, só tive esse caso com esse cliente, mas acontecendo novamente tentarei sua dica. Abraços

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.

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

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.***

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.

Olá a todos, Resolvi seguir a dica do amigo @Diego Foliene e perguntei direto para a SEFAZ-RJ. Segue a resposta: 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.

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.

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?!?!

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.

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?!?!

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

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

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.

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.

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

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

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).

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.

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.