>
С точки зрения программы, учетная система базируется на архитектуре, определяемой фреймворком 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 решение.
Программа состоит из двух базовых частей – ядра с общими страницами
и функциональностью (пользователи, управление системой и т.д.) и, собственно,
учетной части включающей объекты метаданных (документы, справочники, отчеты), реализующие основную
бизнес-логику.
В терминах 1С можно условно назвать эти части платформой и конфигурацией.
Основа учетной части – объекты метаданных (справочники, документы, отчеты, журналы).
Объекты спроектированы с минимальной зависимостью друг от друга и доступны через общее меню, которое
строится
динамически, согласно списку объектов, который задается администратором.
Это позволяет независимо модифицировать их без смены других объектов и модулей системы.
Разработчики по аналогии с конструктором Lego могут легко создавать разные конфигурации (в терминологии
1С) под разные типы бизнеса,
обмениваться реализацией отдельных объектов системы и печатными формами обычным копированием файлов.
Алгоритмы бизнес-логики реализуются непосредственно на языке PHP.
Шаблоны (бланки) печатных форм документов и отчетов выполнены в чистом HTML,
что позволяет как печатать их напрямую, так и экспортировать в Word, Excel или PDF, а также
корректировать их с помощью обычного текстового редактора.
| ТМЦ | товары, материалы, продукция |
| Склады | склады, магазины |
| Контрагенты | поставщики, покупатели |
| Денежные счета | кассы, банки |
| Документы | первичные документы, фиксирующие хозяйственные операции |
В соответствии с архитектурой фреймворка, все бизнес-сущности реализованы классами, наследоваными от
Entity.
Аналитический учетведется на основании движения материальных и денежных средств, согласно
хозяйственных операций.
Система не сохраняет исходные и текущие остатки за период (используется полный пересчет движений).
Это упрощает гранизацию данных и позволяет вводить и изменять информацию задним числом, а также передним,
что позволяет выполнять
резервирование товара и планирование сделок.
Аналитические данные хранятся в одной таблице entrylist. По сути, таблицы фактов в ROLAP где
измерение – бизнес-сущности.
Увеличение запасов отображается записью с положительными значениями количества и суммы, уменьшение -
отрицательными, таким образом остатки и обороты по товару
получаются простым суммированием за период.
Также аналитические данные, как и ссылающиеся на другие бизнес-сущности,
хранятся в самом документе в упакованном виде. Подобная денормализация позволяет избежать
дополнительных обращений к БД, а также позволяет хранить "исторические" данные в документе
- документ сохраняет все атрибуты такими, какие они были на момент создания документа.
Складской учет ведется по партиям. Партия – тот же товар по той же учетной цене (цена поступления) независимо от поставщика. Записи по движениям на складе хранятся в таблице store_stock, где кроме ссылки на склад и ТМЦ указана учетная цена (партия).
Элементы справочников – объекты, находящиеся в пространстве имен App\Entity. Объекты
предназначены для хранения справочных бизнес-сущностей.
Для редактирования списков объектов предназначены соответствующие страницы в пространстве имен
App\Pages\Reference.
Страницы отчетов нахожятся в пространстве имен App\Pages\Report.
С каждым отчетом связана печатная форма из папки /templates/printforms/report
Журналы объединяют объекты и бизнес-сущности по типу использования. Например – журнал документов, журнал
заказов.
Страницы журналов нахожятся в пространстве имен 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 | Філія,якщо ввімкнена підтримка |
| parent_id | Батьківський документ (підства) |
| state | Статус |
| headerdata['store'] | id складу |
| headerdata['time'] | Час (document_date має тільки дату) |
| headerdata['payment'] | id грошового рахунку для оплати (каса, банк) |
| amount | Сума по документу (по позиціях) |
| payamount | Сума дл сплати (amount мінус наприклад знижка) |
| payed | Фактична оплата (сума по таблиці платажів) |
| headerdata['payed'] | Внесена оплата. Для відповідного поля на сторінці редагування документу. Може не збігатись з payed наприклад при частковій оплаті |
| headerdata['detaildata'] | Упакована таблична частина. |
Все объекты зарегистрированы в таблице метаданных на соответствующей странице настроек.
По таблице метаданных автоматически формируется меню.
В таблице указывается тип, название объекта, имя класса (пространство имен вычисляется по типу),
группа (для второго уровня меню).
Допустимо добавление в систему документа «Товарно-транспортная накладная». Необходимо ввести запись в метаданные, повествование сторителлинговой стороне редактирования документа, класс сущности для редактирования документа в БД и HTML-шаблоны печатных форм.
Необходимая последовательность:TTN создается в пространстве
вид класса Document.
generateReport и Execute.
Метод Execute отображает запись в аналитической облачной таблице.
Метод generateReport вызывается генератором отчётов, передавая шаблон в печатные
формы и данные из реквизитов документа, создающие представление
HTML-файла, для заполнения формы для печати или экспорта.
/app/entity/doc/
BankStatement в пространстве App\Pages\Doc как ссылка
с архитектурой фреймворка Zippy. Файл с классом storynki хранится в каталоге
app/pages/doc, шаблон страницы — в каталоге /templates/pages/doc.
/templates/printforms.Документ ТТН появится в основном меню после перелогинивания.
| branches | Филиалы |
| contracts | Договора с контрагентами |
| crontask | Задания планировщика |
| custacc | Балансовые счета контрагентоа. Движения по дебеьу или кредиту выполняются при проведении документов. Положитедный баланс - кредитный долг компании контрагенту , негативный дебетовый долг. |
| custitems | Товыры у поставщика |
| docstatelog | История статусов документов |
| documents | Документы. Поля: amount - сумма по документу, payamount - к оплате, payed - оплачено (сумма по таблице payments) |
| empacc | Лицевой счет сотрудника. В первую очетедь для движений по зарплате. |
| employees | Сотрудники. Поле login соединяет с пользователем системы (аккаунтом) |
| entrylist | Движение по складу |
| equipments | Основные фонды и оборудование |
| eqentry | Проводки по ОС |
| eventlist | События, используется для контрагентов и заданий |
| files | Загруженные файли |
| filesdata | Содержимое файлов. Отдельная таблица чтобы не грузить всю БД |
| images | Изображения |
| iostate | Записи доходов и расходов |
| issue_* | Таблицы модуля Проекты и задания |
| item_cat | Категрии (группы) ТМЦ |
| item_set | Комплекты для ТМЦ |
| items | Номенклатура ТМЦ |
| keyval | Вспомагательная таблица для данных типа ключ-значение |
| messages | Сообщения |
| metadata | Метаданные обектов (документы, справочники, отчеты, журналы... Формирует сновное меню программы) |
| mfund | Денежные счета |
| note_* | Таблицы модуля Органайзер |
| notifies | Уведомления |
| options | Общие настройки и настройки модулей |
| parealist | Производственные участки |
| paylist | Оплаты (движение по денежных счетах) |
| poslist | POS терміналы |
| prodproc | Производственные процессы |
| prodstage | Производственные этапы |
| promocodes | Промо коды |
| roles | Роли пользователей |
| saltypes | Тиры начислений и удержаний по зарплате |
| services | Услуги, работы |
| shop_* | Таблицы онлайн-каталога |
| stats | Служебная таблица для статистических данных |
| store_stock | Партии ТМЦ. Связывает ТМЦ склады и учетные цены. Поле qty (количество) пересчитывается с помощью триггеров при изменении таблицы entrylist Поле partion - учетная цена. Дополнительная разбивка если включен учет по сериям |
| stores | Склады |
| subscribes | Подписки на события в системе ()например изменения статуса документа |
| substitems | Замены ТМЦ |
| taglist | Тэги |
| timesheet | Учет рабочего времени |
| users | Пользователи системы (аккаунты. admin - неудаляемый пользователь |
В системе предусмотрена возможность создания шаблонов страниц и печатных форм, которые не будут перезатираться при обновлении.
Для этого нужно сделать файл на основе основного и добавить в название соответствующего файла окончание _custom.
К примеру, ttn_custom.html или ttn_ps_custom.tpl.
Система будет сначала искать файл с таким окончанием.
В случае использования кастомных шаблонов разработчик сам должен следить за обновлениями и вручную переносить изменения из основного файла.
Для перевода на другой язык необходимо:
- перевести на соответствующий язык все файлы в папке templates (lang.json больше не используется)
- перевести все сообщения в папке app (преимущественно в строках типа $this->setError() $this->setSuccess() $this->setInfo() $this->setWarn() )
- если в процессе эксплуатации всплывет непереводимое сообщение найти его в коде обычным поиском по файлам программы
В случае локализации разработчик должен вручную переносить изменения основной системы после обновлений