Задача ведение работы транспорта.
Есть набор данных
КМ
Выезд(км). Пробег(км). Возврат(км)
Топливо
Выезд(л). Расход(л). Возврат(л),Заправка(л)

Остальные данные для проблемы, не важны.

Можно хранить либо
1.все эти данные,
либо только
2. пробег,расход,Заправка
И на некую дату, начальные данные выезда. (Например на каждое 1е число)

1 вариант
Плюсы
Легко выбираются данные на конкретную ездку. Просто берешь из таблицы.
минусы
В случае изменения данных где то в середине, все последующее, надо аккуратно пересчитать, заполнить.

2. Вариант.
Плюсы
Легко менять данные за любой период.
Минус.
Выборка усложняется. Данные на конкретную ездку надо собирать,

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

Каково мнение сообщества?

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

Интересно, а у кого то может неделю назад пробег измениться?
IMHO, разовый корректирующий пересчёт - это не проблема.

Из личного опыта - обязательно добавь "показание спидометра".

S-type
Интересно, а у кого то может неделю назад пробег измениться?

Данные заносят люди. Ошибиться можно в любом месте.

S-type
Из личного опыта - обязательно добавь "показание спидометра".

Аспид
КМ
Выезд(км). Пробег(км). Возврат(км)

Если подумать, то выезд и возврат, не может быть, ни чем иным.

Типовое ПО работает в нескольких вариантах, лет 15.
Тут более сложный вариант подвернулся, вот и думаю... может поменять структуру.

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

Я бы спидометр писал на выезде и въезде. Пробег писать не надо, он ведь очевиден.
А вот как количество горючки в баке заметить? Лишнее это.
Транспорт личный или живёт в гараже фирмы тоже не маловажный вопрос.
Я считал по норме расхода и начислял деньги на топливо, масло, резину.
А сколько водила там залил - фиолетово. Но то были частные машины, ну и пара конторских, но это сути не меняет.
Если уж реально надо учитывать горючку в баке, то только один варик. Бак под горлышко должен быть либо на въезде, либо на выезде.
Таксеры иногда так делают когда двоем на одной машине катаются. Передают машину с полным баком. Для чистоты учёта - прямо на заправке. Ну это уж от порядочности зависит.

У меня реализован Вариант 1 (это фактически склад).

Да, минус пересчёта - головная боль, особенно когда бизнес-логика реализована средствами сервера, в терминах 1с тогда приходится перепроводить от редактиуемого дока до текущего.

Из плюсов, фактически одна функция обслуживает все отчеты.

Taran
Я бы спидометр писал на выезде и въезде. Пробег писать не надо, он ведь очевиден.

Так и пишу. Пробег очевиден, но есть.
Расчет топлива довольно сложный. Есть норма расхода, коэффициент. Норма ХХ.
Логика не простая. К тому же, много строительной техники. с доп. техникой, которая бывает, питается из того же бака.
Но все это нужно. И работает.
Кроме управленческого учета - главное для бухов, списание ГСМ.

Руководить, сколько заливать, не удастся.
Да нет тут проблем. Остаток топлива, в начале, не принципиален.

Пашь, это все да. У меня та же система.
Но при перепроведении, у меня последовательно, от исправленной, до последней открываются путевки, что бы видели, что изменилось. Может распечатали по новой.

А тут новая фирма. Косячат...
И совершенно новое у них. Есть система "Пилот" которая через глонас следит за авто.
Я их интегрировал к себе.

Есть расхождения в пробегах.
Много править приходится.
Вот и подумал.
Сейчас эксперементирую.

Мне как то 2й вариант милее сейчас.
Но... надо внимательно посмотреть, на всю логику, не упустить бы чего.

оффтоп он
Я бы спидометр писал на выезде и въезде.
тогда не было возмжности считывать автоматом - только руками вводить

ходил лет 15-20 назад на собеседование в таксопарк (гос.)
ну там история ясная

про показания счетчика до и после.
а как же левак ??
вообщем полит. проблемы

в частных не знаю как


оффтоп офф

Поскольку доводов, против второго подхода нет, потихоньку, пытаюсь, в новой конторе, перейти на него.

там еще какие сложности, мешающие варианту 1.
Они сейчас ведут Декабрь, в реальном времени.
Но прошлый период не охвачен.
И они забавно его вносят.
Ноябрь, затем Октябрь, затем Сентябрь.
Думаю Паша меня поймет, насколько, для 1го варианта, это усложняет жизнь.

Аспид
Поскольку доводов, против второго подхода нет, потихоньку, пытаюсь, в новой конторе, перейти на него..

По сути, это вариант работы бухгалтерии. Ввод документов по мере поступления. А он сопровождается таким понятием, как "закрытие периода". Это те самый предложенные тобой "начальные данные".

У тебя будут просто глобальные проблемы, когда захотят изменить показания в "закрытом периоде"

Аспид
там еще какие сложности, мешающие варианту 1.
Они сейчас ведут Декабрь, в реальном времени.
Но прошлый период не охвачен.
И они забавно его вносят.
Ноябрь, затем Октябрь, затем Сентябрь.
Думаю Паша меня поймет, насколько, для 1го варианта, это усложняет жизнь.

Угу. А теперь представь, что по варианту 2 ты исходишь из предположения, что начальный период - это Январь, а данные хотят внести за Декабрь.

У нас вышло, что надо хранить "параллельно" (реально в одной БД, табличке) реальные данные, снятые с показателей (километрометра в данном примере), и "фиксированные" (официально утвержденные), которыми мы отчитываемся. Естественно, фиксировать каждую минуту нет смысла, поэтому есть понятие "рабочий месяц" (в банках - "рабочий день"). Из этих двух сильнокоррелирующих таблиц и выдаются "реальные" и "официальные". Оба этих показателя похожи, но они для разных видов отчетности, как белая и черная бухгалтерии. Но без правок ("сторнаций", и просто "исправить ошибку оператора, или сбой в программе" жить невозможно, чтобы найти конца несхождений)

Владимир Максимов
А теперь представь, что по варианту 2 ты исходишь из предположения, что начальный период - это Январь, а данные хотят внести за Декабрь.

Совершенно нет проблем. Заносим данные на начало декабря. И поехали.
А они должны быть, по любому, хоть для старой, хоть для новой.

of63
У нас вышло, что надо хранить "параллельно" (реально в одной БД, табличке) реальные данные, снятые с показателей (километрометра в данном примере), и "фиксированные" (официально утвержденные),

Я тоже, не ломал старую структуру, а просто добавил.
И показываю, считаю теперь по новому.
Показывать, считать по 2м системам, это ужас... ужас несхождений, поиск причины которых, никому не нужен)

Аспид

Владимир Максимов
А теперь представь, что по варианту 2 ты исходишь из предположения, что начальный период - это Январь, а данные хотят внести за Декабрь.

Совершенно нет проблем. Заносим данные на начало декабря. И поехали.
А они должны быть, по любому, хоть для старой, хоть для новой.

Вопрос не в том, как внести данные за закрытый период, а в том, что после этого тебе придется пересчитывать "начальное сальдо" для текущего периода

Т.е. за декабрь-то ты внесешь. Но следствием этого внесения у тебя станет то, что начальные данные за январь станут не корректными. Их надо пересчитать. А поскольку все остальные данные текущего периода у тебя ведутся от "начального сальдо", то тебе придется пересчитывать вообще все данные текущего периода

Владимир Максимов
придется пересчитывать вообще все данные текущего периода

По 1 способу, это просто обязательно.

Но специфика такова, что по второму, не надо.
Это не бух-ия. Это учет и управление работой транспорта.
И прошлый период, это от обратного, бухи дают инфу, по которым формируются путевки.
Тех, кто работает с этим ПО, прошлый период, вообще не интересует. Фактически, интересует обозримое будущее, и недалекое прошлое.
Конечно возвращаются иногда и на год назад, но не за этими бух. данными.
Это только для фискалов интересно.

Тут еще плюс поимел.
Тупо время от времени, списывают реальные спидометры, и они расходятся с данными БД.
Так вот, просто заносим эти значения на начальный период, и все.
Никаких расхождений.

Аспид

Владимир Максимов
придется пересчитывать вообще все данные текущего периода

Тут еще плюс поимел.
Тупо время от времени, списывают реальные спидометры, и они расходятся с данными БД.
Так вот, просто заносим эти значения на начальный период, и все.
Никаких расхождений.

А "заносим в начальный период" - это как? просто в путёвке на 31 число ставим нужную цифирь или же формируется документ корректировки на основании которого цифра спидометра на 31 число берётся из корректировочного дока?

Беру предыдущий, перед началом периода, день, и собираю на него данные по возвращению, и заношу как начало периода.
А дальше эти данные можно редактировать.
Ну остаток в бензобаке, никому в голову не приходит исправлять)))
А спидометр, запросто.
дело в том, что у них система слежения по гланас.
И я данные от туда беру, автоматом заполняя путевку.
И есть небольшие расхождения с одометром.

Хочу добавить. Это не бухгалтерия. Просто для бухов делается отчет по списанию ГСМ.



Исправлено 1 раз(а). Последнее : Аспид, 19.12.18 13:46

> Т.е. за декабрь-то ты внесешь. Но следствием этого внесения у тебя станет то, что начальные данные за январь станут не корректными. Их надо пересчитать. А поскольку все остальные данные текущего периода у тебя ведутся от "начального сальдо", то тебе придется пересчитывать вообще все данные текущего периода

Фишка в том, что это есть "двойная бухгалтерия": есть реальные показания километрометров, и есть те показания, которыми вы отчитались на конец года (или на "отчетный период"). Пересчитать ничего не надо. Надо:
- как фиксировали показания на вьезде/выезде в парк показания - так и фиксируйте
- производите расчеты на конец периода о километраже, И ФИКИРУЙТЕ ЕГО НА ДАТУ СЧЕТА В ТОЙ ЖЕ БД
- из этих двух компонент (фиксрованные показания на дату, и интегралы от дифференциалов там всякие от показаний километромера) можно строить отчетность. Например, с вас требуют абсолютные показатели километража - вы даете зафиксированные на последний отчетный срок. Просят на произвольный период - даете последний зафиксированный + дифференциал от показаний за заданный период...