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