!-- hit.ua -->
З точки зору програми, облікова система базується на архітектурі, яка визначається фреймворком Zippy.
У зв'язку з чим, розробнику слід ознайомиться зі сторінками проектів
Фреймворк Zippy і Zippy
DB
Стилі програми засновані на Twitter Bottstrap. Верстка сторінки, бічне меню та інше зроблено на адмінці AdminLTE2.
У загальному випадку сторінку можна умовно розділити на бекенд і фронтенд. Бекенд - це PHP файл (папка pages),
фронтенд - шаблон (папка templates/pages). Також у шаблонах є папка printforms із шаблонами друкованих форм
документів
та звітів.
Файл бекенда по суті є комбінацією контролера та моделі - методи є методами контролера, що реагують на події
фронтенда, тобто на дії
Користувача, а поля та zippy-компоненти - це модель, що зберігає стан сторінки.
Існує кілька варіантів взаємодії між фронтендом і бекендом, які можуть використовуватися як окремо, так і в
комбінації
один з одним.
Через компоненти zippy
Використовується для двостороннього обміну між фронтендом та бекендом. Насамперед із елементами введення з форм,
а також для виведення таблиць, в яких є елементи виклику методів бекенда (наприклад, іконки редагування).
У цьому випадку фронтенд-компонент прив'язується через атрибут zippy до бекенд частини компонента та забезпечує
двосторонній обмін даними, реакцію на події,
а також персистентність стану сторінки, оскільки сторінка разом з компонентами та їх даними кешуються в сесії,
та відновлюється після перезавантаження.
Крім цього, основні компоненти мають вбудовану можливість обробки подій (викликів бекенду) за допомогою ajax
запитів
без перезавантаження сторінки.
За допомогою шаблонізатора Mustache
Якщо виведення даних одностороннє, тобто тільки у бік фронтенду і не передбачає введення даних
(наприклад показати/приховати якийсь блок залежно від даних, вивести якусь інформацію і т.д.),
використовується шаблонізатор Mustache, який працює за типом шаблонізаторів Twig або Smarty. Таке рішення набагато
простіше, ніж за допомогою компонентів Zippy.
Дані шаблонізатора додаються в поле сторінки - масив $this->_tvars.
Також за допомогою Mustache рендеруються друковані форми документів та звітів.
Запити від javascript фреймворків
Для обробки запитів, не пов'язаних із подіями компонентів zippy, передбачено виклик
методів сторінок за ім'ям. Для цього слід використовувати javascript функцію callpagemethod, яка йде з фреймворком
та формує правильний url для виклику сторінки. Метод розташований у
/vendor/leon-mbs/zippy/assets/js/zippy-bundle.js.
Зазвичай на фронті використовується бібліотека jquery або, у складніших випадках (наприклад, віджет перегляду
документа або сторінка нарахування зарплати), фреймворк Vue, але
може бути використание будь-яке Javascript рішення.
Програма складається з двох базових частин - ядра з загальними сторінками
і функціональністю (користувачі, управління системою і т.д.) і, власне,
облікової частини куди входять об'єкти метаданих (документи, довідники, звіти), що реалізують основну
бізнес-логіку.
У термінах 1С можна умовно назвати ці частини платформою і конфігурацією.
Основа облікової частини - об'єкти метаданих (довідники, документи, звіти, журнали).
Об'єкти спроектовані з мінімальною залежністю один від одного і доступні через загальне меню, яке
будується
динамічно, згідно зі списком об'єктів, що задається адміністратором.
Це дозволяє незалежно модифікувати їх без зміни інших об'єктів і модулів системи.
Розробники за аналогією з конструктором Lego можуть легко створювати різні конфігурації (в термінології
1С) під різні типи бізнесу,
обмінюватися реалізацією окремих об'єктів системи та друкованими формами простим копіюванням файлів.
Алгоритми бізнес-логіки реалізуються безпосередньо на мові PHP.
Шаблони (бланки) друкованих форм документів і звітів виконані в чистому HTML,
що дозволяє як друкувати їх безпосередньо, так і експортувати в Word, Excel або PDF, а також
коригувати їх за допомогою звичайного текстового редактора.
| ТМЦ | товари, матеріали, продукція |
| Склади | склади, магазини |
| Контрагенти | постачальники, покупці |
| Документи | первинні документи фіксують господарські операції |
У відповідності з архітектурою фреймворка, всі бізнес-суті реалізовані класами, наслідуваними від
Entity.
Аналітичний облік ведеться на підставі руху матеріальних і грошових коштів, відповідно до
господарських операцій.
Система не зберігає початкові і поточні залишки за період (використовується повний перерахунок рухів).
Це спрощує огранізацію даних і дозволяє вводити і змінювати інформацію заднім числом, а також переднім,
що дозволяє виконувати
резервування товару і планування операцій.
Аналітичні дані зберігаються в одній таблиці entrylist. По суті, таблиці фактів в ROLAP де
вимірювання - бізнес-сутності.
Збільшення запасів відображається записом з позитивними значеннями кількості і суми, зменшення -
негативними, таким чином залишки і обороти по товару
виходять простим підсумовуванням за період.
Також аналітичні дані, як і дані, що посилаються на інші бізнес-суті,
зберігаються в самому документі в упакованому вигляді. Подібна денормалізація дозволяє уникнути
додаткових звернень до БД, а також дозволяє зберігати "історичні" дані в документі
- документ зберігає всі атрибути такими, якими вони були на момент створення документа.
Складський облік ведеться по партіях. Партія - той же товар за тією ж обліковою ціною (ціна надходження) незалежно від постачальника. Записи по рухах на складі зберігаються в таблиці store_stock, де крім посилання на склад і на ТМЦ вказана облікова ціна (партія).
Елементи довідників - об'єкти, що знаходяться в просторі імен App\Entity. Об'єкти
призначені для зберігання довідкових бізнес-сутностей.
Для редагування переліків об'єктів призначені відповідні сторінки в просторі імен
App\Pages\Reference.
Сторінки звітів знаходяться в просторі імен App\Pages\Report.
З кожним звітом пов'язана друкована форма, яка знаходиться в папці /templates/printforms
Журнали об'єднують об'єкти та бізнес-сутності за типом використання. Наприклад - журнал документів, журнал
замовлень.
Сторінки журналів знаходяться в просторі імен App\Pages\Register.
Для кожного типу документа реалізований клас в просторі імен App\Entity\Doc, успадкований
від базового класу Document.
Клас документа реалізує бізнес-логіку відповідно до типу госп. операції і забезпечує зберігання
документа в БД.
З кожним типом документа пов'язані сторінка редагування документа в просторі імен
App\Pages\Doc і шаблон друкованої форми в папці /templates/printforms.
Кожен клас документа
передбачає два методи: generateReport и Execute.
Метод generateReport призначений для заповнення друкованої форми даними документа.
Метод Execute змінює данні аналітичного обліку - фіксує рух матеріальних і грошових
коштів.
За збереження документа в БД та інші загальні операції над усіма типами документів відповідає базовий
клас Document.
Всі документи зберігаються в одній таблиці. Таблиця містить
кілька загальних полів (наприклад: дати, номер документа) і текстове поле content де зберігається деталізація
документа у вигляді XML.
Використання XML дозволяє, при необхідності, виконувати пошук за документами, орієнтуючись на XML теги,
а також використовувати XPath. Упаковку і розпаковування детальних даних документа виконує
базовий клас.
Для цього клас містить масив $headerdata для шапки та таблиць
частини документа.
Сторінка редагування документа повинна записувати атрибути до цього масиву. Таблична частина
пакується в одне з полів, наприклад $doc->packDetails('detaildata', $itemlist);
Деякі поля загального признаяення,яких слід притримуватись для сумісності документів та правильної работи бізнес-логіки .
| headerdata['author'] | Автор (створювач) документа |
| user_id | Користувач ассоційований з документом. За замовчанням- автор |
| customer_id | Коннтрагент (якщо заданий) |
| branch_id | Філія,якщо ввімкнена підтримка |
| firm_id | Компанія |
| parent_id | Батьківський документ (підства) |
| state | Статус |
| headerdata['store'] | id складу |
| headerdata['time'] | Час (document_date має тільки дату) |
| headerdata['payment'] | id грошового рахунку для оплати (каса, банк) |
| amount | Сума по документу (по позиціях) |
| payamount | Сума дл сплати (amount мінус наприклад знижка) |
| payed | Фактична оплата (сума по таблиці платажів) |
| headerdata['payed'] | Внесена оплата. Для відповідного поля на сторінці редагування документу. Може не збігатись з payed наприклад при частковій оплаті |
| headerdata['detaildata'] | Упакована таблична частина. |
Всі об'єкти зареєстровані в таблиці метаданих на відповідній сторінці налаштувань.
По таблиці метаданих автоматично формується меню.
У таблиці вказується тип, назва об'єкта, ім'я класу (простір імен обчислюється за типом),
група (для другого рівня меню).
Припустимо потрібно додати в систему документ Товарно-транспортна накладна. Необхідно внести запис в метадані, створити сторінку редагування документа, клас-сутність для зберігання документа в БД і HTML шаблон друкованої форми.
Необхідна послідовність:App\Entity\Doc клас сутності TTN, успадкований
від класу Document.
generateReport і Execute.
Метод Execute виконує відповідні записи в таблиці аналітичного обліку.
Метод generateReport звертається до генератора звітів, передаючи йому шаблон друкованої
форми і дані з деталізації документа, створюючи на виході
HTML файл із заповненим бланком для друку або експорту.
/app/entity/doc/
BankStatement в просторі імен App\Pages\Doc як звичайна сторінка
відповідно
з архітектурою фреймворка Zippy. Файл з класом сторінки створюємо в каталозі
app/pages/doc, шаблон сторінки - в каталозі /templates/pages/doc.
/templates/printforms.Документ ТТН з'явиться в головному меню і буде готовий до використання.
У програмі передбачено API для інтеграції з зовнішніми системами.
Вбудований готовий набір функцій виконаний на основі JSON-RPC. Опис функцій знаходиться за адресою
/api/help. Перед використанням в налаштуваннях системи необхідно вказати метод авторизації. API дозволяє
працювати з довідниками товарів і контрагентів, створювати замовлення і відслідковувати їх статус.
| branches | Філії |
| contracts | Договори. Пов'язують компанію і контрагента |
| crontask | Завдання планувальника |
| custacc | Балансові рахунки контрагентів. При проведенні документу виконується рух по дебету обо кредиту. Позитивнмй баланс - кредитовий борг фірми, негативний - дебетовий. Також в таблиці Зберігаются нараховані бонуси |
| custitems | Товари у постачальника |
| customers | Контрагенти |
| docstatelog | Исторія статусів документіа |
| documents | Документи. Поля: amount - сума по документу, payamount - до сплаты, payed - оплачено (сума по таблиці payments) |
| empacc | Особовий рахунок співробітника. В першу чергу для руху по зарплаті. |
| employees | CСпівробітники. Поле login з'єднує з користувачем системи (аккаунтом) |
| entrylist | Рух по складу |
| equipments | Основні засоби та обладнання |
| eventlist | Події, використовуєтся для контрагентів і завдань |
| files | Загружені файли |
| filesdata | Зміст файлів. Окрема таблиця щоб не грузити всю БД |
| firms | Компанії |
| images | Зображення |
| iostate | Записи прибутків та видатків |
| issue_* | Таблиці модуля Проекти та завдання |
| item_cat | Категорії (групи) ТМЦ |
| item_set | Комплекти для ТМЦ |
| items | Номенклатура ТМЦ |
| keyval | Допоміжна таблиця для даних типу ключ-значення |
| messages | Повідомлення |
| metadata | Бізнес-об'єкти (документє, довідники, щвіти, журналм... Формує меню програми) |
| mfund | Грошові рахунки рахунки |
| note_* | Таблиці модуля Органайзер |
| notifies | Повідомлення |
| options | Загальні налаштування та налаштування модулів |
| parealist | Виробничі дільниці |
| paylist | Оплати (рух по грошових рахунках) |
| poslist | POS термінали |
| prodproc | Виробничі процеси |
| prodstage | Виробничі етапм |
| prodstageagenda | Розклад этапів |
| promocodes | Промо коди |
| roles | Ролі користувачів |
| saltypes | Типи нарахувань та утримань по зарплаті |
| services | Послуги, роботи |
| shop_* | Таблиці онлайн-каталогу |
| stats | Службова таблиця для статистичних даних |
| store_stock | Партії товарів. Пов'язує товар, склади та облікові ціни. Поле qty (кількість) вираховується за допомогою триггерів при зміні таблиці entrylist Поле partion - облікова ціна. Додаткова розбивка якщо ввімкнений облік по серіях |
| stores | Склади |
| subscribes | Підписки |
| taglist | Теги |
| timesheet | Облік робочого часу |
| users | Користувачі системи. admin - невидялюваний користувач |