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