RELATÓRIO DE PLANO DE CONTAS

KERPLUNK 09/12/2015 13:47:16
#454906

Você vai criar uma tabela para os planos de contas, mais ou menos assim:
[th][/th]

Cabecalho
Codigo	Nivel	Pai	Descricao
1	1	null	Ativo
2	1	1	Circulante
3	1	2	Lançamento2

Acho que já se entende. Tudo é baseado no [Ô]pai[Ô], você vai percorrer a tabela várias vezes para montar a árvore. Quando fizer os lançamentos de valores em si, você indica o campo código nessa conta e ao montar a árvore, você procura os lançamentos de valores que estão com esse código. Assim, você consegue montar a árvore toda e com todos os seus respectivos valores atrelados. é mais ou menos assim que funciona a FAT(File Allocation Table), que era o antigo sistema de formatação, muito usado no DOS. Tinha uma tabela de pastas, com um [Ô]campo[Ô] indicando qual era a pasta [Ô]pai[Ô] da mesma, montando assim a árvore de pastas. Cada arquivo, tinha também um [Ô]campo[Ô] que indicava o código único de pasta ao qual ele pertencia, completando assim a estrutura de pastas e arquivos. é a maneira mais simples e eficaz de se fazer o que você quer.

ALVAROVB2009 09/12/2015 14:19:38
#454908

Kerplunk obrigado pelo retorno

Minha tabela de plano de contas que estava na minha idéia era algo parecido com isso, não tinha pensado no código pai ainda, que ia ver isso mais para frente

Más realmente não tem como fugir muito , terei que fazer um trabalho manual grande

KERPLUNK 09/12/2015 14:28:15
#454909 Resposta escolhida

Esse tipo de dados, onde a dependência de outros dados é crucial, se não for bem planejado e implementado com antecedência, com certeza vai dar dor de cabeça no futuro e pra isso que a orientação à objeto serve. Quando você montar a sua [Ô]árvore[Ô], cada nó(plano de contas), vai conter os dados do plano de contas, incluindo o código de conta, que é o valor que vai ter vinculado em cada conta individual, algo como [Ô]conta de luz - R$ 100,00[Ô], estará vinculado ao plano [Ô]Despesas gerais[Ô] por exemplo que por sua vez tem o código 9 e é filho de 4, que é filho de 2, o que geraria algo assim:
2.4.9 - Conta de Luz - R$ 100,00
O que conta, não é o [Ô]caminho[Ô] ou filiação de cada tipo de conta, mas sim o código individual dela, por isso, você pode ter:
2.4.9 - Conta de Luz - R$ 100,00
2.4.10 - Conta de Água - R$ 190,00
2.4.11 - Conta de Telefone - R$ 85,00

Aqueles prefixos [Ô]2.4.9[Ô], [Ô]2.4.10[Ô] e [Ô]2.4.11[Ô], não tem nenhum vínculo com o código do tipo de conta em si, que podem ser qualquer inteiro. Desde que se lance as contas com o tipo certo, a árvore será montada da maneira certa e a soma deles é feita simplesmente vendo todos os registros cujo [Ô]pai[Ô] seja o mesmo. Simplesmente porque o [Ô]pai[Ô] de cada tipo de conta, define o grupo e por isso se podem ou não ser somados juntos.

ALVAROVB2009 11/12/2015 20:31:32
#455050

Vlw Kerplunk, consegui fazer o somatório e agora o relatório só que esta me perturbando rsrs

Más a idéia do código pai, funcionou legal e foi até mais fácil que eu imaginei, com poucas linhas fiz todo o somatório

Rs.Open StrSql, Conexao, adOpenKeyset, adLockPessimistic

Dim Rs2 As ADODB.Recordset
Dim Codigo As Integer
Do While Not Rs.EOF
Codigo = Rs(0)
Continua:
Set Rs2 = New ADODB.Recordset
Rs2.Open [Ô]Select codcontapai from tbplanocontas where codplanocontas = [Ô] & Codigo, Conexao, adOpenKeyset, adLockPessimistic
Conexao.Execute ([Ô]update tbplanocontas set valortotalgrupoconta = valortotalgrupoconta + [ô][Ô] & CCur(Rs!valorparcela) & [Ô][ô] where codplanocontas = [Ô] & Codigo)
If Not IsNull(Rs2(0)) Then
Codigo = Rs2(0)
GoTo Continua
End If
Rs.MoveNext
Loop

Dessa forma o que manda é o código pai e não a sequencia da conta, procurei pensar e ajustar para o caso que vc colocou