1s omräkning. Rättelser och omräkningar av löner. Förköp efter giltighetstid

Från andra - till exempel kan bonusen bestämmas av beloppet av löner för perioden. I det här fallet är det möjligt att lönen ändras efter att bonusen har beräknats. Som standard kontrollerar inte plattformen sådana situationer. Om utvecklaren anser att det är nödvändigt att spåra detta, måste du använda ett speciellt underordnat objekt i beräkningsregistret - Omräkning:

Omräkningsposter lagras i en separat tabell. De garanterar inte att det beroende registret behöver räknas om korrekt, utan fungerar som en signal om ett sådant potentiellt behov.

I allmänhet innehåller omräkningstabellposter följande fält:

omräkningsobjekt (journaldokument vars data behöver räknas om)
beräkningstyp - länk till beräkningstypen från Plan över beräkningstyper definierad för detta beräkningsregister

Poster kan lagras mer i detalj, inom ramen för en eller flera dimensioner av ett givet beräkningsregister. Till exempel var löneregistratorn för hela avdelningen tillbakadaterad; Dessutom var förändringarna endast för den anställde Ivanov. Genom att lägga till dimensionen Employee i Omräkning kan du spåra detta. I det här fallet måste dimensionen Omberäkning vara kopplad till beräkningsregisterdimensionen:

Data från omräkningstabellen genereras automatiskt om motsvarande beräkningstypsplan har egenskapen Basperiod set. Om egenskapen inte är inställd är utvecklaren ansvarig för att generera poster.

Fråga 14.41 i tentamen 1C: Plattform Professional. Omräkningsdata...

är inte beräkningsregisterposter
är beräkningsregisterposter
är omräkningsregisterposter
är poster över den faktiska giltighetsperiodtabellen

Rätt svar är det första, de lagras vanligtvis i separata tabeller.

Fråga 14.42 i tentamen 1C: Plattform Professional. I fönstret "Omberäkning" för dimensionsegenskaper, på fliken "Kommunikation", i egenskapen "Registrera dimension", ange...

mätning av basregistret, när vars uppgifter ändras, måste aktuell registerpost räknas om
mätning av det aktuella registret, vars poster bör räknas om när basregistrens uppgifter ändras
mätningar av basregister, när vars uppgifter ändras, måste aktuell registerpost räknas om

Rätt svar är det andra. Själva omräkningen behövs för att spåra behovet av att uppdatera posterna i det aktuella registret.

Fråga 14.43 i tentamen 1C: Platform Professional. Tabellen "Omberäkning" är fylld med rader, som var och en representerar...

en uppsättning information om typen av beräkning och dokumentregistratorn för beräkningsregisterposten som behöver räknas om. Tabellen kommer även att innehålla omräkningsmått
en uppsättning information om typen av beräkning och dokumentregistratorn för beräkningsregisterposten som behöver räknas om
en uppsättning information om typen av beräkning, registrardokumentets radnummer och registratorn själv för beräkningsregisterposten som behöver räknas om. Tabellen kommer även att innehålla omräkningsmått
det finns inga korrekta svar

Det första svaret är korrekt, analys ovan.

Fråga 14.45 i tentamen 1C: Platform Professional. Välj det rätta svaret:

I processen att arbeta med omberäkningar kan utvecklaren "ignorera" informationen som systemet tillhandahåller i omräkningstabellen, det vill säga vägra att revidera beräkningsresultaten
Funktionsprincipen för omräkningar i 1C:Enterprise 8-systemet är "meddelar"
Konfigurationsutvecklaren kan inte styra processen för omräkning av avräkningsregisterposter, systemet gör allt automatiskt
Påstående 1 och 2 är sanna

Det fjärde rätta svaret är att omräkning endast övervakar det potentiella behovet av att ändra beroende data.

Fråga 14.46 i tentamen 1C: Platform Professional. För ett beräkningsregister...

Endast en omräkning kan stödjas
Endast tre tilldelningar av olika strukturer kan stödjas
Valfritt antal omräkningar av olika strukturer stöds

Rätt svar är det tredje, det är inga problem att lägga till hur många underordnade Omräkningsobjekt som helst till beräkningsregistret, deras struktur styrs inte på något sätt.

Fråga 14.57 i tentamen 1C: Platform Professional. Avvecklingsfrekvensen är månadsvis. Motsvarande inställningar har gjorts i beräkningsregistret. För beräkningstypen Löne anges beräkningstypen Resa som en förskjutande beräkningstyp. Den 03/01/14 fördes löneuppgifter in i informationsunderlaget, men ingen beräkning gjordes. Den 20/03/14 lades tjänsteresan in i informationsdatabasen och beräknades. Den 30/03/14 lanserades löneberäkning. Kommer uppgifter om tjänsteresor att beaktas vid beräkning av lön? Behöver jag räkna om min affärsresa?

Kommer att beaktas, men tjänsteresan måste räknas om
Kommer att beaktas, ingen reseomräkning krävs
Kommer inte att beaktas. Det är nödvändigt att avbryta reseberäkningen och räkna om båda typerna av beräkningar
Kommer inte att beaktas. För att göra beräkningen korrekt måste lönen och tjänsteresan finnas i ett dokument

Omräkning behövs inte, affärsreserekordet ligger inom månaden.

I den här artikeln kommer vi att överväga de teoretiska grunderna för att arbeta med beräkningsregister, och även beräkna den anställdes lön i proportion till antalet arbetade timmar.

Teori

Beräkningsregister (RR)- ett konfigurationsmetadataobjekt som används för att implementera periodiska beräkningar i 1C-systemet. Till de självklara tillämpningsområdena för beräkningsregister hör följande: löneberäkning, hyresberäkning, hyresberäkning.

Beräkningsregister liknar till sin struktur ackumuleringsregister eller informationsregister. De har precis som ackumuleringsregister mått, resurser, detaljer, men principen för drift av beräkningsregister är en helt annan.

I sin kärna fungerar mätningar i ackumuleringsregistret som " filtrera» i samband med vilket vi får uppgifter från ackumuleringsregistret. Som ett exempel, när vi tar ”rester” enligt ackumuleringsregistret ”Restgods” i samband med en viss vara eller ett ”klipp av det senaste” enligt informationsregistret ”Anställdas löner” i samband med en viss anställd . Till skillnad från ackumuleringsregistret tjänar mätningar i det periodiska beräkningsregistret till att implementera "" (detta är när tidsförlängda beräkningstyper konkurrerar med varandra under intervallet av postens giltighetstid, dvs. som ett exempel, beräkningen av tjänsteresor. typ förskjuter löneberäkningsslaget för giltighetsperioden) och ""(detta är när typen av bonusberäkning beror på typen av löneberäkning för tidigare perioder).

förtryckningsmekanism efter verkningsperiod«:

Här ser vi att beräkningstypen ”Tjänsteresa” har en varaktighet i tid och gäller från 10 april till 20 april, ”Tjänsteresa” anges som undanträngande beräkningstyp för beräkningstyp ”Lön”. Även ”lönen” sträcker sig över tiden och gäller från 1 april till 30 april. Eftersom ”Tjänsteresa” anges som en undanträngande beräkningstyp för beräkningstypen ”Lön” (har högre prioritet än lön) och gäller under lönens giltighetstid, så förskjuts lönen av en tjänsteresa och "Lönens faktiska giltighetstid" bildas." Faktisk giltighetstid för lönen "Detta är giltighetstiden för lönen efter förskjutning av en tjänsteresa, i vårt fall består den av 2 perioder - från 1 april till 9 och från 21 till 30 april och totalt är 19 dagar. Den periodbaserade förskjutningsmekanismen fungerar bara för långtidsberäkningar.

Figuren ovan visar grafiskt principen om " beroendemekanism efter basperiod«:

Låt oss säga att vi i slutet av april 2017 vill ge en anställd en bonus på 10 % av lönen. Lön anges som grundberäkningstyp för bonus.

Men som "bas" för beräkning av premien tar vi inte hela april månad, utan endast intervallet från 10 april till 20 april (11 dagar). Låt oss beräkna basen för bonusen, den anställdes lön är 60 000 rubel, det finns 30 dagar i en månad, dagslön = 60 000/30 = 2 000 rubel. Nästa 2000*11 = 22000 rub. Grunden för beräkning av premien är 22 000 rubel.

Låt oss beräkna premien: (22000/100)*10 = 2200 rubel. En bonus på 10% av lönen är 2 200 rubel.

Applikationsmetadataobjektet ”Plan över beräkningstyper” är nära förknippat med beräkningsregistret.

Plan över beräkningstyper (PVR)- ett konfigurationsmetadataobjekt som lagrar information om typerna av beräkningstyper och bestämmer olika beräkningars inflytande på varandra.

En beräkningstypsplan kan användas i flera beräkningsregister, men ett beräkningsregister kan inte använda flera beräkningstypsplaner samtidigt.

Beräkningsregistret är en tabell i vilken beräknade data lagras och vad gäller beräkningstyper lagras algoritmer för att beräkna dessa data. Beräkningsregistret ska ha minst en dokumentregistrator som gör rörelser i beräkningsregistret (exempelvis Lön).

Beräkningsmekanismerna i 1C Enterprise-systemet är utformade så att du först behöver göra anteckningar i beräkningsregistret och först därefter utföra beräkningen utifrån dessa data. Det är till exempel omöjligt att beräkna en bonus baserat på en lön förrän samma lön registreras i beräkningsregistret.

Öva

Låt oss ta en närmare titt på beräkningsregistren i praktiken:

Steg 1 Låt oss börja med en plan för typerna av beräkningar. Du måste skapa en beräkningstypsplan innan du skapar ett beräkningsregister. Vi skapar en plan för beräkningstyper före beräkningsregistret eftersom innan vi skapar en tabell för lagring av beräknade data (dvs. ett beräkningsregister), är det nödvändigt att specificera algoritmer för att beräkna dessa data (dvs. en plan för beräkningstyper).

Låt oss skapa en plan för typerna av beräkningar "Grundavgifter". Låt oss omedelbart gå till fliken "Beräkning". Här ser vi genast flaggan " Använder giltighetstid", när denna flagga är inställd kommer alla typer av beräkningar som ingår i denna plan att ha längd i tiden(till exempel lön, affärsresa), och även för denna plan med beräkningstyper, " förtryckningsmekanism efter verkningsperiod". Om flaggan "Använder giltighetsperioden" inte är inställd, kommer beräkningstyperna inte att förlängas i tiden (till exempel bonus, böter) och "förskjutningsmekanismen efter giltighetsperiod" kommer inte att fungera. På den här fliken finns också avsnitten "Beroende av basen" och "Grundläggande planer för beräkningstyper" - de tjänar till att implementera " beroendemekanism efter basperiod", men vi pratar om det senare. För nu, låt oss lämna "Beroende på basen" i "Oberoende" -läget.

Låt oss skapa en fördefinierad beräkningstyp "Lön". På fliken "Grundläggande" är allt enkelt. Ställ in namn och kod för beräkningstypen.

Tack vare att vi satte flaggan " Använder giltighetstid"Vi har nu en flik" Förskjuter"och slog på" periodbaserad repressionsmekanism«.

På den här fliken anger vi vilka typer av beräkningar som kommer att förskjuta lönen efter giltighetstid (till exempel affärsresa).

Notera: i "Förskjuta" kan du lägga till beräkningstyper som bara hör till denna plan av beräkningstyper.

Det finns också en flik " Presentatörer»—det anger vilka typer av beräkningar som, när de ändras, måste räkna om den aktuella typen av beräkning. Här kan du även ange beräkningstyper från andra beräkningstypsplaner. Till exempel är beräkningstypen "Lön" den ledande för beräkningstypen "Bonus", dvs. När lönen ändras måste vi även räkna om bonusen pga Bonusen beräknas beroende på lönen. I det här fallet tillhör beräkningstypen "Lön" till PRP "Basic Accruals", som använder en giltighetstid, och beräkningstypen "Bonus" tillhör PRP "Additional Accruals", som inte använder en giltighetsperiod.

Steg 2.Låt oss skapa en "Charts"-katalog med standardstrukturen. I katalogen "Schedules" kommer vi att lagra de anställdas arbetstider (fem dagar, sex dagar, etc.).

Steg 3.Vi behöver också ett objekt där vi kommer att lagra Produktionskalendern (arbetsdagar och helger). För dessa ändamål använder vi ett icke-periodiskt oberoende register över information.

Låt oss skapa ett icke-periodiskt oberoende informationsregister "Arbetsscheman" med 2 dimensioner "Datum" och "Schema" och resursen "Antal timmar".

Tack vare informationsregistret ”Arbetsscheman” kommer vi att kunna räkna ut lön från lönen i proportion till antalet arbetade dagar.

Steg 4.Skapa ett "lönedokument" med detaljstrukturen som visas nedan:

Krav:

Operationell utförande är inställd på "Förbjud" därför att det är inte vettigt för mekanismen för periodiska avräkningar i 1C - vi beräknar aldrig bonusar, löner eller böter i realtid.

Låt oss skapa ett dokumentformulär med standardinställningar.

Steg 5. Slutligen kom vi till punkten att skapa beräkningsregister.

Beräkningsregistermetadataobjektet finns i grenen "Beräkningsregister" i konfiguratorn.

Låt oss skapa ett beräkningsregister "Grundavgifter". Låt oss titta på inställningarna för beräkningsregistret nedan:

1. I fältet "Plan över beräkningstyper" anger du PVR "Basic charges" som skapades i steg 1.

2. Ställ in "Giltighetsperiod"-flaggan till "True" eftersom Den PVR som anges i steg 1 har förlängning i tid.

Efter att ha ställt denna flagga blir standarduppgifterna "Action Period", "Action PeriodStart", "ActionPeriodEnd" omedelbart tillgängliga för oss, vilket innebär att de typer av beräkningar som registreras i detta beräkningsregister också har längd i tiden och vi har tillgång till " förtryckningsmekanism efter verkningsperiod«.

P.S. Om du anger en PVR som har längd i tiden för en RR med flaggan "Validity Period" inställd på "False", kommer denna PVR att fungera som en PVR som inte har förlängning i tid.

3. Efter att ha ställt in flaggan "Giltighetsperiod" till "True", blir fälten "Diagram", "Diagramvärde", "Diagramdatum" tillgängliga för oss.

I fältet "Schedule" anger vi informationsregistret "Work Schedules" som skapades i steg 3.

I fältet "Schedule Value" anger vi resursen "Antal timmar" i informationsregistret "Arbetsscheman".

I fältet "Schedule Date" anger vi dimensionen "Datum" i informationsregistret "Arbetsscheman".

4.I fältet "Frekvens" anger vi värdet "Månad", detta betyder att uppgifterna kommer att föras in i registret på månadsbasis.

Nedan är registermetadatastrukturen:

"Grundläggande"-flaggan för en dimension påverkar bara prestanda; du behöver inte ställa in den, men om du gör det kommer fältet "Anställd" att indexeras.

Dimensionen "Anställd" - den används i " förtryckningsmekanism baserad på verkningsperioden"och" mekanism för beroende av basperioden«.

Resurs "Belopp" - den beräknade lönen kommer att registreras där.

Attributet "Diagram" indikeras som ett attribut, och inte en registerdimension, eftersom varken det eller det förskjuter någonting - i huvudsak ett referensfält. Viktig!!! Glöm inte att fylla i fältet "Schedule Link". vid attributet "Schedule" ska dimensionen "Schedule" i informationsregistret "Work Schedules" anges där, annars kommer lönebeloppet inte att beräknas.

Attributet "Parameter" kommer att lagra lönevärdet.

Nu när vi har angett sambandet med "Arbetsscheman" MS kommer vi att beräkna den anställdes lön i proportion till antalet arbetade dagar.

Vi anger dokumentet som registrator " Löner" skapades i steg 4.

Steg 6. Vi gör rörelser enligt beräkningsregistret ”Grundavgifter”.

Låt oss återgå till dokumentet "Lön" som skapades i steg 4.

Låt oss beskriva behandlingen av bokföring i dokumentobjektmodulen:

Fragment av dokumentbehandlingskod

1C (kod)

Procedur ProcessingProcessing(Failure, Processing Mode) // register BasicAccruals of Movement.MainAccruals.Write = True; Movements.MainAccruals.Clear(); Registreringsperiod = månadens början (datum); För varje TechLineMainAccruals från MainAccruals Cycle Movement = Movements.MainAccruals.Add(); Move.Reversal = Falskt; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Registreringsperiod; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Slut på procedur

Bearbetningsprocedur (fel, läge)

// Huvudsakliga periodiseringsregister

Rörelser. Grundläggande periodiseringar. skriv = sant;

Rörelser. Grundläggande periodiseringar. Klar() ;

Registreringsperiod = Början av månaden (datum) ;

För varje TechLine BasicAccrualsFrom BasicAccrualsCycle

Rörelse = Rörelser. Grundläggande periodiseringar. Lägg till() ;

Rörelse. Storno= Falskt;

Rörelse. Beräkningstyp=TexLineMainAccruals. Beräkningstyp;

Rörelse. PeriodActionStart = TechLineMainAccruals. Start datum;

Rörelse. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ;

Rörelse. Registreringsperiod = Registreringsperiod;

Rörelse. Anställd = TechLineMainAccruals. Anställd;

Rörelse. Diagram = TechLineMainAccruals. Schema;

Rörelse. Parameter = TechStringMainAccruals. Storlek;

EndCycle;

Slut på procedur

Låt oss skapa ett testdokument och köra det:

Låt oss gå till "Dokumentrörelser":

Vi ser att anmälningstiden är satt till början av månaden pga Frekvensen för RR anges som "Månad". Vi ser också att alla fält utom beloppet är ifyllda (lönen är ännu inte beräknad).

Steg 7.Låt oss skriva löneberäkningskoden.

Låt oss skapa en allmän modul "Beräkning" med följande flaggor:

Själva beräkningen kommer att ske i denna allmänna modul.

Låt oss skriva exportfunktionen "Beräkna avgifter" i modulen "Beräkning":

Eftersom vi fyllde i fälten "Schema", "Schedule value", "Schedule date" i inställningarna för RR "Basic charges", blev en virtuell tabell i beräkningsregistret tillgänglig för oss DataGraphics, i en fråga till en virtuell tabell är vi intresserade av följande fält:

"Antal timmar faktisk åtgärdsperiod" - innehåller antalet faktiskt arbetade timmar beräknat utifrån schemadata

"Antal timmar åtgärdsperiod" - innehåller antalet arbetstimmar som beräknats utifrån schemadata i beräkningsperioden

Löneberäkningsförfarande

1C (kod)

Procedur CalculateAccruals(Registrator, Set of Records) Export //Lönebegäran=Ny begäran; Query.Text="VÄLJ | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData.NumberofHoursActionPeriod,AsccrualsAction0Plan,AccrualsDataPeriod) .Linjenummer |FRÅN |Beräkningsregister.Grundläggande periodiseringar. Grafikdata(| Registrar = &Registrar | Och beräkningstyp = &BeräkningstypLön) AS Basic AccrualsDataGraphics"; Request.SetParameter("Registrator", Recorder); // skicka dokumentet till registraren så att sökningen endast utförs på det aktuella dokumentet Request.SetParameter("Calculation TypeSalary", Planer of Calculation Types. Basic Accruals. Salary); //ställ typ av beräkning lön eftersom beräkna lönen Selection=Request.Run().Select(); SearchStructure=NewStructure; SearchStructure.Insert("RowNumber",0); //skapa en struktur för sökning av data för beräkning efter radnummer för varje post från RecordSet Cykel //cykel genom uppsättningen poster för den aktuella documentSearch Structure.LineNumber=Record.LineNumber; //fyll i radnumret för sökning If Selection.FindNext(Search Structure) Sedan //letar vi i provet efter data för beräkning baserat på det aktuella radnumret Record.Sum =?(Selection.HoursPlan=0.0, Sampling.HoursFact /Sample.HoursPlan * Sampling .Parameter); //beräkna lön i proportion till arbetade dagar, i Parameter - aktuell lön EndIf; Selection.Reset(); //återställ urvalet, vi behöver nästa post i postuppsättningen för att söka igenom urvalet första EndCycle; Recordset.Write(, True); //skriv de beräknade posterna till databasen, skicka parametern Replace = True EndProcedure

//Lön

Request=Ny förfrågan;

Begäran. Text="VÄLJ

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActualActionPeriod, 0) AS HoursFact,

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS HoursPlan,

| BasicAccrualsDataGraphics.NumberLines

|FRÅN

| Beräkningsregister. Grundläggande periodiseringar. Grafikdata (

| Inspelare = &Inspelare

God eftermiddag. Jag har inte hört från dig på länge :) Idag vill jag förtydliga funktionerna i omräkningar i ZUP 3.0 för tidigare perioder. Den här artikeln talar om hur det fungerar inuti och följaktligen kan du kontrollera den här processen. När allt kommer omkring har du förmodligen stött på det faktum att programmet oväntat samlar på sig okända belopp för en person, vänder på dem, vissa skillnader dyker upp ... och du ville inte ha det eller ville ha det. men detta hände inte))

Låt oss börja. För det första sker omräkningar i det ögonblick då du betraktar lönen som ett "lönedokument". För detta ändamål tillhandahålls en flik "Ytterligare periodiseringar, omräkningar". Det första jag vill tipsa dig om: kontrollera alltid uppgifterna på etiketten "Ytterligare periodiseringar, omräkningar" . De kan dyka upp där utan din vetskap, och du kommer inte att förstå varför beloppet i kalkylen inte är detsamma.

I teorin, i dokumentets rubrik blir vi alltid varnade för att programmet är på väg att räkna någon eller att vi behöver fylla på det, eftersom... någon räknades inte.

Hur vet programmet vem jag behöver räkna och för vilken månad?

Hon bestämmer detta utifrån dina handlingar. Har du tillbakadaterat dokumentet? Programmet tittade på de anställda som fanns i detta dokument och spelade in deras lista. Gjorde du en rättelse i dokumentet (till exempel korrigerade tidrapporten för förra månaden)? Programmet har kommit ihåg alla från denna tidrapport och denna månad kommer att räknas om. Nästan alla handlingar, både personal och löner, berörs. I det här fallet bryr programmet sig inte om huruvida du rörde vid dokumentet påverkade din lön eller inte.

Låt oss säga att du gick till jobbansökan och skrev en kommentar där, varefter du lade upp dokumentet igen. Ingen lön, inget tillsättningsdatum, ingen tjänst... ingenting rördes. Men programmet vet inte varför du skrev över dokumentet från föregående period, det är inte en telepat, det spelade helt enkelt in den här medarbetaren.

Andra tipset (aka den första hemligheten): genom "alla funktioner", gå till informationsregistret "Löneomräkning". Var inte lat och klättra in! Gå in där före varje löneberäkning och efter varje bakdaterat dokument.

Många revisorer uppfattar detta råd som att de har ett nytt jobb, som de redan har nog av. Men om du inte klättrar dit kommer du inte att förstå logiken i arbetet, och om programmet är som en svart låda för dig, kommer du inte att bli vän med det. Vänskap börjar med att förstå en väns inre värld! Om du inte bryr dig om din motståndares inre värld, då är han inte din vän.

Så, har du klättrat in? Bra. I regel är den tom och det finns inte en enda rad, men så fort du trycker på något retroaktivt kommer det upp en post här som innehåller den anställde och månaden som behöver räknas om.

Tredje tipset: Om du inte håller med programmets avsikt att räkna medarbetaren, radera raden från detta register.

1. Förstår du redan hur linjerna ser ut? Bra.

2. När du fyller i dokumentet "Lön" och bokför det utifrån raderna i registret, görs en omräkning och ifyllning av tabellen "Ytterligare periodiseringar, omräkningar."

3. Omräknade anställda tas bort från registret och det blir tomt.

4. När du avbryter dokumentet "Lön" återförs raderna till sin plats så att när du fyller på dem igen kommer allt att falla på plats.

Fjärde tipset (kanske detta löser sig): Innan du fyller på dokumentet "Lön" sprid ut det!

Baserat på algoritmen, efter att dokumentet har lagts upp, rensas registret. Om du fyller på den utan att rensa den kommer programmet inte att veta vem som behöver räknas, och tabelldelen med omräkningar kommer att vara tom. Detta gällde för release 21. Jag har inte hunnit kolla det ännu i 22:a.

En annan nyans, om du klickar på listan över personer för omräkning i dokumentet öppnas formuläret för informationsregistret"Omräkning av löner." Och det kommer också att finnas en knapp för att "ta bort" en post.

P.S. (Viktig)

Anledningen till denna undersökning var de oändliga omräkningarna vid överföring av originaldata från Accounting 3.0. Under övergången måste du röra alla tekniker och översättningar)) efter det, radera allt innehåll i registret " "Löneomräkning", annars får du en omräkning av allt för alla år Komma igång i ZUP 3.0 med dataöverföring från Accounting 3.0

Detta är vad som hände i demodatabasen när ett jobb kördes om. Och när du överför 1C Accounting 3.0 till 1C ZUP 3.0 kommer du att göra om allt som är möjligt:

Det är allt, frågor i kommentarerna och var inte rädd för programmet, du måste förstå det och det kommer att betala dig för det med kärlek.

Många 1C-programmerare har aldrig stött på komponenten "Beräkning" i sin praktik, därför, när de måste ta prov för en specialist på plattform 8.0, där varje uppgift innehåller en uppgift om komplexa periodiska beräkningar, uppstår svårigheter, främst svårigheter att förstå.

Låt oss försöka ta reda på den här komponenten i 8.0. Istället för att lösa olika beräkningsproblem, låt oss försöka förstå denna komponent så att vi kan lösa alla beräkningsproblem. Efter att ha studerat denna manual kommer du att förstå hur beräkningsregister är uppbyggt och fungerar.

Till exempel kommer vi att använda ramkonfigurationen installerad under tentor.

För att vara ärlig försökte jag under lång tid ta reda på vad mer beräkningar behövdes för, men jag kunde inte lista ut det, så låt oss överväga problemet med att beräkna löner.

Vad är beräkningar

I grund och botten är den slutliga löneprodukten en uppsättning löneregisterposter av formuläret:

Anställd	Period	Typ av beräkning	Resultat	Data	En kommentar
Mått	Officiell	Officiell			Rekvisita

Värdet i kolumnen "Data" återspeglar den anställdes grundlön (enligt anställningsavtalet), men detta belopp kan ökas med bonusar, minskas med böter och frånvaro etc., därför läggs det faktiska beloppet som ska betalas in efter beräkningen i kolumnen "Resultat". Detta är beräkningen. Beloppet i kolumnen "Resurs" för en viss anställd är lönen som han betalar.

Således är beräkningsregistret i huvudsak en uppsättning poster som till sin struktur liknar det förhandlingsbara ackumuleringsregistret. Det är bara det att för att utföra komplexa beräkningar specificeras ytterligare inställningar för det, som sedan låter dig bygga många virtuella tabeller för beräkningsregistret, även om detta register i huvudsak bara är en uppsättning poster som anges i figuren.

Varje anteckning i avräkningsregistret avser en viss typ av avräkning och tidsperiod.

Typer av beräkningar

Varje post med beräkningstyper har ett serviceattribut - beräkningstyp.

En typ av beräkning kan ses som en del av en speciell uppslagsbok som "Plan över beräkningstyper" - den har också detaljer, tabelldelar, fördefinierade och användarskapade element. Det kan finnas flera sådana "kataloger" i systemet.

Låt oss till exempel skapa en plan för huvudberäkningstyper och i den fördefinierade beräkningstyper lön, bonus, frånvaro, affärsresa.

Beräkningstyper används funktionellt för att återspegla påverkan av beräkningsregisterposter på varandra. Men kortfattat talar de om inflytandet av beräkningstyper på varandra:

Typ av beräkning	Beskrivning	Exempel
Per basperiod	Resultatet av den beroende periodberäkningen beror på resultatet av basperioden. Om resultatet av basperioden ändras, måste resultatet av den beroende perioden räknas om.	Bonusen beror på basperiodens lön.
Torkar efter period	Giltighetsperioden för den beroende perioden ersätter basperiodens giltighetstid, så basperioden har en faktisk	Frånvaro påverkar lönens faktiska period.
Ledande beräkningar	Beräkningen beror på den ledande beräkningen, men inte direkt utan indirekt, d.v.s. beräkning A beror på grundkalkylen B, och beräkning B beror på grundkalkylen B, därför beror A indirekt på B, d.v.s. A beror på den ledande beräkningen B. Faktum är att när beräkning C ändras kan B ändras och därför kan A. Systemet spårar inte automatiskt sådana komplexa beroenden, så du måste ange vilka beräkningar som leder.	Bonusen beror på löneunderlaget, men beror också indirekt på frånvaro.

På grund av detta inflytande är giltighetstiden för avräkningsregistret uppdelad i fyra perioder:

Period	Beskrivning
Registreringsperiod	Under vilken period registrerades händelsen, d.v.s. vanligtvis när ett dokument matas in.
Giltighet	Under vilken period pågår evenemanget, d.v.s. vilken period evenemanget tillhör.
Basperiod	Endast meningsfullt för perioder som har en basperiod - beskriver intervallet för basperioden.
Faktisk giltighetstid	Om giltighetstiden ersätts av andra typer av beräkningar, så består den faktiska giltighetstiden av flera perioder då denna typ av beräkning faktiskt är i kraft.

Registreringsperioden anges med en siffra - början av perioden, motsvarande frekvensen av beräkningsregistret. Även om vi ställer in ett annat datum i det här servicefältet kommer det fortfarande att ersättas med början av perioden. De återstående perioderna anges av två fält - början och slutet av perioden. Den faktiska giltighetstiden är en uppsättning perioder, eftersom den kan bestå av flera datumintervall.

Tidsdiagram

Systemet har möjlighet att koppla data från beräkningsregister med tidsdiagram så att antalet arbetstimmar kan erhållas för valfri period.

En tidslinje är ett enkelt informationsregister där en dimension lagrar ett datum, en annan är associerad med en dimension av ett beräkningsregister och en av resurserna används för att spåra tid.

En dimension som förknippade med beräkningsregistret vanligtvis bär betyder "typ av graf".

datum	Diagramtyp	Menande
11.01.05 fre	Fem dagar
11.01.05 fre	Sex dagar
12.01.05 lö	Fem dagar
12.01.05 lö	Sex dagar

Varför använda datumdimensionen snarare än det periodiska detaljregistret? Det hela är väldigt enkelt - om vi fredagen den 11 januari har 8 arbetstimmar under en femdagarsperiod, betyder det inte att vi nästa dag igen har 8 arbetstimmar. Men om vi använde ett periodiskt register, skulle värdet för nästa dag tas från föregående dag i avsaknad av poster.

Med en viss period (faktisk åtgärd, registrering, basperiod, etc.) kan vi alltså automatiskt erhålla antalet timmar för denna period enligt schemat.

Omräkning

Omräkning påminner lite om en sekvensgräns. Eftersom vi har beroende beräkningar, när vi ändrar deras bas- och ledande beräkningar, måste systemet på något sätt notera att vi måste räkna om de beroende beräkningarna.

Det är vad omräkningar är till för.

Om vi beräknar basposterna kommer systemet att notera i allokeringarna att vi behöver beräkna de beroende posterna. När vi väl har beräknat de beroende posterna kommer tilldelningarna att raderas.

Omberäkningar är i huvudsak en lista över beräkningsregisterposter som behöver räknas om.

Om du inte anger några mått i omräkningar kommer alla beroende poster att läggas till i omräkningslistan när grundberäkningarna ändras.

Om vi skapar dimensionen "Anställd" vid omberäkning, kommer när grundberäkningen för en anställd ändras, beroende poster endast för denna anställd att läggas till i omräkningarna.

Praktisk uppgift

Nog med teori. Låt oss försöka studera detaljerna i praktiken. Låt oss ta ramkonfigurationen som grund.

Formulering av problemet:

Låt bonusen sättas som en fast procentsats av lönen (minus frånvaro och reseersättning).

Låt reseersättning utgå i dubbel lön + ett fast belopp för varje resedag.

Låt den anställde åläggas böter med halva lönen för frånvarotiden för frånvaro.

Framsteg:

Grundutbildning

Låt oss skapa en ny plan för beräkningstyper "Main".

Låt oss definiera typerna av beräkningar och beroenden mellan dem:

	Grundläggande	Förskjuter	Presentatörer
Lön		Frånvaro, affärsresa
Pris		Frånvaro, affärsresa	Lön, Frånvaro, Affärsresa
Affärsresa
Skolk

Låt oss lägga till dessa typer av beräkningar till "Huvud" beräkningstypsplanen och ställa in beroenden i egenskaperna för beräkningstyperna enligt tabellen.

I löneberäkningsregistret kommer vi att skapa dimensionen ”Anställd” av typen ”Enskilda” - så att registret får en analysavdelning för anställda.

Konfigurationen innehåller redan dokumentet "Lön".

Den har två datum i rubriken - "datum" och "registreringsperiod", samt två datum "startdatum" och "slutdatum" på varje rad.

Det är underförstått att datumet helt enkelt är det datum då dokumentet utfördes, registreringsperioden anger för vilken månad vi räknar lönen och datumen på varje rad beskriver giltighetstiden för varje typ av beräkning.

Låt oss lägga till den initiala inställningen av "Data" -attributet till dokumentmodulen - vi kommer att ange startlönen, ställa in registreringsperioden, giltighetsperioden och basperioden i den.

Dokumentmodulen kommer att se ut ungefär så här:

För Till varje TechStringList Från listcykel

// register Beräkningar

Rörelse = Rörelser .Beräkningar.Lägg till();

Rörelse .S torno= Falskt;

Rörelse .I idCalculation = TechStringList.CalculationType;

Rörelse .PeriodActionsStart= Start på dagen ( TechStringList.StartDate);

Rörelse .PeriodActionEnd= EndDay();

Rörelse .Registreringsperiod = Registreringsperiod;

Rörelse .BasicPeriodStart= Start på dagen ( TechStringList.StartDate);

Rörelse .BasePeriodEnd= Slutdag ( TechStringList.Slutdatum);

Rörelse .Anställd = TechStringList.Employee;

Rörelse .Schema = TechStringList.Graph;

Rörelse .Resultat = 0;

Rörelse .Data = TechStringList.Size;

EndCycle ;

Reversal-attributet behövs för att vända poster (analogt med ett minustecken).

Vi anger typen av beräkning och ställer in datumen till början och slutet av dagen. Naturligtvis kan basperioden bara anges för beräkningstyper beroende på basen, och Data kan endast anges för lönen, men allt fungerar så.

Vi kommer att datera alla dokument 2003-01-20, registreringsperioden kommer att sättas till 01-02-2003 (jag anger specifikt inte början och slutdata, detta spelar ingen roll här, i alla fall, vid inspelning i Registreringsperiod omräknat till början av perioden 01/01/2003). Vi använder januari 2003 eftersom arbetsscheman var klara för denna period.

Låt oss skapa en omräkning "Omberäkning" och lägga till dimensionen "Anställd" som är kopplad till dimensionen "Anställd".

Leker med omräkningar.

För att spela spelet, öppna begäran konsolen - bearbetning " CustomRequest» i en ramkonfiguration. Låt oss skapa en ny fråga med hjälp av frågekonstruktorn och lägga till en virtuell tabell där Omräkningar Omräkningar Omräkningar, kommer texten för begäran att se ut så här:

VÄLJA

CalculationsRecalculation.Om objektet Recalculation,

CalculationsRecalculation.In Calculations ID,

Beräkningar Omräkning Från anställd

FRÅN

Beräkningsregister Beräkningar Omräkning HUR Beräkningar Omräkning

Vi kommer att generera tre dokument - först kommer vi att tillföra löner till anställda A och B. Anställd A arbetar från 1 till 31 januari, B arbetar från 1 till 20 januari. Den andra kommer att tilldela anställd B en bonus för perioden 1 till 31 januari, den tredje kommer att tilldela frånvaro till anställd A från 20 till 25 januari.

Vi leker med den faktiska giltighetstiden.

Låt oss skapa en ny fråga - den här gången lägger vi till tabelldata till den Beräkningsregister Beräkningar Faktisk åtgärdsperiod.

Låt oss skapa en begäran och se att anställd A:s löneperiod är uppdelad i två perioder – från 1 till 19 januari och från 26 till 31 januari. Jag hoppas att du förstår att perioden delades upp i två, för... frånvaro ersatte lön.

Jag tror att beräkningsregistrets funktionsmekanismer blir allt tydligare framför våra ögon.

Låt oss studera grafer.

Låt oss nu försöka räkna ut lönen utifrån den anställdes lön.

Låt oss skapa en ny fråga för beräkningsregistret med hjälp av en virtuell tabell Beräkningsregister, beräkningar, datagrafik. Du kan ställa in en parameter för denna virtuella tabell - ett villkor för att välja poster, till exempel Anställd=&Välj Anställd Och Beräkningstyp=&Beräkningstyp Och Graph=&ViewGraphic.

Låt oss ställa in specifika anställda, typer av beräkningar och scheman i förfrågningsparametrarna och se hur många timmar resultatet blir.

Resultatkolumn	Menande
ValuePeriodAction	För vilken giltighetstid i timmar gällde anteckningen i registret.
ValueActualPeriodAction	Hur många timmar arbetade den anställde egentligen?
ValueBasePeriod	För lön är det inte vettigt, för bonusar - antalet arbetstimmar i basperioden.
Värderegistreringsperiod	Hur många arbetstimmar finns det i anmälningsperioden (januari månad)

Omräkningar är en integrerad del av löneberäkningen. Information om sjukfrånvaro, semester eller frånvaro för anställda som tas emot av ekonomiavdelningen med viss fördröjning leder till omräkning av löner och följaktligen försäkringspremier. 1C-experter berättar om hur beräkningar och omräkningar av försäkringspremier återspeglas i redovisning och reglerad rapportering i programmet 1C: Löner och personalledning 8, utgåva 3.

Vid omräkning av löner blir det nödvändigt att räkna om försäkringspremier. Dessutom kan skälet till omräkning av avgifter vara en förändring av taxan under året eller upptäckt av fel, till exempel att beräkningen inte tagits med i underlaget för försäkringspremier.

I dessa fall har revisorn frågor om behovet, skyldigheten och rätten att lämna uppdaterad information till Federal Tax Service.

Enligt klausul 1.2 i förfarandet för att fylla i beräkningen av försäkringspremier, som ges i bilaga nr 2 till ordern från Rysslands federala skattetjänst daterad 10.10.2016 nr ММВ-7-11/551@, är betalaren skyldig att göra nödvändiga ändringar i Beräkningen och lämna en uppdaterad rapport till skattemyndigheten om någon oretecknad eller ofullständig information, samt fel som leder till en underskattning av beloppet av försäkringspremier.

När revisorn beslutar om en uppdaterad beräkning ska lämnas in ska revisorn svara på följande frågor:

om all information återspeglades;
huruvida fel begåtts och om de ledde till en underskattning av storleken på försäkringspremierna.

Inlämning av en uppdaterad beräkning kan vara en skyldighet, en rättighet eller en påtvingad nödvändighet.

Uppdaterad beräkning av försäkringspremier

Skyldigheten att lämna in en uppdaterad beräkning uppstår om det, efter att ha lämnat in rapporten till Federal Tax Service, visar sig att ofullständig eller felaktig information om anställda har lämnats, eller fel upptäckts som ledde till en underskattning av beloppet av försäkringspremier som ska betalas.

Typer av vanliga fel som kräver obligatorisk inlämning av en uppdaterad beräkning:

1. Den anställde rapporterade inte omedelbart ändringar i sina personuppgifter, och Federal Tax Service gav falsk information om honom i avsnitt 3 i beräkningen.

2. Den anställde arbetade på en avdelning som har rätt att tillämpa en förmånlig ränta på försäkringspremier. Därefter överfördes han till en enhet där grundförsäkringspremien tillämpas. Information om den anställdes överföring kom sent till ekonomiavdelningen. Beräkningen av avgifterna gjordes felaktigt till reducerad skattesats.

3. I det inledande installationsskedet av programmet 1C: Lön och personalledning 8 gjordes ett misstag genom att premien uteslöts från beräkningsunderlaget för försäkringspremier. Att rätta till felet kommer att resultera i ytterligare avgifter.

4. En avdelning med förmånstaxa förlorar rätten att använda den men informationen når löneansvarig med dröjsmål. Omräkning enligt grundtaxan leder till en ökning av beloppet av försäkringspremier.

5. Vid beräkningen av försäkringspremier angav programmet inte att tjänsten var listad i listan över farliga yrken som omfattas av tilläggstaxor. Efter att felet upptäckts och rättats ledde omräkningen till att försäkringspremier till tilläggsavgifter betalades under.

Låt oss titta på funktionerna i omräkning av försäkringspremier i "1C: Löner och personalhantering 8" utgåva 3 med hjälp av exempel.

Exempel 1

Vid beräkning av försäkringspremier för en enhet Stock en förmånlig ränta på försäkringspremier tillämpades Invånare i teknik-innovation särskilda ekonomiska zonen(biljettkod "05"). Denna tariff ger bidrag till pensionsfonden med 13 % 2018; i socialförsäkringskassan 2,9 %; i Federal Compulsory Medical Insurance Fund 5,1 %. Exakt så beräknades bidrag för anställd V.S. Murgröna. Med månatliga inkomster på 10 000 rubel. Beloppet för försäkringsavdrag för månaden var:

i pensionsfonden - 1 300 rubel;
i FFOMS - 510 rubel;
i socialförsäkringsfonden - 290 rubel.

De angivna beloppen återspeglades i beräkningen av försäkringspremier för första kvartalet 2018.

När det visade sig att divisionen hade förlorat rätten att tillämpa en förmånlig ränta på försäkringspremier, då i enlighet med skrivelser från Rysslands federala skattetjänst daterade den 25 oktober 2017 nr GD-4-11/21611@ och ministeriet of Finance of Russia daterad 18 december 2017 nr? 03-15-06/ 84443 det fanns ett behov av att lämna in en klargörande beräkning. För att bilda det är det nödvändigt att räkna om försäkringspremier med nya priser.

I kortet Divisioner fältet ska rensas Rädsla för förmånstullar. bidrag. Nu är uppdelningen föremål för den taxa som används för organisationen och som anges i kortet Organisationer på bokmärket Redovisningsprinciper och andra inställningar länk Redovisningsprincip i fält Tarifftyp.

I exempel 1 är organisationen inställd på Grundförsäkringspremie(tullkod "01"), som föreskriver avgiftssatser 2018: till Ryska federationens pensionsfond till ett belopp av 22%; Försäkringskassan 2,9 %; FFOMS 5,1%. Det är uppenbart att pensionsfonden har "underbetalt" 9% av bidragen (22% - 13%), och taxekoden har ändrats.

I exempel 1 under övervägande bör inkomstredovisningsförfarandet ses över för att omräkna bidragen. Dokumentet är avsett att registrera förfarandet för inkomstregistrering och omräkning av försäkringspremier från föregående period. (meny Skatter och avgifter). På bokmärket Inkomstinformation det är nödvändigt att manuellt klargöra alla anställdas inkomster. Samtidigt på bokmärket Beräknade bidrag Försäkringspremier kommer att räknas om automatiskt.

Till följd av omräkning av försäkringspremier för anställd V.S. Murgröna med månatliga inkomster på 10 000 rubel. Beloppet för försäkringsavdrag för månaden var:

i Rysslands pensionsfond - 2 200 rubel;
i Federal Compulsory Medical Insurance Fund och Social Insurance Fund - beloppet ändrades inte och uppgick till 510 rubel. och 290 rub.

Efter omräkning av försäkringspremier för första kvartalet bör förtydligande Beräkningar utarbetas. Använder tjänsten 1C-Rapportering, det är nödvändigt att skapa nya rapporter för de perioder som korrigeras och för Titelsida ange Rättelsenummer(Fig. 2). Förtydligandena påverkade alla anställda på avdelningen, eftersom allas tariffkod hade ändrats. Därför bildas avsnitt 3 i den uppdaterade beräkningen för alla anställda på avdelningen. I andra fall, när bildandet av en uppdaterad beräkning orsakas av ändringar i data eller periodiseringar för enskilda anställda, visar avsnitt 3 data endast för dessa anställda. I vilket fall som helst är de återstående avsnitten av den klargörande beräkningen ifyllda med helt nya uppgifter.

Ris. 2. Titelsida för den förtydligande beräkningen av försäkringspremier för första kvartalet 2018

Rätten att lämna en uppdaterad beräkning av försäkringspremier

Försäkringstagare kan lämna in en uppdaterad Beräkning till besiktningen om de hittar fel som leder till en överskattning av försäkringspremiens storlek. Faktum är att vid nästa beräkning av bidragen under innevarande period görs en omräkning, och resultatet återspeglas i rapporten för nästa period. Situationsalternativ som låter dig presentera en uppdaterad beräkning:

1. Den anställde fick lön för hela arbetade månaden. Beräkningen av försäkringspremier lämnades till Federal Tax Service, men det visade sig senare att den anställde var sjukskriven eller på semester på egen bekostnad. En periodisering som inte ingick i underlaget för premieberäkningen ersatte en periodiseringspliktig försäkringspremie, vilket ledde till överbetalning av premier.

2. Eventuell omräkning av intjänad personal, vilket leder till en omräkning av försäkringspremier för att minska dem.

Exempel 2

Vid beräkning av lön för juni till anställd S.S. Gorbunkov tilldelades:

lönebetalning - 7 500 rubel;
betalning för affärsresa (baserat på genomsnittlig inkomst) för juni - 2 500 rubel.

Försäkringspremier har beräknats till grundtaxan. I juni bidrag från S.S:s lön. Gorbunkov var:

i Rysslands pensionsfond - 2 200 rubel;
i FFOMS - 510 rubel;
i socialförsäkringsfonden - 290 rubel.

Dessa bidrag är inbetalda och inkluderade i 2018 års halvårskonto. Den sjukfrånvaro som lämnats in till redovisningsavdelningen för perioden 2018-06-25-30-06-30 skapar inte skäl för bildandet av en uppdaterad Beräkning. Dokument registrerat i programmet Sjukskrivenåterför det tidigare upplupna beloppet av reseersättningar (fig. 3).

Ris. 3. Omräkning av reseersättning i dokumentet ”Sjukskrivning”.

Sjukskrivningen togs emot av organisationen i juli. Detta är ingen felsituation och leder inte till underbetalning av försäkringspremier. Eftersom det intjänade beloppet vid sjukfrånvaro inte omfattas av försäkringsavgifter har det skett en överbetalning av avgifter med:

i Ryska federationens pensionsfond - 550 rubel;
i FFOMS - 127,50 rubel;
i socialförsäkringsfonden - 72,50 rubel.

I ett program Sjukskriven, registrerad juli 2018, påverkar beräkningen av försäkringspremier under innevarande månad, vilket minskar beräkningsunderlaget.

Det finns inga lagkrav för att lämna in en uppdaterad beräkning i en sådan situation. Alla omräkningar sker under nästa period och återspeglas i nästa rapporter. Men samtidigt har organisationen rätt att förtydliga rapporten för halvåret och meddela Federal Tax Service om överbetalningen som har inträffat genom att lämna in ett förtydligande.

Före slutet av månaden bör du dock inte göra förhastade förtydliganden av beräkningen. Det finns trots allt olika handlingar registrerade under hela månaden. Vid något tillfälle dokumentet Sjukskriven kan verkligen vända inkomsten från föregående månad, och baserat på resultaten av beräkningen av löner för månaden, ett annat dokument, till exempel, Beräkning av löner och bidrag, kommer att göra ytterligare periodiseringar som överstiger återföringsintäkterna från föregående period. Som ett resultat kommer den innevarande månadens inkomst att minska med beloppet för återföring av affärsresan, inga minus för föregående månad kvarstår och justeringsrapporten kommer inte att visa några förändringar.

Behovet av att lämna in en uppdaterad beräkning av försäkringspremier

I ett antal fall har försäkringstagaren, trots avsaknad av skyldighet att lämna en uppdaterad beräkning, ingen annan möjlighet att rapportera sin överbetalning av premier, förutom att lämna en uppdatering:

1. Som ett resultat av omräkning av avgifter under innevarande period får den anställde ett negativt belopp. En rapport med ett negativt belopp kan inte skickas till Federal Tax Service. Därför finns det bara en utväg - att generera en uppdaterad rapport för föregående period.

2. Den anställde arbetade i riskfyllt arbete. Försäkringspremier beräknades med en tilläggssats. Information om den anställdes övergång till arbete under normala arbetsförhållanden inkom sent till ekonomiavdelningen. Som ett resultat av omräkning är det omöjligt att sänka de beräknade avgifterna till tilläggssatsen, eftersom den anställdes periodiseringar under den aktuella perioden inte längre är föremål för avgifter till tilläggssatsen.

Exempel 3

I det här fallet, till skillnad från föregående exempel 2, kommer det negativa beloppet av försäkringspremier som härrör från avbokning av en affärsresa inte att kompenseras av periodiseringar. Trots det faktum att det totala beloppet av försäkringspremier på grund av andra anställdas intjänande kommer att vara positivt, i avsnitt 3 kommer den anställde att förbli negativa värden, och detta är oacceptabelt. Och därför måste revisorn skapa ett dokument Omräkning av försäkringspremier, räkna om bidrag för juni, generera och skicka in en uppdaterad beräkning till Federal Tax Service.

Programmet 1C: Lön och personalhantering 8 automatiserar processen för omräkning av försäkringspremier. Använder tjänsten 1C-Rapportering initiala och förtydligande beräkningar för försäkringspremier genereras automatiskt. Beslutet att upprätta en förtydligande Kalkyl ligger dock kvar hos revisorn. Efter att ha analyserat konsekvenserna av att registrera ett dokument som ändrar beräkningar i den period som en rapport redan har lämnats för, räknar revisorn antingen om försäkringspremier för föregående period, eller så sker beräkningen automatiskt under innevarande månad.

Från redaktören. Läs i artikeln om mekanismen som implementeras i 1C:Enterprise 8 för att kontrollera kontrollförhållanden för beräkning av försäkringspremier, som tar hänsyn till data från justeringsberäkningar.