Alex писал(а):Могим службам нужна отчетность в разрезе месяцев, кварталов и даже лет и их сравнение и тд. Сейчас все ведется вручную, данные преносятся из одних таблиц екселя в другие, соответственно куча работы, ошибок. Возможно ли в АП получать набор неких суммированных показателей в разрезе, например, вида перевозок для отчетности 5АХ, 2АТ и прочих по закрытии месяца, и при этом не тащить всю кучу данных ПЛ.)
Проблемы, которые следует решить, для того, чтобы это работало:
1 Автоматическая переподготовка сводных (хранимых) данных при изменении первичных документов (равно как и справочной информации, в общем, первичных данных). Например, ковырнули путевой лист за 08.2007 сейчас, надо "понять", что хранимые данные пришли в негодность и требуют переподготовки. Сейчас Вы можете наблюдать проблемы, связанные с отсутствием такой системы на примере хранимых файлов (синенькие такие окошечки появляются время от времени - со словами, что такой-то хранимый файл был подготовлен тогда-то - бум использовать? или лучше переделать?) - даю на отсечение все, что Вы пожелаете - 90% пользователей принимают решение, ну, скажем так, не вполне обоснованное. Для автоматического отслеживания фактов модификации первичных данных следует «понимать» зависимости - модификация каких именно первичных данных ведет к изменению каких именно сводных данных. Для этого нужно качественно решить проблему из п.2
2 Эффективная структура базы данных. Самая эффективная структура – соответствующая прикладной области – время, пробег и т.п. в разрезе маршрутов, марок и т.п. Но это самая негибкая структура. Другая крайность – хранить Показатель1, Показатель452 и т.д. в разрезе Разрез1, Разрез42 и т.д. С учетом п.3 надо выбрать вот эту, крайне неэффективную крайность. И не забыть разработать механизм, который позволяет модифицировать систему хранимых показателей самим пользователям АвтоПарк, ибо если этого не сделать, то мы, боюсь, выйдем далеко за рамки бюджета ежемесячного сопровождения АвтоПарк.
3 Система хранения (и использования) сводных данных имеет смысл исключительно в условиях стабильной (в течение нескольких лет) учетной модели. Поднимите, пожалуйста, руку те, кто имеет эту стабильную учетную модель. Хм. Тогда, пожалуйста, поднимите руку те, кто имеет хоть какую-нибудь учетную модель. О, есть таки у кого-то? Учетную модель в студию! Вы, Алексей, упомянули виды перевозок. А я говорю - группы маршрутов, как минимум – муниципальные и т.п. Но одно предприятие может обслуживать несколько муниципальных образований. Т.е. группы маршрутов по конкретному источнику финансирования. О, этот источник хочет знать структуру в разрезе маршрутов и как это соотносится с прошлым годом – давайте хранить по маршрутам. Упс, тут
Павел Штатнов упомянул про Ipl10 – там бы по выходам надо. Т.е. добрались до выходов. А как насчет модификаций маршрутов – с заездом в деревню Гадюкино отделить от таковых без заезда? Нужно еще про разнообразие подвижного состава не забыть, ибо скорость появления всего (!) потроха показателей в разрезе Спринтеров, Коннекто, Богданов и прочая и прочая просто поражает воображение. Вернее, не скорость появления как таковая, а методика, согласно которой каждую партию закупленных ТС нужно обосабливать в учете и только так можно понять, что цена автобусов из такой-то поставки неадекватная (или, наоборот, хорошая). И непременно в сравнении с прошлым годом.
Ок, конечно, мы думаем над этим. Этому процессу можно существенно помочь, если попытаться сформулировать и довести до нас учетную модель каждого конкретного филиала. Мы постараемся найти в них (в моделях) что-то общее
P.S.
В SAP с этим полегче. Там учетная модель такова, какова она в SAP и больше никакова.