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