Ir para conteúdo
  • Cadastre-se

bnobre

Membros Pro
  • Total de ítens

    1.458
  • Registro em

  • Última visita

  • Days Won

    4

Tudo que bnobre postou

  1. 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
  2. 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.***
  3. 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.
  4. 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.
  5. 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.
  6. 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?!?!
  7. 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.
  8. 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?!?!
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. 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
  15. 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).
  16. 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.
  17. 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.
  18. 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.
  19. 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
  20. 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
  21. 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: Mas se eu usar: 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
  22. 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!!!
  23. Oi @EdmarFrazao Tudo bom? Sim, coloquei um atraso de 5seg, nada! 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!!!
  24. Bom dia meu amigo @Renato Rubinho A luta continua kkkkkkkkkkkkkkkkk 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!!! 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. 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
  25. Então no meu caso não irá servir, o cenário aqui é outro, não são forms diferentes de uma mesma aplicação, são aplicações diferentes... Para ficar um exemplo mais claro, eu tenho a aplicacao1.exe e aplicacao2.exe. Estou com a janela do Meu Computador aberta onde localizo e executo a aplicacao1.exe, essa por sua vez dá um ShellExecute chamando a aplicacao2.exe e depois se fecha, pois quero somente rodando a aplicacao2.exe. A aplicacao2.exe abre, mas fica ESCONDIDA atrás da janela do Meu Computador. Preciso que ela fique na frente dos outros programas ao abrir, não precisa ficar em definitivo, mas só ao abrir, para o usuário ver que carregou. Depois o mesmo pode minizar, fechar, fazer o que quiser com esse programa. Valeu, é praticamente o que eu já achava que fazia, mas a documentação é sempre importante pra definir com certeza. Então foi onde testei, mas não funcionou. Mas não creio que nesse cenário o ProcessMessages seria útil, pois são 2 aplicações diferentes e a segunda se ESCONDE ao ser chamada. Ela é chamada, mas não fica na frente... O ProcessMessages é para quando a aplicação não responde e visualmente parece que travou... Correto? Se sim não teria nem problema a segunda aplicação travar, contanto que ela travasse aparecendo na frente de todos os outros programas... Esse é o problema, ela fica escondida atrás dos demais programas e o cliente não percebe que ela abriu kkkkkkkkkkkkkkkkk Legal, mas não funcionou... Mas ao ler a documentação já imaginei que não funcionaria, pois diz basicamente que restaura os formulários para fsStayOnTop. Mas meu cenário não são formulários de uma mesma aplicação se escondendo conforme expliquei no início desse post. Então meu amigo, peço até desculpas pois eu acho que não me expressei bem sobre o cenário aqui. Pelo que li nesse tópico entra novamente de um único sistema com várias janelas no mesmo, onde se quer uma na frente, pois o autor diz: "eu estou desenvolvendo um sistema baseado em duas janelas, uma principal onde relaciono uma lista de canais e outra em paralelo, onde o video ou a estação de rádio é transmitida." Aqui o problema é diferente, é como o exemplo que dei da aplicacao1.exe e aplicacao2.exe no início. Estou com a janela do Meu Computador aberta onde localizo e executo a aplicacao1.exe, essa por sua vez dá um ShellExecute chamando a aplicacao2.exe e depois se fecha, pois quero somente rodando a aplicacao2.exe. A aplicacao2.exe abre, mas fica ESCONDIDA atrás da janela do Meu Computador. Aí o cliente acha que a aplicacao2.exe não abriu e vai lá abrir ela dinovo manualmente. Mas só por curiosidade testei e não funcionou. Mas novamente no final ele está setando como fsStayOnTop, que é relacionado a controle de forms na mesma aplicação. O cenário dele é diferente.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.