Isaque Pinheiro

Se quiser que saia a tempo da exigência que será nessa semana seguinte, é melhor colocar a mão na massa e resolver esse problema, e dai se quiser compartilhe com a comunidade, pois os responsáveis pelo componente de CTe trabalham em atender as exigências da Lei, mas ajustes para todos os geradores de relatórios não, para isso contamos com a colaboração de todos que usam.

Prezados usuários, depois de vários estudos e analise, chequei a uma conclusão que, para o projeto ACBr viesse a poder ser totalmente convertido de forma satisfatória para que o mesmo pudesse ser usado na tecnologia firemonkey, precisaríamos de uma reformulação ampla, tendo outra Unit.pas para cada unit existente hoje com as iniciais FMX.Unit.pas, dessa forma levei isso aos adms do projeto o qual foi avaliado que não é o momento de tal esforço, dessa forma lamento informar que essa força será suspensa nesse momento. os fontes do que foi convertido permanecerá em anexo ao post acima, dessa forma que precisar analisar e tiver a necessidade de algo do tipo no momento já terá algo começado, só precisando de melhorias. De minha parte lamento.

Atualize seus fontes.

No Sábado na parte da manhã, estarei subindo a versão oficial para o CTe 2.0

Retornei o código anterior ao que subi ontem, era par voltar ao normal, se não voltou não sei falar o que possa ser, sem contar que no Sped Contribuição não houve nenhuma mudança, o que fiz foi add uma nova função LFill() com parâmetro do tipo Variant, o que removi hoje e subi no ACBrTXTClass.pas

Pessoal gostaria de fazer uma tentativa de parar de usar os eventos para tal finalidade, pretendo aplicar as mudanças nos registros C481 e C485 para teste e qual será a mudança? 1o Vou mudar os tipos dos campos para Variant VL_BC_PIS: Variant; ALIQ_PIS: Variant; QUANT_BC_PIS: Variant; ALIQ_PIS_QUANT: Variant; VL_PIS: Variant; 2o Vou mudar as funções LFill() para VLFill() Pretendemos com essa mudança, da a vocês a dinâmica de alimentar o campo como lhe for conveniente dependendo da necessidade do momento, ela irá proporcionar a vocês o controle do que deve ir nos campos como exemplo abaixo: wite C481 do begin VL_BC_PIS := 0; ALIQ_PIS := 0; QUANT_BC_PIS := 0; ALIQ_PIS_QUANT := 0; VL_PIS := 0; end; OU wite C481 do begin VL_BC_PIS := 10,00; ALIQ_PIS := 10,00; QUANT_BC_PIS := 10,00; ALIQ_PIS_QUANT := 10,00; VL_PIS := 10,00; end; OU wite C481 do begin VL_BC_PIS := Null; ALIQ_PIS := Null; QUANT_BC_PIS := Null; ALIQ_PIS_QUANT := Null; VL_PIS := Null; end; Gostaria de saber a opinião de vocês, em seguida irei anexar a unit aqui, para testes antes.

Faça a atualização novamente e verifique, acabei de subir algo.

Sei que foi uma opinião e acatamos quando enxergamos fundamentos para a mesma, por isso gostaria que fizesse um teste e me relatasse se voltou ao normal, pois voltei a versão anterior.

Carlos, voltei a versão anterior, vamos tentar fazer a mudança gradativamente, tentando atender sua solicitação de cautela nas implementações. 1o - As funções que recebe o tipo Variant vão ter uma letra V antes do no ficando assim VDFill() e VLFill() 2o - Todos os campos voltaram a ter os tipos anteriores, Currency e Double, só vamos mudando os tipo para Variant os campos que precisarem de ter valor NULL e junto add a letra V antes do nome da função para que não haja risco ambiguidade.

Não a versão que esta com CTe 2.0 é a versão teste do link que disponibilizei acima, ela foi gerada com o mesmo fonte que irá subir nesse final de semana, dessa forma se quiser testar CTe 2.0, baixe a versão teste do link.

Novamente, não que criticar o senhor ou o Sr. Isaque só verificar a possibilidade de usar este critério durante as implementações. Carlos, sempre tentamos o máximo, fazer implementações da qual sofra o menor impacto possível, e se possível impacto ZERO. Já sofremos com esses problemas a um bom tempo, fizemos várias tentativas e nenhuma foi a contento de todos por não resolver 100% a situação. Essa ultima mudança foi analisar juntamente com outros administradores, e chegamos a conclusão de que para atender a todas situações que apareceram e podem aparecer, a melhor opção seria a mudança do tipo para Variant, sendo que essa mudança não afetaria o código já existente dos usuário que usam. Além disso fiz um comunicado no fórum disponibilizando em anexo os fontes antes de subir, sabe quantos baixaram e testaram para sabermos ser teríamos alguma divergência? Nenhum. Eu também uso os componentes em meus clientes, antes de subir testei em produção em um de meus maiores clientes, e não vi divergência. Agora você atualizou os fontes pelo jeito, deve algum problema? Nos reporte vamos analisar, e se virmos que é de tal importância, além da mudança que foi feita para resolver N problemas relatados, e que nosso usuário ficavam de mãos amarradas, pois o componente tava engessado, não os deixando alimentar valores, zero ou vazio em cada situação que aparecia, analisaremos a volta da versão anterior. Estamos aqui para ouvir a todos. Só para constar as implementações foram feitas somente no SPED Fiscal, Contribuição não foi mexido em nada, por acaso ta dando conflito com a função LFIll() ? Se tiver reporte.

Se existe a necessidade de que em alguns casos o valor seja gerado com ZERO e não VAZIO, que fique por conta do implementador, no momento de alimentar os campos(usando o novo método LFILL com variant). Só para constar, esta pequena alteração me causou e esta causando muita dor de cabeça. Carlos você não foi bem claro aqui, o que quer dizer? Que o componente fique da forma que tava e que caca usuário se vira em usar o novo método ?

O CSOSN da direito a crédito e com cobrança de ICMS ST alimente as tags: <pCredSN>0.00</pCredSN> - Aqui não é 18% é o % que a empresa pode dar de crédito, veja com o contador <vCredICMSSN>0.00</vCredICMSSN> - aqui é o valor do crédito A Base de ICMS deve ser calculada para você achar a base de ICMS ST e calcular o valor do ICMS ST, mas a base e o valor de ICMS não deve ser informada.

Paulo, deixa eu entender, a empresa emitente da NF está enquadrada no simples nacional, e quer emitir uma NF para outra empresa destacando ICMSST, por algum motivo talvez uma devolução de mercadoria é isso ?

Comente esse campos, eles estão sem uso por enquanto.

pode ser a versão dessa DLL, pegue a que tem no dir do ACBr e leve para o System32

Não, agora vc testou assinar outro arquivo? Pois para que colocou o TXT em anexo ? Seu problema deve ta com a rotina de assinar não no arquivo.

O sintegra não permite mandar intervalo menor dentro do mês, ou seja a Data Inicial TEM que ser 01/??/???? e a data final tem que ser o último dia do mês no registro 10, mesmo que a movimentação seja só de dois dias.

Vimos comunicar aos usuários ACBr que estamos trabalhando para sempre trazer melhorias ao Projeto e por consequência a nossos usuário, este post tem por finalidade informar que além das novas versões de NF-e, CT-e, lançamento de SAT-e, NFC-e ,estamos trabalhando para que o projeto ACBr possa ser utilizado na plataforma Firemonkey, no 1o momento não vamos nos preocupar com multi-plataform, vamos usar o que temos e ajusta-lo para que uma aplicação feita em Firemonkey possa usa-la. Como é um caminho novo para nós também, estamos encontrando obstáculos, e não sabemos até onde podemos chegar realmente, mas de 1a mão anuncio que temos 80% dos componentes podendo ser compilados em uma aplicação Firemomkey, como mostra a imagem em anexo. Hoje faltando os componentes ACBrECF (falta bem pouco para esse), todos os eletrônicos NFe, CTe, NFSe, MDF-e, NFC-e se não esqueci de algum são esses. Em anexo segue os fontes alterados, para quem queira fazer algum teste, nesse 1o passo ajustaremos os fontes para que possam ser compilados, num segundo passo converteremos os demos para Firemonkey, não daremos tempos para conversão, o que fizemos até o momento é fruto de tempo disponível que tiramos do nosso tempo de trabalho ou folga, então conto com a compreensão e também ajuda para que possamos o mais breve possível conseguir essa e novação ao Projeto ACBr. Fontes_FMX.zip

Os dois Speds estavam começando a usar eventos, mas não resolveu os problemas apresentados por vários usuários, então siga o que tem no link que o Elton passou, se ninguém reclamar situações, ela será aplicada em todos os Speds também.

Detectei o erro, a versão Teste não usou a diretiva de compilação da versão 2.00, já corrigi e substitui o instalador, favor baixar novamente no link http://www.projetoacbr.com.br/forum/index.php?/files/category/5-utilit%C3%A1rios-acbr/ e testar.

A última versão de teste que subi é a 0.0.0.0 e está nesse link http://www.projetoacbr.com.br/forum/index.php?/files/category/5-utilit%C3%A1rios-acbr/

Pablo vc testou a versão de teste? Se sim pode deixar vou atualizar os schemas sim na oficial.

Ei Caetano, então não sei te informar lamento.

Não vai ficar muito em cima, pois como já falei em um posta acima a versão de teste já está disponível no fórum aberto, ela pode ser baixada para fazer todos os testes necessários. essa de teste tem os mesmos fontes que a oficial que subirá no final de semana.