Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Добрый день
Когда можно будет в Hecterra увидеть не только работу в поле за указанную смену, а и перезды? Это важная составляющая для формирования отчетов.
Смена 07:00 - 06:59
В поле выполненно = 50 га. Расход в поле - 300 л, 6 л/га
Перезды 12 км. Расход на переезды - 60 л.
artem.gps
Hecterra отслеживает только работы в поле.
Переезды можно попытаться учитывать в Wialon.
А почему бы треки не попадающие в геозоны вывести в отчёт как переезды? Отрисовка при этом не нужна. Работа в двух системах и последующее сведение сильно увеличит время получения нужной информации и повысит нагрузку на диспетчера.
Poddias
тогда решение о том, что что-то является переездом будет приниматься на основании информации о неподтвержденных кандидатах?
А не мог ли бы пояснить? Не совсем понял
Poddias
что считать переездом? я так понимаю, что пробег от предыдущей обработки до следующей. так?
artem.gps Poddias
Скажите, по смысу переезд должен соотноситься как-то с обработками (например, относиться к обработке, которой он предшествует)?
Или это должно выглядеть как отчет не по обработке, а по обекту: за неделю\день Х объект выполнил столько-то обработок, потратил на них столько-то топлива, а весь остальной пробег (то есть вне зарегистрированных обработок) считать переездами?
Это используется в основном для начисления зарплаты и списания ГСМ по видам работ. Обычно на переезды выделяются другие нормы и другие тарифы. Используется это в финальном отчете таблице, где указаны все виды работ, в том числе и переезды.
Думаю, эти работы можно учитывать следующим образом:
Добавить в поиск обработок еще одну графу - переезды вне поля и присвоить назначаемый статус из операций. А опереции дополнительно разбить на полевые и дополнительные, например подвоз воды - операция довольно емкая, но вне поля. Оператор при поиске сможет дополнительно назначать статус операции, либо поставить статус не учитывать и выводить их в отчете "все операции", без га, но с километражом, часами и расходом.
Poddias
Я там понимаю, что подвоз воды осуществляется техникой, которая на полях никогда не работает. Так?
То есть у этой техники весь пробег НЕ относится к обработкам. Получается, что нет смысла отделять у этой техники полевой пробег от неполевого. И весь этот пробег можно просто запросить в виалоне.
Я просто не очень понимаю, как это в программе может относиться к обработке. Обработка выполняется одним объектом (или несколькими), а подвоз воды — другими объектамИ, которые не участвуют в обработке вовсе.
У нас в компании переезд - любое движение за пределами поля, или, если есть датчик работы - любое движение с выиключеным датчиком работы.
Это можно конечно определить в виалоне, но потом нужно сопоставлять данные с Виалона и Хектэрры, что, как уже говорили, занимает дополнительное время.
Техника, которая работала на подвозке воды будет иметь обработку - если с прицепом или датчиком работы, то работа Перевозка и километраж, если без - переезд и километраж.
Таким образом не нужно будет работать в двух программах одновременно и сводить данные вручную.
dimonovych
А движение с высключенным датчиком работы при развороте во время обработки тоже тогда будет считаться переездом?
Должны ли переезды относиться к обработке или вы это видите как отдельный вид отчета?
Скорей переезд (Перегон), нужно сделать по типу как Поездки между геозонами.
Только тут нужно поездки между обработками.
А если, допустим, пять полей находится рядом, и к первому из них он едет 10 км, а ко всем остальным по 100 метров, не будет смущать, что у первой обработки переезд большой, а у остальных почти нулевой?
Или переезд к обработке не надо относить?
alek К обработке не надо относить.
Клиенту нужно понимать, что у ТС пробег за день например 100км.
Из 60км это обработки (Это он скорей видит не в км в Га)
И 40 км это перегоны между обработками.
На этим операции во первых разные нормы на топливо и во вторых разные ставки по ЗП механизатора.
В виалоне это сложно сделать, так как у нельзя подцепить информацию о подтвержденных обработках.
Beifuss
Но чтобы понять пробег между обработками, надо сначала чтобы все обработки были зарегистрированы.
После этого уже получается можно будет запросить у виалона данные по пробегу за интервалы, которые не входят в обработки.
Ну а если какую-то обработку пропустят и зарегистрируют потом, то надо будет эти пробеги между обработками перезапрашивать и пересчитывать снова.
Потом выяснится, что пробег вне обработок какой-то подозрительно большой и придется все равно идти в виалон, чтобы посмотреть, где он ездил...
Кстати, а это надо для водителя или для объекта?
alek По идее для объекта.
Может при выполнении отчета по объекту вывести пробег между обработками (от конца одной обработки до начала следующей), что бы он считался при выполнении отчета.
Может при выполнении отчета по объекту вывести пробег между обработками (от конца одной обработки до начала следующей), что бы он считался при выполнении отчета.
В целом можно, но есть нюансы: сейчас отчет по объекту — это отчет по обработкам объекта. То есть тут нужен новый вид отчета по объекту. Не то, чтобы это проблема, просто сейчас в Hecterra в принципе есть отчеты только по обработкам. Так что это что-то совсем новое.
И еще нюанс связан с ситуациями, когда объект параллельно\попеременно обрабатывает 2 (или даже больше) полей. По времени может получиться, что обработка второго поля находится хронологически внутри обработки первого. То есть между ними переезда не будет.
Ну и также, если объект обработал часть поля, потом куда-то отъехал, а затем обработал еще часть в тот же день, то вот это вот "куда-то объехал" не будет учтено в переезде.
И еще нюанс связан с ситуациями, когда объект параллельно\попеременно обрабатывает 2 (или даже больше) полей. По времени может получиться, что обработка второго поля находится хронологически внутри обработки первого. То есть между ними переезда не будет.
Так по сути между ними и не должно быть переездов. Здесь не вижу проблем
Ну и также, если объект обработал часть поля, потом куда-то отъехал, а затем обработал еще часть в тот же день, то вот это вот "куда-то объехал" не будет учтено в переезде.
А вот тут как раз и нужно "Время отсутствия на поле". И разбивать это на две обработки.
И перегоны будут видны и время обработки будет корректно выведено.
Коллеги, смена у механизатора начинается в 8:00 длится 11 часов и 1 час на перекуры с осмотром техники при передаче смены. Делится смена на следующие виды работ:
это то что сегодня реализовано в хегтерра,
А вот такое надо бы тоже реализовать
Это всё необходимо учитывать, простои техники в сырую погоду или при уборке на засоренных полях достигают +\- 5 часов (совокупные за сутки) если больше, не рентабельно, час простоя около 100 руб. Я так понимаю хегтерра задумывалась как инструмент позволяющий минимизировать время на обработку данных (а косвенно и сократить издержки на содержание учётчиков и диспетчеров), именно это мне лично и интересно.
На сегодня с такого рода задачей я справляюсь с помощью отчёта посещения геозон и допиливании его в экселе, работу облегчает от избытка персоонала избавились, но сам эксель как инструмент так себе за год около 50 000 строк, куча формул в ячейках плюсом сводных таблиц на з/п, выработку и топливо, учет сзр и пр... В общем не быстро он эту простынь считает. Постгрес со скуэлем (если не ошибаюсь) должен пошустрее да и понадёжнее быть. И ещё эксель не позволяет работать коллективу в одном файле, без плясок с бубном.
Добрый день.
Можно ли в Hecterra вывести отдельный вид отчета, это пробег и потраченное топливо между обработками, т.е. это будет считаться перегоном.
Стандартными средствами не нашел нормального решения, так как поездки между геозонами не подходят, так как ТС могло ехать внутри геозоны а эта поездка может быть не зарегистрирована как обработка например по усмотрению диспетчера. Если диспетчер видит, что техника прошла транзитом например по краю поля (по краю но внутри геозоны) он отклоняет потенциальную обработку.
Beifuss
Пока Hecterra не ведет учет переездов.
Но мы учтем ваше предложение на будущее.
