Новый движок расчета топлива в путевых листах
Добавлено: 20 авг 2010, 14:15
Предлагаю пользователям модуля "Управление транспортом" обсудить следующее совершенствование движка расчета топлива в путевых листах.
Сейчас существует огромное количество настроек как считать ГСМ, создавать или не создавать всякие записи по баку и т.д. На наш взгляд данная ситуация является следствием ошибки при проектировании подисистемы расчета топлива.
Основные ошибки проектирования:
- заправки взаимоувязаны с расходами топлива, из-за этого возникает проблема по одному разрезу учета расхода топлива приходится вводить несколько строк движения (чтобы ввести несколько заправок), потом нужно отлавливать в какой строке считать норм расход и в какой вести факт расход (разбивать его на строки или не разбивать и т.д.)
- наличие неопределенного количества строк топлива, в которых можно ввести остатки топлива, вызывает необходимость вести промежуточные остатки топлива например между заправками, которые никому не интересны, и тем более являются виртуальными, т.к. замеры остатков в пути между заправками не делаются; также как следствие этого есть проблемы с определением какой-же из остатков является последним (для правильного определения нужно заполнять "Дату заправки" и "Время заправки" даже для тех записей о движении ПЛ, в которых не было заправок).
Для преодоления этих проблем предлагается реализовать механизм расчета топлива следующим образом. Строки движения ГСМ должны быть следующих типов:
- остатки - одна для бака
- заправка-сдача - сколько хочешь для бака
- расход (норм-факт) ТС - для каждого разреза учета * только одна
- расход (норм-факт) спецоборудования - для каждого разреза учета * только одна
- расход (норм-факт) спецоборудования прицепа - для каждого разреза учета * только одна
* - разрез учета - это единица учета расхода топлива в зависимости от того как он ведется на предприятии (заказы, участки пути, спецоборудование, ...), причем разрез учета топлива должен задаваться на уровне настройки.
Эти записи фактически сохраняются в базе данных, а на уровне работы с интерфейсом работа осуществляется следующим образом.
1) По баку видна только одна строчка движения топлива.
2) Остаток начальный и конечный видны из записи типа "Остатки", "заправлено" и "сдано" видно как сумма строк с типом "заправка-сдача", нормативный расход и фактический расход видны как сумма всех нормативных и фактических расходов из строк "расход (норм-факт)" всех типов.
3) По этой строчке поддаются редактированию начальный остаток, конечный остаток, фактический расход.
4) При редактировании поля "заправлено" или "сдано" открывается списочный интерфейс, в котором можно внести несколько заправок или сдач.
5) При пересчете нормативного расхода итог пересчета подсвечивается в поле "нормативный расход" в единой строке для бака, по F3 на этой строке можно увидеть из чего сформировалась эта сумма - списочный интерфейс по разрезам учета расхода топлива.
6) При вводе количества израсходованного топлива в поле "фактический расход" он распределяется по строкам типа "расход (норм-факт)" по некоторому алгоритму; один из них - пропорционально нормативному расходу.
(ПИР 102.100559)
Сейчас существует огромное количество настроек как считать ГСМ, создавать или не создавать всякие записи по баку и т.д. На наш взгляд данная ситуация является следствием ошибки при проектировании подисистемы расчета топлива.
Основные ошибки проектирования:
- заправки взаимоувязаны с расходами топлива, из-за этого возникает проблема по одному разрезу учета расхода топлива приходится вводить несколько строк движения (чтобы ввести несколько заправок), потом нужно отлавливать в какой строке считать норм расход и в какой вести факт расход (разбивать его на строки или не разбивать и т.д.)
- наличие неопределенного количества строк топлива, в которых можно ввести остатки топлива, вызывает необходимость вести промежуточные остатки топлива например между заправками, которые никому не интересны, и тем более являются виртуальными, т.к. замеры остатков в пути между заправками не делаются; также как следствие этого есть проблемы с определением какой-же из остатков является последним (для правильного определения нужно заполнять "Дату заправки" и "Время заправки" даже для тех записей о движении ПЛ, в которых не было заправок).
Для преодоления этих проблем предлагается реализовать механизм расчета топлива следующим образом. Строки движения ГСМ должны быть следующих типов:
- остатки - одна для бака
- заправка-сдача - сколько хочешь для бака
- расход (норм-факт) ТС - для каждого разреза учета * только одна
- расход (норм-факт) спецоборудования - для каждого разреза учета * только одна
- расход (норм-факт) спецоборудования прицепа - для каждого разреза учета * только одна
* - разрез учета - это единица учета расхода топлива в зависимости от того как он ведется на предприятии (заказы, участки пути, спецоборудование, ...), причем разрез учета топлива должен задаваться на уровне настройки.
Эти записи фактически сохраняются в базе данных, а на уровне работы с интерфейсом работа осуществляется следующим образом.
1) По баку видна только одна строчка движения топлива.
2) Остаток начальный и конечный видны из записи типа "Остатки", "заправлено" и "сдано" видно как сумма строк с типом "заправка-сдача", нормативный расход и фактический расход видны как сумма всех нормативных и фактических расходов из строк "расход (норм-факт)" всех типов.
3) По этой строчке поддаются редактированию начальный остаток, конечный остаток, фактический расход.
4) При редактировании поля "заправлено" или "сдано" открывается списочный интерфейс, в котором можно внести несколько заправок или сдач.
5) При пересчете нормативного расхода итог пересчета подсвечивается в поле "нормативный расход" в единой строке для бака, по F3 на этой строке можно увидеть из чего сформировалась эта сумма - списочный интерфейс по разрезам учета расхода топлива.
6) При вводе количества израсходованного топлива в поле "фактический расход" он распределяется по строкам типа "расход (норм-факт)" по некоторому алгоритму; один из них - пропорционально нормативному расходу.
(ПИР 102.100559)