Как да сравнявате системи за автопаркове с REST API

Ако сравнявате системи за автопаркове и краткият списък включва нещо, описано като софтуер за съответствие на автопаркове с API достъп, полезният въпрос не е дали API съществува. Важно е какво всъщност може да направи този API за работа с операторски лиценз в Обединеното кралство, колко актуални остават записите и дали доказателствата ще издържат, ако DVSA (Управление за безопасност на пътищата) или Комисар по транспорта поискат да ги видят.

За повечето оператори правилният отговор е система, която обхваща записите, които вече трябва да поддържате, позволява на тези записи да се движат чисто и запазва правилна следа от одит. Полирано табло е второстепенно. Ако API не може да поддържа инспекции, дефекти, проверки на шофьори, доказателства от тахограф и контрол на сроковете по начин, който съответства на практиката в Обединеното кралство, той не решава трудната част.

Какво наистина имат нужда операторите в Обединеното кралство от API

Полезен REST API за работа по съответствие трябва да поддържа задачите, които транспортните мениджъри вече изпълняват всяка седмица, а не само общо обмен на данни за автопаркове.

За превозвачите това обикновено започва с превозни средства, ремаркета, проверки за безопасност, история на ремонти, дати на MOT, проверки на шофьорски лиценз, дати на Driver CPC, доказателства за DQC и записи от тахограф. Ако операторът работи под O-licence, софтуерът също трябва да отразява начина, по който се планира и документира поддръжката в съответствие с ръководството на DVSA за поддържане на пътна безопасност. Това означава, че интервалите за инспекции, пропуснатите или пренасрочени инспекции, периодите на VOR, записите за корекция и подкрепящите документи не са опционални допълнения.

За автопаркове с ванове, моделът е подобен, но често разпределен в смесена операция. Някои ванове може да не попадат под същия режим на поддръжка като HGV, но операторът все пак се нуждае от надежден запис за обслужване, проверки за пътна безопасност, дефекти, застраховка и права на шофьорите. Ако автопаркът включва превозни средства над праговете, които активират правилата за операторски лиценз, системата трябва да се справя както с обикновената администрация на автопарка, така и с официалните записи за съответствие на едно място. Нашата страница за софтуер за съответствие за автопаркове с ванове обхваща това изискване за смесена употреба в повече детайли.

За оператори на автобуси и микробуси, планирането на годишни тестове, PMI, записи за квалификация на шофьори и докладване на дефекти са централни. REST API трябва да позволява тези записи да бъдат извлечени в инструменти за отчитане, системи за заплати или работилници, без да се нарушава веригата на доказателствата. Пътническите автопаркове също се нуждаят от ясна контрол върху това, кой е подписал какво, кога е бил докладван дефект и кога е бил отстранен обратно в експлоатация.

За собствени шофьори, въпросът за API обикновено е по-прост. Те често не се нуждаят от голям проект за интеграция. Те се нуждаят от опцията да свържат услуга за тахограф, хранилище на документи или клиентски портал, без да въвеждат отново същите записи. Най-добрите системи не принуждават собствени шофьори да преминават през настройка в стил предприятие, за да получат основна съвместимост.

За бизнеси за наемане и агенции за шофьори, нуждите от API са основно свързани с наемането на шофьори, проверки на лицензи, Driver CPC, DQC и доказателства, че правилните проверки са завършени преди назначаването. Ако шофьорите от агенцията преминават между оператори, системата трябва да улесни съхраняването на записи за квалификация централизирано, като същевременно запазва специфичните за оператора доказателства, където е необходимо.

В термини на Обединеното кралство, също така има важна разлика от по-широкия софтуер за автопаркове на ЕС. Много европейски платформи са силни в телематиката или контрола на маршрути, но слаби по отношение на практическите доказателства, очаквани около лицензиране на оператори в Обединеното кралство. Ние изграждаме Operator Compliance чрез Fleeta Limited около записите, за които наистина се искат от операторите в Обединеното кралство, защото сами управляваме камиони и знаем, че файлът трябва да има смисъл за DVSA и, ако е необходимо, за Комисаря по транспорта.

Кои записи трябва да бъдат налични чрез системата

Когато сравнявате системи, погледнете отвъд заглавната фраза "отворен API" и изброявайте действителните типове записи, които са налични. Тук един продукт може да изглежда интегриран на хартия, но все пак да остави транспортните мениджъри да експортират електронни таблици за ключови задачи по съответствие.

Превозните средства трябва да бъдат налични с регистрация, номер на автопарка, марка и модел, данни за данъчно облагане, когато е уместно, дати на MOT или годишни тестове, графици за инспекции, статус и периоди на VOR. Ако използвате askMID, за да проверите застраховка срещу Бюрото на моторните застрахователи или записи от MIB, е полезно тези проверки да могат да бъдат свързани с файла на превозното средство, а не да остават в имейл вериги.

Ремаркетата също са важни за много оператори на стоки. Някои системи третират ремаркетата като активи от второстепенно значение или изцяло ги пропускат от API достъпа. Това създава пропуск веднага, защото инспекциите на ремаркета, доказателствата за тестове на спирачки, дефекти и годишни графици са част от реалната картина на съответствието.

Записите за инспекции трябва да включват планирана дата, завършена дата, пробег или референтен номер, където е използван, самият лист за инспекция, резултати, свързани дефекти, бележки за корекция и подписаните доказателства. Трябва също да е възможно да се види дали инспекцията е завършена навреме, пренасочена по оперативна причина или пропусната напълно. Ако доставчик предлага само качване на PDF и никакви структурирани данни за инспекция, API ще бъде с ограничена полза.

Записите за дефекти трябва да включват източника на доклада, шофьора, превозното средство или ремаркето, времеви печат, категория дефект, тежест, статус на корекция и одобрение. За оператори с ежедневни проверки на обиколка, проверките на шофьори трябва да бъдат налични отделно или ясно свързани, включително нулеви доклади за дефекти. На практика, доказателствата за нулеви дефекти често са толкова важни, колкото и докладите за повреди, защото показват, че проверката е извършена.

Записите за шофьори трябва да обхващат категории на лицензи, дати на изтичане, дати на проверки, одобрения, където са записани, крайни срокове за Driver CPC и статус на DQC. Ако разчитате на външна проверка на лицензи, попитайте дали системата съхранява само резултата или също доказателството за проверката и датата, на която е направена.

Записите от тахографи изискват внимателно сравнение. Някои продукти твърдят, че имат интеграция с тахограф, когато всъщност само съхраняват обобщени доклади за нарушения. За работа с операторски лиценз, може да се нуждаете от история на изтеглянията на шофьори и единици на превозни средства, липсващи пробег или флагове за липсващи данни, докладване на нарушения, видимост на работното време и доказателства, че изтеглянията са прегледани. Ако сравнявате системи частично по този въпрос, нашето ръководство за анализ на тахографи за малки автопаркове описва какво да търсите.

Съхранението на документи също е важно. API трябва идеално да поддържа прикрепени файлове към превозни средства, ремаркета, шофьори и събития. Това включва сертификати за MOT, резултати от годишни тестове, листове за инспекции, застрахователни документи, сертификати за калибриране, фактури от работилници и кореспонденция. Записът за съответствие често е само завършен, когато структурирани данни и документът са заедно.

Накрая, проверете логиката на датите. Операторите в Обединеното кралство често планират около календарни месеци, фиксирани интервали и ISO седмично отчитане. Ако вашата работилница, планер или месечен пакет работи по ISO седмица, системата не трябва да принуждава неудобни преобразувания на дати или да скрива оригиналните правила за срокове.

Как работят интеграциите в ежедневния контрол на автопарка

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

Ръчните импорти са най-простият вариант. Изнасяте CSV от една система и го качвате в друга. Това може да е достатъчно за първоначална миграция или случайни масови актуализации, но не е активна интеграция. То зависи от някой да запомни да го направи, да провери формата на файла и да коригира неуспехите. За статични записи това може да е приемливо. За дефекти, проверки на лицензи или дейности с тахограф, обикновено не е.

Планираните синхронизации са следващата стъпка нагоре. Те се изпълняват в определени часове, често нощем или на всеки час, и автоматично преместват записи между системите. Например, платформа за работилници може да актуализира завършените инспекции през нощта, или система за HR може да изпраща нови шофьори всяка вечер. Планираните синхронизации често са напълно работещи за съответствие, при условие че времето съвпада с риска. Нощна синхронизация за дати на годишни тестове обикновено е приемлива. Нощна синхронизация за отстраняване на дефекти в същия ден може да не е.

Директният REST API достъп ви дава повече контрол. Вашият собствен софтуер или слой за отчитане може да поиска текущия запис, когато е необходимо, да създаде нови записи или да актуализира съществуващите в съответствие с разрешенията на доставчика. Това е полезно, когато операторите искат един източник на истина, но няколко свързани инструмента, като заплати, управление на работилници, контрол на документи или наемане на агенции. Също така улеснява изграждането на отчети за изключения, например идентифициране на превозни средства с предстоящи инспекции в следващите 14 дни, но без свързано резервиране на работилница.

Webhooks решават различен проблем. Вместо вашата система да пита многократно дали нещо се е променило, платформата за съответствие изпраща известие, когато настъпи промяна. Това е полезно за събития като повдигане на дефект, преминаване на превозно средство в VOR, изтичане на документ на шофьор или одобрение на инспекция. Webhooks често са най-чистият начин да поддържате друга система актуална без постоянно запитване.

В ежедневния контрол на автопарка, правилният модел често е смес. Основните данни могат да постъпят чрез планирана синхронизация. Чувствителните към времето събития могат да използват webhooks. Историческото отчитане може да използва REST API запитвания. Грешката е да се предполага, че всички "интеграции" са еквивалентни. Те не са. Попитайте какво се случва, когато шофьор подаде дефект в 05:30, когато работилницата го отстрани в 07:10 и когато транспортният офис може да види, че превозното средство е готов