Безкоштовна програма для складського обліку, Документація розробника

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

Архітектура

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

З точки зору програми, облікова система базується на архітектурі, яка визначається фреймворком 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 фреймворків
Для обробки запитів не пов'язаних із подіями компонентів zipoy передбачити виклик методів сторінок на ім'я. Для цього слід використовувати 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.
Всі документи зберігаються в одній таблиці. Таблиця містить кілька загальних полів (наприклад, дати, номер документа) і текстове поле де зберігається деталізація документа у вигляді XML. Використання XML дозволяє, при необхідності, виконувати пошук за документами, орієнтуючись на XML теги а також використовувати XPath.. Упаковку і розпаковування детальних даних документа виконує базовий клас. Для цього клас містить масиви $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 для інтеграції з зовнішніми системами. Оброблювач може бути виконаний як звичайна сторінка так і оформлений за допомогою інтерфейсу RESTful або JSON-RPC. Приклади для кожного варіанта в каталозі app/api.
Вбудований готовий набір функцій виконаний на основі JSON-RPC. Опис функцій доступно за адресою /api/help. Перед використанням в настройках системи необхідно вказати спосіб авторизації. API дозволяє працювати з довідниками товарів і контрагентів, створювати замовлення і відслідковувати їх статус.