Changes between Version 1 and Version 2 of Project

Timestamp:

09/13/26 21:29:39 (12 days ago)

Author:

223235

Comment:

--

Project

@@ -1 @@
-== Project Description
-
-
-== Податочни побарувања
-=== Ентитети
-
-
-
-**ADMIN**
-* user_id int, примарен клуч DEFAULT 1
-* CONSTRAINT fk_admin_user
-        FOREIGN KEY (user_id)
-        REFERENCES api_user(user_id)
-        ON UPDATE CASCADE
-\\test
-test
-test
+## Project Description
+
+Овој проект претставува интегриран информациски систем за организирање на процесот на нарачување, подготовка и доставување храна и пијалоци од ресторани до компании. Неговата главна цел е да овозможи контролирана соработка помеѓу рестораните и компаниите, преку која вработените во компаниите можат да нарачуваат оброци за време на работното време.
+
+Системот ги опфаќа сите поважни аспекти од процесот: управување со корисници, компании и ресторани, дефинирање договори за соработка, креирање менија, евидентирање нарачки, организирање достава, издавање фактури, оставање рецензии и водење програма за лојалност.
+
+Сите лица што го користат системот најпрво се евидентираат како корисници. За секој корисник се чуваат име, презиме, адреса за електронска пошта и телефонски број. Електронската пошта мора да биде единствена и да има правилен формат, додека телефонскиот број, доколку е внесен, исто така мора да биде единствен и форматиран според предвидените правила.
+
+Корисниците се поделени во три меѓусебно исклучиви улоги:
+
+- администратор;
+- клиент, односно вработен во компанија;
+- доставувач.
+
+На тој начин, една корисничка сметка не може истовремено да има повеќе различни улоги.
+
+Администраторите се поврзани со рестораните и се одговорни за управување со податоците што се однесуваат на соодветниот ресторан. Еден администратор припаѓа на точно еден ресторан, додека еден ресторан може да има повеќе администратори.
+
+Слично правило важи и за доставувачите. Секој доставувач работи за еден ресторан, а ресторанот може да располага со повеќе доставувачи. Клиентите се поврзани директно со компанијата во која работат. Еден клиент може да припаѓа на една компанија, додека една компанија може да има повеќе регистрирани клиенти кои преку системот создаваат сопствени нарачки.
+
+За секоја компанија се чуваат нејзиното име и адреса, при што името мора да биде единствено. За рестораните се чуваат подетални информации, како име, локација, електронска пошта, телефонски број и веб-страница. Електронската пошта и телефонскиот број на ресторанот мора да бидат единствени. Овие информации овозможуваат прецизно идентификување на деловните субјекти и нивно правилно поврзување со останатите податоци во системот.
+
+Соработката помеѓу компаниите и рестораните се реализира преку договори. Секој договор поврзува една компанија со еден ресторан и содржи датум на почеток, датум на завршување и соодветен статус. Датумот на завршување не може да биде пред датумот на почеток.
+
+Со чувањето на договорите како посебни записи може да се води историја на претходните соработки, како и да се проверува дали определен договор е активен во моментот на нарачувањето. Базата овозможува една компанија и еден ресторан да учествуваат во повеќе договори во различни временски периоди. Валидноста на активниот договор е едно од главните деловни правила при изборот на храна, пијалоци и доставувач.
+
+За секој договор може да се дефинираат термини за ручек. Терминот содржи ден во неделата, време на почеток и завршување, како и временско ограничување за предвремено нарачување. Времето на завршување мора да биде по времето на почеток, а вредноста за предвремено нарачување не смее да биде негативна.
+
+Терминот може да биде поврзан и со конкретна групна нарачка на компанијата. Ова овозможува доставата да се приспособи на работното време и на паузите за ручек во различни компании.
+
+Секој ресторан располага со сопствено мени составено од јадења и пијалоци. За јадењата се чуваат:
+
+- назив;
+- опис;
+- цена;
+- тежина;
+- категорија;
+- ресторан што го нуди јадењето.
+
+Цената на јадењето не смее да биде негативна, а тежината мора да биде поголема од нула. Називот на јадењето мора да биде единствен во рамките на еден ресторан. Категориите овозможуваат јадењата да се групираат, на пример, како појадок, главно јадење, салата или десерт.
+
+За пијалоците се чуваат:
+
+- назив;
+- цена;
+- количина во милилитри;
+- ресторан што го нуди пијалокот.
+
+И кај пијалоците цената не смее да биде негативна, количината мора да биде позитивна, а називот мора да биде единствен во рамките на ресторанот.
+
+Составот на јадењата е моделиран преку состојки. Едно јадење може да содржи повеќе состојки, а една состојка може да се користи во повеќе јадења. Дополнително, состојките се поврзуваат со алергени. Една состојка може да содржи повеќе алергени, а ист алерген може да биде присутен во повеќе состојки.
+
+За секој алерген се чуваат име и опис. Преку овие врски може да се утврди кои алергени потенцијално ги содржи определено јадење, што е особено важно за клиентите со алергии или специфични прехранбени ограничувања.
+
+Процесот на нарачување е организиран на две нивоа. На првото ниво се наоѓа компаниската нарачка, која претставува заедничка нарачка за една компанија. Во неа се групираат поединечните нарачки на вработените.
+
+На второто ниво се наоѓа клиентската нарачка, создадена од конкретен вработен. За неа се чуваат:
+
+- датум и време на креирање;
+- статус на нарачката;
+- вкупен износ;
+- клиент што ја направил нарачката;
+- компаниска нарачка во која припаѓа.
+
+Системот проверува дали клиентот што ја креира нарачката припаѓа на истата компанија за која е создадена компаниската нарачка. Со тоа се спречува вработен од една компанија да додава нарачки во групната нарачка на друга компанија.
+
+Во секоја клиентска нарачка може да бидат вклучени повеќе јадења и пијалоци. Поврзувањето се реализира преку посебни табели за нарачани јадења и нарачани пијалоци. Пред да биде прифатен производот, се проверува дали ресторанот што го нуди има важечки договор со компанијата на клиентот.
+
+Вкупниот износ на нарачката не се внесува произволно, туку автоматски се пресметува од цените на избраните јадења и пијалоци. При додавање, промена или отстранување ставка, вкупната вредност повторно се пресметува. Со тоа се намалува можноста за појава на неконзистентни податоци.
+
+За компаниската нарачка може да се организира една достава. Во записот за доставата се чуваат:
+
+- датум на доставување;
+- статус на доставата;
+- дополнителни забелешки;
+- доставувач задолжен за транспортот.
+
+При доделување доставувач се проверува дали тој работи за ресторан што има активен договор со компанијата. Статусите овозможуваат следење на доставата низ различни фази, како создадена, доделена, во тек или завршена.
+
+За секоја компаниска нарачка може да се создаде и една фактура. На овој начин повеќе индивидуални нарачки на вработените можат да бидат обединети во една пресметка за компанијата.
+
+Системот поддржува и оценување на услугата. Основната рецензија содржи:
+
+- коментар;
+- време на креирање;
+- општа оцена од еден до пет.
+
+Рецензиите се специјализираат како рецензии за нарачка или рецензии за достава. Кај нарачката дополнително се оценуваат квалитетот на храната и ресторанот, додека кај доставата се оценуваат доставувачот и брзината на доставувањето.
+
+Една нарачка или достава може да има најмногу една соодветна рецензија, со што се спречува повеќекратно оценување на истиот запис.
+
+Дополнителна функционалност на системот е програмата за лојалност. Секој клиент може да има еден запис со:
+
+- тековен број поени;
+- статус на лојалност;
+- датум на зачленување;
+- ниво на лојалност.
+
+Нивоата на лојалност се определуваат според минимален и максимален број поени и можат да обезбедуваат различни поволности, како:
+
+- попуст;
+- бесплатна достава;
+- приоритетна корисничка поддршка.
+
+Поените се пресметуваат врз основа на историјата и вредноста на нарачките, при што откажаните нарачки не придонесуваат кон вкупниот број поени.
+
+Базата содржи функции, процедури и тригери преку кои се спроведуваат главните деловни правила. Тие ги извршуваат следните задачи:
+
+- проверуваат дали постои активен договор;
+- ја пресметуваат вкупната цена на нарачката;
+- ги освежуваат поените за лојалност;
+- создаваат и финализираат нарачки;
+- додаваат и отстрануваат производи;
+- доделуваат доставувачи;
+- го контролираат менувањето на статусите;
+- го спречуваат внесувањето невалидни податоци.
+
+Дополнително, креираните погледи овозможуваат поедноставен приказ на менијата, целосните нарачки, доставите, рецензиите, приходите од договорите, корисниците на компаниите, фактурирањето и програмата за лојалност.
+
+На овој начин, проектот не претставува само едноставна апликација за нарачување храна, туку целосен систем за управување со деловната соработка помеѓу компании и ресторани. Релацискиот модел овозможува централизирано и конзистентно чување на податоците, додека ограничувањата и автоматизираната логика ја заштитуваат базата од невалидни нарачки, погрешни пресметки и недозволени поврзувања меѓу корисниците, компаниите, рестораните и доставувачите.
+
+## Податочни побарувања
+
+### Кориснички улоги
+
+Системот дефинира три основни кориснички улоги:
+
+- **API_ADMIN** – администратор поврзан со ресторан;
+- **CUSTOMER** – клиент или вработен поврзан со компанија;
+- **DRIVER** – доставувач поврзан со ресторан.
+
+Секој корисник може да има само една од наведените улоги.
+
+### Компании и ресторани
+
+Системот треба да овозможи:
+
+- регистрирање компании и нивните адреси;
+- регистрирање ресторани и нивните контактни информации;
+- поврзување клиенти со компании;
+- поврзување администратори и доставувачи со ресторани;
+- склучување и следење договори меѓу компании и ресторани;
+- проверка на временската важност и статусот на договорите.
+
+### Мени
+
+Секој ресторан треба да може да располага со сопствено мени составено од:
+
+- јадења;
+- пијалоци;
+- категории на јадења;
+- состојки;
+- алергени.
+
+Системот треба да овозможи едно јадење да содржи повеќе состојки и една состојка да се користи во повеќе јадења. Исто така, треба да биде можно поврзување на состојките со алергени.
+
+### Нарачки
+
+Системот треба да овозможи:
+
+- создавање компаниски нарачки;
+- групирање повеќе клиентски нарачки во една компаниска нарачка;
+- додавање јадења и пијалоци во клиентските нарачки;
+- автоматско пресметување на вкупниот износ;
+- следење на статусот на нарачката;
+- проверка дали клиентот нарачува за сопствената компанија;
+- проверка дали компанијата има активен договор со ресторанот.
+
+### Достава и фактурирање
+
+За компаниските нарачки системот треба да овозможи:
+
+- создавање и доделување достава;
+- избор на соодветен доставувач;
+- следење на статусот на доставата;
+- внесување забелешки;
+- поврзување на една фактура со една компаниска нарачка.
+
+### Рецензии
+
+Корисниците треба да можат да оставаат:
+
+- општа оцена и коментар;
+- оцена за храната;
+- оцена за ресторанот;
+- оцена за доставувачот;
+- оцена за брзината на доставата.
+
+Сите оценки мора да бидат во интервал од еден до пет.
+
+### Програма за лојалност
+
+Системот треба да овозможи:
+
+- евидентирање поени за клиентите;
+- автоматско пресметување на поените;
+- определување ниво на лојалност;
+- доделување попусти;
+- овозможување бесплатна достава;
+- овозможување приоритетна поддршка.