5.3. Функциональные особенности архитектуры системы «Галактика»

Как было сказано выше, система развивалась без единого плана, под заказ и результатом такого проектирования и разработки стало следующее:

• система состоит из набора слабосвязанных между собой модулей;

• модули реализуют, в первую очередь, функции учета конкретных внешних документов (приходных ордеров, счетов-фактур, складских документов и т.д.);

• управляющих документов или автоматически генерируемых с целью управления документов в системе не существует.

Информационные связи между модулями это, в первую очередь, общие справочники и, очень редко, передача данных. Передача данных реализована, как правило, следующим образом: просматривается список документов на входе (из другого модуля) и к каждому документу можно ввести новый в текущем модуле. Так связаны модули Снабжение, Сбыт и Склад. !! Самое интересное, что таким же образом связаны все модули с бухгалтерией (т. е. проводки, точнее хозяйственные операции к внешним документам, вводятся вручную).

Настройка системы производится путем настройки базовых справочников и определения хозяйственных операций (кодов проводок). Данная информация влияет на системы материального и бухгалтерского учета (учет по складам, по балансовым счетам и т.д.), а также на содержание отчетных форм. Настройки абсолютно не влияют на технологию или процедуру обработки документов. Она всегда одинакова.

Схемой настройки бухгалтерского учета - является классическая Советская схема по балансовым счетам и хозяйственным операциям. Причем, оперативные документы в системе существуют сами по себе, а хозяйственные операции - сами по себе.

Какой-либо единой базовой технологии обработки документов (типа FLEXBUILDER,WORKFLOWилиACCOUNTENGINE) не существует. Результатом этого является то, что не существует способа определить сквозную (по всей системе) процедуру обработки бизнес - функции (например, реализация бизнес - функции снабжения материалами, начиная от заявки и проверки бюджета и кончая поступлением на склад и отражением этого в бухгалтерском учете).

В целом архитектура примитивна и вполне типична для такого класса задач.

5.4. Технологические особенности архитектуры системы «Галактика»

Система исходно была реализована в архитектуре клиент-сервер в понимании этого термина системой BTRIEVEи остается такой же, и по сей день.

Реализация прикладного программного обеспечения на языке высокого уровня теоретически позволяло разработчикам обеспечить работу системы с любым СУБД путем простой подмены базовой библиотеки. Однако, практически, сложность заключается в том, каким набором функциональности базовой библиотеки BTRIEVEпользовались разработчики. Таким образом, если система работы с новым СУБД похожа наBTRIEVE, то переход не представляет проблем. Если же это не так, то требуется весьма трудоемкая доработка базовой библиотеки, которая иногда завершается изменением функциональности и необходимостью переписывания исходных программ системы. Нет установок систем наSQLServerилиOracle. В заключении, необходимо отметить, что техническая реализация на базеBTRIEVEне позволяет системе манипулировать большими объемами данных и, соответственно, претендовать на Корпоративное решение.