Den här artikeln behandlar fyra aspekter av stöd efter generationens utveckling: vad rutinverifiering omfattar och hur det skiljer sig från djupare forskning, när assisterad komplettering gäller och vad det kan erbjuda, hur korrigerings- och revisionspolicyn fungerar inklusive avgifter och tidsplan, och vad du kan förvänta dig av framtida evidensstatusetiketter på ditt Build Sheet . Var och en av dessa ämnen har ett eget avsnitt nedan, med djupare operativa detaljer tillgängliga i de länkade underartiklarna.
Denna artikel publiceras av ClassicDecoder , ett företag som specialiserar sig på klassisk VIN-avkodning och rekonstruerad fabrikskonfigurationsforskning för äldre fordon och fordon från före 1981. Deras Classic Decoder Build Sheet är en rekonstruerad forskningsprodukt, och den här guiden förklarar de aktuella policyerna för granskning, korrigering, assisterad ifyllning och revision som gäller när en rapport behöver ytterligare uppmärksamhet.
Dessa supportprocesser ingår i det bredare arbetsflödet Classic Decoder Build Sheet . För en övergripande förklaring av vad produkten är, hur fabrikskonfigurationsforskning fungerar och vad det rekonstruerade Build Sheet kan och inte kan fastställa, se Build Sheet klassisk bil.
Vad rutinmässig manuell verifiering faktiskt omfattar
Rutinmässig manuell verifiering är den grundläggande granskning som varje Classic Decoder beställning får. I detta skede kontrolleras det ifyllda Build Sheet för fel, såsom inkonsekvenser eller uppenbara dataproblem, innan det når dig. Denna granskning är en standarddel av processen och tillämpas på alla beställningar.
Vad rutinmässig verifiering inte gör är att oberoende autentisera varje fält genom att konsultera tillverkarens originalregister, korsreferera flera arkivkällor eller genomföra en historisk undersökning. Det är kategoriskt olika aktiviteter. Att förstå denna distinktion är viktigt eftersom ordet "manual" lätt kan tolkas som mer omfattande än det faktiskt är.
Djupare manuell forskning är en separat process, som i syfte och omfattning skiljer sig från felkontrolllagret. Den är inte automatisk och bör inte antas ske vid varje beställning. Dessa två processer tjänar olika funktioner och bör inte behandlas som utbytbara.
Har du ett klassiskt VIN-nummer att undersöka?
Ange den för att se vilken fordonsinformation som kan vara tillgänglig.
Rutinmässig verifiering kontra djupare forskning i korthet
Kontrasten nedan fångar de viktigaste skillnaderna mellan dessa två processtyper.
Rutinmässig manuell verifiering
Gäller alla Classic Decoder beställningar
Omfattar felkontroll av det färdiga Build Sheet
Utgör inte oberoende autentisering av enskilda fält
Inkluderar inte en omfattande historisk undersökning av källor
Djupare manuell forskning
En separat process, separat från rutinmässig verifiering
Inte automatisk och ingår inte som standardkomponent i varje beställning
Utlöstes inte bara för att ett Build Sheet levererades
Aktiveras inte enbart av glesa data
Den praktiska implikationen är enkel: att ta emot ett Build Sheet , inklusive ett med fullständiga data, betyder inte att varje fält har autentiserats oberoende genom historisk forskning. Rutinmässig verifiering är felkontrolllagret. Djupare forskning är något annat. För mer information om hur granskningen och den djupare forskningsprocessen fungerar, se Hur klassisk bil Build Sheet och assisterad färdigställande fungerar.
När assisterad ifyllning gäller och vad den kan erbjuda
Assisterad ifyllning är ytterligare stöd som kan användas i tillämpliga fall där ytterligare forskning och verifiering kan komplettera informationen Build Sheet . Nyckelordet är "kan". Huruvida saknade data kan läggas till i ditt Build Sheet beror på om det finns stödjande bevis tillgängligt. Assisterad ifyllning är inte en garanterad tjänst och den aktiveras inte automatiskt.
När ett Build Sheet har luckor kan dessa fält kompletteras där bevisen tillåter. Om lämpliga bevis finns kan den saknade informationen eventuellt läggas till genom en efterföljande granskning. Om bevisen inte finns tillgängliga kvarstår luckan. Processen är villkorad av vad den historiska dokumentationen stöder, inte av hur mycket du vill ha informationen eller hur många gånger en revision begärs.
Information från ägaren är en typ av indata som kan bidra till korrigeringsprocessen. Om du har dokumentation eller register som rör ditt fordons ursprungliga konfiguration kan den informationen skickas in som en del av en korrigering. Hur information från ägaren hanteras och utvärderas beskrivs i detalj i underartikeln om korrigeringar.
Anmärkning om glesa eller datafattiga Build Sheet : Ett Build Sheet som returnerar begränsad information kan återspegla begränsningar i tillgängliga historiska bevis snarare än ett tekniskt fel. En rapport med låg data utlöser inte automatiskt djupare manuell forskning eller assisterad ifyllning. Det återspeglar vad tillgängliga bevis stöder för det fordonet.
För inlämningssteg och en mer fullständig förklaring av hur information som lämnats av ägaren hanteras, se Hur korrigeringar av klassisk bil Build Sheet granskas.
Rättelse- och revisionspolicy — Avgifter och handläggningstider
Rättelser i ditt Classic Decoder Build Sheet medför ingen extra avgift. Det finns ingen angiven revisionsgräns. Dessa är aktuella villkor i korrigeringspolicyn och innebär inte obegränsad manuell forskning eller garanterade lyckade revisioner.
För tillämpliga korrigerings- och assistansärenden är handläggningstiden upp till 24 till 48 timmar, ofta snabbare. Detta fönster omfattar korrigeringar och granskningar med assisterad slutförande, inte den första leveransen av ditt Build Sheet .
En gräns förtjänar tydlig uppmärksamhet: avsaknaden av en angiven revisionsgräns betyder inte att saknade historiska data alltid kan återställas, oavsett hur många gånger en revision skickas in. Revisionspolicyn tar bort kostnader och upprepning som hinder, men den ändrar inte vilka bevis som finns för ett givet fordon. Om den historiska registreringen inte innehåller information om ett visst alternativ eller en viss specifikation, kommer inget antal revisioner att producera dessa data. Komplettering är möjlig där bevisen tillåter, och den villkorligheten försvinner inte eftersom revisionspolicyn är generös.
Enkelt uttryckt: korrigeringar ingår utan extra kostnad, och det finns ingen angiven revisionsgräns, men dessa villkor garanterar inte att alla problem kan lösas. Tillgängligheten av bevis är fortfarande den styrande faktorn för vad som faktiskt kan läggas till.
För detaljerad information om korrigeringsavgiftsstrukturen och revisionsprocessen, se Avgifter, handläggningstider och revisionstider för korrigering Build Sheet.
Etiketter för granskningsstatus kommer till ditt Build Sheet
Nuvarande Classic Decoder Build Sheet visar inte universellt proveniensmarkörer på fältnivå. Det finns inget system på plats idag som fäster en synlig beviskälla-etikett på varje enskilt fält i din rapport. Om du letar efter sådana indikatorer på ett Build Sheet som du redan har fått är de för närvarande inte en universell funktion i produkten.
Framöver planeras tre evidensstatusetiketter som framtida terminologi för styrning Build Sheet : Reviderad, Ägarbekräftad och Manuellt granskad. Deras exakta omfattning och placering, inklusive huruvida de gäller på fält-, rapport- eller arbetsflödesnivå, bör inte enbart utgå från etikettnamnen. De representerar ett planerat framtida tillstånd, inte en beskrivning av vad aktuella rapporter visar universellt.
Skillnaden mellan aktuella och planerade ärenden här. Dessa etikettnamn ska inte läsas som en bekräftelse på att ditt befintliga Build Sheet innehåller dem. Om och när dessa etiketter distribueras ska deras exakta betydelse, omfattning och tillämpning läsas utifrån produktens tillstånd vid den tidpunkten. För dessa definitioner, se Förklaring av status- och granskningsetiketter för reviderade Build Sheet.