Documentos fiscais salvar no banco de dados ou não

[diegao15]

Olá boa tarde, estou implementando alguns documentos fiscais aqui no sistema em que trabalho e me surgiu a seguinte duvida, é realmente necessário salvar todas as informações dos documentos fiscais no banco de dados, ou eu posso continuar fazendo como já faço, salvo somente as informações chaves como datas, horários, chaves, protocolos, etc.. e o local do arquivo, ou eu devo salvar todas as informações no banco de dados?

[Daniel Simoes]

Porque não salvar o próprio XML no Banco de Dados ?

[Gr@c@]

Para gerar os documentos fiscais eu já tenho tudo salvo em banco de dados, depois salvo apenas os dados de envio do documento(chave de acesso,protocolo,data de envio ao SEFAZ). E também salvo o xml em uma tabela fiscal que fica em um BD a parte. Salvo tudo para que depois seja possível gerar os arquivos digitais do fisco:sped/sintegra e alguns relatorios gerenciais e contábeis. E também para que a empresa tenha um historico fiscal.

[Maiquel]

Creio que a ideia de salvar em banco é válida, porém em um BD a parte como colocou o colega acima, pois caso for salvo no mesmo banco em que você está salvando os dados, corre o risco de ter um banco demasiadamente "pesado", principalmente se seu cliente emite várias notas.

Abraço;

[Marcelo Calvi Belanga]

Não sei se estou correto, mas mantenho os arquivos salvo apenas em disco e quando preciso de informações o próprio aplicativo busca esses arquivos e traz a informação. É claro que com isso, além do backup do BD, o cliente tem que manter o backup das pastas dos XML.

[Daniel Simoes]

manter em disco é um risco... Os usuários mal fazem Backup do BD corretamente... e são constantes problemas no RuWindows, onde o "técnico de TI" decide formatar a máquina...

[Marcelo Calvi Belanga]

Entendo perfeitamente o risco Daniel. Mas se nem backup os usuários fazem, de que adianta manter em banco se o mesmo não tiver backup também. Então o risco é do cliente e não do desenvolvedor.

Mas estou pensando em ajustar as rotinas, para, além de manter no disco, grava no BD também.

[Gr@c@]

Você disse: " Mas se nem backup os usuários fazem, de que adianta manter em banco se o mesmo não tiver backup também. "

Adianta que o seu cliente não terá motivos para processar judicialmente você desenvolvedor ou a sua empresa, sob alegação de que o seu sistema não salva dados em BD. Além de dar mais credibilidade ao seu sistema. Isso sem falar que o próprio backup pode ser automatizado no gerenciador de BD sem depender da intervenção do usuário. 

[Caejr]

No meu caso, como utilizamos como BD o Firebird, criei um banco separado somente para gravar os arquivos XML de notas, cartas de correção e cancelamentos, até porque a legislação exige que você guarde os documentos fiscais por 5 anos, o Danfe impresso não é documento fiscal, o que vale é o XML mesmo.

[Marcelo Calvi Belanga]

Essa é uma boa discussão e vale muito para tentarmos sempre deixar os dados mais seguros. Porém sempre a responsabilidade pelos dados é sempre do cliente. Isso é claro na minha opinião. E o cliente processar é uma coisa, ganhar o processo por erro dele próprio não fazer backup é outra coisa.

[Gr@c@]

Agora, Marcelo Calvi Belanga disse:

Essa é uma boa discussão e vale muito para tentarmos sempre deixar os dados mais seguros. Porém sempre a responsabilidade pelos dados é sempre do cliente. Isso é claro na minha opinião. E o cliente processar é uma coisa, ganhar o processo por erro dele próprio não fazer backup é outra coisa.

Mas o que está sendo discutido é o "sistema não salvar os dados no BD". Se não salva dados no BD não tem backup. Culpa do cliente? Não. Culpa do sistema que não salva dados no BD. Agora, uma vez que o sistema salva os dados no BD e disponibiliza recurso para o usuário realizar o backup, aí sim, é culpa do cliente não realizar o backup. Mas minha filosofia como programadora é: "faciliar a vida do meu cliente, disponibilizando recursos através do aplicativo ou do proprio gerenciador de BD. Isso porque, se o meu aplicativo não fizer, o aplicativo do meu concorrente com certeza, fará."

[Marcelo Calvi Belanga]

Como você mesmo disse "o que está sendo discutido é salvar os dados no BD ou não", mas do resto você está coberta de razão. Quanto mais recurso o sistema tiver, mais facilidade e comodidade para o cliente.

[diegao15]

olá pessoal bom dia, bom depois de muito discutir a respeito do tema aqui no trabalho e de ler a sugestão do pessoal decidimos fazer da seguinte forma:

no banco de dados vamos salvar as informações chaves do documento fiscal, tipo chave,protocolo,data,dir,etc.., para os arquivos xml decidimos fazer da seguinte forma, instalamos no pc do cliente uma aplicação estilo oneDrive, ou Dropbox, e criaremos uma pasta de sincronização no cliente, configuramos o componente para salvar todos os arquivos xml dentro desta pasta e desta forma o cliente fica com uma copia em nuvem de tudo o que ele emite, o único problema vai ser quando o cliente não possui internet, nestes casos ele terá somente a copia local do arquivo, por isso já começamos a desenvolver um modulo que ficara responsável por zipar e realizar backup (em uma pasta) destas xmls nestes casos excepcionais.

[Solivan]

Trabalho dessa forma ai usando o dropbox para armazenar o backup do banco de dados em formado script SQL o que reduz significavelmente o tamanho do arquivo de banco de dados, tenho cliente emitindo documentos ha 3 anos e o seu backup não passa de 5 megas.

[Marcelo Calvi Belanga]

Boa noite!

Depois de analisar a discussão, resolvi também manter os XML salvos no BD, além do disco.

Para isso qual tipo de campo seria o mais indicado?  Uso Firebird.

Obrigado. 

[Gr@c@]

No SQL Server campo tipo nText

[Caejr]

Utilizo Blob sub_type 0