Painel de líderes

O maior medo de todo programador, é ver a sua linguagem morrer... Foi assim com o COBOL, com o Clipper, e por várias vezes já se falou do fim do Object Pascal... Hoje em dia é muito difícil achar novos programadores em Delphi, a nova geração nem pensa em aprender ObjectPascal, e para eles, não faz o menor sentido usar um produto pirata, ou pagar caro numa IDE, para aprender a programar... (ainda mais tendo Java, PHP, e tantas outras linguagens disponíveis livremente) Como uma linguagem não morre ? A resposta é simples, com investimento... enquanto houver empresas investindo nela, ela irá crescer e existir... Adquirindo as novas IDEs do Delphi, os programadores (que são dependentes dessa linguagem), mantém o fluxo de investimento e o desenvolvimento da mesma.. Por outro lado, ficar preso a uma IDE de mais de 18 anos... só traz limites... limites de técnicas de programação, limites de tecnologia, limites de interface, de plataforma, etc.... Do ponto de vista de negócios.. é estratégico evoluir para uma nova IDE.. isso DEVE ser planejado e constar no "RoadMap" do produto da empresa... caso contrário o produto (o sistema), ficará preso as limitações da antiga IDE... Sabemos que a decisão é difícil e que irá incomodar muitos usuários do ACBr... mas há tempos já adiamos essa decisão, e agora chegou a hora...

Luis acho que o problema maior é outros componentes e não o ACBr em si! A grande maioria está preso a versão da IDE porque optaram por adiciona o máximo possível de componentes de terceiros!

arquivo anexo ACBrSpedFiscal.pas

Bom dia a Todos, eu estou terminando a migração do acbr para trunk 2 e tenho um relatório de DANFE's onde o usuário digita a nota inicial e final , o sistema carrega essas notas no acbrnfe e depois gera todas de uma vez no acbrdanfervcodebase, como se fosse um relatório só com varias paginas, no Rave funciona belezinha, mas no fortes report ele fica gerando varias impressões independentes, ja pesquisei no fórum porem dos colegas que enviaram esse tipo de duvida só obtiveram negativas, gostaria de saber se algum dos colegas conseguiu por meio de ajuste fazer funcionar da forma como falei? Trabalhei com o Fortes por algum tempo e na época agrupava relatórios usando a propriedade do RLReport NextReport, mais estudando os fontes do Fortes constatei que ele gera 1 relatório por vez impossibilitando esse tipo de artificio, eu acho que o componente da DANFE deveria gerar a DANFE na memoria com o nome da chave e verificar se esta é apenas 1 e no caso de mais, deveria setar em memoria a propriedade nextreport para a próxima, e imprimir apenas o primeiro report, é apenas uma divagação ainda não estou familiarizado com a estrutura de desenvolvimento do ACBR NF-e para fazer esse tipo de alteração sem prejudicar alguma coisa, como eu disse é apenas a sugestão de um fã do componente..rsrs Muito obrigado pela atenção. Sucesso a todos.

perfeito Juliomar... removi todo o acbr e o fortes, baixei novamente os dois e fiz uma nova instalação... funcionou certinho muito obrigado pela ajuda

O histórico do SVN deve ser público... se nele há um link para a área do SAC... os moderadores podem/devem mover esse tópico para a área aberta (mesmo após essa operação o link permanece o mesmo)

Problema resolvido, removi todos os componentes do Delphi instalei na sequência fortesReport(Pelo Instalador), FastReport e ACBR pelo instalador. Quero aproveitar a parabenizar aos membros do fórum em especial ao Juliomar, Obrigado pela atenção e a vontade de ajudar.

Boa tarde! Tenho o ACBr instalado em três versões de Delphi e funciona normalmente. Quando eu faço a atualização, deleto as pastas referente a versão do Delphi antes de reinstalar, ou seja, no meu caso: C:\ACBr-Trunk2\Lib\Delphi\LibD14 C:\ACBr-Trunk2\Lib\Delphi\LibD21 C:\ACBr-Trunk2\Lib\Delphi\LibD7 Espero ter ajudado.

O erro na realidade foi apresentado antes: E2137 Method 'CodOcorrenciaToTipoRemessa' not found in base class. Provavelmente seu library path/Search path está configurado incorretamente e está pegando uma versão anterior dos arquivos. Se você possuía outra versão do ACBr antes, isso pode ser o que está ocasionando o erro. Pode ser também que você possui uma unit ACBrBoleto.pas nos caminhos do seu projeto. Ou algo parecido.

3Soft Sistemas, isso é bem verdade. Fiz tal alteração pois ainda não tenho tempo para realizar a migração para o Trunk2. Mas compreendo as novas mudanças e melhorias para o Trunk2. Mudança apenas para o CEST.

Acho que este é um problema um pouco difícil de resolver visto que o problema está no fortesreport e não no ACBR. O problema acontece porque não há nenhum espaço na descrição do produto e assim o fortes não consegue fazer a quebra de linha. Faça um teste e verifique se é isso mesmo, depois relate pra gente aqui. Abraço

Pessoal, como foi dito anteriormente, o componente ainda vai funcionar, porém terá um trabalho maior pra compilar, uma vez que os códigos novos serão pensados apenas pra outras versões do Delphi. Eu também sou desenvolvedor sozinho e vou me empenhar pra que dê certo, as vezes precisamos de incentivos como esse pra poder crescer, não vai ser fácil, mas ficar só reclamando e choramingando não irá nos levar a nada. Creio que aqui no fórum deva ter algum lugar que possamos abrir um tópico pra quem tiver com dificuldades pra migrar de versão poder relatar os erros e problemas e cada um vai se ajudando, assim todos conseguiremos avançar ainda mais. Forte abraço e boa sorte pra todo mundo.

Na verdade sempre precisou.. conforme está no manual, desde a primeira versão: O que ocorre é que a rotina de Parser de comandos tenta se recuperar em alguns casos..

Nada a ver a sua dúvida com o título do tópico ! O seu problema esta no <cEAN>1952402</cEAN> que não é um EAN válido. Da próxima vez, nova dúvida, novo tópico, e use a busca antes de postar

da um estudada na pasta exmplos\ACBrTCP\ACBrIBPTax deve ter o que você precisa

Procure o suporte do MULTiPDV pois eles devem poder lhe ajudar corretamente.

Acabei de atualizar o script do CEST disponível em http://www.firebase.com.br/artigo.php?id=2862 usando como base a tabela de códigos publicada no CONVÊNIO ICMS 146, DE 11 DE DEZEMBRO DE 2015.

Vou deixar minha experiência, eu migrei do D7 para D2007, depois Delphi 2010, e então XE7, XE8 e agora Seattle, porque estás versões? Porque segui a linha do que era estável para mim, agora com as versões XE7 em diante basta recompilar o projeto, não tem segredo. Quando migrei de D7 para D2010 eu tinha essa mesma cabeça de não mudar porque daria trabalho, era milhões de linhas de código para revisar, centenas de tabelas em um BD Firebird e muita, muita regra de negócio, mas não foi um bicho de 7 cabeças. O ganho com o uso de novas versões foi enorme, hoje o Delphi e Lazarus suportam muitos features de linguagem que o D7 nem sonha ter, coisas que facilitam em muito o dia-a-dia, principalmente para quem pensa em programar multi-plataforma e suportar mobile. A dificuldade sempre vai existir, isso é um fato, migrar um sistema não é fácil quando se vem de uma linguagem muito antiga, mas manter Delphi 7 só tem atrasado o projeto ACBr, sempre que vamos fazer algo temos que pensar na limitações do Delphi 7 e nivelar por ela, isso traz transtornos enormes, um exemplo foi alguns dias atrás quando fui implementar a API IBPT no componente ACBrIBPTax, o retorno a API é em JSON uma tecnologia extremamente corriqueira é que é usada em tudo que diz respeito a troca de informações web, mas o Delphi 7 não tem suporte nativo, já Lazarus e versões mais novas do Delphi sim, tive que implementar uma leitura básica de JSON para suprir a necessidade do Delphi 7 para que não tivéssemos que agregar bibliotecas de terceiros e inchar o ACBr com mais uma biblioteca. Este é um exemplo simples, imaginem todo o resto que temos que passar, leitura de XML, listas e afins que já são suportados nativamente em versões mais novas e temos que sermpre fazer tudo manualmente por conta de limitações do D7. Seu problema é dinheiro, acha caro uma nova versão do Delphi, o Lazarus é tão bom quanto, fora a IDE, ele suporta tudo que uma versão de Delphi mais nova suporta e é GRÁTIS e praticamente idêntico ao Delphi 7 em termos de funcionalidades e IDE.

Queria dar uma sugestão aqui para quem ainda usa o Delphi 7. Eu não uso o ACBr no meu sistema de gestão. Tudo o que uso com ACBr está em módulos separados. As notas fiscais são digitadas no meu sistema de gestão, mas são enviadas através de um módulo separado onde uso o ACBr. Então, tudo o que tenho com ACBr são módulos que são chamados pelo sistema de gestão. Assim, posso continuar compilando meu sistema de gestão no Delphi7 (que é enorme e não seria possível convertê-lo para uma nova versão do Delphi de uma hora para outra) e compilar meus módulos com ACBr numa nova versão do Delphi. Assim, tenho os seguintes módulos em ACBr: Emissor de NFe, Emissor de CTe, Emissor de boletos. Hoje vejo que foi a melhor escolha que fiz. Lembrando que, nos módulos que uso ACBr eu não uso outros componentes terceirizados, justamente para facilitar uma migração emergencial.

Rodrigo, Boa noite. Tudo isso é confuso mesmo, mas lendo o convênio 93 encontrei o seguinte: Cláusula nona. Aplicam-se as disposições deste convênio aos contribuintes optantes pelo Regime Especial Unificado de Arrecadação de Tributos e Contribuições devidos pelas Microempresas e Empresas de Pequeno Porte - Simples Nacional, instituído pela Lei Complementar nº 123, de 14 de dezembro de 2006, em relação ao imposto devido à unidade federada de destino. O resultado das disposições deste convênio (que é gerar a partilha), quando se trata de empresa do simples na origem, não se aplica (em termos né, veremos mais a frente na outra citação o porque), portanto não tem nada a ser partilhado para o origem (#sqn) e sim somente para o destino. Vendo esta interpretação do convênio creio que: a sistemática da partilha é igual para qualquer regime, mas aplicada somente ao destino quando na origem o regime é simples nacional (#sqn, veja a citação seguinte). Não sei se expliquei ou compliquei. Rsrs Companheiro Jorge, Boa noite. Sim sim, vc está correto. Analisando tudo isso, para o estado de destino, será recolhido ICMS agora quando seu contribuinte for comprar em outro estado, e isso será ótimo pro destino, massss, será péssimo pra quem está comprando porque se o comprador for do simples (caso de hotéis por exemplo) será tratado como um consumidor final e em sendo pessoa jurídica terá que recolher este imposto que lhe foi partilhado (phoda). E quando a venda for pra um cliente comum, quem se ferra é quem vende, mesmo sendo do simples e do seu lado não deveria recolher nada na origem (a tag da origem de ir zerada) terá que recolher para o destino a parte que a ele (Destino) cabe na partilha. Então, existe de um certo modo, uma 'ilegalidade' deste convênio para com as empresas do simples nacional sim, porque ela fere a lei do simples onde a unificação de impostos foi criada para amenizar a carga tributária dessas empresas, mas agora quando ela comprar (ou mesmo vender) de outros (ou para outros) estados, com a difal, ela terá que recolher a parte que lhe cabe na partilha. Ou seja, já recolhe o seu imposto das vendas pelo DAS, e terá de recolher o ICMS da partilha por GARE/GNRE (de um lado ou de outro). Isso ao meu vai ferrar tudo (desculpe o termo). No caso das empresas normais não deveria haver bi-tributação pois lendo o convênio 93 Cláusula terceira. O crédito relativo às operações e prestações anteriores deve ser deduzido do débito correspondente ao imposto devido à unidade federada de origem, observado o disposto nos arts. 19 e 20 da Lei Complementar nº 87/1996. Ou seja, quando ele for recolher seus impostos normais, o valor que vier de partilha a ser recolhido deve ser abatido deste total, essa é minha interpretação. Isso tudo, ao meu ver ainda não vai cheirar bem, rsrs, vai acirrar a guerra fiscal e vai prejudicar muita gente. E Jorge, quando você diz que ainda está utilizando em alguns clientes uma versão que não gera essas tags eles estão em descumprimento a lei da partilha, porque mesmo sem ser validada, as tags devem existir e existindo partilha ela deve ser recolhida. Somente a validação foi adiada tá ok. Espero ter mais explicado do que complicado. Até mais,

Isso mesmo. Via BD, flags e status. As notas são digitadas no gestão (que já contem todas as regras fiscais) e ficam em espera para envio. Ao chamar o emissor, as notas estão lá paradas pendentes e é só enviar. Se houver rejeição da nota por erro de dados, ela só pode ser corrigida no gestão. O modulo de envio (com ACBr) atualiza o banco de dados com os dados de retorno do SEFAZ. Também dá pra fazer isso desenvolvendo o módulo como um serviço do Windows. Tudo o que é feito com ACBr e relacionado com transação Emitente <->SEFAZ está no módulo de envio. Dou entrada nas nfe recebidas também através do módulo, pois o controle de estoque é todo via trigger e procedure. O meu módulo NFe não precisa do gestão para funcionar(precisa só do BD). O gestão é que precisa dele para enviar e atualizar as notas. Tenho mais de um sistema de gestão (por serem muito diferentes) e um único módulo emissor de NFe que é usado por todos já que o xml é universal.

o ideal... seria primeiro você estudarem a Refactoring que foi feito no ACBrNFe, ACBrCTe e demais... para tentar fazer o mesmo com o GNRE Vocês estão preocupados apenas em "deixar compilando"... e isso não faz muito sentido... e como o Juliomar disse, não integraremos ao SVN, fontes nessas condições... O grande motivo da criação do Trunk2, foi o refactoring que economizou milhares de linha de código, e abstraiu toda a complexidade de comunicação segura, assinatura, criptografia, na classe mãe "TACBrDFe"

Não vai adiantar deixar compilando e fora dos padrões não será subido!

Ele esta sendo destruído duas veses ai da acesso violado.

Verifica se o papel está com GAP posicionado de forma correta... a impressora pode ficar "perdida" se não encontrar o "GAP" no papel

Sim... mas repare que a Quantidade "qCom", suporta 4 casas.. Então ele pode modificar o estoque Unitário dele para milhar, centena, dezena, etc... e usar as decimais...

D7 já está morto faz tempo... não faz sentido ficar preso ao passado... para quem tem como descupa o custo de uma nova IDE, hoje em dia o Lazarus/FPC é muito melhor do que o D7, e "de grátis" (na DJSystem já usamos o mesmo a anos)... Os novos Delphis XE, são fantásticos, e ainda compilam para Mobile... sinceramente, não vejo porque ficar preso ao passado

SIM, provavelmente no segundo semestre desse ano... Afinal de contas o D7 já tem 18 anos (lançado em 2002) As diferenças de String entre as versões ANSI (D7) e as versões que suportam Unicode (XE), trazem muita dificuldades para manter o código do ACBr

Estimado raosistemas, Boa noite.Suas dúvidas são complexas mas vamos lá. 1) a pergunta 1 ficou meio confusa mas você citou ST. Substituição tributária é o seguinte, é algo em que cada estado ainda irá (e deve) definir (e nos explicar certinho) como vai ser (isso tudo ainda é totalmente confuso pra nós, rsrs), porque a regra geral é a seguinte: como a mercadoria está sujeita a ST e o imposto já foi retido e pago antecipadamente (pulo do gato) essa mercadoria não teria diferencial de alíquota a ser recolhida, ou seja, não se gera as tags da partilha para a linha deste item. Resumindo, o valor do ICMS devido (e pago) por antecipação que é calculado nos termos do art 426-a do RICMS/2000 de são paulo já englobaria o valor que seria devido pela diferença entre as alíquotas interna e interestadual. Mas ninguém nos orienta corretamente e o que se vê, no geral, é o pessoal dizendo que independente de ter ST ou não se a venda for pra outro estado e o cliente for consumidor final (contribuinte ou não) a partilha deve ser feita e eu estou fazendo dessa maneira e o sistema tá validando. E a ultima coisa, o FCP não faz mais parte do total da difal devido na uf de destino, isso foi alterado na nota técnica 2015.03.v160. 2) independente se é do simples ou não deve-se calcular a difal, mas com uma excessão.Apenas a parte do difal do destino é recolhida, porque a do remetente é recolhida de forma unificada através de DAS. Portanto, vc deve calcular tudo certinho, mas na hora de informar as tags do produto deve-se ficar assim: <ICMSUFDest> <vBCUFDest>10.00</vBCUFDest> <pFCPUFDest>1.0000</pFCPUFDest> <pICMSUFDest>19.0000</pICMSUFDest> <pICMSInter>12.00</pICMSInter> <pICMSInterPart>40.0000</pICMSInterPart> <vFCPUFDest>0.10</vFCPUFDest> <vICMSUFDest>1.75</vICMSUFDest> <vICMSUFRemet>0.00</vICMSUFRemet> (vai zerado quando for empresa do simples nacional) </ICMSUFDest> A tag vICMSUFRemet deve ser informada com valor zero nas tags relativas ao produto. E lá no total assim: <ICMSTot> <vBC>0.00</vBC> <vICMS>0.00</vICMS> <vICMSDeson>0.00</vICMSDeson> <vFCPUFDest>0.10</vFCPUFDest> <vICMSUFDest>1.75</vICMSUFDest // não aparece a informação da tag do remetente quando a empresa for do simples nacional) Nem sequer informar a TAG. Meu sistema está validando assim. O CFOP 6108 só será utilizado se o consumidor final pra quem vc está vendendo for pessoa física mesmo e a operação não tiver ST, e, as informações não vão para o campo de informações adicionais não, imagina uma nota com 30 produtos vc colocar as informações todas lá naquele campo, não dá, pelo menos no nosso caso aqui eu estou colocando os dados na tag infAdProd; <infAdProd> Conv.ICMS.93/2015: vFCPUFDest : 0,10 vICMSUFDest : 1,75 vICMSUFRemet: 0,00 (zero porque é do simples) </infAdProd> 3) Os CSTs aceitos para clientes consumidores finais não contribuintes são aqueles constantes na nota técnica 2015.03.v160 que são 00 20 40 41 60, mas isso se o indIEDest for igual a 9, agora se o consumidor pra quem vc tá vendendo, fora do estado, for ISENTO de inscrição estadual então os CSTs que vc deve usar são o 50 e 51. Para empresas do simples os csts válidos seriam 102 103 300 400 e 500 e no caso do isento fora do estado a regra seria usar 400. 4) Esta é parecida com a 2, ou seja, não há diferença nenhuma no cálculo e sim, apenas na hora de preencher a tag vICMSUFRemet. Acho que é isso, espero ter explicado mais e complicado de menos. Até mais.

Só para deixar registrado também estava com este problema e mudei a propriedade TACBrNFe.Configuracoes.Certificado.VerificarValidade para FALSE e parrou de ocorrer o erro.

@Leandro Araújo, Forneça um passo a passo de como reproduzir o problema, usando o Demo do ACBrNFe... Como configurá-lo ? Qual botão clicar até o erro ?

É justamente o que discutimos acima. Eu sempre sigo a máxima, esse tipo de informação é por conta do cliente, então tenho formas de configurar para que ele escolha como quer fazer, se a Sofware House tomar esse tipo de responsabilidade sempre acaba mal.

Uma ideia, utilizem a tabela IBPT para validar, ela só tem NCMs válidos, lembrem que um NCM pode ser válido hoje e deixar de ser válido futuramente, depende de lei isso, a tabela IBPT é atualizada de 6 em 6 meses então dificilmente se pegar por ela vai ter problemas, além do que você já a utiliza para os percentuais de impostos aproximados. E ela já possui a descrição

Alguém usando Maravilha no NFSe com a Betha no trunk 2? No trunk antigo mudamos no pnfsConversao.pas do provedor Pronim para Betha e está em produção. Migrando para o trunk 2 ainda está como Pronim. [4210506] Nome=Maravilha UF=SC Provedor=Pronim Mudamos para Provedor=Betha Ainda não conseguimos validar, pois está retornando um erro de cadastro, que precisamos ver com a prefeitura que está de férias. Então ainda não posso validar o funcionamento. Temos até um post a respeito da mudança: http://www.projetoacbr.com.br/forum/topic/23943-novo-provedor-de-maravilha-nfse-betha-e-nota/ Alguém já está funcionando no trunk2? Precisamos passar para os moderadores para alterar. @Oneide Luiz Schneider já está no trunk 2? Abraços e feliz natal !!!!

pelo que eu intendi no leiaute do arquivo de venda(CF-e-SAT) http://www.fazenda.sp.gov.br/sat/downloads/Especificacao_SAT_v_ER_2_14_10.pdf pagina .77 grupo de pis para contribuinte do SIMPLES NACIONAL =>CST=49 pagina .80 Grupo CONFINS para contribuinte do SIMPLES NACIONAL =>CST=49 da uma olhada la mais e isso mesmo ...

Pessoal, Segue o link do arquivo executável que estou disponibilizando. http://1drv.ms/1ESi0lX