Painel de líderes

Sou o único programador da empresa, tenho pessoas para suporte mas quem faz todo o resto sou eu.

Enviei uma correção para este problema no DEMO hoje. Acredito que agora está exemplificando corretamente como agir. Mas lembramos que é apenas um exemplo e sua aplicação pode fazer de forma diferente.

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.

Você pode experimentar o ACBrMonitorPlus, e com ele fazer uma "ponte" entre o seu PDV e a dll usada pelo simulador. Instale, leia o manual fornecido e o grande conteúdo publicado aqui no fórum.

Leu o tópico com atenção ?? Como vc espera que funcione, se você está desligando CAPICOM e OpenSSL ao mesmo tempo ??

Boa tarde, Essa alteração se refere aos fontes do Trunk? Se sim, não estamos mais dando suporte ao Trunk, somente ao Trunk2. E no caso do Trunk2 o relacionamento entre a cidade e o provedor e através de um arquivo INI.

Boa tarde a todos, Enviei uma atualização, criei uma função chamada RemoveNameSpace em pnfsConversao.pas caso algum outro provedor tenha algum NameSpace que precisa ser removido basta incluir ele na função, desta forma fica muito mais simples em vez de fazer diversas alterações em pontos diversos do componente. Favor atualizar os fontes e testar.

Até mesmo o suporte a D7 será descontinuado em breve... http://www.projetoacbr.com.br/forum/announcement/16-fim-de-suporte-ao-delphi-7/

Boa tarde Claudemir, No que diz respeito a GNRE já temos o componente ACBrGNRE mas este esta passando por uma reformulação, sendo assim ainda não é possível nem sequer compilar ele, muito menos instalar no Delphi. Por favor aguarde mais um pouco, acredito que até o final deste mês ele já vai estar pronto.

Acho que não fui claro no meu tópico anterior... o que desejo saber, é se podemos manter apenas o código da versão 64bits... e com isso evitar o IFDEF

Juliomar, Pelo menos em relação a layout, não estou tendo mais problemas com o PVA. []´s Everton Garcia

O código 07 não existe na tabela de formas aceitas pelo SAT. Use o código 99 para "Outros meios de pagamento".

Boa tarde, não existe 07, somente as abaixo: 01 - Dinheiro 02 - Cheque 03 - Cartão de Crédito 04 - Cartão de Débito 05 - Crédito Loja 10 - Vale Alimentação 11 - Vale Refeição 12 - Vale Presente 13 - Vale Combustível 99 - Outros Sds, Ricardo.

Lembre-se que o ACBr é Opensource... ou seja, você pode abrir os fontes do componente e analisar como foi feito... Veja o trecho abaixo da Unit ACBrSATExtratoFortesFr.pas if MostrarPreview then RLLayout.PreviewModal else RLLayout.Print;

Olá Daniel, me desculpe se fiz algo de errado. Mas a cobrança foi só porque nas regras do SAC esta que teríamos uma resposta em 24 hs e fazia quase uma semana. E referente (SAC não dá direito a desenvolvimento específico) é que na aba BOLETO tem E-mail Boleto, Assunto e Mensagem. O que eu coloco como assunto sai e o que coloquei em mensagem não sai nada. Mas como você disse que enviou para SNV, vou aguardar a próxima atualização..ok Desculpa mais uma vez. Obrigado

ã? Como é? Acho que vc não leu direito, esqueceu de ler as vírgulas... Não disse que Lazarus é ruim!!! Disse que o ruim era isso, por ser Lazarus nós apanhamos feio!!! huasuhas

O A1 é o mais indicado nesse caso, e por PDV você pode mudar a série. Existem alguns tópicos onde isso já foi comentado.

Quem gera a assinatura é o desenvolvedor. Sendo assim seu cliente vai precisar apenas que você faça esta assinatura para ele com o seu certificado. Ele pode conectar na retaguarda de contribuinte com o usuário e senha do posto fiscal eletrônico. Att Cristiano Abbud

Após ler com atenção a NT 2015 003 v1.60 referente a ao grupo do ICMS de destino "tag: ICMSUFDest)", na pág. 14 tem uma exceção que me chamou atenção. "Exceção 7: A regra de validação acima não se aplica se informada UF do local de entrega (tag: entrega/UF) igual à UF do emitente (tag: emit/enderEmit/UF)" Entendi que aqui seja a saída para operação de venda presencial para consumidor final onde o consumo ocorreu no próprio estado, ou seja, o local de entrega do destinatário seja o mesmo do emitente. Para ter certeza disso, resolvi fazer um teste e inclui o seguinte: if Ide.indPres = pcPresencial then begin Entrega.xLgr := Emit.EnderEmit.xLgr; Entrega.nro := Emit.EnderEmit.nro; Entrega.xCpl := Emit.EnderEmit.xCpl; Entrega.xBairro := Emit.EnderEmit.xBairro; Entrega.cMun := Emit.EnderEmit.cMun; Entrega.xMun := Emit.EnderEmit.xMun; Entrega.UF := Emit.EnderEmit.UF; end; Resultado: Nota Fiscal Autorizada! A SEFAZ aceitou a nota mesmo sendo com os dados: Ide.idDest = doInterestadual Ide.indFinal = cfConsumidorFinal Dest.indIEDest = inNaoContribuinte Ide.indPres = pcPresencial Sem preencher a partilha do ICMS

Bom dia, Neste caso, o procedimento correto seria emitir uma danfe com CFOP 5949 referente ao "Lançamento efetuado em decorrência de emissão de documento fiscal relativo à operação ou prestação também registrada em equipamento ECF". No meu blog tem um artigo de dezembro falando realmente sobre isso: http://diarioautomacaocomercial.blogspot.com.br/2015/12/como-emitir-uma-nota-fiscal-para.html

Bom dia. Antes de tudo, é importante ressaltar que, para a validade dos contratos independentemente de escrito ou verbal, deve haver pessoas capazes. Para o judiciário, tanto vale o contrato escrito quanto o verbal, pois, no caso do contrato verbal, é a livre manifestação da vontade, pois assim estabelece o Código Civil em seu Art. 107, in verbis: “ A validade da declaração de vontade não dependerá de forma especial, senão quando a lei expressamente a exigir”. Portanto é válido o contrato verbal. Isso significa que, para as partes contratantes, quando a lei não exigir forma especial, o legislador estabeleceu a boa-fé objetiva das partes, ou seja, o contrato mesmo que verbal deve ser cumprido como se expresso fosse. Pelo que a colega dispôs, apesar de esclarecer os pontos que entende relevante, é importante que ela saiba como foi contratada, se era para criar o software com os direitos para a empresa ou não, pois, apesar do Art. 4º § 2º da 9609/98, estabelecer inicialmente que, pertence ao contratado o programa de computador, deve ser analisado o que dispõe o contrato, mesmo que verbal. Se não há nenhum acordo para que as fontes fossem entregues para o contratante, é claro que eles pertencem a quem criou, pois assim define a lei, especialmente quando se trata de nenhum recurso de quem contratou, se empresa ou pessoa física, mas, o que deve prevalecer é o que foi acordado. O instituto do PACTA SUNT SERVANDA, no direito civil, estabelece que, os tratos são para serem cumpridos, e, caso haja pactuado algum direito, este deve ser respeitado, sob pena de quebra de contrato, ensejando assim em responsabilidade civil. Por outro lado, é importante que as partes a partir de então, acordem sobre o que fazer no futuro, no caso do contratante pelo que entendi, não atua no ramo de desenvolvimento, diferentemente da colega. Neste caso, entendo que a contratada comunique, ao contratante sua decisão de não mais prestar os serviços de desenvolvimento, nos moldes antes acordado. Lembre-se que agora é a hora de fazer o contrato antes verbal tornar-se escrito, ou seja, em sua comunicação deverá descrever exatamente o que antes foi acordado verbalmente, e, expressando a sua vontade em não mais seguir o que antes acordou. Por fim, se não houve a previsão de entrega das fontes, elas são suas de pleno direito, tendo em vista os moldes que você os concebeu. Att,

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

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.

O Delphi 2010 é o que estaria mais próximo do Delphi 7 em relação á compatibilidade com componentes antigos, e 100% compatível com o ACBr.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum.

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

Boa tarde Daniel Simoes! A solução foi altearar no form ACBrDANFCeFortesFr o nome do objeto trlabel de lNumSerie para lNumSerieEmissao e criar em tempo de execução o objeto lEmissaoVia. Estes objetos estão perdendo suas propriedades na hora de imprimir o relatório. Obrigado pela atenção.

Boa tarde Gilson, ConsultaLoteAposEnvio é uma configuração que você determina se o componente realiza todas as ações do Enviar até chegar ao resultado final que é ter o XML da NFS-e ou se você vai montar a sua própria rotina. Se essa propriedade for True, tudo fica por conta do componente. Ela é útil também para aqueles provedores que durante o dia só recebem os lotes, para processa-los durante a madrugada e disponibilizar o XML da NF-e no período da manhã do dia seguinte. Deste caso você deixa essa propriedade com o valor False para que somente ocorra o envio.

A meu ver SIM... Ficou muito fechada essas opções fixas... Porém o fisco vai ter estatísticas precisas sobre os meios de pagamento mais utilizados...