Saiba que este documento não poderá ser reproduzido...

Saiba que este documento não poderá ser reproduzido, seja por meio eletrônico ou

mecânico, sem a permissão expressa por escrito da Domínio Sistemas Ltda. Nesse caso,

somente a Domínio Sistemas poderá ter patentes ou pedidos de patentes, marcas comerciais,

direitos autorais ou outros de propriedade intelectual, relacionados aos assuntos tratados nesse

documento. Além disso, o fornecimento desse documento não lhe concede licença sobre tais

patentes, marcas comerciais, direitos autorais ou outros de propriedade intelectual; exceto nos

termos expressamente estipulados em contrato de licença da Domínio Sistemas.

É importante lembrar que as empresas, os nomes de pessoas e os dados aqui

mencionados são fictícios; salvo indicação contrária.

© 1998 - 2010 Domínio Sistemas Ltda. Todos os direitos reservados.

Sugestões

A Domínio Sistemas busca aumentar a qualidade dos seus produtos continuamente. Um exemplo disso é esse material, que tem como objetivo aumentar a produtividade e o desempenho dos usuários de nossos sistemas.

O processo de elaboração desse material passou por freqüentes correções e testes de qualidade, mas isso não exime o material de erros e possíveis melhorias. Para que haja melhoras, nós contamos com o seu apoio. Caso você tenha alguma sugestão, reclamação ou até mesmo encontre algum tipo de erro nesse material, solicitamos que você entre em contato conosco. Dessa forma, poderemos analisar suas sugestões e reclamações para corrigir eventuais erros.

Para entrar em contato com o nosso Centro de Treinamento, escreva para [email protected]. Relate, pois, a sua sugestão, reclamação ou o erro encontrado e sua localização para que possamos fazer as devidas correções.

Você também dispõe do seguinte formulário para enviar-nos suas notações. Basta destacar essa folha, relatar sua sugestão e/ou reclamação e remeter ao seguinte endereço:

Centro de Treinamento DomínioAvenida Centenário, 7405Nossa Senhora da SaleteCriciúma – SC – CEP: 88815-001

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

Índice

Convenção de cursores, ícones e tipografia................................................................................9

Lista de Abreviaturas e Siglas...................................................................................................10

Visão Geral do Curso................................................................................................................11

Descrição..............................................................................................................................11

Público Alvo.........................................................................................................................11

Pré-requisitos........................................................................................................................11

Objetivos..............................................................................................................................11

1. Principais Tabelas e Colunas do Banco de Dados................................................................12

1.1. Domínio Contabilidade.................................................................................................12

1.2. Escrita Fiscal.................................................................................................................14

1.3. Folha de Pagamento......................................................................................................26

2. Relacionamentos Entre as Tabelas e Colunas.......................................................................32

2.1. Contabilidade.................................................................................................................32

2.1.1. Relação de Lançamentos em Lote.........................................................................32

2.1.2. Balancete................................................................................................................36

2.1.3. Balancete por Centro de Custos.............................................................................44

2.2. Escrita Fiscal.................................................................................................................48

2.2.1. Livro de Saídas......................................................................................................48

2.2.2. Contas a pagar........................................................................................................53

2.2.3. Movimento Individual de Produto.........................................................................60

2.2.4. Relação de Lançamentos Contábeis das Notas de Serviços..................................64

2.2.5. Saldo dos impostos................................................................................................66

2.3. Folha de Pagamentos.....................................................................................................68

2.3.1. Relação de Empregados e Contribuintes Ativos....................................................69

2.3.2. Bases de FGTS e INSS com Salário da Competência Informada..........................71

2.3.3. Resumo da Folha...................................................................................................75

2.3.4. Relação de Rescisões.............................................................................................77

2.3.5. Resumo de Férias (Períodos Aquisitivos X Férias Gozadas)................................81

3. Recursos Avançados.............................................................................................................89

3.1. Argumentos...................................................................................................................89

3.2. Tabela dbo.rowgenerator...............................................................................................90

3.3. Vetores...........................................................................................................................94

3.4. Sub-relatórios..............................................................................................................105

Centro de Treinamento Domínio A sua melhor escolha

Convenção de cursores, ícones e tipografia

A fonte Arial é utilizada para se referir a títulos de janelas, guias e quadros, por exemplo:

Abra a pasta Domínio Utilitários e dê duplo clique no ícone Gerador de Relatórios, para abrir a janela Conectando...

A fonte Arial em Negrito é utilizada para definir botões, ícones, menus e opções, em que você deverá clicar, por exemplo:

Clique no menu Relatórios, opção Gerenciador de Relatórios.

A fonte Arial em Itálico é utilizada para definir os nomes dos sistemas da Domínio, bem como marcas registradas citadas nesse material, por exemplo:

Este curso é direcionado a usuários e técnicos que participaram do treinamento de Introdução a SQL para o Domínio Gerador de Relatórios.

A fonte Arial Sublinhado é utilizada para definir os nomes dos campos de cadastros e janelas do Gerenciador de Relatórios, por exemplo:

No campo Descrição, digite um nome para a nova classificação.

A fonte Times New Roman em Itálico junto com o ícone abaixo são utilizados em observações importantes, que estarão dispostas nesse material, por exemplo:

O modo de edição Gráfico é para relatórios que serão impressos em impressoras jato de tinta e laser, já o modo de edição Texto é para relatórios que serão impressos em impressoras matriciais.

9


Lista de Abreviaturas e Siglas

CTRL – Control;

SQL – Structured Query Language.

10


Visão Geral do Curso

Descrição

A finalidade do curso do utilitário Domínio Gerador de Relatórios - II é apresentar aos nossos usuários e técnicos, os seguintes tópicos:

• As principais tabelas dos módulos Domínio Escrita Fiscal, Domínio Contabilidade e Domínio Folha;

• Relacionamento entre as tabelas para montagem de relatórios complexos;• Utilizar recursos avançados do Domínio Gerador de Relatórios.

Público Alvo

Esse curso é direcionado aos usuários e técnicos que participaram dos treinamentos de Introdução a SQL para o Domínio Gerador de Relatórios e Domínio Gerador de Relatórios I. O conhecimento a ser adquirido é inteiramente voltado a gerar relatórios nos vários módulos dos sistemas da Domínio.

Pré-requisitos

Para o estudante ter um bom desempenho durante o treinamento, é necessário que atenda aos seguintes requisitos:

• Completado o curso Introdução a SQL para o Domínio Gerador de Relatórios;• Completado o curso do Domínio Gerador de Relatórios I;• Ter familiaridade com os sistemas da Domínio.

Objetivos

Ao término desse treinamento, o aluno estará apto a realizar a seguinte função:

• Gerar seus próprios relatórios com base nos bancos de dados dos aplicativos Domínio.

11


1. Principais Tabelas e Colunas do Banco de Dados

Neste capítulo, serão apresentadas as principais tabelas e colunas dos módulos Domínio Escrita Fiscal, Domínio Contabilidade e Domínio Folha, com intuito de possibilitar a criação de consultas que poderão ser utilizadas, por exemplo, em relatórios de faturamento da empresa, balancetes e cálculos da folha, usando recursos aprendidos nos cursos de Introdução a SQL e Domínio Gerador de Relatórios I.

1.1. Domínio Contabilidade

Veja agora as principais tabelas e colunas envolvidas nos lançamentos contábeis, nos rateios de centros de custos e saldos de contas, que são as seguintes:

1. Tabela:

• bethadba.ctcontas : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Contas Contábeis – Cadastro (ctcontas). Ela é a

responsável por armazenar o cadastro das contas contábeis, observe na figura a seguir

que está sendo demonstrada a tabela e suas colunas.

12


2. Colunas:

• codi_emp : código da empresa a qual pertence a conta;

• codi_cta : código sequencial da conta;

• nome_cta : descrição da conta;

• clas_cta : classificação da conta (sem máscara, conforme já visto no treinamento do

utilitário Domínio Gerador de Relatórios I);

• tipo_cta : tipo da conta (S=Sintética/A=Analítica).

3. Tabela:

• bethadba.ctlanctolote : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Lançamento em lote. Trata-se da tabela referente ao lote dos

lançamentos contábeis.

4. Colunas:

• codi_lote : código sequencial do lote;

• tipo : tipo do lote (D=Um débito para vários créditos / C=Um crédito para vários

débitos / X=Um débito para um crédito / V=Vários débitos para vários créditos).

5. Tabela :

• bethadba.ctlancto : Essa tabela está disponível no Domínio Gerador de Relatórios

com o texto Lançamentos Contábeis, esta é a tabela que armazena os lançamentos

contábeis de cada lote.

6. Colunas:

• nume_lan : número sequencial de lançamentos dentro do lote;

• data_lan : data do lançamento;

• vlor_lan : valor do lançamento;

• cdeb_lan : conta débito;

• ccre_lan : conta crédito;

• chis_lan : código do histórico;

• orig_lan : origem do lançamento contábil (1=Normal / 2=Zeramento / 3=Patrimônio /

4=Escrita Fiscal / 5=Saídas / 6=Entradas / 7=Serviços / 8=Ajustes / 9=Acumuladores /

10=Apuração / 11=Pagamento Guia / 12=Domínio Cliente / 13=Folha de Pagamento /

14=Honorários);

• fili_lan : código da filial/matriz a qual corresponde o lançamento contábil;

• codi_lote: código do lote a qual o lançamento pertence.

13


Caso existam lançamentos contábeis desvinculados de lotes (lançados em data que não era obrigatório o lançamento em lote ou quando o sistema não comportava ainda tal

tipo de lançamentos), esses estarão gravados nessa mesma tabela contendo a colunacodi_lote nula.

7. Tabela:

• bethadba.ctclancto : Essa tabela está disponível no Domínio Gerador de

Relatórios como o texto Lançamento do centro de custo, refere-se a tabela

responsável por armazenar os lançamentos contábeis rateados por centro de custos.

8. Colunas:

• nume_ccu : número do lançamento contábil a qual pertence o rateio;

• cdeb_ccu : código do centro de custos lançado como débito;

• ccre_ccu : código do centro de custos lançado como crédito;

• codi_cta : código da conta contábil referente ao rateio;

• vlor_ccu : valor do rateio.

1.2. Escrita Fiscal

As principais tabelas e colunas do módulo Domínio Escrita Fiscal que poderão ser utilizadas para montagem de relatórios de faturamentos, relação de notas com seus impostos, como por exemplo, livros fiscais, parcelamentos e seus pagamentos e também lançamentos contábeis gerados por este módulo, serão demonstradas neste item.

1. Tabela:

• bethadba.efparametro : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Parâmetros – Cadastro – Escrita Fiscal, nela ficam os

dados gerais dos parâmetros das empresas, ou seja, aqueles dados que não dependem

da vigência, dados que estão na guia Personaliza da janela dos Parâmetros.

2. Colunas:

• peri_par : período atual de apuração;

• pini_par : período inicial de apuração;

• inicioefetivo_par : início efetivo das atividades;

• caixa_par : indica se a empresa usará controle de contas a pagar/receber (S=Sim /

N=Não);

• esto_par : indica se fará controle de estoque (1=Sim / 2=Não);

14


• digecf_par : indica se gera arquivo do Sintegra (S=Sim / N=Não);

• dipi_par : indica se gera movimentação de produtos para o Sintegra (1=Sim / 2=Não).

3. Tabela:

• bethadba.efparametro_vigencia : Essa tabela está disponível no Domínio Gerador

de Relatórios com o texto Parâmetros – Cadastro – Escrita Fiscal, ela grava

dados que dependem da vigência cadastrada nos parâmetros da empresa. Os dados

armazenados nesta tabela estão na guia Geral e basicamente nas subguias Federal,

Estadual, Municipal e Contabilidade.

4. Colunas:

• vigencia_par : competência da vigência cadastrada;

• descricao_par : descrição dada a vigência cadastrada;

• rfed_par : regime federal (1=Normal / 2=Microempresa / 4=Empresa de Pequeno

Porte / 5=Lucro Presumido);

• simplesn_optante_par : indica se é optante do Simples Nacional (S=Sim / N=Não);

• fili_par : processa filiais (S=Sim / N=Não);

• crffatger_par : fato gerador da CRF (E=Emissão / P=Pagamento);

• irrffatger_par : fato gerador do IRRF (E=Emissão / P=Pagamento);

• crfopfatger_par : fato gerador da CRFOP (E=Emissão / P=Pagamento);

• irrfpfatger_par : fato gerador do IRRFP (E=Emissão / P=Pagamento);

• simplesn_codigo_acesso_par : código do acesso para o Simples Nacional;

• rest_par : regime estadual (1=Normal / 2=Microempresa / 3=Estimativa / 4=Empresa

de Pequeno Porte / 7=Bares, Rest. e Similares / 13=Simples Nacional);

• lctb_par : indica se gera lançamentos contábeis (S=Sim / N=Não);

• codmat_par : código da empresa que gerará lançamentos contábeis.

Existem outras tabelas que são utilizadas para gravar outros dados dos parâmetros,como por exemplo bethadba.efparametro_vigencia_impostos que armazena osimpostos utilizados na vigência e bethadba.efparametro_vigencia_eventos_hnpara armazenar os dados de eventos do módulo Domínio Honorários, além deoutras.

Nos cadastros de impostos e acumuladores, também existem tabelas que armazenamdados gerais para cada registro (cada imposto ou cada acumulador) e outra tabelapara guardar informações separadas por vigência.

15


5. Tabela:

• bethadba.efentradas : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Entradas, refere-se a tabela que armazena

os dados da nota fiscal de entrada.

6. Colunas

• codi_ent : código sequencial da nota fiscal de entrada;

• codi_for : código do fornecedor;

• codi_esp : código da espécie;

• codi_acu : código do acumulador;

• codi_nat : CFOP da nota;

• nume_ent : número do documento fiscal;

• segi_ent : segmento da nota;

• seri_ent : série do documento;

• atex_ent : número do documento final (quando não informado, gravará zero);

• dent_ent : data de entrada;

• ddoc_ent : data de emissão;

• vcon_ent : valor contábil;

• emitente_ent : emitente da nota (P=Próprio / T=Terceiros);

• vprod_ent : valor dos produtos;

• situacao_ent : situação do documento (0=Documento regular / 1=Documento regular

extemporâneo / 2=Documento cancelado / 6=Documento fiscal complementar /

referenciado / 9=Documento fiscal emitido com base em Regime Especial /

10=Documento fiscal complementar extemporâneo).

7. Tabela:

• bethadba.efimpent : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Entrada – Impostos, corresponde a

tabela responsável pelo detalhamento dos impostos das notas de entradas. Apenas são

gravados nesta tabela, os impostos que foram definidos com o tipo Lançados em seu

cadastro. A seguir, suas principais colunas:

8. Coluna:

• codi_ent : identifica a qual nota pertence o imposto;

• codi_imp : código do imposto;

16


• bcal_ien : base de cálculo do imposto;

• aliq_ien : alíquota do imposto;

• vlor_ien : valor do imposto;

• vise_ien : valor de isentas;

• vout_ien : valor de outras;

• vcon_ien : valor contábil do registro do imposto.

9. Tabela:

• bethadba.efentradaspar : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Entradas – Parcelas, esta tabela

armazena as parcelas geradas para a nota. Suas principais colunas são as seguintes:

10. Colunas:

• codi_ent : identifica a qual nota pertence a parcela;

• parc_entp : sequencial da parcela na nota;

• vcto_entp : vencimento da parcela;

• vlor_entp : valor da parcela;

• vbru_entp : valor bruto da parcela.

11. Tabela:

• bethadba.efentradaspag : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Entrada – Pagamento das Parcelas, a

tabela é responsável por armazenar os pagamentos das parcelas das notas de entradas.

Suas principais colunas estão a seguir:

12. Colunas:

• codi_ent : identifica a nota pertencente ao pagamento;

• parc_entp : identifica a parcela pertencente ao pagamento;

• nropag_entp : sequencial do pagamento da parcela (pois uma parcela pode ser paga

em etapas até completar o valor integral);

• pgto_entp : data do pagamento;

• tipo_entp : tipo do pagamento (1=Normal / 2=Juros / 3=Multa / 4=Desconto /

5=Devolução / 6=PIS / 7=COFINS / 8=CSOC / 9=CRF / 10=IRRF / 11=IRRFPF, ou

seja, quando existir o pagamento de uma parcela com juros e multas, serão gerados

três registros nesta tabela, sendo um com o tipo normal, referenciando o pagamento do

valor da parcela, outro para juros cobrados e mais um para a multa);

17


• vpag_entp : valor do pagamento.

13. Tabela:

• bethadba.efmvepro : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Entrada – Produtos, esta tabela

armazena os dados da guia Estoque das notas de entradas ou entradas extras.

Algumas das suas colunas são as seguintes:

14. Colunas:

• codi_ent : identifica a nota a qual pertence o registro;

• nume_mep : sequencial de produto na nota;

• codi_pdi : código do produto lançado;

• qtde_mep : quantidade do produto;

• vlor_mep : valor total;

• vipi_mep : valor do IPI para o produto;

• bcal_mep : base de cálculo do IPI;

• orig_mep : identifica a origem do registro (1=Lançamento na nota / 2=Entradas

extras);

• data_mep : data de entrada do produto;

• cst_mep : CST do ICMS;

• vpro_mep : valor do produto;

• vdes_mep : valor do desconto;

• bicms_mep : base do ICMS;

• bicmsst_mep : base da Subtri;

• aliicms_mep : alíquota do ICMS;

• valor_icms_mep : valor do imposto ICMS;

• valor_unit_mep : valor unitário do produto;

• (outras colunas de impostos e códigos de situações tributárias referentes a outros

impostos).

Quando o lançamento do produto for feito por Entradas Extras, várias colunasficarão nulas ou zeradas.

18


15. Tabela:

• bethadba.efentradas_lancto : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas de entradas X Lançamentos contábeis, esta tabela

é responsável por indicar quais lançamentos contábeis foram originados para a nota de

entrada. Suas colunas são as seguintes:

16. Colunas:

• nume_lan : número do lançamento contábil vinculado à nota;

• fili_lan : código da empresa (filial ou a própria matriz) que pertence a nota;

• codi_ent : código da nota que gerou o lançamento contábil.

17. Tabela:

• bethadba.efsaidas : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Saídas, refere-se a tabela que armazena os

dados das notas fiscais de saídas, conforme colunas abaixo:

18. Colunas:

• codi_sai : código sequencial da nota fiscal de saída;

• codi_cli : código do cliente;



• codi_nat : CFOP da nota;

• nume_sai : número do documento fiscal;

• segi_sai : segmento da nota;

• seri_sai : série do documento;

• atex_sai : número do documento final (quando não informado, gravará zero);

• dsai_sai : data de saída;

• ddoc_sai : data de emissão;

• cifob_sai : modalidade do frete (C=CIF / F=FOB);

• vcon_sai : valor contábil;

• vprod_sai : valor dos produtos;

• situacao_sai : situação do documento (0=Documento regular / 1=Documento regular

extemporâneo / 2=Documento cancelado / 3=Cancelamento de cupom fiscal anterior /

4=Documento cancelado extemporâneo / 5=Desfazimento de negócios / 6=Documento

fiscal complementar/referenciado / 7=NF-e ou CT-e denegado / 8=NF-e ou CT-e

19


Numeração inutilizada / 9=Documento fiscal emitido com base em Regime Especial /

10=Documento fiscal complementar extemporâneo).

19. Tabela:

• bethadba.efimpsai : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Saídas – Impostos, corresponde a tabela

responsável pelo detalhamento dos impostos das notas de saídas. Apenas são gravados

nesta tabela, os impostos do tipo Lançados definidos em seu cadastro. A seguir, suas

principais colunas:

20. Colunas:

• codi_sai: identifica a qual nota pertence o imposto;


• bcal_isa : base de cálculo do imposto;

• aliq_isa : alíquota do imposto;

• vlor_isa : valor do imposto;

• vise_isa : valor de isentas;

• vout_isa : valor de outras;

• vcon_isa : valor contábil do registro do imposto.

21. Tabela:

• bethadba.efsaidaspar : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Saídas – Parcelas, esta tabela armazena

as parcelas geradas para a nota. Suas principais colunas são as seguintes:

22. Colunas:

• codi_sai : identifica a qual nota pertence a parcela;

• parc_saip : sequencial da parcela na nota;

• vcto_saip : vencimento da parcela;

• vlor_saip : valor da parcela;

• vbru_saip : valor bruto da parcela.

23. Tabela:

• bethadba.efsaidaspag : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Saídas – Pagamento das Parcelas, a

tabela é responsável por armazenar os pagamentos das parcelas das notas de saídas.


20


24. Colunas:

• codi_sai : identifica a nota pertencente ao pagamento;

• parc_saip : identifica a parcela pertencente ao pagamento;

• nropag_saip : sequencial do pagamento da parcela (uma parcela pode ser paga em

etapas até completar o valor integral);

• pgto_saip : data do pagamento;

• tipo_saip : tipo do pagamento (1=Normal / 2=Juros / 3=Multa / 4=Desconto /

5=Devolução / 6=PIS / 7=COFINS / 8=CSLL / 9=IRRF / 11=PISOP /

12=COFINSOP / 13=CSLLOP / 14=IRPJOP / 15=IRRFP, ou seja, quando existir o

pagamento de uma parcela com juros e multas, serão gerados três registros nesta

tabela, sendo um com o tipo normal, referenciando o pagamento do valor da parcela,

outro para juros cobrados e mais um para a multa);

• vpag_saip : valor do pagamento.

25. Tabela:

• bethadba.efmvspro : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Saídas – Produtos, esta tabela armazena

os dados da guia Estoque das notas de saídas ou saídas extras. Algumas das suas

principais colunas são as seguinte:

26. Colunas:

• codi_sai : identifica a nota a qual pertence o registro;

• nume_msp : sequencial de produto na nota;

• codi_pdi : código do produto lançado;

• qtde_msp : quantidade do produto;

• vipi_mep : valor do IPI para o produto;

• bcal_msp : base de cálculo do IPI;

• orig_msp : identifica a origem do registro (1=Lançamento na nota / 2=Saídas extras);

• data_msp : data de entrada do produto;

• cst_msp : CST do ICMS;

• vpro_msp : valor do produto;

• vdes_msp : valor do desconto;

• bicms_msp : base do ICMS;

• bicmsst_msp : base da Subtri;

21


• aliicms_msp : alíquota do ICMS;

• valor_icms_mep : valor do imposto ICMS;

• valor_unit_msp : valor unitário do produto;

• (outras colunas de impostos e códigos de situações tributárias referentes a outros

impostos).

Quando o lançamento do produto for feito por Saídas Extras, várias colunas ficarãonulas ou zeradas.

27. Tabela:

• bethadba.efsaidas_lancto : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas de saídas X Lançamentos contábeis, esta tabela é

responsável por indicar quais lançamentos contábeis foram originados para a nota de

saída. Suas colunas são as seguintes:

28. Colunas:



• codi_sai : código da nota que gerou o lançamento contábil.

29. Tabela:

• bethadba.efservicos : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Serviço, refere-se a tabela que armazena

os dados das notas fiscais de serviços, conforme colunas abaixo:

30. Colunas:

• codi_ser : código sequencial da nota fiscal de serviço;

• codi_cli : código do cliente;



• nume_ser : número do documento fiscal;

• segi_ser : segmento da nota;

• seri_ser : série do documento;

• atex_ser : número do documento final (quando não informado, gravará zero);

• dser_ser : data de saída;

• ddoc_ser : data de emissão;

22


• vcon_ser : valor contábil;

• situacao_ser : situação do documento (0=Documento regular / 1=Documento regular

extemporâneo / 2=Documento cancelado / 3=Cancelamento de cupom fiscal anterior /

4=Documento cancelado extemporâneo / 5=Desfazimento de negócios / 6=Documento

fiscal referenciado).

31. Tabela:

• bethadba.efimpser : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Serviço – Impostos, corresponde a tabela

responsável pelo detalhamento dos impostos das notas de serviços. Apenas são

gravados nesta tabela, os impostos do tipo Lançados definidos em seu cadastro. A

seguir, suas principais colunas:

32. Colunas:

• codi_ser : identifica a qual nota pertence o imposto;


• bcal_ise : base de cálculo do imposto;

• aliq_ise : alíquota do imposto;

• vlor_ise : valor do imposto;

• vise_ise : valor de isentas;

• vout_ise : valor de outras;

• vcon_ise : valor contábil do registro do imposto.

33. Tabela:

• bethadba.efservicospar : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Serviço – Parcelas, esta tabela armazena

as parcelas geradas para a nota. Suas principais colunas são as seguintes:

34. Colunas:

• codi_ser : identifica a qual nota pertence a parcela;

• parc_serp : sequencial da parcela na nota;

• vcto_serp : vencimento da parcela;

• vlor_serp : valor da parcela;

• vbru_serp : valor bruto da parcela.

35. Tabela

23


• bethadba.efservicospag : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas Fiscais de Serviços – Pagamento das Parcelas, a

tabela é responsável por armazenar os pagamentos das parcelas das notas de serviços.


36. Colunas:

• codi_ser : identifica a nota pertencente ao pagamento;

• parc_serp : identifica a parcela pertencente ao pagamento;

• nropag_serp : sequencial do pagamento da parcela (uma parcela pode ser paga em

etapas até completar o valor integral);

• pgto_serp : data do pagamento;

• tipo_serp : tipo do pagamento (1=Normal / 2=Juros / 3=Multa / 4=Desconto /

5=Devolução / 6=PIS / 7=COFINS / 8=CSLL / 9=IRRF / 11=PISOP /

12=COFINSOP / 13=CSLLOP / 14=IRPJOP / 15=IRRFP, ou seja, quando existir o

pagamento de uma parcela com juros e multas, serão gerados três registros nesta

tabela, sendo um com o tipo normal, referenciando o pagamento do valor da parcela,

outro para juros cobrados e mais um para a multa);

• vpag_serp : valor do pagamento.

37. Tabela:

• bethadba.efservicos_lancto : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Notas de serviços X Lançamentos contábeis, esta tabela

é responsável por indicar quais lançamentos contábeis foram originados para a nota de

serviços. Suas colunas são as seguintes:

38. Colunas:



• codi_ser : código da nota que gerou o lançamento contábil.

39. Tabela:

• bethadba.efsdoimp : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Saldo dos Impostos, esta tabela é responsável por

armazenar o resultado dos impostos ao final da apuração. Suas colunas são as

seguintes:

40. Colunas:

24


• codi_imp : código do imposto apurado;

• data_sim : competência da apuração;

• pdic_sim : periodicidade da apuração (1=1º Decêndio / 2=2º Decêndio / 3=3º

Decêndio / 4=1ª Quinzena / 5=2ª Quinzena / 6=Mensal / 7=Trimestral / 11=1ª

Semana / 12=2ª Semana / 13=3ª Semana / 14=4ª Semana / 15=5ª Semana /

51=Complementar / 52=13º Salário);

• sdev_sim : saldo a recolher;

• scre_sim : saldo credor;

• vcoe_sim : valor contábil das entradas;

• bcae_sim : valor da base de cálculo das entradas;

• vime_sim : valor do imposto das entradas;

• vise_sim : valor de isentas do imposto das entradas;

• voue_sim : valor de outras do imposto das entradas;

• vcos_sim : valor contábil das saídas;

• bcas_sim : valor da base de cálculo das saídas;

• vims_sim : valor do imposto das saídas;

• viss_sim : valor de isentas do imposto das saídas;

• vous_sim : valor de outras do imposto das saídas;

• vcov_sim : valor contábil dos serviços;

• bcav_sim : valor da base de cálculo dos serviços;

• vimv_sim : valor do imposto dos serviços;

• visv_sim : valor de isentas do imposto dos serviços;

• vouv_sim : valor de outras do imposto dos serviços;

• outc_ sim : total de outros créditos/outros recolhimentos;

• outd_sim : total de outros débitos/outras despesas;

• dpag_sim : data do pagamento do imposto;

• dvct_sim : data do vencimento do imposto;

• vlrpago_sim : valor pago do imposto.

25


1.3. Folha de Pagamento

Abaixo serão detalhadas algumas das tabelas e colunas utilizadas pelo módulo Domínio Folha. Entre elas estarão as tabelas utilizadas no cálculo da folha, cálculo de rescisões e férias.

1. Tabela:

• bet hadba.foempregados : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Empregados – Cadastro, esta tabela armazena o cadastro

de empregados e também de contribuintes. Abaixo, algumas das colunas da tabela que

identificam o tipo de empregado e também o tipo de contribuinte:

2. Colunas

• i_empregados : código sequencial do empregado;

• nome : nome do empregado;

• salario : salário atual do empregado;

• admissao : data de admissão;

• tipo_epr : tipo do empregado (1=Empregado / 2=Contribuinte);

• tipo_contrib : tipo do contribuinte (X=Empregado / R=Produtor rural / A=Autônomo /

E=Empregador / F=Facultativo / M=Microempreendedor individual).

A tabela possui várias outras colunas que podem ser facilmente identificadasvisualizando-as no Domínio Gerador de Relatórios.

3. Tabela:

• bethadba.foafastamentos : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Afastamentos dos empregados, esta é responsável por

guardar o histórico de afastamentos dos empregados. Suas principais colunas são:

4. Colunas:

• i_empregados : código do empregado;

• data_real : data do afastamento;

• i_afastamentos : código do afastamento (conforme códigos padrões disponíveis no

sistema).

26


Os empregados terão um registro inicial com a data da troca igual a data daadmissão e com o código do afastamento igual a 1, representando a situaçãoTrabalhando.

5. Tabela:

• bethadba.foaltesal : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Salário – Processos, esta tabela é responsável por

armazenar as alterações salariais dos empregados. Abaixo estão algumas de suas

colunas:

6. Colunas:


• competencia : competência da alteração;

• tipo_alt_grade : tipo da alteração para professores (0=Não é professor / 1=Salário /

2=Grade);

• novo_salario : salário alterado;

• periodo_inicio : competência em que o salário iniciou;

• periodo_fim : competência em que o salário finalizou.

Esta tabela gera um registro com a competência da troca preenchida com acompetência da data da admissão do empregado quando o cadastro é realizado.

As colunas periodo_inicio e periodo_fim são atualizadas a cada nova alteração.Inicialmente, quando não há trocas, no único registro existente as competências sãogravadas como 01/01/1900 e 01/12/3000. Quando há uma nova troca, a data final doprimeiro registro é atualizada para um mês antes que a competência da troca. Já nonovo registro, a competência inicial será a própria da troca e a final 01/12/3000.

7. Tabela:

• bethadba.fobasesserv : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Bases – Cálculo, a tabela armazena dados de bases do

cálculo da folha e as principais colunas são:

8. Colunas:

• i_empregados : código do empregado calculado;

• competencia : competência do cálculo;

27


• tipo_process : tipo do cálculo (11=Mensal / 21=1ª Quinzena / 22=2ª Quinzena / 31=1ª


41=Adiantamento Mensal / 42=Complementar / 51=Adiantamento 13º / 52=13º

Integral / 60=Férias / 61=Férias);

• num_filhos : número de filhos para base do salário família;

• num_dependentes : número de dependentes para base do imposto de renda;

• proventos : total de proventos do cálculo;

• descontos : total de descontos do cálculo;

• rateio : indica se o registro corresponde ao valor integral ou ao rateio do serviço;

• salario_mes : salário do mês;

• data_pagto : data do pagamento;

• i_calculos : código de referência a tabela dos valores das bases.

A tabela fobasesserv possui várias colunas que não são mais utilizadas pelosistema. Os dados são armazenados de maneira diferente em outra tabela que serávista em seguida.

9. Tabela:

• bethadba.focalculos : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Cálculo – Sequência de cálculos, esta tabela armazena

apenas uma chave primária referenciando os cálculos realizados e que possuirão bases

de cálculos. Sua única coluna é a seguinte:

10. Coluna:

• i_calculos : código sequencial gerado pelo cálculo.

11. Tabela:

• bethadba.focalculosbases : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Cálculos – Bases de cálculos, esta tabela armazena as

bases, as taxas e seus valores gerados pelos cálculos efetuados no módulo Domínio

Folha, como por exemplo, FGTS, INSS, entre outros. Suas principais colunas são:

12. Colunas:

• i_calculosbases : sequencial dos cálculos feitos;

• i_calculos : código de referência;

28


• i_cadbases : código da base a qual refere-se o registro (lista dos códigos será vista em

outro tópico);

• base : valor da base calculada;

• taxa : valor da taxa aplicada;

• valor : valor calculado.

13. Tabela:

• bethadba.fomovtoserv : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Movimentação – Cálculo, esta tabela é responsável por

guardar dados dos eventos de todos os cálculos da folha de pagamento. Suas principais

colunas são:

14. Colunas:

• i_empregados : código do empregado calculado;

• data : competência do cálculo;

• tipo_proces : tipo do cálculo (11=Mensal / 21=1ª Quinzena / 22=2ª Quinzena / 31=1ª


41=Adiantamento Mensal / 42=Complementar / 51=Adiantamento 13º / 52=13º

Integral / 60=Férias / 61=Férias);

• i_eventos : código do evento calculado;

• valor_inf : valor de referência do evento;

• valor_cal : valor calculado do evento;

• prov_desc : indica se o evento é um provento ou um desconto;

• rateio : indica se o registro corresponde ao valor integral ou ao rateio do serviço.

A coluna rateio, tanto da tabela de bases como da tabela de movimentação da folha,poderá receber o valor 0 ou 1, sendo que quando corresponder ao registro com valor0, indicará o valor integral calculado para tal registro (base ou evento). No registrodo valor 1, indicará o rateio do serviço, caso a empresa esteja configurada para fazerrateio por serviço e exista uma troca de serviço para o empregado na competência.

Existe também a coluna origem que recebe o valor C, indicando que o evento éproveniente de um cálculo de folha mensal e R de uma rescisão. Neste caso, a colunatipo_proces armazena o valor 11 para ambos os cálculos, então o campo origem éusado para distinguir os dados.

29


15. Tabela:

• bethadba.forescisoes : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Rescisão – Cálculo, esta tabela é responsável por armazenar

os dados do cálculo da rescisão. Logo abaixo, algumas das colunas que a tabela possui:

16. Colunas:


• demissao : data da demissão;

• motivo : código do motivo da demissão (conforme imagem abaixo);

• data_aviso : data do aviso prévio;

• aviso_indenizado : indica se o aviso prévio foi indenizado (S=Sim / N=Não);

• salario : salário do empregado no mês;

• proventos : total de proventos da rescisão;

• descontos : total de descontos da rescisão;

• tipo : tipo da rescisão (1=Normal / 2=Complementar);

• data_pagto : data do pagamento da rescisão.

17. Tabela:

• bethadba.foferias_aquisitivos : Essa tabela está disponível no Domínio Gerador

de Relatórios com o texto Cadastros de períodos aquisitivos, é responsável por

armazenar os períodos aquisitivos dos empregados. Algumas de suas colunas são as

seguintes:

18. Colunas:

30



• i_ferias_aquisitivos : sequencial do período aquisitivo;

• data_inicio : data inicial do período aquisitivo;

• data_fim : data final do período aquisitivo;

• situacao : situação do período aquisitivo (1=Em aberto / 2=Parcialmente gozado /

3=Gozado / 4=Perda por afastamentos / 5=Perda por faltas);

• dias_direito : dias de férias que o empregado tem direito;

• dias_gozados : dias gozados.

19. Tabela:

• bethadba.foferias_gozo : Essa tabela está disponível no Domínio Gerador de

Relatórios com o texto Controle de gozo de ferias, esta tabela corresponde às

férias gozadas dos empregados. Algumas das colunas estão abaixo:

20. Colunas:


• i_feiras_gozo : sequencial das férias gozadas;

• i_feiras_aquisitivos : sequencial que indica a qual período aquisitivo o gozo foi

realizado;

• gozo_inicio : data inicial do gozo;

• gozo_fim : data final do gozo;

• data_pagto : data do pagamento das férias.

31


2. Relacionamentos Entre as Tabelas e Colunas

Aqui você verá como criar consultas relacionando as tabelas e algumas colunas que foram detalhadas no capítulo 1 para encontrar dados fundamentais na emissão de relatórios completos.

2.1. Contabilidade

A seguir, teremos o desenvolvimento de alguns relatórios contendo dados do módulo Domínio Contabilidade. Os relatórios consistem em emitir uma relação de lançamentos em lote, um balancete com saldo das contas analíticas e sintéticas e também um balancete por centro de custos com intuito de mostrar onde utilizar, quando e principalmente, como realizar os relacionamentos adequados.

2.1.1. Relação de Lançamentos em Lote

O relatório que será montado emitirá os lançamentos contábeis separados por lote e somente aparecerá os registros que possuírem vínculo com lote. Primeiramente selecionamos as colunas que desejamos aparecer, conforme já visto no curso Domínio Gerador de Relatórios I. As colunas da tabela de lotes serão as seguintes:

• ctlanctolote.codi_lote ;

• ctlanctolote.tipo .

Criando o relatório utilizando apenas a tabela de lançamentos em lote, não teríamos maiores detalhes dos lançamentos, como por exemplo, as contas envolvidas, o valor e o histórico. As demais colunas utilizadas serão da tabela de lançamentos contábeis, conforme abaixo:

• ctlancto.nume_lan ;• ctlancto.data_lan ;• ctlancto.data_lan ;• ctlancto.cdeb_lan ,• ctlancto.ccre_lan ;• ctlancto.chis_lan .

A inserção destas colunas gerará automaticamente o SQL fazendo relacionamentos entre elas indicando que somente serão emitidos os registros que possuírem em comum, o código da empresa e o código do lote, conforme imagem:

32


Para a emissão do relatório não listar todos lançamentos em lote de todas as empresas, criaremos três argumentos, um para o usuário informar o código da empresa, outro para informar a data inicial e mais um para a data final que deseja listar o relatório. Em seguida, criar os relacionamentos com estes argumentos, conforme já visto no curso Domínio Gerador de Relatórios I. Além disso, recomenda-se ordenar o relatório pelo código do lote devido a necessidade de criar uma quebra.

Em seguida, teremos de adequar o leiaute do relatório, posicionando no cabeçalho da quebra do código do lote, as colunas referentes ao código do lote e ao tipo do lote. Desta forma o relatório será listado conforme imagem abaixo:

É possível perceber na imagem acima, que foi criada uma quebra pelo lote, evitando que o mesmo saísse repetido conforme a quantidade de lançamentos existentes para ele e também percebe-se que o tipo do lote contém diferentes valores, que são os seguintes:

• X: um débito para um crédito;

• D: um débito para vários créditos;

• C: um crédito para vários débitos;33


• V: vários débitos para vários créditos.

Uma característica do sistema e do relacionamento entre estas duas tabelas, é que somente quanto o tipo do lote for X (um débito para um crédito) o registro do lançamento (tabela ctlancto) terá as contas débito e crédito informadas na mesma linha. O restante dos tipos somente grava uma das contas a cada registro, deixando a contrapartida zerada (de acordo com imagem anterior).

Para não aparecer as letras X, D, C ou V, pode-se utilizar o recurso de tabela de valores do objeto coluna, conforme imagem a seguir:

Nota-se também que no histórico do lote 2, foi feita uma quebra de linha automaticamente. Este recurso é proveniente da opção Auto-dimensionar marcada, que encontramos nas propriedades do objeto coluna, na guia Posição, conforme imagem abaixo:

Caso a opção esteja desmarcada e o conteúdo do campo seja maior que o tamanho doobjeto, o texto será cortado e não mostrará todo o conteúdo.

Inserindo computados no rodapé da quebra, pode-se encontrar os totais de débito e de crédito utilizando a função “SUM(#x for gruop x)”, porém, devido a particularidade da tabela

34


de lançamentos, caso desejam buscar o total de lançamentos a débito, por exemplo, será necessário criar uma expressão diferenciada, conforme exemplo abaixo:

• Se a conta débito existir no registro, irá somar o valor do lançamento para o totalizador

de débitos utilizando a expressão:

SUM( if( ctlancto_cdeb_lan > 0, ctlancto_vlor_lan, 0 ) for group 1 )

• Se a conta crédito existir no registro, irá somar o valor do lançamento para o

totalizador de créditos utilizando a expressão:

SUM( if( ctlancto_ccre_lan > 0, ctlancto_vlor_lan, 0 ) for group 1 )

A sintaxe da estrutura de condição “if()” nas expressões do objeto computado tem as seguintes regras:

if( [condicao] , [faz isso se a condição for verdadeira], [senão faz isso se for falsa] )

Nos exemplos acima tínhamos um retorno contendo o valor do lançamento ou o valor zero na estrutura de condição “if()”. Caso a condição fosse verdadeira, retornaria o valor do lançamento, caso fosse falsa, retornaria zero. Este retorno do “if()” é utilizado para somar no totalizador do grupo.

Com os totalizadores, o leiaute do relatório poderia ficar da seguinte maneira:

Desta forma, o resultado da emissão do relatório seria a seguinte:

35


Assim finalizamos o modelo do relatório que lista os lançamentos contábeis separados por lote e juntamente, as características das tabelas envolvidas e seus relacionamentos. Em seguida, iniciaremos o desenvolvimento de um balancete.

2.1.2. Balancete

Neste modelo será mostrado o que é necessário fazer de consultas e relacionamentos para buscar o saldo de uma conta, tanto analítica como sintética. Como este tipo de relatório emite basicamente a estrutura do plano de contas e seus saldos, o mesmo será desenvolvido partindo de uma relação simples das contas, selecionando inicialmente apenas colunas da tabela de contas contábeis ctcontas, conforme abaixo:

• ctcontas.codi_cta ;

• ctcontas.nome_cta ;• ctcontas.clas_cta ;• ctcontas.tipo_cta .

O relatório terá colunas demonstrando o saldo anterior da conta, o total de débito do período, o total de crédito do período e o saldo atual. Para que possamos fazer estas separações, precisamos nos referenciar em algum período e por isso criaremos inicialmente, três argumentos. Um para informar o código da empresa e outros para as datas inicial e final.

36


No módulo Domínio Contabilidade, a empresa pode estar configurada para utilizaro plano de contas de outra empresa. Neste caso, o relatório terá de possuir areferência da empresa origem do plano de contas, inserindo a tabela de parâmetrosda contabilidade (que não citamos no capítulo 1). Abaixo estão detalhes do queprecisará ser inserido no relatório para listar o plano de contas corretamente.

Existem diferentes maneiras de resolver esta situação, mas adotaremos a inserção de uma coluna da tabela de parâmetros, juntamente com as colunas já selecionadas. Será necessário localizar a tabela com descrição Parametros ( ctparmto ) e inserir a coluna masc_par. Em seguida, criar os seguintes relacionamentos na guia Seleção:

A função IsNull() foi vista no curso Introdução a SQL para Domínio Gerador deRelatórios.

O resultado da emissão poderá sair de forma desordenada, por isso é importante a criação de uma ordenação e no balancete, o correto é fazer a ordem pela classificação da conta contábil. Esta funcionalidade foi vista no curso Domínio Gerador de Relatórios I.

Na guia Computados serão criadas as consultas dos saldos das contas, utilizando a tabela de lançamentos contábeis. Na primeira linha desta guia, insira os seguintes dados para buscar o saldo das contas analíticas:

• nome: deb_atu_a;

A função isNull apresentada a seguir, deve ser informada na coluna Definição daguia Computados, tudo em uma mesma linha, não podendo ter quebras de linhas enem identação.

• definição: isNull((SELECT sum(ctlancto.vlor_lan)

FROM bethadba.ctlancto

WHERE ctlancto.codi_emp = ctparmto.codi_emp AND

ctlancto.cdeb_lan = ctcontas.codi_cta AND

ctlancto.data_lan BETWEEN :data_ini AND :data_fim), 0)

Este SQL fará a consulta nos lançamentos contábeis que possuírem a conta lançada a débito, somando a coluna do valor do lançamento quando feito no período informado nos argumentos, considerando que data_ini e data_fim são os nomes dos argumentos criados anteriormente. A coluna ficará zerada quando o tipo da conta for Sintética por não existir

37


lançamentos contábeis contendo a conta sintética informada diretamente na janela de lançamentos.

O mesmo precisará ser feito para buscar o total da conta lançada a crédito no período, porém, criando uma nova subconsulta na guia Computados com o nome cre_atu_a e na definição, alteração a coluna ctlancto.cdeb_lan para ctlancto.ccre_lan da seleção, ficando da seguinte forma:

Utilizando estas colunas, teríamos na emissão do relatório, apenas o saldo do período das contas analíticas. Inserindo a coluna abaixo, será buscado o total de lançamentos a débito para as contas sintéticas:

• nome: deb_atu_s;


FROM bethadba.ctlancto, bethadba.ctcontas AS contas


contas.codi_emp = ctcontas.codi_emp AND

ctlancto.cdeb_lan = contas.codi_cta AND

ctcontas.tipo_cta = 'S' AND

ctcontas.clas_cta =

LEFT(contas.clas_cta, length(ctcontas.clas_cta)) AND

ctlancto.data_lan BETWEEN :data_ini AND :data_fim), 0)

Esta consulta buscará o saldo a débito das contas sintéticas apenas e ficará com valor zero quando a conta for do tipo Analítica, pois existe uma seleção indicando que somente somará quando a conta for sintética.

O mesmo terá de ser feito para buscar o total a crédito das contas sintéticas, porém, o nome será cre_atu_s e também precisa alterar a definição, substituindo a coluna ctlancto.cdeb_lan por ctlancto.ccre_lan na seleção.

Nas consultas das contas sintéticas foi utilizada novamente a tabela do plano decontas. Isso se fez necessário pois somente é possível identificar quais contasanalíticas pertencem a uma conta sintética, pela sua classificação. Desta forma foifeita a seleção, buscando as contas analíticas que iniciam com a mesma classificaçãodas contas sintéticas.

O saldo inicial de cada conta também necessitará de quatro novas colunas, sendo duas para encontrar o saldo das contas sintéticas e outras duas para o saldo das contas analíticas, seguindo o mesmo padrão do que foi feito até o momento.

38


Criaremos então as colunas deb_ant_a, cre_ant_a, deb_ant_s e cre_ant_s. Todas utilizarão SQLs muito semelhantes aos já usados anteriormente, alterando apenas a seleção das datas. Onde existir a seleção “ctlancto.data_lan BETWEEN :data_ini AND :data_fim”, será alterado para “ctlancto.data_lan < :data_ini”.

Esta mudança fará com que nas novas colunas do saldo anterior, busque a soma dos lançamentos que foram feitos com data menor que a data inicial informada nos argumentos. Abaixo estão detalhadas as sintaxes das colunas que retornarão o saldo inicial a débito das contas analíticas e sintéticas, respectivamente:

• nome: deb_ant_a;


FROM bethadba.ctlancto


ctlancto.cdeb_lan = ctcontas.codi_cta AND

ctlancto.data_lan < :data_ini), 0);

• nome: deb_ant_s;


FROM bethadba.ctlancto, bethadba.ctcontas AS contas


contas.codi_emp = ctcontas.codi_emp AND

ctlancto.cdeb_lan = contas.codi_cta AND

ctcontas.tipo_cta = 'S' AND

ctcontas.clas_cta =

LEFT(contas.clas_cta, length(ctcontas.clas_cta)) AND

ctlancto.data_lan < :data_ini), 0).

Com estas oito colunas, o relatório já possui todos os dados necessários para mostrar o saldo anterior, o saldo do período separado em débito e crédito e também o saldo atual que será um cálculo com todas essas colunas. Abaixo, a imagem que demonstra todas as oito colunas utilizadas (não é possível demostrar o SQL de todas, devido ao tamanho da consulta necessária):

O SQL do relatório está praticamente pronto, necessitando agora manipular o leiaute dele para melhor visualização, deixando os campos semelhante a imagem abaixo:

39


Com o atalho Ctrl+T é possível fazer a seleção de todos os campos ao mesmo tempo.Também poderá manter a tecla Ctrl pressionada e após selecionar todos, clicar sobrealguns campos que não deseja apagar, deixando-os não selecionados. Isso será útilpara remover os objetos que são inseridos automaticamente pelo Domínio Geradorde Relatórios.

Na imagem também foi mostrada a expressão do objeto computado que mostra o saldo anterior da conta. Abaixo estão as expressões de cada um dos campos:

• Saldo anterior: (deb_ant_a - cre_ant_a) + (deb_ant_s - cre_ant_s);

• Débito: deb_atu_a + deb_atu_s;

• Crédito: cre_atu_a + cre_atu_s;

• Saldo atual: (deb_ant_a - cre_ant_a) + (deb_ant_s - cre_ant_s) + (deb_atu_a -

cre_atu_a) + (deb_atu_s - cre_atu_s).

Na emissão do relatório temos o seguinte resultado:

40


Algumas contas sem saldos poderiam ser inibidas do relatório, pois ficam com todos os campos zerados. É possível evitar que elas sejam emitidas criando seleções com as colunas inseridas, fazendo com que somente serão mostradas as contas que tiverem valores em alguma das colunas, conforme abaixo:

Note que as seleções ficaram entre parênteses, pois utilizam a condição OU. Isso significa que somente emitirá a linha da conta, quando pelo menos uma coluna daquelas for maior que zero.

Com isso finalizamos o desenvolvimento de um balancete onde demonstra os saldos das contas analíticas e sintéticas, porém, este modelo poderá ser melhorado de modo a ganharmos performance. O problema consiste em cada conta contábil, sendo ela analítica ou sintética, estar executando todas as consultas nas oito colunas criadas, ou seja, cada conta buscará o saldo analítico e sintético, sendo que fará quatro vezes a consulta em todas as contas buscando por lançamentos vinculados a outras contas com a mesma classificação (saldo sintético).

41


Modificando o SQL manualmente para deixá-lo com melhor entendimento, quebramos as linhas das colunas, conforme demonstra a figura a seguir, para que possamos compreender a melhoria a ser feita:

Como as colunas são separadas em valores das contas analíticas e valores das contas sintéticas, podemos fazer que somente quando a conta for sintética, faça a consulta no SQL mais complexo, o qual necessita de mais tempo para execução da consulta, e também somente as contas analíticas façam as consultas mais simples. O SQL otimizado ficará da seguinte maneira:

42


Percebe-se que temos agora apenas duas colunas fazendo com que o SQL mais complexo e demorado seja executado somente quando a conta for do tipo sintética. Do contrário, irá executar o SQL mais simples. Com isso o relatório ganha tempo em sua execução, pois quando ao conta é analítica, não mais executará o SQL demorado, característica que não havia no relatório inicial, o qual estávamos desenvolvendo.

O mesmo poderá ser feito para o saldo anterior da conta.

Como foram alterados os nomes das colunas no SQL e outras foram apagadas, também será necessário alterar os nomes delas nas seleções feitas anteriormente para não mostrar as contas com valores zerados, caso contrário, erro de sintaxe ocorrerá ao clicar em OK na janela das Definições de dados. Além disso os objetos computados que utilizavam as antigas colunas ficarão na cor vermelha quando as alterações no SQL forem confirmadas e as novas colunas (com novos nomes que não existiam), terão objetos colunas inseridos no leiaute automaticamente, conforme imagem a seguir:

43


Os novos objetos colunas e objetos textos (cabeçalho) inseridos, terão de ser apagados manualmente e os objetos computados, atualizadas as expressões para as seguintes:

• Saldo anterior: deb_ant – cre_ant;

• Débito: deb_atu;

• Crédito: cre_atu;

• Saldo atual: ( deb_ant - cre_ant ) + ( deb_atu - cre_atu ).

A otimização será percebida quando emitir o relatório em um banco de dados quetenha muitos lançamentos contábeis em períodos diferentes e muitas contas contábeiscadastradas, ou seja, dependerá muito do volume de dados existente no banco dedados.

2.1.3. Balancete por Centro de Custos

Com o relatório de balancete que criamos até o momento, faremos alterações para que o mesmo seja emitido separado por centro de custos. Para isso implementaremos o relatório de modo que cada centro de custos, avalie se todas as contas contém saldos.

A tabela de contas, utilizada no SQL, não tem relacionamento direto com a tabela de centro de custos e desta forma, precisaremos criar um produto cartesiano (como visto no curso Introdução a SQL para o Domínio Gerador de Relatórios) entre elas. Com o resultado do produto cartesiano, teremos o código do centro de custos e o código da conta na mesma linha do relatório para avaliarmos nas colunas dos saldos se existem rateio para o determinado centro de custos na conta contábil.

44


Dando início a implementação, vamos inserir no relatório de balancete, as colunas referentes ao código e descrição do cadastro do centro de custos, conforme a seguir:

• ctcontas.codi_cta ;

• ctcontas.nome_cta ;• ctcontas.clas_cta ;• ctcontas.tipo_cta ;• ctparmto.masc_par ;• ctccusto.codi_ccu ;• ctccusto.desc_ccu .

Na guia Seleção, criar as seleções com a nova tabela inserida, conforme abaixo:

As seleções acima já estão adequadas referenciando os novos nomes das subconsultasalteradas anteriormente na parte em que otimizamos o relatório do balancete.

Com esta alteração no relatório, a ordenação também precisa ser modificada, fazendo com que seja primeiramente ordenado pelo código do centro de custos e em seguida pela classificação da conta.

Para uma melhor compreensão das alterações necessárias nas colunas dos saldos, é importante frisar que a tabela de rateios por centro de custos tem características semelhantes a dos lançamentos contábeis, porém, nunca existirá o centro de custo débito no mesmo registro do centro de custos a crédito. Quando uma linha possuir o centro de custos a débito, a coluna referente ao centro de custos a crédito ficará zerada e vice-versa, mesmo que no lançamento exista o rateio a débito e a crédito para a mesma conta contábil.

45


As subconsultas precisarão ser modificadas para buscar da tabela de lançamentos por centro de custos. A consulta ficará com as seguinte sintaxes conforme imagem abaixo:

O mesmo precisará ser feito para as colunas que montarão o saldo anterior, porém, nelas deve-se alterar a seleção da data, trocando a seleção “ctclancto.data_ccu BETWEEN :data_ini AND :data_fim” por “ctclancto.data_ccu < :data_ini”.

Com estas alterações, finalizamos a parte do SQL para o balancete separado por centro de custos. No leiaute do relatório, será necessário criar uma quebra pelo código do centro de custos (funcionalidade vista no curso Domínio Gerador de Relatórios I) e deslocar os campos do código e nome do centro de custos para a banda 1:Cabeçalho grupo ctccusto_codi_ccu, podendo deixar o leiaute conforme imagem abaixo:

46


Como resultado, temos a seguinte emissão do relatório:

Neste leiaute, o relatório listará o balancete para cada centro de custos que possuir saldos dos rateios realizados. Como já visto no curso Domínio Gerador de Relatórios I, este balancete poderia ser implementado para listar as contas com identação conforme seu grau, utilizando a função “IdentaConta()”.

Assim, finalizamos a implementação de uma relação de lançamentos em lote, de um balancete e um balancete por centro de custos, demonstrando como utilizar as tabelas e quais relacionamentos necessários para encontrar os dados desejados.

47


2.2. Escrita Fiscal

Neste tópico desenvolveremos relatórios do módulo Domínio Escrita Fiscal para emissão de um livro de saídas, um relatório de controle de contas a pagar, movimento de saídas de produtos e relação de lançamentos contábeis gerados pelas notas fiscais de serviços.

2.2.1. Livro de Saídas

No desenvolvimento deste modelo, usaremos as tabelas bethadba.efsaidas e bethadba.efimpsai para mostrar os dados da nota e os dados dos impostos, respectivamente. Também será utilizada a tabela do cadastro de empresas para montar o cabeçalho, demonstrando os dados da empresa que está emitindo o livro. A tabela é bethadba.geempre e está disponível no Domínio Gerador de Relatórios com o texto Empresa – Cadastro. Desta tabela, serão emitidas as colunas nome_emp, cgce_emp e iest_emp que armazenam o nome da empresa, o CNPJ/CPF/CEI e a inscrição estadual.

Esta tabela não foi relacionada neste curso, por se tratar de uma tabela geral que já émuito conhecida e muito utilizada nos relatórios.

Selecionaremos também as colunas dos dados das notas, conforme abaixo:

• efsaidas.codi_esp ;

• efsaidas.seri_sai ;

• efsaidas.sub_serie_sai ;

• efsaidas.nume_sai ;• efsaidas.atex_sai ;• efsaidas.ddoc_sai ;• efsaidas.sigl_est ;• efsaidas.vcon_sai ;• efsaidas.codi_nat ;• efsaidas.obse_sai .

Além das colunas dos dados da nota, precisamos selecionar as colunas dos impostos das notas, conforme abaixo:

• efimpsai.codi_imp ;• efimpsai.bcal_isa ;• efimpsai.aliq_isa ;• efimpsai.vlor_isa ;• efimpsai.vise_isa ;• efimpsai.vout_isa .

48


Avaliando o SQL montado, é possível perceber que o relacionamento entre as tabelas já foi feito automaticamente com o que havia de colunas em comum. Para emissão do livro, precisamos criar pelo menos três argumentos iniciais, um para o usuário informar o código da empresa e outros para as datas inicial e final.

Após criação dos argumentos, iremos criar as seleções necessárias para emitir os dados conforme informações que o usuário passará nos argumentos. Além disso, indicaremos que o relatório terá de emitir apenas os dados dos impostos ICMS e IP, seleções criadas conforme imagem abaixo:

Para a emissão ser feita de forma correta, precisamos também ordenar o relatório pelo código da nota (codi_sai) e código do imposto (codi_imp) para que sempre seja listadas as notas em ordem e o imposto ICMS na primeira linha seguido do IPI.

Após finalizarmos as inserções de colunas, seleções e argumentos da fonte de dados, podemos apagar todos os objetos inseridos automaticamente no leiaute do relatório para que possamos dar início a montagem do leiaute do livro de saídas. Como vimos anteriormente, pode-se usar o atalho Ctrl+T para selecionar todos os campos e apagá-los.

Na banda Cabeçalho incluiremos os dados da empresa, o período solicitado na emissão e também os objetos textos que identificarão as colunas na emissão do relatório, conforme imagens abaixo:

49


Antes de dar continuidade ao desenvolvimento alocando as colunas nas devidasposições, é importante realizar testes de impressão com o cabeçalho já definido paraavaliar se sairá correto, pois como este modelo ocupa bastante espaço devido aonúmero de colunas, é comum ocorrer problemas de campos que são cortados ousobrepostos na impressão. Então adequando o cabeçalho para a impressão correta,raramente haverá problemas na impressão das colunas.

Após a criação do cabeçalho, podemos inserir os objetos colunas logo abaixo a cada objeto texto que representa o determinado dado.

O campo Sub-série da nota armazena o valor 0 (zero) quando deixamos em branco. Para que a emissão do relatório não mostre a sub-série zero, no campo correspondente a série/sub-série usamos um objeto computado contendo a seguinte expressão:

if(isNull(efsaidas_seri_sai), '', efsaidas_seri_sai + if(isNull(efsaidas_sub_serie_sai) or efsaidas_sub_serie_sai = 0, '', '/' + String(efsaidas_sub_serie_sai)))

Esta expressão verifica primeiramente se a série está preenchida. Se não estiver, jogará vazio para emissão do campo, caso esteja, emitirá a série e avaliará se a sub-série existe. Caso esta última checagem seja afirmativa, irá jogar o separador “/” e a sub-série em seguida.

O mesmo tratamento poderia ser feito para mostrar o campo correspondente ao número/até, mas por se tratar de um campo com tamanho maior, inserimos dois objetos colunas, um para mostrar a coluna nume_sai e outro para mostrar a coluna atex_sai, sendo que nesta última utilizamos o campo Visível da guia Expressões disponível nas propriedades do objeto. A seguinte expressão foi utilizada:

if( efsaidas_atex_sai = 0, 0, 1 )

Com estas implementações, temos a emissão conforme imagem abaixo, selecionando o período de um ano inteiro:

50


Na imagem é possível perceber que o relatório está mostrando na mesma página, notas fiscais de outros meses, não sendo possível identificar qual a data real do lançamento da nota. Será necessário criar uma quebra por competência para identificação de tal informação. Para isso, acessaremos novamente a definição da fontes de dados e criaremos um computado que referenciará a competência da nota utilizando a seguinte expressão:

Esta função “YMD()” monta uma nova data recebendo três argumentos, sendo o primeiro que corresponderá ao ano, o segundo ao mês e o último ao dia. Então buscamos o ano e mês da data de emissão da nota e forçamos ao computado competencia receber sempre a data do primeiro dia do mês. Desta maneira todas as notas lançadas no mesmo mês, terão neste relatório um computado com informação comum.

Como será criada uma quebra, precisamos alterar a ordenação do relatório, assim evitamos que a emissão saia com quebra indevidas. A ordenação do relatório deverá ser alterada para considerar o computado competencia como o primeiro critério de ordem.

Em seguida, podemos criar a quebra por este computado e marcar a opção Nova página na quebra para que cada competência seja emitida em uma nova página.

O cabeçalho possui um campo que demonstra o período, que inicialmente emitimos as datas informadas nos argumentos, porém, como o cabeçalho é demonstrado em cada página para competências diferentes, precisamos alterar esta informação. Podemos então utilizar a seguinte expressão:

TrazNomeMes( Month( competencia ) ) + ' de ' + String( Year( competencia ) )

A função TrazNomeMes() não está disponível na lista de funções do objeto computado, mas pode ser utilizada inserindo-a manualmente na expressão.

Estas alterações farão com que o relatório seja listado com pelo menos uma página para cada mês, conforme imagens abaixo:

51


• Página 1:

• Página 2:

A banda 1:Rodapé grupo competencia será emitida somente no final de cada quebra, ou seja, de cada competência. Então nela iremos inserir objetos com totalizadores por competência dos impostos ICMS e IPI, utilizando objetos computados que farão as somas por grupo com a função “SUM( #x for group x)”, conforme visto no curso Domínio Gerador de Relatórios I e exemplo abaixo:

sum( efimpsai_bcal_isa for group 1)

Porém, como a quebra irá somar todos os registros acima, independente do imposto que gerou o valor, irá somar no mesmo campo as bases de cálculos dos dois impostos. Então precisamos utilizar o mesmo recurso do item 2.1.1, onde colocamos uma estrutura do condição, um IF(), dentro da função SUM(), conforme exemplo abaixo:

sum( if( efimpsai_codi_imp = 1, efimpsai_bcal_isa, 0) for group 1)

O mesmo critério faremos para os demais campos (valor contábil, valor do imposto, isentas e outras), inclusive para um totalizador do imposto IPI também, deixando os campos conforme imagem abaixo:

A emissão do mês de Janeiro no relatório, conforme nossos exemplos anteriores, ficará da seguinte maneira:

52


O relatório está praticamente pronto, necessitando de alguns ajustes que façam com que não se repitam os dados da nota para o mesmo documento, mas impostos diferentes. Note que os dados são mostrados repetidamente quando existir ICMS e IPI na mesma nota. Outro ajuste a ser feito, é adequar os totalizadores do valor contábil para não repetir o valor contábil em notas que possuírem mais de um segmento do mesmo imposto, pois caso exista, o valor será replicado pela quantidade de segmentos existentes para o mesmo imposto.

Estas alterações serão vistas no capítulo 3, onde demonstraremos o uso de alguns recursos avançados do Domínio Gerador de Relatórios.

O livro que estamos desenvolvendo é semelhante ao emitido pelo sistema mas nãoidêntico. A criação deste modelo tem o intuito de mostrar como buscar os dados dastabelas utilizadas.

2.2.2. Contas a pagar

No desenvolvimento do relatório de contas a pagar, utilizaremos o relacionamento entre três tabelas. A tabela das notas de entradas efentradas para demonstrar os dados do documento, a tabela das parcelas da nota efentradaspar que listará as parcelas e também a tabela dos pagamentos das parcelas efentradaspag para podermos visualizar o que está em aberto para o documento.

Inicialmente iremos inserir no relatório algumas colunas da tabela efentradas, para fazer uma listagem dos documentos, que são elas:

• efentradas.codi_ent ;

• efentradas.nume_ent ;• efentradas.seri_ent ;• efentradas.dent_ent ;• efentradas.vcon_ent .

Também podemos inserir as colunas abaixo, referentes a tabela efentradaspar:• efentradaspar.parc_entp ;• efentradaspar.vcto_entp ;• efentradaspar.vlor_entp .

53


Automaticamente o Domínio Gerador de Relatórios já inseriu o relacionamento entre elas, criando as seleções entre as colunas comuns. Com estas colunas, já poderíamos emitir um relatório de parcelas, ou seja, somente as parcelas que cada nota possui. Para isso, precisamos criar uma ordenação por código de nota codi_ent e também por número sequencial da parcela parc_entp.

Além disso e como já fizemos nos outros modelos, precisamos criar argumentos, podendo ser um para o usuário informar a empresa e outros dois para informar as datas inicial e final que farão as comparações com as datas da nota ou do vencimento das parcelas, conforme desejado. Em seguida, criar as seleções adicionais, conforme imagem abaixo:

Levando em consideração que a seleção será feita pelo vencimento da parcela e que onome do argumento para o usuário digitar o código da empresa é empresa e dasdatas inicial e final são data_ini e data_fim, respectivamente.

Com o que temos até o momento, podemos montar a relação de notas fiscais com suas parcelas (sem seus devidos pagamentos, que será implementado na sequencia), deixando o leiaute do relatório da seguinte maneira, após criarmos uma quebra pelo código da nota:

A emissão deste modelo será feita da seguinte maneira quanto possuímos duas notas de entradas com parcelas:

54


A emissão deste exemplo foi feita informando o período de 2005 inteiro. Caso solicitasse a emissão de 01/01/2005 até 31/10/2005, as duas últimas parcelas do segundo documento não seriam listados, conforme exemplo abaixo, devido a seleção ter sido feita pela data de vencimento da parcela:

A tabela de pagamentos das parcelas pode conter mais de um registro de pagamento para a mesma parcela, ou seja, o usuário poderá baixar parte do valor e deixá-la ainda com situação em aberto. Neste caso, poderíamos desenvolver o relatório para mostrar o total pago em uma única linha ou podemos detalhar os pagamentos abaixo de cada parcela.

Optaremos por detalhar os pagamentos devido ao desenvolvimento ser mais complexo e também ao fato de ficar mais claro os dados emitidos em tela.

O desenvolvimento desta maneira requer o uso de uma união para listar a nota, a parcela e seus pagamentos. A parte do SQL desenvolvida até o momento será alterada para listar apenas as notas e parcelas que ainda não possuem pagamentos.

A preparação da união atual para deixá-la emitindo apenas as parcelas sem pagamentos, consiste em criar uma nova seleção diretamente no SQL com a expressão abaixo, pois não há recursos de utilizar nas guias do Domínio Gerador de Relatórios:

Fazendo esta seleção diretamente no SQL, os recursos de implementação pelas guiasforam perdidos. Por isso as novas implementações terão de ser feitas manualmentenesta união.

55


Como alternativa, poderíamos ter inserido todas as demais colunas que usaremos e por último, inseriríamos a seleção. Assim implementaríamos praticamente todo o relatório pelas guias do Domínio Gerador de Relatórios. Mas manteremos desta forma para que você acompanhe o desenvolvimento de um modelo com estas limitações, para quando necessário fazê-lo diretamente pelo SQL.

As consultas as novas colunas que precisam ser inseridas, poderão ser feitas por outra seção aberta do Domínio Gerador de Relatórios.

Dando continuidade ao desenvolvimento, como esta união não emitirá dados dos pagamentos, precisamos criar as colunas de pagamentos que serão utilizadas na outra união, deixando estes zerados ou nulos, conforme exemplo abaixo:

56


Como as demais guias estão desabilitadas, precisamos remover a cláusula ORDERBY do SQL atual, pois ela somente deve ser utilizada no final do SQL, ou seja, naúltima união.

Em seguida, podemos dar início a implementação da união que listará as parcelas que já possuem pagamentos. A criação de uma nova união já foi vista no curso Domínio Gerador de Relatórios I, e precisamos inserir as mesmas colunas do banco já inseridas no primeiro SQL:

• efentradas.codi_ent ;

• efentradas.nume_ent ;• efentradas.seri_ent ;• efentradas.dent_ent ;• efentradas.vcon_ent ;• efentradaspar.parc_entp ;• efentradaspar.vcto_entp ;• efentradaspar.vlor_entp .

57


Além destas já utilizadas, precisamos inserir também as colunas da tabela de pagamentos, que são as seguintes:

• efentradaspag.pgto_entp ;• efentradaspag.vpag_entp .

Criaremos também as seguintes seleções adicionais, visto que automaticamente foram feitos os relacionamentos entre as tabelas inseridas:

A seleção da coluna efentradaspag.tipo_entp igual a 1, faz com que seja emitidouma vez o pagamento da parcela, caso este pagamento possua multas, juros,descontos, entre outros registros que possam existir, conforme visto no capítulo 1,item 1.2 e sub-item 6, onde demonstramos os tipos existentes.

Como os valores de juros, multas e descontos estarão em registros diferentes do que será mostrado, precisamos inserir as colunas utilizando sub-consultas. Estas sub-consultas serão criadas na guia Computados da união ou diretamente no SQL.

Abaixo, temos a imagem das colunas de multa, juros e descontos inseridas na união:

A guia Ordem não é habilitada nas uniões, então precisamos inserir a ordem manualmente no SQL desta segunda união e não usaremos mais o nome da coluna, mas sim a posição em que ela se encontra nas uniões, conforme abaixo:

58


Esta nova união, como já foi citado anteriormente, gerará os pagamentos das parcelas, sendo que uma parcela poderá ter mais de um pagamento. Por isso precisamos criar uma nova quebra por parcela e após, configurar o leiaute do relatório da seguinte maneira:

Os campos que mostrarão os dados da nota, ficarão no cabeçalho da quebra 1. Os objetos que emitirão os dados das parcelas, deverão estar no cabeçalho da quebra 2 e na banda Detalhe os campos correspondentes aos pagamentos das parcelas.

O campo que mostrará o saldo em aberto, será um objeto computado com uma subtração em sua expressão, entre as colunas efentradaspar.vlor_enpt e valor_pago (computado criado no SQL).

A emissão do relatório ficará conforme imagem abaixo:59


Percebe-se que a data do pagamento somente é demostrada quando realmente existe um registro de pagamento de parcela, que é emitido pela união. O primeiro SQL possui o computado data_pagto nulo no SQL.

Assim, finalizamos o modelo de contas a pagar. No capítulo 3, onde demonstraremos alguns recursos avançados, iremos mostrar os totalizadores deste relatório que requer o uso de uma funcionalidade que demonstraremos.

2.2.3. Movimento Individual de Produto

As tabelas de movimento de produtos não armazenam apenas os dados da guia Estoque das notas, mas também a movimentação extra (saídas e entradas extras). Neste item demonstraremos como montar um relatório para listar os produtos que estão na guia Estoque das notas, fazendo o relacionamento entre a tabela de notas com a de movimento de produtos.

Para o desenvolvimento do modelo, utilizaremos as seguintes colunas da tabela de notas de saídas:

• efsaidas.nume_sai ;

• efsaidas.seri_sai ;• efsaidas.ddoc_sai .

Também selecionaremos as colunas abaixo, correspondentes a movimentação dos produtos:

• efmvspro.codi_pdi ;• efmvspro.qtde_msp ;• efmvspro.valor_unit_msp ;• efvmspro.vpro_msp ;• efvmspro.bicms_msp ;• efmvspro.valor_icms_msp .

60


O relacionamento entre as duas tabelas será feito automaticamente. Precisamos também inserir os argumentos que desejamos. Neste modelo utilizaremos um para a empresa, outro para a competência e outro para o código do produto, conforme imagem abaixo:

O argumento referente ao código do produto precisa ser do tipo Caracter, pois será feita a seleção com a coluna do código do produto no banco de dados e corresponde a esse mesmo tipo. Em seguida, inseriremos as seleções abaixo:

No banco de dados a coluna do código do produtos aceita digitação de até 14 caracteres, ou seja, o código pode ter até este tamanho. Além disso o sistema armazena no banco de dados sempre os 14 caracteres completando com espaços em branco na esquerda. Por exemplo, se o código do produto é 134, o banco estará armazenado “ 134” (sem as aspas).

Na seleção acima, foi utilizada a função “TRIM()” que faz a remoção dos espaços em branco na esquerda e na direita, caso existam. Desta forma, se digitarmos o produto 134 no argumento, o relatório emitirá os registros com tal produto.

Também foram utilizadas outras duas seleções que fazem a comparação do argumento competencia com a data de emissão da nota, levando em consideração o mês e o ano.

Inicialmente, o leiaute do relatório poderá ficar conforme exemplo abaixo:

Como indicamos anteriormente, o código do produto é armazenado com espaços em branco na esquerda, desta forma, se optarmos por utilizar um objeto coluna para mostrar o código do produto, o mesmo sairá afastado do texto Produto: (da imagem acima) devido aos espaços. A solução será o uso de um objeto computado com a função “TRIM()” para remoção destes espaços.

61


A emissão do relatório ficará da seguinte maneira:

O modelo está listando apenas as saídas de produtos, mas iremos implementá-lo para listar também as entradas. A implementação será feita por meio de uma união, semelhante ao que fizemos no item 2.2.2, onde teremos este primeiro SQL exclusivo para emitir os produtos vendidos e a união que listará as compras de produtos.

Clicando no botão União... da janela Definição da Fonte de Dados, criaremos uma nova união para inserirmos as mesmas colunas existentes no primeiro SQL e na mesma ordem, mas selecionando das tabelas das notas de entradas (efentradas) e entradas de produtos (efmvepro), conforme abaixo:

• efentradas.nume_ent ;

• efentradas.seri_ent ;• efentradas.ddoc_ent ;• efmvepro.codi_pdi ;• efmvepro.qtde_mep ;• efmvepro.valor_unit_mep ;• efvmepro.vpro_mep ;• efvmepro.bicms_mep ;• efmvepro.valor_icms_mep .

Assim como o primeiro SQL, o relacionamento foi feito automático, mas precisamos criar outras seleções conforme os argumentos que serão utilizados, inserindo as seleções semelhantes ao que foi feito anteriormente.

Com isso teremos o relatório listando as saídas e entradas de um produto no mês, conforme imagem abaixo:

62


Não é possível identificar qual registro corresponde a saída de produto e qual refere-se a entrada. Então precisamos indicar nas definições de fonte de dados, diferenciando o primeiro SQL da união 1. Podemos fazer isso criando um computado no primeiro SQL e outro na união, recebendo valores diferentes.

Abaixo a imagem do computado do primeiro SQL:

A figura abaixo, corresponde ao computado da união:

Em seguida, podemos disponibilizar o objeto coluna deste computado no local desejado, fazendo com que na emissão do relatório possamos identificar se o registro corresponde a uma entrada ou saída do produto, conforme imagem abaixo:

Podemos ainda melhorar o relatório, ordenando por data e por número de documento. A ordenação também pode ser feita pelo menu Relatório, opção Ordenar..., do Domínio Gerador de Relatórios, conforme imagem abaixo:

63


Caso tenha sido feita alguma ordenação pela definição de fonte de dados e tambémfeita a ordenação pelo menu do Domínio Gerador de Relatórios, prevalecerá aordem definida na janela acima, desprezando o que existe na definição.

Inserindo um objeto computado utilizando a função CUMULATIVESUM(), podemos obter o saldo do produto a cada saída ou entrada. A expressão do computado seria a seguinte:

• CumulativeSum( efmvspro_qtde_msp * if( tipo = 'E', 1, -1 ) )

A emissão do relatório ordenado e com o saldo indicado anteriormente, ficaria da seguinte maneira:

Finalizamos a criação do modelo com estas implementações. O modelo poderia ainda ser aprimorado para ter outros totalizadores, conforme visto em itens anteriores.

2.2.4. Relação de Lançamentos Contábeis das Notas de Serviços

Na tabela de lançamentos contábeis existe uma coluna que indica a origem do lançamento (orig_lan), conforme visto no item 1.1, porém, não é bem específico quanto ao registro que originou o lançamento, como por exemplo, qual a nota fiscal de serviço gerou tal lançamento, sabe-se apenas que o lançamento foi originado de uma nota de serviço do módulo Domínio Escrita Fiscal.

Mas existe tabela que faz esta relação e neste item, demonstraremos como listar as notas de serviços e seus respectivos lançamentos contábeis. Trata-se de um simples relatório, mas envolve três tabelas para chegar-se ao resultado.

Na tabela efservicos temos os dados das notas de serviços. A tabela ctlancto armazena os registros dos lançamentos contábeis e a tabela efservicos_lancto faz o relacionamento entre as duas, indicando qual lançamento contábil pertence a nota fiscal de serviço. Para a montagem do relatório, utilizaremos as seguintes colunas da tabela de notas fiscais de serviços:

• efservicos.codi_ser ;

• efservicos.nume_ser ;

• efservicos.ddoc_ser ;• efservicos.vcon_ser .

64


Da tabela de lançamentos contábeis, utilizaremos as seguintes colunas:• ctlancto.cdeb_lan ;• ctlancto.ccre_lan ;• ctlancto.vlor_lan ;• ctlancto.chis_lan .

Selecionando estas colunas, não há algum relacionamento entre elas e por isso selecionaremos a coluna abaixo:

• efservicos_lancto.nume_lan .

Após inserir a última coluna, o SQL teve os relacionamentos gerados automaticamente, pois com esta tabela existe relação com as outras duas.

Em seguida, podemos ordenar por código da nota e número do lançamento. Além disso, criaremos uma quebra pelo código da nota e disponibilizaremos os objetos conforme o seguinte leiaute:

Sua emissão ficará da seguinte maneira:

65


Neste modelo não foram inseridas seleções de empresa e competência, sendonecessário fazê-las para não emitir todos os lançamentos contábeis de notas deserviços do banco de dados, ou seja, de todas as empresas cadastradas.

Os lançamentos contábeis referentes a pagamentos de parcelas não serãodemonstrados, pois existe outra tabela que faz o relacionamento das parcelas com oslançamentos (efentradaspag_lancto, efsaidaspag_lancto eefservicospag_lancto, disponíveis no Domínio Gerador de Relatórios com ostextos Baixas de entradas X Lançamentos contábeis, Baixas de saídas XLançamentos Contábeis e Baixas de serviços X Lançamentos contábeis).

2.2.5. Saldo dos impostos

Abaixo veremos como podemos criar um relatório onde possamos consultar os saldos de impostos em um intervalo de competências. Aproveitando este modelo, mostraremos também como buscar o regime federal da empresa dentro da vigência.

Selecionaremos as seguintes colunas para desenvolvimento do relatório:

• efsdoimp.codi_imp ;

• efsdoimp.data_sim ;• efsdoimp.pdic_sim ;• efsdoimp.sdev_sim ;• efsdoimp.scre_sim ;• efsdoimp.vime_sim ;• efsdoimp.vims_sim ;• efsdoimp.vimv_sim .

66


Os seguintes argumentos precisão ser criados:

Também serão criadas as seguintes seleções:

Não foi criada uma seleção com o argumento que possui a classificação Seleção,pois a seleção é feita automaticamente, mas não gera no SQL da definição de dados.Além disso, como visto no curso Domínio Gerador de Relatórios I, o nome doargumento deve ser o nome da coluna do banco de dados.

Podemos agora, inserir as colunas correspondentes a vigência para buscarmos o regime federal da empresa. As colunas serão as seguintes:

• efparametro_vigencia.vigencia_par ;

• efparametro_vigencia.rfed_par .

As novas seleções abaixo precisam ser inseridas:

As seleções 3 e 4 foram inseridas para relacionar a tabela da vigência dos parâmetros com a tabela do saldo dos impostos. Para buscar a vigência correta para a competência, foi utilizada a função “DSDBA.D_BUSCA_VIGENCIA_PARAMETRO()” criada para retornar a vigência correspondente a data passada por argumentos, conforme sintaxe abaixo, utilizada na seleção acima:

• DSDBA.D_BUSCA_VIGENCIA_PARAMETRO (efsdoimp.codi_emp, data_sim)

Para finalizar a parte das definições de dados, precisamos determinar uma ordem para a emissão pelas colunas efsdoimp.data_sim e efsdoimp.codi_imp.

67


Utilizaremos uma quebra pela coluna efsdoimp.data_sim e o leiaute do relatório ficará da seguinte maneira:

O resultado da emissão será o seguinte, caso selecionar os impostos 1, 2 e 3:

Para os campos referentes ao regime federal e periodicidade do imposto, pode-seutilizar as tabelas de valores para aparecer os textos que são representados peloscódigos.

2.3. Folha de Pagamentos

O módulo Domínio Folha possui muitas tabelas que são resultados de processos envolvendo cálculos, como por exemplo, folhas mensais, férias, bases e rescisões. Neste item mostraremos como buscar estes principais dados montando relatórios de relação de empregados e contribuintes, bases de cálculos, resumo da folha, rescisões e resumo de férias envolvendo períodos aquisitivos e gozo de férias.

68


2.3.1. Relação de Empregados e Contribuintes Ativos

A tabela do banco de dados que armazena os empregados e contribuintes é a foempregados. Como visto no item 1.3, os empregados e contribuintes são diferenciados pela coluna tipo_epr. Quando a coluna possuir o valor 1, o registro corresponderá a um empregado e quando for 2, corresponderá a um contribuinte.

No desenvolvimento deste modelo, utilizaremos as seguintes colunas:

• foempregados.i_empregados ;

• foempregados.nome ;

• foempregados.admissao ;• foempregados.salario ;• foempregados.tipo_epr .

O modelo que desenvolveremos fará a listagem de empregados ativos em uma determinada competência e precisamos criar os argumentos para informarmos a empresa e também a competência (argumento do tipo Mês e Ano) que gostaríamos de listar. Em seguida, criar as seguintes seleções:

Com o que foi feito até o momento, listaríamos todos os empregados e contribuintes admitidos antes ou na competência que informamos.

A listagem dos ativos será feita após implementarmos a seleção que consultará na tabela de afastamentos, se o empregado teve a situação 8 (demitido) antes da competência informada nos argumentos, conforme SQL abaixo:

Novamente, esta seleção não poderá ser criada na guia Seleção das definições de dados, desabilitando as demais guias por ser necessário alterar diretamente o SQL. Isso ocorre

69


devido ao fato desta seleção não possuir uma comparação, ou seja, não utiliza um teste dos que estão disponíveis na guia Seleção.

A tabela de afastamentos contém um registro para cada situação do empregado, desde a sua admissão, ou seja, quando o empregado é admitido (cadastrado no sistema) um registro na data da admissão é gerado com o código do afastamento 1, representando a situação Trabalhando. Por este motivo não podemos acrescentar ao relatório as colunas da tabela de afastamentos, pois o empregado seria listado repetidamente, de acordo com a quantidade de afastamentos e retornos existentes.

Em seguida, ordenamos o relatório pelas colunas tipo_epr e nome e criamos uma quebra pela coluna tipo_epr, deixando o leiaute da seguinte maneira:

O objeto computado que encontra-se na banda 1:Cabeçalho grupo tipo_epr, há a seguinte expressão para mostrar se o grupo será empregados ou contribuintes:

A emissão do relatório ficará da seguinte maneira:

70


Os empregados 2 e 3 estão demitidos com rescisões em 03/02/2010 e 28/02/2010,respectivamente. Como não estão mais ativos na competência 03/2010, conformeemissão do relatório, os mesmos não foram demonstrados.

Emitindo o relatório em 01/2010, teremos o seguinte resultado:

Os empregados 2 e 3 foram listados, pois na competência 01/2010 eles estavamativos.

2.3.2. Bases de FGTS e INSS com Salário da Competência Informada

Aproveitando o relatório desenvolvido no item 2.3.1, acrescentaremos nele, os dados das bases de FGTS e INSS dos empregados, utilizando a tabela focalculosbases e fobasesserv. Também acrescentaremos uma consulta que substituirá a coluna foempregados.salario, com o objetivo de retornar o salário que o empregado tinha no mês solicitado, buscando da tabela de alterações salariais. Como o relatório está bloqueado o uso das demais guias das definições de dados, faremos alterações diretamente no SQL, conforme retângulos na imagem abaixo, deixando-o da seguinte maneira:

71


A seleção com a coluna bethadba.fobasesserv.tipo_process, fará com que apenasos cálculos de folha mensal sejam mostrados e a seleção com a colunabethadba.fobasesserv.rateio, fará com que sejam mostrados os registros docálculo integral.

Com estas alterações, serão listadas também a data do pagamento da folha mensal, para a competência solicitada, o salário líquido calculado e o salário do empregado na competência solicitada.

Para buscarmos as bases, precisamos utilizar computados no SQL com subconsultas nas tabelas focalculos e focalculosbases e indicando na coluna focalculosbases.i_cadbases, quais as bases deseja buscar. Abaixo temos a relação das bases padrões disponíveis para os usuários:

72


Também existem as bases padrões do sistema que o usuário não tem acesso a alteração e visualização e que também são utilizadas para consultas aos valores das bases, conforme lista abaixo:

Os computados com subconsultas terão de ser criados com as seguintes expressões dentro do SQL:

73


Acima temos a imagem das consultas para encontrarmos a base e o valor do FTGS do mês e também a base e o valor do INSS. Percebe-se que eles utilizam códigos de bases diferentes e o SQL é o mesmo para encontrar a base e o valor, alterando apenas a coluna na função SUM().

Nas duas últimas, utilizamos o KEY JOIN que é um mecanismo da própria linguagem SQL, a qual faz o relacionamento das colunas chave primárias e chaves estrangeiras entre as tabelas automaticamente, não necessitando definir as seleções na cláusula WHERE.

Quando estiverem em dúvida de quais os códigos de base precisam utilizar, editemrelatórios padrões do sistema que possam ter tais informações, como por exemplo, orecibo da folha e/ou recibo de rescisão.

As consultas por outras bases seguirá a mesma sintaxe, necessitando apenas a alteração dos códigos das bases.

Podemos montar o leiaute do relatório da seguinte maneira:

Sua emissão ficará conforme imagem abaixo:

74


Este modelo poderia ter ainda, objetos computados no rodapé da quebra para exibir um total por tipo de empregados, ou seja, um total para os empregados e outro para os contribuintes. Também poderia ter outros objetos computados na banda Sumário, que mostraria o total geral, somando os valores dos empregados e dos contribuintes.

A diferença dos objetos inseridos, seria a expressão. Os objetos teriam, por exemplo, as seguintes expressão:

• Rodapé da quebra: sum( base_fgts for group 1)

• Sumário: sum( base_fgts ) ou sum( base_fgts for all )

2.3.3. Resumo da Folha

O relatório que criaremos utilizará apenas a tabela que a grava os cálculos da folha, que é a fomovtoserv. Selecionaremos as seguintes colunas:

• fomovtoserv.i_eventos ;

• fomovtoserv.valor_inf ;• fomovtoserv.valor_cal ;• fomovtoserv.prov_desc .

Criaremos os argumentos para o usuário informar o código da empresa e a competência desejada para emissão do relatório. Em seguida, faremos as seguintes seleções:

Ordenaremos o relatório pela coluna de proventos e descontos, de modo que saia primeiramente os proventos e em seguida os descontos e também acrescentaremos na ordenação, o código do evento.

75


Na guia Computados, vamos inserir um registro, conforme abaixo, para trazer o nome do evento:

• Nome: nome_evento;

• Definição: (SELECT foeventos.nome

FROM bethadba.foeventos,

bethadba.foparmto

WHERE foparmto.codi_emp = fomovtoserv.codi_emp AND

foeventos.codi_emp = foparmto.codi_emp_eve AND

foeventos.i_eventos = fomovtoserv.i_eventos) .

Faremos uma quebra pelo tipo do evento, representado pela coluna fomovtoserv.prov_desc e outra pelo código do evento, pois na mesma competência existirão vários eventos calculados repetidamente, sendo uma vez para cada empregado, como por exemplo, o evento de horas normais (código 1).

Como os totais estarão na quebra do evento, precisamos inserir objetos computados para totalizar os valores dos campos para cada evento e montaremos o leiaute do relatório conforme figura a seguir:

Os objetos computados com os totalizadores, tando da primeira quebra, como dasegunda e da banda Sumário, foram disponibilizados com intuito das expressõesficarem visíveis por inteiras.

A emissão do relatório ficará conforme imagem abaixo:

76


2.3.4. Relação de Rescisões

A relação de rescisão terá alguns dados da tabela de rescisões relacionados com os dados da tabela de empregados, para listar o nome e data de admissão, e também utilizaremos um computado com subconsulta para demonstrar o líquido da rescisão.

Utilizaremos as seguintes colunas da tabela de rescisões neste relatório:

• forescisoes.i_empregados ;

• forescisoes.data_demissao ;• forescisoes.motivo ;• forescisoes.salario ;• forescisoes.proventos ;• forescisoes.descontos ;

77


• forescisoes.data_pagto ;• forescisoes.tipo .

Também acrescentaremos as colunas abaixo, referentes a tabela de empregados:

• foempregados.nome; • foempregados.admissao.

O relacionamento entre as tabelas será feito automaticamente e criaremos argumentos para fazermos outras seleções em seguida, filtrando por empresa e por data de rescisão (intervalo de data). As novas seleções serão as seguintes:

Na guia Computados, criaremos a seguinte consulta:

• Nome: evento51;

• Definição: (SELECT sum(fomovtoserv.valor_cal)

FROM bethadba.fomovtoserv

WHERE fomovtoserv.codi_emp = foempregados.codi_emp AND

fomovtoserv.i_empregados = foempregados.i_empregados AND

fomovtoserv.data = forescisoes.competencia AND

fomovtoserv.i_eventos = 51 AND

fomovtoserv.rateio = 0 AND

((fomovtoserv.tipo_proces = 11 AND forescisoes.tipo = 1) OR

(fomovtoserv.tipo_proces = 42 AND forescisoes.tipo = 2))).

A consulta do valor calculado para o evento 51 (Líquido rescisão) é necessário, pois na tabela de rescisões, assim como na tabela de bases, existe gravado os totais de proventos e descontos, mas como o líquido resulta no valor R$ 0,00, não conseguimos buscar o devido valor pela tabela de rescisões. A imagem abaixo demonstra que o líquido fica zerado.

78


Com as colunas já inseridas e o relacionamento feito, podemos partir para a definição do leiaute do relatório, deixando-o da seguinte maneira:

Os objetos colunas forescisoes_motivo e forescisoes_tipo estão utilizando a tabela de valores para converter o código armazenado no banco pela descrição correspondente. Além disso, utilizamos também um objeto computado para o campo Descontos, contendo a seguinte expressão:

79


Com esta expressão, temos o total real de descontos, ou seja, o total desprezando o que foi calculado para o evento 51 (Líquido rescisão).

Abaixo temos a imagem da emissão do relatório desenvolvido:

Percebe-se que o modelo pode ser melhorado fazendo com que o empregado não saia repetido, conforme o empregado 2 que foi emitido duas vezes devido a existência da rescisão normal e da complementar. Para evitar que o nome saia repetidamente, podemos criar uma quebra pelo código do empregado e deslocar alguns objetos que são emitidos duas vezes desnecessariamente, para o cabeçalho da quebra, conforme próxima imagem:

Sua emissão ficará da seguinte maneira:

Com estas alterações, finalizamos a implementação da relação de rescisões dentro de um período solicitado por argumentos.

80


2.3.5. Resumo de Férias (Períodos Aquisitivos X Férias Gozadas)

O desenvolvimento deste relatório consistirá em emitir os períodos aquisitivos dos empregados e listar também as férias gozadas para cada período aquisitivo. Inicialmente montaremos a listagem dos períodos aquisitivos e complementaremos posteriormente com os gozos de férias.

Inseriremos as seguintes colunas da tabela de períodos aquisitivos no relatório:

• foferias_aquisitivos.i_empregados ;

• foferias_aquisitivos.i_ferias_aquisitivos ;

• foferias_aquisitivos.data_inicio ;

• foferias_aquisitivos.data_fim ;• foferias_aquisitivos.situacao ;• foferias_aquisitivos.dias_direito ;

• foferias_aquisitivos.dias_gozados .

Também acrescentaremos a coluna referente ao nome do empregado foempregados.nome para que possamos identificar com maior facilidade, a qual empregado o período pertence.

Em seguida, criaremos argumentos para informarmos a empresa e permitir a seleção da emissão por centro de custos, departamentos e também por filial, conforme imagem a seguir:

Os argumentos com classificação Seleção foram criados como não obrigatórios.Desta forma o usuário poderá deixar o campo em branco para que não haja filtro deseleção. Ou ainda, poderá fazer um filtro emitindo apenas empregados da filial decódigo 1, com centro de custos 10 e departamento 28, por exemplo.

Devido a existência do argumento com classificação Argumento, precisamos inserir a seguinte seleção:

81


Como os demais argumentos correspondem a classificação Seleção, não existe apossibilidade de criação de seleção, pois já são feitas automaticamente, conforme jávisto no curso Domínio Gerador de Relatórios I.

Utilizaremos também a ordenação por código do empregado e sequencial do período aquisitivo (coluna i_ferias_aquisitivos) e em seguida, podemos montar o leiaute do relatório com quebra por funcionário, conforme imagem abaixo:

No objeto coluna referente a situação do período aquisitivo, foi utilizada a tabela de valores para emitir a descrição ao invés dos códigos armazenados, conforme vimos no item 8 do subcapítulo 1.3.

A emissão do relatório ficará de acordo com imagem a seguir:

82


Podemos partir para implementar neste relatório, as férias gozadas. Iniciaremos acrescentando as seguintes colunas:

• foferias_gozo.gozo_inicio ;

• foferias_gozo.gozo_fim ;

• foferias_gozo.abono_inicio ;

• foferias_gozo.abono_fim ;

• foferias_gozo.data_pagto .

83


As seleções entre as tabelas foram criadas automaticamente, não havendo mais necessidade de relacionar algo. Precisamos apenas acrescentar uma nova coluna na ordenação, que corresponderá a coluna foferias_gozo.i_ferias_gozo.

Uma nova quebra pela coluna fofeiras_aquisitivos.i_ferias_aquisitivos terá de ser criada para que os períodos não sejam emitidos repetidamente, conforme a quantidade de férias do empregado no mesmo período aquisitivo. Deixaremos o leiaute conforme figura abaixo:

Realizando tal alteração no modelo, sua emissão ficará da seguinte forma:

84


A emissão foi feita apenas para os empregados que possuíam gozo de férias. Percebe-se que os períodos aquisitivos sem gozo ou os empregados sem gozo de férias, não foram listados. Isso se deve ao fato da emissão ser feita apenas para existência do relacionamento entre a tabela de períodos aquisitivos e férias gozadas, ou seja, quando existir registros comuns entre as duas tabelas.

Uma alternativa de fazer com que sejam emitidos os períodos sem os gozos, é utilizar a instrução OUTER JOIN para emitir todos os resultados, mesmo quando não existir relação entre as duas tabelas.

Por não ser possível inserir esta instrução automaticamente pelo Domínio Gerador de Relatórios, precisamos alterar diretamente no SQL, conforme figuras abaixo, sendo a primeira do SQL atual:

85


Abaixo temos a alteração a ser feita, inserindo a instrução OUTER JOIN na cláusula FROM e removendo as seleções da cláusula WHERE que serão transportadas para a instrução:

Após a alteração realizada, teremos a emissão do relatório de modo que todos os períodos aquisitivos sejam listados independente da existência de um registro de gozo para tal relacionamento, ficando com a seguinte emissão em duas páginas:

86


Acima temos a primeira página e em seguida, teremos a segunda página da emissão do relatório:

87


Assim finalizamos o desenvolvimento do relatório de férias, listando os períodos aquisitivos e os gozos de férias dos empregados.

88


3. Recursos Avançados

Neste capítulo veremos alguns recursos avançados bastante utilizados para solucionar problemas ou modelar o relatório conforme desejado.

3.1. Argumentos

Existe uma funcionalidade nos argumentos que permite definirmos valores padrões com textos para o usuário escolher na digitação do argumento, como por exemplo, escolher entre as opções Sim e Não, sem a necessidade de digitar S, Sim, N ou Não.

Este recurso funciona apenas para argumentos do tipo Caracter e consiste em utilizar uma expressão no campo Valor inicial do argumento.

Botando em prática, podemos utilizar o relatório que criamos no item 2.3.2, onde o mesmo lista os empregados e contribuintes da empresa juntamente com suas bases. Criaremos um novo argumento com as seguintes características e imagem a seguir:

• Classif.: Argumento;

• Nome do Argumento: tipo_funcionario;

• Tipo: Caracter;

• Texto: Empregado/Contribuinte/Ambos?

• Valor inicial: Empregados~tE/Contribuintes~tC/Ambos~tA

Além da criação do argumento, para que a emissão seja feita conforme o esperado, precisamos acrescentar no relatório uma nova seleção, de modo que emita no relatório somente os empregados quando selecionada uma das opções Empregados ou Ambos e somente os contribuintes quando escolhida uma das opções Contribuintes ou Ambos, conforme imagem abaixo com a seleção contornada em vermelho:

89


Com esta implementação, o usuário poderá clicar no argumento para listar as opções disponíveis. Os textos mostrados serão sempre o que foi inserido na expressão antes do caractere “~” e o que ficará armazenado para o argumento, será o que está logo após a letra “t”.

Conforme imagem abaixo, é possível visualizar as opções que foram digitadas na expressão do argumento:

O campo do argumento ainda aceitará a digitação de outros valores, porém, caso nãotenha sido tratado o valor no SQL, o relatório não tratará ele e neste exemplo, nãoseriam listados empregados ou contribuintes.

O resultado da emissão será de acordo com a opção escolhida, conforme indicamos anteriormente, emitindo apenas empregados, apenas contribuintes ou ambos (este último teria a mesma emissão que o relatório sem a criação deste argumento, o qual foi demonstrado no item 2.3.2).

3.2. Tabela dbo.rowgenerator

A tabela dbo.rowgenerator existente no banco de dados possui apenas a coluna row_num que armazena um sequencial de 1 até 255. Ela pode ser utilizada de inúmeras maneiras, mas neste item usaremos ela para montar uma competência em um relatório que lista todos os meses do ano e o líquido dos salários dos empregados para cada competência, inclusive nas competências em que não existe cálculo, trazendo zerado.

Caso utilizássemos apenas a tabela de bases, sem montagem da competência com a tabela dbo.rowgenerator, os meses em que não existem cálculos para o empregado não seriam mostradas.

Como ela não está disponível no Domínio Gerador de Relatórios, precisamos inserir toda a consulta diretamente no SQL e inicialmente criaremos os seguintes argumentos:

90


No campo Valor inicial do argumento tipo_folha, temos a seguinte expressão completa:

• Mensal~t11/Complementar~t42/Adiantamento 13º~t51/13º Integral~t52

O SQL será montado inicialmente da seguinte maneira:

Este SQL fará com que cada empregado seja emitido 12 vezes e com isso, podemos montar uma data partindo da data inicial, informada nos argumentos, somando os meses conforme o valor da coluna row_num, de acordo com o SQL abaixo:

O computado criado com o nome nova_data utiliza a função “Months()” que faz a soma de meses em uma data passada como parâmetros. Neste caso a data será a competência informada no argumento para emissão do relatório. Como a primeira linha emitida terá o valor

91


1 para a coluna dbo.rowgenerator.row_num, então sempre subtrai 1 da coluna, para que a nova data inicie na competência informada no argumento.

O outro computado, com nome liquido, busca da tabela de bases (fobasesserv) o líquido do empregado na competência criada e para o tipo da folha informada nos argumentos.

A seleção com a coluna fobasesserv.tipo_process teve a coluna convertida paraString, devido ao fato do argumento ser do tipo Caracter. Caso o mesmo fosse dotipo Número, não haveria a necessidade da conversão.

Com este SQL, temos a seguinte emissão para o relatório (apenas a primeira página emitida):

92


Para evitar que o nome e código sejam emitidos repetidamente, conforme imagem acima, criaremos uma quebra por empregado e deslocaremos estes campos para o cabeçalho da quebra, deixando o leiaute da seguinte maneira:

93


No próximo item, avaliaremos como fazer para deixar as competências e os valores um ao lado do outro, ou seja, na horizontal, ocupando assim, apenas uma linha para cada empregado.

3.3. Vetores

Este recurso é muito utilizado para adequar o leiaute do relatório conforme desejado. Muitas vezes por necessitar que o relatório seja desenvolvido com mais de um registro na mesma linha, como por exemplo, as etiquetas da folha, onde são listados mais de um empregado, ficando um ao lado do outro.

Também utilizamos muito em totalizadores de relatórios que possuam quebras, para que some somente uma vez o valor desejado ou em relatórios que precisam ter um tamanho fixo e conter detalhamento de dados que podem variar, como o caso do recibo de pagamento da folha, onde utiliza-se vetores para listar os eventos calculados para cada empregado.

Os objetos com vetores são utilizados sempre em alguma quebra. No detalhe dorelatório teríamos sempre o detalhamento, ou seja, uma linha para cada resultado,mas como utilizamos vetores para aparecer mais de um resultado na mesma páginaou linha, precisamos forçar uma quebra para que não liste várias vezes odetalhamento.

Estes exemplos veremos logo abaixo, explicando como fazer tais implementações.

Exemplo 1: Inicialmente faremos um simples relatório para compreendermos como funciona este

recurso. O relatório consistirá em emitir uma simples etiqueta de empregados, com uma, duas e três colunas.

Utilizaremos as seguintes colunas no relatório:


• foempregados.nome ;• foempregados.admissao ;• foempregados.salario .

94


Criaremos um argumento para informarmos o código da empresa que listará os empregados e faremos a seleção, conforme já vimos algumas vezes neste mesmo curso e adequaremos o leiaute deixando-o da seguinte maneira:

Desta forma, como os campos encontram-se na banda Detalhe, será listado um empregado por vez, conforme imagem seguinte:

Inserindo objetos computados com vetores, logo ao lado desta primeira etiqueta, teremos o seguinte leiaute:

E teríamos a seguinte emissão:

95


O resultado que temos consiste em emitir a próxima linha no vetor [1]. Por isso a segunda etiqueta emitiu os empregados da linha abaixo. Se criarmos outra etiqueta, com vetor [2], irá sair na primeira linha, os empregados de códigos 1, 2 e 3, na segunda linha, os empregados 2, 3 e 4, e assim sucessivamente, repetindo também os demais empregados.

Por este motivo é que precisamos criar uma quebra e utilizar os vetores nelas. Para este exemplo, precisamos criar uma quebra a cada dois empregados. Como não há algo em comum para facilitar, precisamos forçar, criar um contador que será acrescido a cada dois empregados.

O computado a ser criado que forçará a criação de uma quebra a cada dois empregados emitidos, está logo abaixo:

Para facilitar o entendimento, podemos inserir objetos computados no leiaute do relatório contendo detalhes utilizados no cálculo do computado quebra para compreendermos os passos e o cálculo que será realizado para a criação da quebra:

96


O computado com nome sequencial terá o valor retornado da função “GetRow()” subtraído de 1, que será um sequencial iniciando em 0 (zero), gerando um sequencial para cada registro no detalhamento. O de nome divisao fará uma divisão entre este sequencial e o número de colunas que desejamos mostrar. E por último, o computado quebra (inserido nas definições de dados) que, com o uso da função “DSDBA.N_TRUNC()”, pegará apenas a parte inteira do resultado da divisão devido ao segundo parâmetro da função, onde definimos o número zero que representa o número de casas decimais. Conforme imagem seguinte, temos o leiaute com os objetos já inseridos:

Teremos o seguinte resultado:

97


Já possuímos um resultado em comum entre dois registros, podendo criar a quebra pelo computado que inserimos nas definições de dados. Após, deslocaremos os objetos já inclusos para o cabeçalho da quebra, deixando o leiaute de acordo com imagem abaixo:

Assim, teremos o seguinte resultado na emissão do relatório:

Caso desejamos utilizar três etiquetas na mesma linha, deve-se alterar a expressão docomputado quebra para fazer a divisão por 3.

Exemplo 2:Outra forma de utilizar o vetor, é trabalhar com computados para avaliar se o campo

será mostrado na tela ou não, devido a informações repetidas por falta de uma quebra, por exemplo. Este recurso podemos aplicar no relatório que desenvolvemos no item 2.2.1. Conforme imagem neste item, é possível perceber que os dados da nota são emitidos duas vezes, caso a nota tenha os dois impostos (ICMS e IPI).

98


Para fazer com que não seja emitida a segunda linha com os mesmos dados, precisamos avaliar se ela corresponde a mesma nota da linha anterior. Utilizando o vetor [1] e [2], por exemplo, como vimos anteriormente, podemos avaliar as próximas duas linhas que serão emitidas, então para avaliar a anterior, utilizaremos o vetor [-1].

O campo Visível da guia Expressões disponível nas propriedades dos objetos inseridos, podemos utilizar o vetor para fazer com que a informação não seja mostrada usando a seguinte expressão, conforme detalhes abaixo e imagem a seguir:

• if( efsaidas_codi_sai[-1] = efsaidas_codi_sai, 0, 1 )

O mesmo terá de ser feito em todos os objetos que não precisam sair repetidos, como a série/sub-série, número do documento, dia, UF do destinatário, valor contábil e codificação fiscal. Todos estes terão de possuir a expressão acima, preenchida no campo Visível.

Tal expressão faz a comparação do código da nota da linha anterior (vetor [-1]) com o código da nota da linha atual (sem vetor ou vetor [0]). Caso seja o mesmo código, irá resultar em 0 (zero) que fará com que o campo não seja mostrado, conforme imagem a seguir:

Como o campo do número final do documento já possui uma expressão, precisamos tratá-la para que o relatório compreenda as duas. Então alteramos a para a seguinte expressão:

99


• if( efsaidas_atex_sai = 0 or efsaidas_codi_sai[-1] = efsaidas_codi_sai, 0, 1 )

Exemplo 3:Um outro exemplo, ainda utilizando o mesmo modelo de relatório, é o caso de uma

nota possuir segmentação de imposto, onde seria listado para a mesma nota, duas linhas do ICMS e uma do IPI. Neste caso, teríamos o seguinte resultado abaixo, onde a soma do valor contábil ficará replicado por causa da nota que possui segmentação:

Percebe-se que o total do ICMS teve o valor de R$ 5.000,00 somado duas vezes, uma para cada segmento do imposto. Pois a expressão inserida no campo Visível (alterações referente ao exemplo anterior), faz com que o valor apenas não seja mostrado, porém, ele encontra-se no relatório ainda. Como solução, precisamos fazer um novo tratamento no objeto computado dos totais de ICMS e IPI, pois a mesma situação poderá existir no outro imposto.

Substituiremos a expressão que faz o somatório do ICMS (visto no item 2.2.1) para a seguinte:

• sum(if( efimpsai_codi_imp=1 and (efsaidas_codi_sai[-1]<>efsaidas_codi_sai or efimpsai_codi_imp[-1] <> efimpsai_codi_imp or isNull( efsaidas_codi_sai[-1])), efsaidas_vcon_sai, 0) for group 1)

A mesma alteração terá de ser feita no totalizador do IPI e teremos o seguinte resultado:

A expressão utilizada, indicada anteriormente, avalia primeiramente se o imposto que está sendo lido é o de código 1. Além disso, avalia também se uma das seguintes comparações são verdadeiras (pelo menos uma delas): se a nota anterior é diferente da atual, se o código do imposto anterior é diferente do atual ou ainda se não existe nota anterior, ou seja, se a nota lida é a primeira linha listada no relatório.

100


Exemplo 4:Como citamos no item 2.2.2, o relatório de contas a pagar não teve totalizadores

inseridos e veríamos como fazê-los neste capítulo. O problema é basicamente o mesmo do relatório que avaliamos anteriormente. Devido a registros repetidos, o totalizador precisará de algo mais complexo, utilizando os vetores.

Caso exista alguma parcela com mais de um pagamento, o totalizador do valor das parcelas e do valor contábil já ficariam replicados. Ou ainda, caso haja mais de uma parcela para a mesma nota, refletirá no valor contábil que também seria replicado conforme a quantidade de parcelas, conforme o exemplo abaixo, onde inserimos um objeto computado no relatório que finalizamos no item 2.2.2 para totalizar o valor contábil, utilizando a expressão seguinte:

• sum( efentradas_vcon_ent )

A nota com valor contábil de R$ 10.000,00 possui duas parcelas então o valor contábil foi somado duas vezes e a nota com valor contábil de R$ 9.900,00 possui três parcelas, somando conforme seu número de parcelas.

No objeto computado que faz o totalizador, precisamos trabalhar com o vetor para fazer com que o valor contábil de cada nota seja somado apenas uma vez. Utilizaremos então a seguinte expressão no objeto:

• sum (if(efentradas_codi_ent[-1] = efentradas_codi_ent, 0, efentradas_vcon_ent))

A expressão fará com que não seja somado o valor, quando a nota anterior for igual a atual, ou seja, ao emitir a primeira nota do relatório, o campo avaliará se a nota anterior (que não existe) é igual a atual. Como não é, irá somar o valor contábil. Ao ler a segunda linha, que corresponde a mesma nota, mas de uma outra parcela, avaliará se a nota é a mesma que a anterior. Confirmado que sim, irá somar zero que não interferirá no resultado, conforme imagem a seguir:

101


O totalizador das parcelas não poderá apenas checar se a nota anterior ou apenas a parcela anterior são diferente. Será necessário fazer uma checagem com os dois campos, código da nota e código da parcela, conforme expressão e imagem abaixo:

• sum (if( efentradas_codi_ent[-1] = efentradas_codi_ent and

efentradaspar_parc_entp[-1] = efentradaspar_parc_entp, 0,

efentradaspar_vlor_entp))

Os totalizadores dos campos referentes aos pagamentos, não haverão problemas necessitando de tratamentos com vetores para emitirem com os valores corretos. Como será preciso somar todos os registros gerados, basta utilizar um objeto computado para cada campo desejado utilizando a função SUM() com o nome da coluna entre os parênteses.

Os mesmos tratamentos terão de ser feitos nos objetos computados totalizadores porgrupos (por nota, por exemplo), acrescentando apenas a expressão “for group X” noobjeto computado.

Exemplo 5:No item 3.2 indicamos que podemos montar tal relatório com os valores dos líquidos

dos empregados mostrando-os em uma linha apenas, ou seja, não ocupando mais as 12 linhas que eram utilizadas uma para cada competência.

102


Seguindo a mesma ideia do que vimos no exemplo 1, o exemplo da etiqueta, podemos utilizar objetos computados com vetores para mostrar as próximas linhas em uma quebra. O modelo já foi desenvolvido contendo a quebra por empregado e na banda Detalhe, ficaram os campos que são mostrados separados por competência.

Neste caso não haverá a necessidade de forçarmos uma quebra devido a existência de uma referência em comum entre os registros, que será o código do empregado.

Utilizando objetos computados com vetores [0], [1], [2] até [11], teremos 12 objetos computados, cada um representando uma competência, conforme imagem abaixo:

Montaremos o cabeçalho com objetos computados também, utilizando a competência para ser mostrada. Como o cabeçalho corresponde a primeira linha do relatório emitido, teremos as 12 competências do primeiro empregado que poderá ser utilizada para trazer as descrições das competências, conforme sintaxe e imagem abaixo:

• Left (TrazNomeMes( Month( nova_data[0] ) ), 3) + '/' + String( nova_data[0], 'yyyy')

A expressão do objeto computado fará mostrar as três primeiras letras do mês (por causa do uso da função LEFT()) e o ano separados por uma barra.

A emissão será dada da seguinte maneira:

Outros relatórios poderão ser montados utilizando esta mesma lógica, forçando a criação de uma data com a tabela dbo.rowgenerator e realizando uma consulta para encontrar determinado valor baseando-se na data montada.

103


Os totalizadores das competências terão de fazer o somatório baseando-se no mês da competência, ou seja, a expressão da primeira competência, conforme o exemplo anterior, terá de avaliar se a competência informada nos parâmetros é igual a competência referente a primeira coluna. Já a segunda, terá de avaliar se a competência corresponde a um mês após a inicial.

Abaixo temos as três primeiras expressões dos objetos computados utilizados:

• sum (if(Month(nova_data) = Month(comp_ini), liquido , 0))

• sum (if(Month(comp_ini) + 1 = Month(nova_data) + if( Month(nova_data) <

Month(comp_ini) + 1, 12, 0), liquido , 0))

• sum (if(Month(comp_ini) + 2 = Month(nova_data) + if(Month(nova_data) <

Month(comp_ini) + 2, 12, 0), liquido , 0))

Na primeira expressão, apenas irá somar a coluna liquido quando o mês da data criada nova_data for igual ao informado no argumento comp_ini. Para as demais expressões, é comparado o mês inicial somado 1, 2, 3 e assim sucessivamente, porém, não basta apenas somar, pois em alguma das colunas haverá a troca do ano, não podendo apenas fazer a comparação 5 + 8 = 1, ou seja, a competência inicial sendo o mês de Maio (mês 5) e a nona coluna corresponderá ao mês de Janeiro do próximo ano. Então 5 + 8 não será igual ao mês de Janeiro.

Neste caso precisamos também somar um determinado valor ao mês da competência atual para igualar os resultados, por exemplo: 5 + 8 = 1 + 12, sendo que 5 corresponderá ao mês inicial, 8 a quantidade de colunas para identificar qual mês corresponde tal coluna totalizadora, 1 ao mês atual lido e 12 um valor que será acrescido ao valor 1 que representará a quantidade de meses do ano para igualar a 13 e reconhecer que será o mês correto, tendo o seguinte resultado na emissão:

Não basta apenas fazer um somatório utilizando o nome do objeto computado, poistemos que sempre pensar no caso do campo estar na banda Detalhe, que destaforma, o valor será replicado várias vezes.

Caso o relatório fosse desenvolvido de modo a sempre mostrar os meses do anointeiro, ou seja, iniciando em Janeiro e finalizando em Dezembro, os totalizadoresseriam mais simples, necessitando apenas comparar se o mês seria igual a 1, igual a2, e assim sucessivamente.

104


3.4. Sub-relatórios

No desenvolvimento de relatórios, temos a opção de inserir objetos textos, computados, figuras, entre outros por meio do menu Inserir, como já trabalhado no curso Domínio Gerador de Relatórios I. Neste item avaliaremos como utilizar a opção de sub-relatório que não foi vista no outro curso.

Basicamente o sub-relatório é um relatório que é chamado dentro de outro. Ele tem seu desenvolvimento da mesma maneira que um relatório normal, como vimos até o momento. O que torna ele um sub-relatório é uma opção em suas propriedades quando marcada, conforme imagem abaixo:

No Domínio Gerenciador de Relatórios, o sub-relatório não é salvo na classificação indicada pelo usuário. Ele fica disponível na classificação Sub-Relatórios. Como no exemplo da imagem anterior, o relatório com o título Teste Sub-Relatório não estaria disponível na classificação Diversos, mas sim na classificação Sub-Relatórios, de acordo com a imagem seguinte:

105


O modelo poderá ser executado pelo Domínio Gerenciador de Relatórios semproblemas, apenas é demonstrado em uma classificação separada para indicar quetrata-se de um modelo próprio para sub-relatório.

Quando optamos por inserir um sub-relatório, ao clicar na tela do relatório que utilizará ele, abrirá o seguinte objeto:

Nesta janela escolhemos qual o sub-relatório gostaríamos de utilizar, sendo que poderão existir inúmeros modelos disponíveis. Quando selecionado o modelo desejado, a guia Argumentos será habilitada caso o modelo escolhido tenha argumentos a serem relacionados.

Quando emitimos um relatório que criamos e que tenha argumentos, informamos determinados valores para que seja feito o filtro. Nos sub-relatórios não informamos os valores na emissão, mas sim, fazemos uma relação entre o modelo atual e o sub-relatório através da janela anterior na guia Argumentos.

Por exemplo, supondo que tenhamos um modelo de relatório que informarmos o código da empresa que desejamos emitir. No sub-relatório, possivelmente, também terá que existir um argumento para que o relatório atual passe para o sub-relatório qual empresa deve executar o comando SQL de consulta. Na guia Argumentos estará disponível o argumento do sub-relatório e temos de selecionar alguma coluna do relatório atual, a qual faz referência ao código da empresa ou então o próprio argumento do relatório atual, que também estará disponível para selecionarmos.

Muitos modelos de relatórios não necessitam de sub-relatórios para seu desenvolvimento, porém, existem modelos que, dependendo da maneira que foi desenvolvido, da consulta ou do leiaute, será necessário utilizar um sub-relatório. Um exemplo que desenvolveremos aqui, será semelhante ao modelo do item 2.3.3, referente ao resumo da folha. Este emite os proventos e logo abaixo, os descontos. A proposta é desenvolver um modelo semelhante, mas separado por empregados e emitindo os proventos na esquerda e os descontos na direita, em duas colunas separadas.

Um outro exemplo de onde poderíamos utilizar sub-relatórios é num modelo de ficha de empregados, onde temos uma folha para demonstrar o histórico do funcionário, podendo

106


estar um histórico ao lado do outro e sem sub-relatório isso não seria possível de ser desenvolvido.

Exemplo 1:A criação do modelo que desenvolveremos requer a criação de dois sub-relatórios, um

para a listagem de proventos e outro para os descontos. Ambos terão praticamente o mesmo SQL e mesma estrutura, mudando apenas a seleção que filtrará somente os proventos ou somente os descontos.

Iniciaremos o desenvolvimento a partir do relatório que chamará os sub-relatórios. Nele selecionaremos as seguintes colunas:


• foempregados.nome .

Também criaremos os seguintes argumentos:

Com os argumentos, criaremos uma seleção, conforme abaixo:

Em seguida, adequar o leiaute do relatório com uma quebra por empregado, conforme imagem seguinte:

O próximo passo será a criação dos sub-relatórios. Para a criação do modelo que listará os proventos, incluiremos as seguintes colunas em um novo relatório:

• fomovtoserv.i_eventos ;

• fomovtoserv.valor_inf ;

• fomovtoserv.valor_cal .

107


Na guia Computados deste relatório, incluiremos a seguinte linha:

• Nome: nome_evento;

• Definição: (SELECT foeventos.nome

FROM bethadba.foeventos,

bethadba.foparmto

WHERE foparmto.codi_emp = fomovtoserv.codi_emp AND

foeventos.codi_emp = foparmto.codi_emp_eve AND

foeventos.i_eventos = fomovtoserv.i_eventos)

Também precisamos criar os argumentos para fazer a seleção do que o sub-relatório irá listar. Criaremos os seguintes argumentos:

Foi criado um argumento a mais que o relatório que chamará ele, porém, como osub-relatório será executado para cada empregado, então precisamos passar paraele, de qual empregado os dados serão listados.

As seguintes seleções precisam ser criadas:

Selecionamos o tipo da folha mensal (tipo_proces = 11) para listar apenas um tipode cálculo.

O leiaute do sub-relatório deixaremos conforme imagem abaixo:

Note que não foram deixados campos como cabeçalho, pois pretendemos montar ocabeçalho no relatório atual, o qual fará a execução deste sub-relatório.

108


Antes de salvar o modelo, precisamos acessar as propriedades do relatório e marcar a opção Sub-Relatório.

Logo em seguida, podemos editar o modelo que utilizará os sub-relatórios e inserir ele na banda Detalhe, conforme abaixo:

Ao inserir o objeto sub-relatório e selecionar o modelo criado anteriormente, a guia Argumentos foi habilitada, devido ao fato deste modelo possuir argumentos. Nela faremos os relacionamentos entre o modelo atual e o sub-relatório:

Nos dois primeiros relacionamento, selecionamos os próprios argumentos do relatório atual, empresa e competencia. O último teve a coluna do banco de dados selecionada, i_empregados.

É possível utilizar expressões como argumentos, dando duplo clique sobre o campo.

Adequaremos o leiaute com o sub-relatório conforme a seguinte imagem:

109


Apenas na banda Detalhe o sub-relatório inserido poderá ter tamanhos variadosconforme o espaço necessário para a emissão dos dados, ou seja, se gerar 10 linhas,o espaço correspondente a 10 linhas será ocupado pelo sub-relatório, desde que aopção Auto-dimensionar da guia Posição das propriedades do objeto sub-relatório esteja marcada.

O resultado da emissão será a seguinte:

110


Percebe-se que para o empregado 1, foram ocupadas apenas 2 linhas, mas para os outros empregados o espaço ocupado pelo sub-relatório foi proporcional a quantidade de eventos emitidos devido a opção Auto-dimensionar estar marcada.

Criaremos agora, um novo sub-relatório que listará os descontos dos empregados. No próprio relatório, clicaremos com o botão inverso do mouse sobre o sub-relatório já inserido e escolheremos a opção Modificar relatório... que abrirá na mesma seção, o sub-relatório em modo de edição.

Com o sub-relatório aberto, acessaremos o menu Arquivo, opção Salvar como..., para que o mesmo relatório seja criado com outro nome. Em seguida, acessaremos a definição

111


da fonte de dados e na guia Seleção, alteraremos a linha com a coluna bethadba.fomovtoserv.prov_desc, substituindo o valor 'P' por 'D'.

Logo após, podemos inserir um novo objeto sub-relatório, desta vez selecionando o novo modelo criado. Seus argumentos serão os mesmos já relacionados anteriormente e teremos o relatório atual com o seguinte leiaute:

A emissão do relatório com os dois sub-relatórios ficará da seguinte maneira:

112


Nesta imagem é possível perceber que a banda Detalhe foi automaticamente dimensionada para o tamanho máximo ocupado por um dos sub-relatórios.

Os totalizadores podem ser feitos no rodapé dos sub-relatórios, utilizando objetos computados com a função “SUM()”. Outra maneira é utilizar no relatório atual, porém, neste caso, como não é possível transportar os dados emitidos pelo sub-relatório para o relatório atual, a única alternativa seria criar consultas que encontrassem os totais. Porém, o relatório estaria fazendo duas vezes a mesma consulta, uma no sub-relatório e outra no relatório atual.

Exemplo 2:

113


Desenvolveremos um outro modelo de relatório utilizando sub-relatórios não mais na banda Detalhe. O intuito é mostrar o comportamento do objeto sub-relatório fora desta banda que permite dimensionar o relatório conforme necessário.

Também trabalharemos com os dados da folha, listaremos três empregados na mesma folha e suas últimas 6 competências calculadas, juntamente com o líquido de cada uma delas. No desenvolvimento do relatório principal, trabalharemos apenas com alguns dados do cadastro de empregados, selecionando as seguintes colunas:


• foempregados.nome ;• foempregados.admissao .

Criaremos um argumento para informarmos o código da empresa a ser emitido o relatório e faremos a seleção deste argumento com a coluna foempregados.codi_emp. Como já vimos no item 3.3, utilizaremos vetores para emitir três funcionários por página e para isso, precisamos criar o computado conforme imagem a seguir:

Em seguida, criaremos uma quebra por este computado e marcaremos a opção Nova página na quebra para gerar apenas uma quebra por página, deixando o leiaute do relatório da seguinte maneira:

114


Como encontra-se o relatório, apenas seria listados os códigos, nomes e datas de admissões dos empregados em grupo de três por folha, como já vimos anteriormente. Em seguida, iniciaremos a implementação do sub-relatório.

Na listagem das competências e os líquidos calculados, utilizaremos as seguintes colunas em um novo relatório que será transformado em sub-relatório:

• fobaseserv.competencia ;

• fobasesserv.proventos ;• fobasesserv.descontos .

O sub-relatório terá os seguintes argumentos:

115


Após a criação dos argumentos, criaremos as seleções abaixo:

Esta consulta fará com que seja listado todos os meses calculados e como desejamos mostrar apenas os últimos, vamos criar uma ordenação pela competência, de forma descendente e em seguida, montar o leiaute do sub-relatório que ficará da seguinte maneira:

Por último, podemos marcar a opção Sub-relatório em suas propriedades e salvá-lo.

Ao inserir o sub-relatório no relatório principal, precisamos vincular os argumentos conforme a seguinte imagem:

Anteriormente foi indicado que pode-se utilizar expressões nos argumentos e como o modelo está utilizando vetores para mostrar três empregados na mesma quebra, o argumento do empregado será vinculado conforme o uso do vetor no relatório principal.

Montaremos o leiaute com os sub-relatórios da seguinte maneira:

116


O tamanho da altura dos sub-relatórios, terá de ser testado até que sejam listadas nomáximo 6 linhas, conforme desejávamos.

A emissão terá o seguinte resultado para a primeira página:

117


Assim encerramos este item, onde demonstramos maneiras diferentes da utilização de sub-relatórios.

118

Saiba que este documento não poderá ser reproduzido...

Documents

Transcript of Saiba que este documento não poderá ser reproduzido...