PAF-ECF vs. Stored Procedures vs. 3-Tier na Mesma Máquina

[pedrocpneto]

Bom dia pessoal,

Aqui na empresa onde trabalho, será necessário o desenvolvimento de um frente de caixa PAF-ECF em .Net. 

Entretanto, graças a burocracia, o PAF-ECF necessita ser homologado, porém temos problemas quanto a algumas regras de clientes nos clientes que podem mudar, além da integração com sistema de retaguarda.

Meu chefe, desenvolvedor Delphi, acredita que o melhor é desenvolver para que as regras de negócio fiquem em Triggers e Stored Procedures. Eu discordo dessa opinião, entretanto, fico em dúvida se a burocracia para homologar um PAF-ECF faria com que essa solução fosse a melhor.

Talvez o PAF-ECF conectando a um serviço desenvolvido em C# seria uma solução melhor (na minha opinião sim). Entretanto, não sei se esta solução seria eficiente (já que tanto o banco de dados quanto o serviço devem ser instalado na mesma máquina pois o PAF-ECF deve funcionar independente da rede), nem se a receita aceitaria na hora da homologação (nesse caso se o serviço fizesse parte da homologação, que é baseada no MD5 do executável, o serviço também não poderia ser modificado, o que dá na mesma de fazer um cliente "gordo").

Gostaria de saber se alguém aqui tem experiência com PAF-ECF, e o que vocês me recomendariam.

Estou aberto a sugestões :-)

Grato,

Pedro Neto

[Jairo Azevedo]

Fala Pedro! 

Recentemente eu desenvolvi uma aplicação PAF-ECF e a mesma está homologada. O que adotamos aqui para o sistema foi:

- Criação de um projeto WinForms com as telas e tratamendo dos ECFs

- Criação de um projeto para a camada de Controle

- Criação de um projeto para a camada de Repositório 

- Criação de um projeto para a camada de Domínio.

O que os homologadores pedem é que tudo que envolve a parte fiscal, diga-se envio de comandos para o ECF, geração de relatórios (EFD, SINTEGRA e outros), aplicação de impostos, parametrização e demais controles de execução (geração de MD5, validação de serial, etc) tem que ficar em uma aplicação que depois de homologada não pode mais ser alterada sem uma nova homologação.

Para resolver isso, eu deixei no projeto WinForms tudo que envolvia a parte fiscal destacada acima e as demais coisas ficaram em outras camadas. O limite da fronteira foi a forma de obter o preço do produto, que está na camada controle, mas a aplicação de impostos (cálculo de ICMS, PIS, COFINS) teve que ficar no WinForms. Até mesmo, algumas telas como importação de DAV e Pré-Venda, bem como o tratamento do TEF está em outro projeto, fora do WinForms. 

Com isso a gente conseguiu a flexibilidade de mudar algumas coisas na aplicação SEM ALTERAR o executável principal, que é o que está homologado.

Agora, vou te dizer uma coisa: Preocupe-se e muito com a parte fiscal porque a validação do SPED e SINTEGRA é fod@ e a gente perdeu umas 4 horas de homologação para fazer essa goiaba validar. Ahh, preocupe-se também com o bloco 7 de testes, que trata da garantia de inviolabilidade do sistema e base de dados.

Com relação ao banco de dados, foi mole. A gente adotou a premissa de trabalhar com arquivos XMLs das informações necessárias para o sistema funcionar, no caso de uma queda da rede. Particularmente eu não adotaria o conceito de instalar um banco em cada máquina. Imagina se você precisar alterar a estrutura de uma tabela, sendo que seu cliente tem 5 PDVs em cada filial, num total de 10 filiais. Certamente você está criando um monstro...

Fora que ainda tem o problema da sincronização das informações (pense no estoque do produto ou na identificação de um cliente).

Se precisar de alguma ajuda, pode entrar em contato comigo em PVT. 

Boa Sorte. 

Jairo.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Jairo Azevedo
jsou...@gmail.com
proth...@yahoo.com.br
http://br.linkedin.com/in/jairodesouza
(21) 8888-6492

[Pedro Neto]

Estes projetos são apenas dll's?

2013/5/24 Jairo Azevedo <jsou...@gmail.com>

Você recebeu esta mensagem porque está inscrito em um tópico do grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste tópico, acesse https://groups.google.com/d/topic/dotnetarchitects/qp7JcyBaNsk/unsubscribe?hl=pt-BR.
Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um e-mail para dotnetarchitec...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Grato,
Pedro Clemente Pereira Neto

[Jairo Azevedo]

Sim, são DLL's e, desde que não tenham função fiscal, não precisam estar relacionadas na lista de demais executáveis do PAF-ECF

Jairo.