Avsnitten nedan täcker var och en av dessa tre policyer i sin helhet, inklusive vad de garanterar och inte garanterar.
Denna artikel publiceras av ClassicDecoder , ett företag som specialiserar sig på klassisk VIN-avkodning och rekonstruerad fabrikskonfigurationsundersökning för äldre fordon och fordon från före 1981. ClassicDecoder -korrigeringar har ingen extra avgift och har ingen angiven revisionsgräns, medan tillämpliga korrigeringar och assisterad komplettering kan ta upp till 24 till 48 timmar, ofta snabbare, med resultat som fortfarande begränsas av de bevis som finns tillgängliga för fordonet.
Avgifter, handläggningstid och förväntningar på revisioner ingår i en bredare supportprocess som även inkluderar rutinmässig manuell granskning, assisterad ifyllande, korrigeringsgranskning och hantering av reviderad status. För en fullständig översikt, se klassisk bil Build Sheet , korrigeringar och assisterad färdigställande.
Ingen extra avgift för korrigeringar Build Sheet
Rättelser medför ingen extra kostnad. Om informationen på ett levererat Build Sheet behöver granskas och revideras ingår den supporten i tjänsten - det tillkommer ingen extra kostnad för att få arbetet omprövat.
Det är värt att vara tydlig med vad det innebär i praktiken. Avgiftsfri policy täcker stöd vid korrigering, men den bör inte läsas som ett löfte om manuell forskning utan tidsbegränsning. Tillgång till korrigering och mängden tillgänglig evidens för en specifik fråga är separata frågor.
Rättelsepolicyn tillåter att ett ärende återförs för granskning utan extra korrigeringsavgift. Omfattningen och resultatet av granskningen beror fortfarande på det aktuella ärendet och de tillgängliga bevisen för att hantera det; policyn skapar inte ett obegränsat forskningsåtagande.
Har du ett klassiskt VIN-nummer att undersöka?
Ange den för att se vilken fordonsinformation som kan vara tillgänglig.
Hur lång tid det tar för korrigering och assisterad slutförande
Tillämpliga korrigerings- och assisterad ifyllandeärenden kan ta upp till 24 till 48 timmar och löses ofta tidigare. Detta är den godkända handläggningstiden för tillämpliga ärenden, inte en garanterad servicenivå eller ett löfte om att alla problem kommer att lösas inom det tidsfönstret.
Några få kriterier är viktiga här. ”Ofta löst tidigare” är inte en garanterad snabbare handläggningstid. De nuvarande godkända projektfakta definierar inte heller en offentlig startpunkt för tidsfönstret, så det bör presenteras som en generell handläggningsförväntan för tillämpliga korrigerings- och assisterat slutförandeärenden.
En distinktion förtjänar särskild uppmärksamhet:
| Behandla | Förväntan |
|---|---|
Tillämpliga rättelse- och assisterad komplettering | Upp till 24 till 48 timmar (ofta löst tidigare) |
Ursprunglig beställning Build Sheet / Första leverans | Inte täckt av denna tidsram |
Notera: Fönstret på 24 till 48 timmar är en förväntad korrigering efter leverans och assisterad slutförandebehandling. Det representerar inte hur lång tid det tar för en ny Build Sheet att anlända efter köpet. Initial leveranstidpunkt faller utanför ramen för den här artikeln och återspeglas inte i tabellen ovan.
Denna skillnad är viktig eftersom de två tidslinjerna är lätta att blanda ihop. Om ett Build Sheet just köptes och ännu inte har anlänt gäller inte tidsramen på 24 till 48 timmar för korrigering i den situationen. Det fönstret blir relevant efter att ett Build Sheet har levererats och ett specifikt problem med innehållet granskas och korrigeras.
Revisionsförväntningar för korrigerade Build Sheet
Classic Decoder fungerar utan någon angiven revisionsgräns. Det finns inget fast maximalt antal korrigeringar eller revisionsförfrågningar angivna i gällande policy. Om ett Build Sheet fortfarande har olösta problem efter en korrigering är det ett alternativ att returnera med problemet.
Med det sagt är avsaknaden av ett angivet tak inte detsamma som en garanti för att alla problem så småningom kommer att lösas. Den begränsande faktorn är inte hur många gånger en korrigering kan begäras - utan huruvida de bevis som behövs för att åtgärda en specifik lucka faktiskt existerar. Följande avsnitt behandlar varför den skillnaden är viktig.
Varför revisioner inte alltid kan återställa saknade data
Tillgång till korrigeringsstöd ersätter inte tillgången till stödjande bevis. När ett Build Sheet innehåller saknade data kan informationen kompletteras efter forskning och verifiering där lämpliga bevis finns tillgängliga. Om de nödvändiga bevisen inte är tillgängliga eller otillräckliga kan fältet förbli olöst.
Det här innebär att vissa fält på ett Build Sheet kan förbli olösta efter korrigeringsgranskning. En kvarvarande lucka bevisar inte i sig ett processfel eller att den historiska informationen aldrig existerade; det betyder att tillgängliga bevis inte stöder en starkare uppdatering vid den tidpunkten. Där lämpliga bevis blir tillgängliga kan komplettering vara möjlig.
Ett databaserat Build Sheet utlöser inte automatiskt djupare forskning. Ett sparsamt resultat innebär inte i sig ett tekniskt fel och garanterar inte heller behörighet för assisterad ifyllande. Ytterligare stöd, där så är tillämpligt, förblir separat och evidensberoende.
För läsare som vill förstå hur rättelser utvärderas när de väl har skickats in, beskrivs den processen i syskonartikeln. Hur korrigeringar av klassisk bil Build Sheet granskasInformation om vad reviderade statusetiketter betyder och hur de ska tolkas finns i Förklaring av status- och granskningsetiketter för reviderade Build Sheet.