Документація розробника

Архітектура

Архітектура програми

З точки зору програми, облікова система базується на архітектурі, яка визначається фреймворком 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 рішення.

Архітектура бiзнес-логiки

Програма складається з двох базових частин - ядра з загальними сторінками і функціональністю (користувачі, управління системою і т.д.) і, власне, облікової частини куди входять об'єкти метаданих (документи, довідники, звіти), що реалізують основну бізнес-логіку.
У термінах 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 шаблон друкованої форми.

Необхідна послідовність:
  1. Створюємо в просторі імен App\Entity\Doc клас сутності TTN, успадкований від класу Document.
  2. Перевизначити методи generateReport і Execute. Метод Execute виконує відповідні записи в таблиці аналітичного обліку. Метод generateReport звертається до генератора звітів, передаючи йому шаблон друкованої форми і дані з деталізації документа, створюючи на виході HTML файл із заповненим бланком для друку або експорту.
  3. Файл з класом сутності копіюємо в каталог /app/entity/doc/
  4. Створюємо сторінку редагування документа. Сторінка створюється з ім'ям класу BankStatement в просторі імен App\Pages\Doc як звичайна сторінка відповідно з архітектурою фреймворка Zippy. Файл з класом сторінки створюємо в каталозі app/pages/doc, шаблон сторінки - в каталозі /templates/pages/doc.
  5. Створюємо файл ttn.tpl з друкарською формою в каталозі /templates/printforms.
  6. Додаємо запис для документа на сторінці налаштування меню з ім'ям класу TTN.

Документ ТТН з'явиться в головному меню і буде готовий до використання.

Інтеграція з іншими системами.

У програмі передбачено API для інтеграції з зовнішніми системами.
Вбудований готовий набір функцій виконаний на основі JSON-RPC. Опис функцій знаходиться за адресою /api/help. Перед використанням в налаштуваннях системи необхідно вказати метод авторизації. API дозволяє працювати з довідниками товарів і контрагентів, створювати замовлення і відслідковувати їх статус.

Опис таблиць БД

Зміна даних напряму в таблиці не рекомендується. Більшість операцій виконується через відповідні Entity
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 - невидялюваний користувач