С точки зрения веб-приложения, учетная система базируется на архитектуре, определяемой фреймворком
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 позволяет
работать со справочниками товаров и контрагентов, создавать заказы и отслеживать их статус.