Em nenhuma parte do sistema é permito o uso de tabelas de movimentos mais compartilhadas do que as tabelas de cadastro.
Isso porque deixar a tabela de movimento mais compartilhada do que a tabela de cadastros causará quebra na integridade referencial das tabelas.
Na verdade, esse conceito se aplica a quaisquer tabelas que possuam relacionamento 1:n (um para muitos). Pode ser cadastro x movimento, cabeçalho x item etc..
Por exemplo:
Tabelas: Cadastro de clientes (SA1) e títulos a receber (SE1)
Relacionamento: (relacionamento 1:n → isto é, deve existir um, e somente um registro de cadastro de clientes para muitos títulos a receber)
Compartilhamentos adequados: Mesmo nível de compartilhamento entre ambas as tabelas ou tabela de cadastros de clientes (SA1) mais compartilhada do que a tabela de títulos a receber (SE1).
O que ocorre se a tabela de títulos a receber for mais compartilhada do que a tabela de cadastro de clientes? Haverá margem para a existência de um registro na tabela de títulos a receber relacionada a mais de um cliente, quebrando a integridade referencial das tabelas.
| Tabela SA1 | Tabela SE1 | Permitido? |
|---|---|---|
| Compartilhado | Compartilhado | Sim |
| Compartilhado | Exclusivo | Sim |
| Exclusivo | Compartilhado | Não |
| Exclusivo | Exclusivo | Sim |
Alguns exemplos de tabelas que possuem o relacionamento 1:n (um para muitos) no módulo financeiro incluem, mas não se limitam a:
| Um registro | Para muitos registros |
|---|---|
| SA1 | SE1 |
| SA2 | SE2 |
| SA3 | SE1 |
| SEH | SE1 |
| SEH | SE2 |
| SA6 | FK5 |
| SA6 | SEE |
| SA6 | SEA |
| SA6 | SE8 |
Isso significa que SE1 não pode ser mais compartilhada do que SA1, SE2 não pode ser mais compartilhada do que SA2 e assim por diante.
Tentar contornar cenários de compartilhamento indevido (talvez utilizando variáveis de ambiente ou campos MSFIL e FILORIG) acarretará em código de alta complexidade, criação de débitos técnicos e perda de performance. Essa prática não é recomendada. O relacionamento deve utilizar a chave estrangeira. |
Em ambientes configurados com gestão de empresas, o Protheus permite o compartilhamento das tabelas em três níveis diferentes: Empresa, Unidade de negócio e Filial. Quando uma tabela está compartilhada em mais níveis do que outra, dizemos que ela é mais compartilhada do que a outra.
Exemplo: Tabela SA1 mais compartilhada do que SE2
* C = Compartilhada, E = Exclusiva
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | C | E |
| Unidade de negócio | C | E |
| Filial | C | E |
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | C | E |
| Unidade de negócio | C | E |
| Filial | C | C |
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | C | E |
| Unidade de negócio | C | C |
| Filial | C | C |
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | E | E |
| Unidade de negócio | C | E |
| Filial | C | E |
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | E | E |
| Unidade de negócio | C | E |
| Filial | C | C |
| Tabela | SA1 | SE1 |
|---|---|---|
| Empresa | E | E |
| Unidade de negócio | E | E |
| Filial | C | E |
Essa informação pode ser obtida na tabela de Relacionamentos (SX9).
Os campos Domínio (X9_DOM) e Contra Domínio (X9_CDOM) indicam as tabelas que estão sendo relacionadas, e os campos Cardinalidade do Domínio (X9_LIGDOM) e Cardinalidade do Contra Domínio (X9_LIGCDOM) indicam como é o relacionamento.
Ainda no exemplo de SA1 x SE1, vemos que o relacionamento é 1:n.
Mais informações: SX9 – Relacionamento entre tabelas
Compartilhamento de tabelas relacionadas ao Cadastro de Clientes
Qualquer alteração no dicionário de dados ou na estrutura do banco de dados deve ser feita por um Administrador de Banco de Dados (DBA) ou outro profissional igualmente qualificado. |