Jump to content

dev botao
  • Este tópico foi criado há 4158 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Senhores,

 

Em primeiro lugar, gostaria de dizer que admiro muito o trabalho que fizeram no Delphi. É excelente. 

 

Em particular o ACBrNFe, que tive a oportunidade de usar.

 

É até interessante listar o motivo pelo qual optamos por usar o ACBrNFe. Nossa software house desenvolveu a nota fiscal eletrônica em .net, em um de nossos projetos web, e quisemos usá-la em nosso projeto delphi (um ERP que estamos migrando também para .net), minimizando os custos de manutenção relacionada a NFe.

 

Apanhamos um pouco com Interoperabilidade, com tipos complexos que não existiam e um mês depois estávamos usando plenamente a nossa NFe .net.

 

Só que um de nossos clientes nos pediu um processamento em massa de notas fiscais eletrônicas e assim fizemos.

 

Já estavamos na implantação quando descobrimos esse problema de consumo de memória no .net (que não foram resolvidos, mesmo nosso código .net sendo código gerenciado).

 

Nos 45 do segundo tempo, já entrando na prorrogação, decidimos trocar a solução e optamos por usar o ACBrNFe e foi uma decisão muito acertada.

 

As razões foram: código nativo delphi, manutenção por uma comunidade.

 

Essa história é um pouco grande, mas é necessária para explicar porque eu gostaria de contribuir com o porting do ACBr para .net, mas não gostaria de usar as Dlls  delphi no .net via Interop.

 

Para contribuir temos conhecimento no negócio, na tecnologia e pelo menos mais 2 desenvolvedores dispostos.

 

Mas como não conheço das implicações legais e até políticas do código aberto, estou lançando esse post.

 

Não queremos subverter as regras ou ofender quem quer que seja, queremos realmente contribuir com esse produto maravilhoso, da maneira que podemos.

 

Link to comment
Share on other sites

Boa tarde, seu interesse é fazer port de todos os componentes ou apenas da NFe ?

Eu penso ja a algum tempo fazer o port de todos os componentes, para .Net, mas falta de tempo sempre atrapalhou este plano.

Se planeja realmente fazer todo os componentes podemos conversar e ver uma forma de como começar a fazer este port.

 

Link to comment
Share on other sites

  • Consultores

Você gostaria de portar todo código feito em Delphi/Lazarus para .net?

Se for, o código é aberto de modo que você pode fazer isso. Você pode criar um outro projeto para isso. Não há problema algum.

Mas se for isso que eu entendi, você vai desvincular o código com o dos componentes mantidos atualmente pela comunidade, e vai perder a comunidade atuante Delphi/Lazarus/etc... atual. Terá que criar uma nova comunidade em torno deste projeto.

 

Não uso .net, então não tenho certeza de qual a necessidade dos usuários atuais nesse caso. É melhor esperar a reação deles...

 

Mas acredito que seria melhor fazer o port dos componentes que você precisa que ainda não estão disponíveis nos moldes atuais do ACBrFrameWork, ou tentar otimizar os atuais que você poderia utilizar.

Ainda assim, a decisão final seria sua. (:

 

EDIT: Olha aí, enquanto eu escrevia o Rafael já se manifestou. Você sempre pulando em minha frente né rapaz. hehe :D

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link to comment
Share on other sites

Renato, seja bem vindo!

 

Assim como você eu já passei por tudo isso ... e temos alguns cenários no universo do ACBr

 

1. Componentes ACBrComum, ACBrSerial, ACBrPAF, ACBrSped, ACBrSintegra, e outros.

 

Esses componentes são vitais para o PAF-ECF e foram o alvo do ACBrFramework.

Hoje eles funcionam em .Net perfeitamente, e temos projetos levando-os para Java e ActiveX.

 

Eu particularmente não vejo vantagem numa migração 100% para .Net desses componentes, seria um trabalho gigante reescrever e debugar as mesmas funcionalidades que hoje já temos muito maduras e funcionando bem. Além de perdermos com correções e evoluções feitas pela comunidade em Delphi.

 

2. Componentes NFe e NFSe

 

Esses dois componentes ganhariam muito se reescritos nativamente no .Net.

Primeiro pela facilidade em se trabalhar com a criptografia e XML do .Net, e depois por causa da  complexidade do projeto, impressão e visualização nativa, etc.

 

3. NFeMonitor

 

Como tinha pressa, eu acabei usando o ACBrNFeMonitor em minha aplicação, e desenvolvi um client em C# que protocola via TCP/IP com ele.

Funcionou muito bem e pude usar os PDFs para visualização e impressão dos Danfes.

 

(...)

 

E fique tranquilo, não está ofendendo absolutamente ninguém, aliás está sendo muito bem vindo.

Diga aí qual a sua idéia em relação a esse port, e com certeza nós estaremos juntos aí pra contribuir no que for possível.

 

Abs

Rafael Batiati

ACBrFramework - Automação comercial para todos.

MultiClubes - Soluções para a área de clubes, parques, lazer e entretenimento.

Link to comment
Share on other sites

  • Este tópico foi criado há 4158 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.