Modelo de sistema contábil

Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

 A minha idéia é através de um arquivo(formato XML) com um plano de contas ir criando as contas e os níveis que o usuário desejar, contudo os níveis 1 e 2 já estão definidos e todas as outras contas ou outros níveis devem ter como pai uma das classe do nivel 2. as classe Patrimonial e Resultado são meramente agregadoras de comportamento, visto que as contas de patrimonio e de resultado tem características (comportamento) diferentes entre si.

Abraços a todos.

P.S. somente as classes do nível mais baixo (especializações) são concretas, as generalizações são abstratas.


Um comentário impertinente a sua dúvida: construtores não são métodos, portanto não tem retorno (nem mesmo void).

Vc pode criar uma flag para controlar o tipo dela.
eh o q temos aqui, na tela tem uma combobox “Analitica ou Totalizadora”.
OUtra coisa q talvez facilite seria criar uma outra tabela para montar a mascara (niveis do plano contabil)

[quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel.

Caro Marco,

 É que a ferramenta CASE implica se não colocar retorno no método. Mas não se preocupe na geração de código já configurei o gerador (que é um XML) para não colocar retorno. Mesmo assim obrigado pelo alerta.

Abraços.

[quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]

Caro Sergio,

 Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?

Abraços.

[quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]

Caro Sergio,

 Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?

Abraços.[/quote]

O seu modelo de ter uma classe para cada conta está errado. Vc só precisa de uma classe: Account
ela implementa o padrão composite. Ou seja ela tem os métodos addAccount() getChildrenAccounts(), etc…

o plano Patrimonial->Ativo->AtivoCirculante seria implementado assim


Account patrimonial = new Account();
patrimonial.setName("Patrimonial");

Account ativo = new Account();
ativo .setName("Ativo");

patrimonial.add(ativo);

Account ativoCirculante = new Account();
ativoCirculante.setName("Ativo Circulante ");

ativo.add(ativoCirculante);

Cada conta é uma instancia de Account e não uma subclass de Account.

[quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]

Caro Sergio,

 Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?

Abraços.[/quote]

O seu modelo de ter uma classe para cada conta está errado. Vc só precisa de uma classe: Account
ela implementa o padrão composite. Ou seja ela tem os métodos addAccount() getChildrenAccounts(), etc…

o plano Patrimonial->Ativo->AtivoCirculante seria implementado assim


Account patrimonial = new Account();
patrimonial.setName("Patrimonial");

Account ativo = new Account();
ativo .setName("Ativo");

patrimonial.add(ativo);

Account ativoCirculante = new Account();
ativoCirculante.setName("Ativo Circulante ");

ativo.add(ativoCirculante);

Cada conta é uma instancia de Account e não uma subclass de Account.
[/quote]

 Inicialemente, obrigado Sérgio. A fato de ter criado o primeiro nível com uma estrutura generalização/especialização foi que cada uma destas contas possui comportamentos específicos (funções contábeis). Poderia usar o Strategy, mas como combinar os dois padrões? Isso fiquei enrolado ai parti para a solução de criar a estrutura de árvore inicial vaté o ponto onde as contas possam a ter comportamentos iguais (como foi o caso do modelo). Qual seria a melhor saída? Juntar os padrões (composite + strategy) ou manter esta estrutura e "pendurar" o composite abaixo das contas já criadas.

Abraços.

[quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]

Caro Sergio,

 Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?

Abraços.[/quote]

O seu modelo de ter uma classe para cada conta está errado. Vc só precisa de uma classe: Account
ela implementa o padrão composite. Ou seja ela tem os métodos addAccount() getChildrenAccounts(), etc…

o plano Patrimonial->Ativo->AtivoCirculante seria implementado assim


Account patrimonial = new Account();
patrimonial.setName("Patrimonial");

Account ativo = new Account();
ativo .setName("Ativo");

patrimonial.add(ativo);

Account ativoCirculante = new Account();
ativoCirculante.setName("Ativo Circulante ");

ativo.add(ativoCirculante);

Cada conta é uma instancia de Account e não uma subclass de Account.
[/quote]

 Inicialemente, obrigado Sérgio. A fato de ter criado o primeiro nível com uma estrutura generalização/especialização foi que cada uma destas contas possui comportamentos específicos (funções contábeis). Poderia usar o Strategy, mas como combinar os dois padrões? Isso fiquei enrolado ai parti para a solução de criar a estrutura de árvore inicial vaté o ponto onde as contas possam a ter comportamentos iguais (como foi o caso do modelo). Qual seria a melhor saída? Juntar os padrões (composite + strategy) ou manter esta estrutura e "pendurar" o composite abaixo das contas já criadas.

Abraços.[/quote]

Elas não têm comportamentos diferentes. As funções contábeis são as mesmas : fazer lançamentos, obter saldo,etc…
O significado das contas que é diferente. Por exemplo, diferenciar entre o ativo e o passivo e calcular algumas coisa usando os dois.

digamos que quero saber a diferença entre o ativo e o passivo. Como eu obtenho isso no sistema ?



public Money diferenca(){

Account ativo =   accountReposiory.getTypedAccount(AccountType.ATIVO);
Account passivo =   accountReposiory.getTypedAccount(AccountType.PASSIVO);

Money balanceAtivo = balanceService.getBalance(ativo);
Money balancePassivo = balanceService.getBalance(passivo );


return balanceAtivo.minus(balancePassivo);

}

o segredo é o getTypedAccount()

Aqui vc tem duas opções. Ou quando vc cadastra a conta vc cadastra o tipo dela, ou vc faz um cadastro em que escolhe para cada
caracteristica contábil qual a conta que a representa. Ou vc cria um mecanismo de script (com o script engine) de forma que a amarração é feita via script e portanto mutável para cada cliente que usar esse sistema. Eu usaria a opção de cadastar contas para tipos, mas eu não conheço plano de contas o suficiente para saber se isso funciona para todos os casos.

[quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,

 Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.

 Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?

[/quote]

A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.

cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]

Caro Sergio,

 Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?

Abraços.[/quote]

O seu modelo de ter uma classe para cada conta está errado. Vc só precisa de uma classe: Account
ela implementa o padrão composite. Ou seja ela tem os métodos addAccount() getChildrenAccounts(), etc…

o plano Patrimonial->Ativo->AtivoCirculante seria implementado assim


Account patrimonial = new Account();
patrimonial.setName("Patrimonial");

Account ativo = new Account();
ativo .setName("Ativo");

patrimonial.add(ativo);

Account ativoCirculante = new Account();
ativoCirculante.setName("Ativo Circulante ");

ativo.add(ativoCirculante);

Cada conta é uma instancia de Account e não uma subclass de Account.
[/quote]

 Inicialemente, obrigado Sérgio. A fato de ter criado o primeiro nível com uma estrutura generalização/especialização foi que cada uma destas contas possui comportamentos específicos (funções contábeis). Poderia usar o Strategy, mas como combinar os dois padrões? Isso fiquei enrolado ai parti para a solução de criar a estrutura de árvore inicial vaté o ponto onde as contas possam a ter comportamentos iguais (como foi o caso do modelo). Qual seria a melhor saída? Juntar os padrões (composite + strategy) ou manter esta estrutura e "pendurar" o composite abaixo das contas já criadas.

Abraços.[/quote]

Elas não têm comportamentos diferentes. As funções contábeis são as mesmas : fazer lançamentos, obter saldo,etc…
O significado das contas que é diferente. Por exemplo, diferenciar entre o ativo e o passivo e calcular algumas coisa usando os dois.

digamos que quero saber a diferença entre o ativo e o passivo. Como eu obtenho isso no sistema ?



public Money diferenca(){

Account ativo =   accountReposiory.getTypedAccount(AccountType.ATIVO);
Account passivo =   accountReposiory.getTypedAccount(AccountType.PASSIVO);

Money balanceAtivo = balanceService.getBalance(ativo);
Money balancePassivo = balanceService.getBalance(passivo );


return balanceAtivo.minus(balancePassivo);

}

o segredo é o getTypedAccount()

Aqui vc tem duas opções. Ou quando vc cadastra a conta vc cadastra o tipo dela, ou vc faz um cadastro em que escolhe para cada
caracteristica contábil qual a conta que a representa. Ou vc cria um mecanismo de script (com o script engine) de forma que a amarração é feita via script e portanto mutável para cada cliente que usar esse sistema. Eu usaria a opção de cadastar contas para tipos, mas eu não conheço plano de contas o suficiente para saber se isso funciona para todos os casos.
[/quote]

Agora ficou mais claro… o classificador de tipos de contas… no exemplo anterior você não mencionou isso… ai fiquei em dúvida como iria distinguir contas de ativo de contas de passivo.

Quanto ao comportamento exitem sim diferenças… por exemplo quando você debita uma conta do ativo você está aumentando seu saldo devedor… e uma conta do passivo funciona ao contrário, quando aumenta seu saldo você deve creditar na conta, ou seja, existe sim um comportamento diferente entre as contas (no ponto de vista contábil).

Abraços.

Caros amigos,

 Acho que descobri um problema. Com as idéias que o pessoal aqui do fórum me deu, estou implementando o composite, contudo cheguei a um dúvida. O padrão composite é usado quando você quer tratar o todo e a parte de forma igual, contudo em um modelo composite para o sistema contábil, fiz o seguinte, a classe pai é o ELEMENTO e as duas herenças são CONTA e GRUPO (GRUPO 1 -> * ELEMENTO).

 Quando fui associar a classe LANCAMENTO com a classe ELEMENTO algo estanho surgiu, posso fazer lançamentos associados a GRUPO!!! Contabilmente isso não existe, somente posso fazer lançamento em contas, mesmo que tenha que fazer lançamentos iguais em diversas contas de um grupo. Sendo assim todas as minhas associações serão com a classe CONTA e quase nenhuma com ELEMENTO. Neste caso pra que usar o composite? Não ficou estranho assim, visto que a finalidade do padrão seira associar somente com a classe ELEMENTO e nunca com as suas especializações (CONTA e GRUPO)?

Abraços a todos.

Caros colegas,

 Esqueçam do meu e-mail anterior. Percebi a orelhada que estava cometendo. Agora já compreendo que devo sim utilizar o padrão composite para esta estrutura de contas. Mas, ainda estou com algumas dúvidas. Primeiro o padrão composite é estrutural ou comportamental? Pergunto isso por que em diversos lugares vejo o relacionamento entre os elementos e as composições como sendo generalização/especialização e algumas vezes os vejo modelados como implementação das interfaces das classes. Pelo que sei o correto é o estrutural, as interfaces das classes irão seguir a estrutura das classes, certo?

 Abaixo segue o código fonte/diagrma das classes (POJO ou JavaBean). De-em uma olhada e critiquem por favor.

ContaContabil.java

/**
 * @author Marcelo Magalhães
 * @version 1.0
 * @created 19-mai-2010 13:06:24
 */
public abstract class ContaContabil 
{

	/**
	 * Identificador da conta. Sequencia gerada pelo banco de dados.
	 */
	private long identificador;
	/**
	 * Nome da conta contábil. Pode ser alfanumérico de até 70 posições.
	 */
	private String nome;
	/**
	 * Campo destinado a observações sobre a conta.
	 */
	private String observacao;
	/**
	 * Saldo total da conta contábil. Nas contas contábeis analíticas é a diferença
	 * entre os lançamento de crédito e os de débito. Já nas contas contábies
	 * sintéticas, o saldo, é o somatório dos saldos das contas contábeis analíticas
	 * pertencentes a esta conta.
	 */
	private float saldo;

	/**
	 * Construtor padrão
	 */
	public ContaContabil()
	{
		super();
	}

	/**
	 * Construtor com argumentos.
	 * 
	 * @param identificador
	 * @param nome
	 * @param observacao
	 * @param saldo
	 */
	public ContaContabil(long identificador, String nome, String observacao, float saldo)
	{

	}

	@Column(name="")
	public long getIdentificador()
	{
		return this.identificador;
	}

	@Column(name="")
	public String getNome()
	{
		return this.nome;
	}

	@Column(name="")
	public String getObservacao()
	{
		return this.observacao;
	}

	/**
	 * 
	 * @param identificador
	 */
	public void setIdentificador(long identificador)
	{
		this.identificador = identificador;
	}

	/**
	 * 
	 * @param nome
	 */
	public void setNome(String nome)
	{
		this.nome = nome;
	}

	/**
	 * 
	 * @param observacao
	 */
	public void setObservacao(String observacao)
	{
		this.observacao = observacao;
	}

	@Column(name="")
	public float getSaldo()
	{
		return <unknown>;
	}

	public void setSaldo()
	{
		<unknown> = newVal;
	}

}

ContaContabilAnalitica.java

/**
 * Conta contábil. É nas contas contábeis que são feitos os lançamentos contábeis
 * que ocorrem no dia a dia de uma empresa. As contas podem ser agrupadas em dois
 * grandes grupo, a saber, grupo das contas patrimoniais e grupo das contas de
 * resultado. As contas patrimoniais são responsáveis por registrar os elementos
 * patrimoniais da empresa, já as contas de resultado servem para apurar a
 * desenvolvimento financeiro da empresa ao longo do ano. Sendo assim estas contas
 * de resultado terão seus saldos zerados ao final do exercício contábil no
 * momento da apuração de resultado do exercício.
 * @author Marcelo Magalhães
 * @version 1.0
 * @created 19-mai-2010 13:06:30
 */
@Entity
@Table(name="ContaContabilAnalitica")
public class ContaContabilAnalitica extends ContaContabil implements Serializable 
{

	private static final long serialVersionUID = 1;

	/**
	 * Construtor padrão
	 */
	public ContaContabilAnalitica()
	{
		super();
	}

	/**
	 * Construtor padrão com argumentos
	 * 
	 * @param identificador
	 * @param nome
	 * @param observacao
	 * @param saldo
	 */
	public ContaContabilAnalitica(long identificador, String nome, String observacao, float saldo)
	{
		super (identificador, nome, observacao , 0);
	}

}

ContaContabilSintetica.java

/**
 * As contas contábeis sintéticas servem somente para agrupar as contas contábeis
 * analíticas, não sendo permitido lançamentos nestas contas. Outra boa finalidade
 * para estas contas é a geração de relatórios sintéticos para niveis gerenciais
 * de uma empresa, visto que tais contas sintéticas possuem o somatório de suas
 * contas analíticas.
 * @author Marcelo Magalhães
 * @version 1.0
 * @created 19-mai-2010 13:06:36
 */
@Entity
@Table(name="ContaContabilSintetica")
public class ContaContabilSintetica extends ContaContabil implements Serializable 
{

	private static final int serialVersionUID = 1;
	/**
	 * Identificador da conta contábil sintética que pertence a esta conta contábil
	 * sintética (filho).
	 */
	private long identificadorFilho;
	/**
	 * Classificador do tipo de grupo ao qual pertence a conta contábil sintética.
	 */
	private Classificador classificador;

	/**
	 * Construtor padrão
	 */
	public ContaContabilSintetica()
	{
		super();
	}

	/**
	 * 
	 * @param classificador    Classificador do tipo de grupo ao qual pertence a conta
	 * contábil sintética.
	 */
	public ContaContabilSintetica(Classificador classificador)
	{
		this.classificador = new Classificador(classificador);
	}

}

Lancamento.java

/**
 * @author Marcelo Magalhães
 * @version 1.0
 * @created 19-mai-2010 13:06:42
 */
@Entity
@Table(name="Lancamento")
public class Lancamento implements Serializable 
{

	private static final long serialVersionUID = 1;
	/**
	 * Identificador do lançamento. Sequence gerada pelo banco de dados.
	 */
	private long identificador;
	/**
	 * Data da cadastro do lançamento. O valor padrão é data corrente. Formato: yyyy-
	 * mm-dd hh:mm:ss
	 */
	private Date dataCadastro = now;
	/**
	 * Valor do lançamento
	 */
	private float valor;
	/**
	 * Histórico ou descrição do lançamento
	 */
	private String historico;
	/**
	 * Identificador da conta de débito do lançamento.
	 */
	private ContaContabilAnalitica contaDebito;
	/**
	 * Identificador da conta de crédito do lançamento.
	 */
	private ContaContabilAnalitica contaCredito;

	/**
	 * Construtor padrão
	 */
	public Lancamento()
	{

	}

	/**
	 * Construtor padrão com argumentos
	 * 
	 * @param identificador
	 * @param dataCadastro
	 * @param valor
	 * @param historico
	 * @param contaDebito
	 * @param contaCredito
	 */
	public Lancamento(long identificador, Date dataCadastro, float valor, String historico, long contaDebito, long contaCredito)
	{
		this.identificador = identificador;
		this.data = data;
		this.valor = valor;
		this.historico = historico;
		this.contaDebito = contaDebito;
		this.contaCredito = contaCredito;
	}

	@Column(name="")
	public long getIdentificador()
	{
		return this.identificador;
	}

	@Column(name="")
	public Date getDataCadastro()
	{
		return this.data;
	}

	@Column(name="")
	public float getValor()
	{
		return this.valor;
	}

	@Column(name="")
	public String getHistorico()
	{
		return this.historico;
	}

	@Column(name="")
	public ContaContabilAnalitica[] getContaDebito()
	{
		return this.contaDebito;
	}

	@Column(name="")
	public ContaContabilAnalitica[] getContaCredito()
	{
		return this.contaCredito;
	}

	/**
	 * 
	 * @param identificador
	 */
	public void setIdentificador(long identificador)
	{
		this.identificador = identificador;
	}

	/**
	 * 
	 * @param data
	 */
	public void setDataCadastro(Date data)
	{
		this.data = data;
	}

	/**
	 * 
	 * @param valor
	 */
	public void setValor(float valor)
	{
		this.valor = valor;
	}

	/**
	 * 
	 * @param historico
	 */
	public void setHistorico(String historico)
	{
		this.historico = historico;
	}

	/**
	 * 
	 * @param contaDebito
	 */
	public void setContaDebito(ContaContabilAnalitica contaDebito)
	{
		this.contaDebito = contaDebito;
	}

	/**
	 * 
	 * @param contaCredito
	 */
	public void setContaCredito(ContaContabilAnalitica contaCredito)
	{
		this.contaCredito = contaCredito;
	}

}

Classificador.java

/**
 * @author Marcelo Magalhães
 * @version 1.0
 * @created 19-mai-2010 13:06:47
 */
public enum Classificador {
	ATIVO(0,"Patrimonial","Ativo"),
	PASSIVO(1,"Patrimonial","Passivo"),
	DESPESAS(3,"Resultado","Despesas"),
	RECEITAS(4,"Resultado","Receitas"),
	APURACAO_RESULTADO(5,"Resultado","Apuração de resultado");

	private final int identificador;
	private final String grupo;
	private final String nome;

	/**
	 * Construtor padrão com argumentos
	 * 
	 * @param identificador    Código identificador do classificador.
	 * @param grupo    Nome do grupo a qual pertence o classificador.
	 * @param nome    Nome por extenso do classificador.
	 */
	private Classificador(int identificador, String grupo, String nome)
	{
		this.identificador = identificador;	 
		this.nome = nome;
	}

	@Column(name="")
	public int getIdentificador()
	{
		return this.identificador;
	}

	@Column(name="")
	public String getGrupo()
	{
		return this.grupo;
	}

	@Column(name="")
	public String getNome()
	{
		return this.nome;
	}
}


[quote=Marcelo Magalh?s]Caros colegas,

 Esqueçam do meu e-mail anterior. Percebi a orelhada que estava cometendo. Agora já compreendo que devo sim utilizar o padrão composite para esta estrutura de contas. Mas, ainda estou com algumas dúvidas. Primeiro o padrão composite é estrutural ou comportamental? Pergunto isso por que em diversos lugares vejo o relacionamento entre os elementos e as composições como sendo generalização/especialização e algumas vezes os vejo modelados como implementação das interfaces das classes. Pelo que sei o correto é o estrutural, as interfaces das classes irão seguir a estrutura das classes, certo?

[/quote]

O composite é um padrão estrutural. Ele serve para criar estruturas complexas de objetos.

Toda o plano de constas é formado por contas. Logo, a raiz da estrutura é conta. Um conta pode conter outras contas.
Lançamentos apenas acontecem em contas “folha”, mas isso não interfere na estrutura.

Outra forma de ver é que o plano contábil é formado por grupos e em alguma ponto grupos têm contas, e apenas contas podem ser alvo de lançamentos. As contas com lançamento tender a ser fixas no tempo, mesmo depois do plano de contas mudar elas são incluidas num grupo que representa contas “antigas”. Os grupos tendem a mudar muito com o tempo e conforme o contador e o ramo de negocio da empresa.

outra forma de pensar é que existe a classe Conta que de divide em ContaSintética e ContaAnalitica. A conta analitica contém lançamentos e não contém outras contas. A conta sintética contém outras contas, mas não contém lançamentos. todas as contas tem em comum coisa como “nome” e “saldo”. Isto é igual ao modelo de grupo-conta.

Lembrando que “saldo” não é um atributo da conta é um calculo sobre a conta. Mas isso vc vai descobrir na prática…

[quote=sergiotaborda][quote=Marcelo Magalh?s]Caros colegas,

 Esqueçam do meu e-mail anterior. Percebi a orelhada que estava cometendo. Agora já compreendo que devo sim utilizar o padrão composite para esta estrutura de contas. Mas, ainda estou com algumas dúvidas. Primeiro o padrão composite é estrutural ou comportamental? Pergunto isso por que em diversos lugares vejo o relacionamento entre os elementos e as composições como sendo generalização/especialização e algumas vezes os vejo modelados como implementação das interfaces das classes. Pelo que sei o correto é o estrutural, as interfaces das classes irão seguir a estrutura das classes, certo?

[/quote]

O composite é um padrão estrutural. Ele serve para criar estruturas complexas de objetos.

Toda o plano de constas é formado por contas. Logo, a raiz da estrutura é conta. Um conta pode conter outras contas.
Lançamentos apenas acontecem em contas “folha”, mas isso não interfere na estrutura.

Outra forma de ver é que o plano contábil é formado por grupos e em alguma ponto grupos têm contas, e apenas contas podem ser alvo de lançamentos. As contas com lançamento tender a ser fixas no tempo, mesmo depois do plano de contas mudar elas são incluidas num grupo que representa contas “antigas”. Os grupos tendem a mudar muito com o tempo e conforme o contador e o ramo de negocio da empresa.

outra forma de pensar é que existe a classe Conta que de divide em ContaSintética e ContaAnalitica. A conta analitica contém lançamentos e não contém outras contas. A conta sintética contém outras contas, mas não contém lançamentos. todas as contas tem em comum coisa como “nome” e “saldo”. Isto é igual ao modelo de grupo-conta.

Lembrando que “saldo” não é um atributo da conta é um calculo sobre a conta. Mas isso vc vai descobrir na prática…[/quote]

Caro Sergio,

 Com relação a mutação do plano de contas, não se preocupe, este modelo será utilizado somente por mim e para somente um ramo de empresa, ou seja, o plano de contas uma vez criado será único e imutável (fechado para altereções aberto para inclusões). Sendo assim não pense neste problema. Se atenha as questões de eng. de software. Sendo assim você chegou a ver o modelo que coloquei? A questão do saldo, se você perceber é um atribuo derivado (/ ante dele), eu somente criei o atributo por questões de performance, imagine em relatórios ter sempre que calcular saldos de diversas contas com milhares de lançamentos. Neste caso uma variável para guardar o saldo é bem vinda.

Abraços.

[quote=Marcelo Magalh?s] A questão do saldo, se você perceber é um atribuo derivado (/ ante dele), eu somente criei o atributo por questões de performance, imagine em relatórios ter sempre que calcular saldos de diversas contas com milhares de lançamentos. Neste caso uma variável para guardar o saldo é bem vinda.
[/quote]

Isso é o que vc acha. Na realidade essa variável é inútil. Problemas de cache, concurrencia, separação de camadas e separação de responsabilidade vao acontecer por causa desse campo.

O composite permite que vc calcula milhares de saldos de forma inteligente pois os saldos das contas sintéticas são a soma dos saldos das contas dentro dela. E o dados das contas a analiticas são a somatória dos saldos dos lançamentos. Isto não é clipper, vc deve usar o SQL de projeção para fazer esses calculos ou ter mecanismo de pre-processamento, mas isso é mais complexo que um simples campo saldo.

Não não vá pelo que estou dizendo, experimente vc mesmo.

Caros colegas,

Evolui mais um pouco no meu sistema contábil (criei os DAOs, os serviços, etc…), mas agora estou com dúvidas no mapeamento (JPA) do composite pattern. Pesquisando achei 3 implementações;

a) 1 classe = 1 tabela (table_per_class)
b) tabela única (single table)
c) super classe não persistida (@MappedSuperclass)

Para as 3 opções não encontrei exemplos bons e concretos somente explicações que ficam no meio do caminho. Sendo assim alguém tem exemplo de alguma das 3 implementações? Ou até mesmo outro tipo de implementação?

Outra pergunta é quanto a qual ser o melhor dos 3, alguém tem experiencias para compartilhar?

Abraços a todos.