Shard-gruppe
Sidst opdateret den
13. apr. 2026
Definer en signaturdeadline, der automatisk annullerer aftalen efter et defineret antal dage.
Funktionen Fuldførelsesdato i Acrobat Sign gør det muligt for afsendere at angive en tidsgrænse for hvornår modtagere skal fuldføre deres underskrifter, før aftalen annulleres automatisk. Det hjælper med at kontrollere frister for underskrivelse, især for tidsfølsomme aftaler såsom sæsonbestemte kontrakter eller særtilbud. Det strømliner også administrationen af aftaler ved at fjerne gamle aftaler eller aftaler, der sandsynligvis ikke kan fuldføres, fra I gang-listen, hvilket gør det nemmere at spore aktive aftaler.
Tilgængelighed:
- Acrobat Standard og Acrobat Pro: Ikke understøttet
- Acrobat Sign Solutions: Understøttet, deaktiveret som standard
- Acrobat Sign for Government: Understøttet; deaktiveret som standard
Konfigurationsomfang:
De konfigurerbare indstillinger for denne funktion kan findes her >
Note
Udløbsdatoen kan indstilles manuelt på op til 365 dage i fremtiden.
Aftaler, der ikke har fået indstillet en udløbsdato, udløber automatisk efter 365 dage.
Hvis funktionen Dokumentudløb er deaktiveret, låses muligheden i sektionen Aftaleindstillinger på siden Opret og kan ikke redigeres. Noten i oversigten over aftaleindstillinger viser Ingen.
Hvis Dokumentudløb er aktiveret, og kun standardværdiindstillingen er aktiveret, er indstillingen Fuldførelsesdeadline synlig på siden Opret i sektionen Aftaleindstillinger. Indstillingen viser deadlinedatoen, indstillet til den administrator, der har gemt som standardvarigheden af den tid, en aftale skal kunne underskrives. Datovælgeren til at vælge en ny dato er nedtonet og låst, hvilket forhindrer afsenderen i at redigere den.
Når funktionen Dokumentudløb er aktiveret, og muligheden for at tillade afsenderen at indstille deadlinen også er aktiveret, er indstillingen Deadline for fuldførelse tilgængelig og redigerbar. Afsenderen kan frit angive et hvilket som helst antal dage (op til 365), som aftalen skal forblive gyldig til underskrivelse.
- Hvis muligheden for at indstille standardantallet af dage er aktiveret, afspejler standarddatoen på en ny aftale standardværdien.
- Hvis muligheden for at indstille en standarddato ikke er aktiveret, vil standardudløbsværdien være 365 dage fra afsendelsesdatoen.
- Man kan ikke slette den automatiske sletning på 365 dage, når Dokumentudløb er aktiveret.
Udløbstidspunkt
Dokumentet udløber altid uden for spidsbelastningsperioder, alt efter hvilken server der har sendt aftalen. Åbningstider uden for spidsbelastningsperioder er fra 19 til 7 i serverens lokale tidszone.
Aftaler, der sendes via den moderne Anmod om signaturer-proces, tildeles som standard en udløbstid, som er 23:59 PM, selvom afsendere kan få tilladelse til at angive brugerdefinerede udløbsdatoer og -tidspunkter. Aftaler, der sendes via API'en, integrationer eller ældre grænseflader, indstilles dog ikke som standard til 23:59 PM. I stedet anvender de tidsstemplet for, hvornår aftalen oprindeligt blev sendt.
Hvis en aftale er indstillet til at udløbe i spidsbelastningsperioder, står den i kø til udløb, men forsinkes automatisk med 12 timer, så udløbshændelsen behandles uden for spidsbelastningsperioder.
Status og redigering under udløbskøen
- Så længe en aftale er i kø til udløb, vil dens status være I proces på siden Administrer og i API-svar.
- Modtagere kan ikke underskrive en aftale, der er i kø, og vil se en fejlmeddelelse om, at aftalen ikke kan underskrives.
- I køvinduet på 12 timer kan afsenderen redigere udløbsdatoen på siden Administrer og forlænge tidsfristen, så modtagerne får mere tid til at underskrive.
Timer uden spidsbelastning er mellem kl. 19.00 og kl. 7.00 baseret på den mest centrale tidszone for den shard-gruppe, aftalen blev sendt fra. Tidszonerne brugt for hver shard-gruppe er:
|
|
Tidszone for spidsbelastningsperioder (7.00-19.00) |
|---|---|
|
NA1, NA2, NA3, NA4 |
USA/Chicago |
|
EU1, EU2 |
Europa/Berlin |
|
AU1 |
Australien/Sydney |
|
JP1 |
Asien/Tokyo |
|
IN1 |
Asien/Kolkata |
|
SG1 |
Asien/Singapore |
Note
Nogle shard-grupper inkluderer flere shards, der spænder over flere tidszoner. Alle shards i gruppen anvender samme udløbsvindue uden spidsbelastning.
For eksempel anvender NA1, NA2, NA3 eller NA4 alle de samme ikke-spidsbelastningsperioder baseret på Central Time (GMT -6).
Aftalen udløber som planlagt, typisk inden for et par minutter efter den indstillede udløbstid.
Den henviser til det shard, hvor aftalen blev sendt, baseret på afsenderens miljø. (Find ud af, hvilket shard du er på >)
Underskriveren vil ikke kunne underskrive efter udløbstidspunktet, selv hvis aftalen endnu ikke er skiftet til statussen UDLØBET . De vil se en fejlmeddelelse:
Er en aftale sat i kø til udløb, men udløbet endnu ikke er blevet behandlet, kan afsenderen muligvis stadig redigere udløbsdatoen. Det giver modtageren ekstra tid til at underskrive aftalen, før den udløber.
Indtil systemet behandler udløbet (inden for 12 timer), forbliver aftalen i statussen IN_PROCESS. Den skifter til UDLØBET, når udløbshændelsen er behandlet.
Ja, du kan redigere udløbstiden når som helst, indtil udløbet er behandlet. Der er ingen begrænsninger for ændringer af udløbstiden, før aftalen skifter til statussen UDLØBET .
Ja, men forsinkelsen kan variere med et par minutter afhængigt af systembelastningen.
Når udløbsdatoen/klokkeslættet indstilles på siden Anmod om signaturer, er standard 23:59, hvilket sikrer, at udløbsdatoen sker uden for spidsbelastningstiden og behandles på det pågældende tidspunkt eller kort tid derefter. Du kan justere dette i afsnittet Aftaleindstillinger.
Aftalen vises fortsat som I gang, indtil udløbet er behandlet, typisk 12 timer senere.
Datastyring starter først, når aftalen skifter til en afsluttet tilstand (f.eks. UDLØBET). Et forsinket udløb forsinker også starten på opbevaringsperioden.
Udløbshændelsen logføres, når udløbet behandles, hvilket kan forsinkes med op til 12 timer, hvis udløbstiden ligger i timerne for spidsbelastningen.
Denne opdatering optimerer systemets ydeevne for at imødegå den stigende efterspørgsel.
