Tecnologias e Sistemas de Informação para Gestão

Ano Letivo 2021/2022

Licenciatura em Contabilidade e Administração
1º Ano
1º Semestre

Gestão de Pedidos de Devolução

Trabalho realizado por:

Grupo 13
João Nunes Nº 2211049
Cláudia Peixoto Nº 2210768
Helena Ferreira Nº 2211155
Paulo Santos Nº 2211407
Carolina Pereira Nº 2211437
Inês Silva Nº 2211439
Inês Silva Nº 2211461
Joana Silva Nº 2211462
Introdução do tema

No âmbito da Unidade Curricular de Tecnologias e Sistemas de

Informação para a Gestão, foi-nos proposto a realização de um projeto que tem
como finalidade consolidar os nossos conhecimentos sobra a matéria lecionada
nas aulas.
Relativamente à primeira parte do projeto, foi-nos pedido que, mediante
ao caso que nos foi proposto, desenvolvêssemos o Modelo Relacional e um
Diagrama ER.
A Electric é uma empresa que comercializa produtos elétricos e
eletrónicos representando várias marcas em Portugal. Devido ao seu
crescimento foi necessária a introdução de uma gestão de pedidos de
devolução, esta gestão é essencial quando ocorre algum erro e os clientes
pretendem devolver os produtos que não se encontram nas condições que
deveriam.
Com a implementação desta nova medida esta empresa viu-se na
necessidade de criar certas regras para a devolução dos seus produtos:
 O prazo máximo de aceitação dos produtos é de 30 dias, após o qual
não se aceitam as devoluções;
 As embalagens entregues devem ser as originais, estarem intactas e
fechadas. Caso isto não se verifique, o produto não poderá ser aceite;
 O motivo de devolução terá de ser válido, ou a devolução não será
aceite;
 O produto entregue não pode ter sido utilizado, caso contrário não será
aceite. Existe uma exceção a esta regra, quando o motivo é (material
danificado).
Com o aumento do número de devoluções, tornou-se necessário
desenvolver uma aplicação para gerir os pedidos de devolução e dar-lhes
seguimento. O processo de devoluções é constituído por seis passos:
registo do pedido, análise do pedido, decisão, verificação do material
devolvido, resolução de pedido de assistência e processo final.
Modelo Entidade-Relacionamentos (E-R)
Modelo conceptual de dados, com um elevado nível de abstração.
Permite que as diferentes perspetivas dos dados apresentados pelos gestores,
pelos utilizadores e pelos analistas se aproximem, formando uma estrutura
comum. É um auxiliar precioso na conceção de bases de dados.

Modelo Relacional
CLIENTE (cod-cliente, nome, nºcontribuinte, telefone, morada)
PRODUTO (referência, designação, preço unitário, stock atual, stock mínimo)
PEDIDO (cod-pedido, cod-cliente, cod-funcionário, referência, quantidade a devolver,
preço unitário, nºfatura, data de emissão da fatura, data de pedido de devolução,
prazo de devolução, motivo de devolução, motivo de devolução, cod-estado)
FUNCIONÁRIO (cod- funcionário, nome, data de nascimento, idade, telefone, morada,
cod-função)
VERIFICAÇÃO (cod-verificação, cod-pedido, cod-funcionário, verificação pedido, data
verificação,cod-estado)
ASSISTÊNCIA (cod-assistência, cod-pedido, cod-funcionário, data assistência, cod-
estado)
DEVOLUÇÕES (cod-devolução, cod-pedido, cod-funcionário, cod-estado, quantidade,
valor final, valor final c/iva, data devolução, duração processo)

Identificação das Entidades

O primeiro passo realizado para a resolução deste problema foi
identificar as entidades envolvidas em todo o processo.
Entende-se por entidade um conjunto de pessoas, lugares, objetos,
acontecimentos ou conceitos sobre o qual pretendemos guardar dados.
Neste caso, as entidades que identificamos foram: CLIENTE,
PRODUTO, PEDIDO, FUNCIONÁRIO, VERIFICAÇÃO, ASSISTÊNCIA e
DEVOLUÇÕES.

Identificação dos Atributos das Entidades

Os atributos são um conjunto de características específicas de cada
entidade. Um atributo ou conjunto de atributos que identificam de forma única o
registo numa tabela chama-se chave primária. Cada atributo tem um domínio,
que é o conjunto de valores que lhe podem ser atribuídos.
Assim, o esquema de uma tabela é definido através do nome da tabela
(entidade) em maiúsculas, seguido do nome dos atributos entre parêntese.
Exemplo:
FUNCIONÁRIO (cod- funcionário, nome, data de nascimento, idade, telefone,
morada, cod-função): FUNCIONÁRIO representa o nome da tabela/ entidade,
enquanto, cod- funcionário, nome, data de nascimento, idade, telefone,
morada, cod-função representam os atributos. Uma vez que, o cod-funcionário
encontra-se sublinhado, torna-se claro que este representa a chave primária da
tabela compra.

Identificação dos Relacionamentos e Cardinalidades

Um relacionamento é uma associação útil entre entidades. A cada
relacionamento é atribuído um nome que descreve a sua função. No Diagrama
E-R representa-se por um losango. A cada uma das ligações entre entidades
dá-se o nome de ocorrência do relacionamento.
A cardinalidade representa o número de ocorrências de uma entidade,
associadas com uma ou mais ocorrências das entidades que com ela se
relacionam. Podem ser de três tipo: 1:1 (de um para um); 1:M (de um para
muitos) e de M: N (de muitos para muitos).
Os relacionamentos e as cardinalidades que identificamos foram as
seguintes:

Entidade Relacionamento Cardinalidade Entidade

Cliente Compra 1:M Produto
Produto Enviado para 1:M Verificação
Verificação Faz 1:1 Análise
Cliente Faz M:1 Devolução
Devolução Tem M:1 Pedido
Pedido Emitido M:1 Funcionário

Analisando cada um destes relacionamentos e respetivas cardinalidades:

Cada cliente compra vários produtos (cardinalidade 1:M)

Cada produto tem várias verificações (cardinalidade 1:M)

Cada cliente faz uma devolução e cada devolução só pode ser feita por um cliente (cardinalidade
1:1)

O mesmo produto pode estar presente em várias devoluções, mas cada devolução só tem um
produto (cardinalidade M:1)

Podem ser registadas várias devoluções, mas a cada uma das devoluções só corresponde a um
pedido (cardinalidade M:1)
Cada funcionário emite vários pedidos, mas cada pedido so é feito por um um funcionário
(cardinalidade M:1)