1s pārrēķins. Darba samaksas labojumi un pārrēķini. Pirmpirkuma tiesības pēc derīguma termiņa

No citiem - piemēram, piemaksu var noteikt pēc perioda algu apmēra. Šādā gadījumā, iespējams, pēc piemaksas aprēķināšanas tiks mainīta alga. Pēc noklusējuma platforma nekontrolē šādas situācijas. Ja izstrādātājs uzskata par nepieciešamu to izsekot, tad jums ir jāizmanto īpašs aprēķinu reģistra pakārtotais objekts - Pārrēķins:

Pārrēķinu ieraksti tiek glabāti atsevišķā tabulā. Tie negarantē, ka atkarīgais reģistrs ir precīzi jāpārrēķina, bet kalpo kā signāls par šādu iespējamu nepieciešamību.

Parasti pārrēķinu tabulas ieraksti satur šādus laukus:

pārrēķina objekts (ieraksts dokuments, kura dati ir jāpārrēķina)
aprēķina veids - saite uz aprēķina veidu no šim aprēķinu reģistram definēto aprēķina veidu plāna

Ierakstus var uzglabāt detalizētāk, ņemot vērā vienu vai vairākas dotā aprēķinu reģistra dimensijas. Piemēram, algu reģistrators visai nodaļai bija ar atpakaļejošu datumu; Turklāt izmaiņas bijušas tikai darbiniekam Ivanovam. Pārrēķināšanai pievienojot kategoriju Darbinieks, varēsit to izsekot. Šajā gadījumā dimensija Pārrēķins ir jāsaista ar aprēķinu reģistra dimensiju:

Dati no pārrēķinu tabulas tiek ģenerēti automātiski, ja atbilstošajam aprēķinu veida plānam ir iestatīts rekvizīts Bāzes periods. Ja īpašums nav iestatīts, izstrādātājs ir atbildīgs par ierakstu ģenerēšanu.

1.C eksāmena 14.41. jautājums: Platform Professional. Pārrēķina dati...

nav aprēķinu reģistra ieraksti
ir aprēķinu reģistra ieraksti
ir pārrēķinu reģistra ieraksti
ir faktiskā derīguma perioda tabulas ieraksti

Pareizā atbilde ir pirmā, tās parasti tiek glabātas atsevišķās tabulās.

1.C eksāmena 14.42. jautājums: Platform Professional. Dimensiju rekvizītu logā "Pārrēķins" cilnes "Saziņa" rekvizītā "Reģistrēt dimensiju" norādiet...

bāzes reģistra mērījums, kura datiem mainoties, jāpārrēķina aktuālais reģistra ieraksts
pašreizējā reģistra mērījums, kura ieraksti būtu jāpārrēķina, mainoties bāzes reģistru datiem
bāzes reģistru mērījumi, kuru datiem mainoties, jāpārrēķina aktuālais reģistra ieraksts

Pareizā atbilde ir otrā. Pats pārrēķins ir nepieciešams, lai izsekotu nepieciešamībai atjaunināt ierakstus pašreizējā reģistrā.

1.C eksāmena 14.43. jautājums: Platform Professional. Tabula "Pārrēķins" ir aizpildīta ar rindām, no kurām katra apzīmē...

informācijas kopums par aprēķinu veidu un pārrēķina reģistra ieraksta dokumentu-reģistratoru. Tabulā būs arī pārrēķinu mērījumi
informācijas kopums par aprēķina veidu un pārrēķina reģistra ieraksta dokumentu-reģistratoru
informācijas kopums par aprēķina veidu, reģistratora dokumenta rindas numuru un pašu pārrēķina reģistra ieraksta reģistratoru. Tabulā būs arī pārrēķinu mērījumi
pareizo atbilžu nav

Pirmā atbilde ir pareiza, analīze iepriekš.

1.C eksāmena 14.45. jautājums: Platform Professional. Izvēlies pareizo atbildi:

Strādājot ar pārrēķiniem, izstrādātājs var “ignorēt” informāciju, ko sistēma sniedz pārrēķinu tabulā, tas ir, atteikties pārskatīt aprēķinu rezultātus
Pārrēķinu darbības princips sistēmā 1C:Enterprise 8 ir “paziņošana”
Konfigurācijas izstrādātājs nevar kontrolēt norēķinu reģistra ierakstu pārrēķina procesu, sistēma visu dara automātiski
1. un 2. apgalvojums ir patiess

Ceturtā pareizā atbilde ir tāda, ka pārrēķins tikai uzrauga iespējamo vajadzību mainīt atkarīgos datus.

1.C eksāmena 14.46. jautājums: Platform Professional. Vienam aprēķinu reģistram...

Var atbalstīt tikai vienu pārrēķinu
Var atbalstīt tikai trīs dažādu struktūru piešķīrumus
Tiek atbalstīts jebkurš dažādu struktūru pārrēķinu skaits

Pareizā atbilde ir trešā, nav problēmu pievienot aprēķinu reģistram jebkādu skaitu pakārtotu Recalculation objektu, to struktūra nekādā veidā netiek kontrolēta.

1.C eksāmena 14.57. jautājums: Platform Professional. Norēķinu biežums ir mēnesis. Aprēķinu reģistrā ir veikti atbilstoši iestatījumi. Algas aprēķina veidam Ceļojuma aprēķina veids ir norādīts kā aizstājošais aprēķina veids. 03.01.14. informācijas bāzē tika ievadīta informācija par algām, taču aprēķins netika veikts. 20.03.14. komandējums ievadīts informācijas datu bāzē un aprēķināts. 30.03.14. tika uzsākta algas aprēķināšana. Vai, aprēķinot algu, tiks ņemti vērā komandējumu dati? Vai man ir jāpārrēķina mans komandējums?

Ņems vērā, bet komandējums būs jāpārrēķina
Tiks ņemts vērā, nav nepieciešams ceļojuma pārrēķins
Neņems vērā. Nepieciešams atcelt brauciena aprēķinu un pārrēķināt abus aprēķinu veidus
Neņems vērā. Lai pareizi veiktu aprēķinu, algai un komandējumam jābūt vienā dokumentā

Pārrēķins nav nepieciešams, komandējuma ieraksts ir mēneša ietvaros.

Šajā rakstā apskatīsim teorētiskos pamatus darbam ar aprēķinu reģistriem, kā arī aprēķināsim darbinieka darba samaksu proporcionāli nostrādāto stundu skaitam.

Teorija

Aprēķinu reģistrs (RR)- konfigurācijas metadatu objekts, ko izmanto periodisku aprēķinu ieviešanai 1C sistēmā. Aprēķinu reģistru acīmredzamās pielietošanas jomas ir šādas: algas aprēķins, īres aprēķins, nomas maksas aprēķins.

Aprēķinu reģistri pēc savas uzbūves ir līdzīgi uzkrāšanas reģistriem jeb informācijas reģistriem. Tiem, tāpat kā akumulācijas reģistriem, ir mērījumi, resursi, detaļas, bet aprēķinu reģistru darbības princips ir pavisam cits.

Būtībā mērījumi uzkrāšanas reģistrā kalpo kā " filtru» kura kontekstā mēs saņemam datus no uzkrāšanas reģistra. Kā piemēru ņemam “atliekas” pēc uzkrāšanas reģistra “Atlikuma preces” kontekstā ar noteiktu priekšmetu vai “nogriezni no jaunākā” pēc informācijas reģistra “Darbinieku algas” konkrēta darbinieka kontekstā. . Atšķirībā no uzkrāšanas reģistra mērījumi periodisko aprēķinu reģistrā kalpo, lai īstenotu "" (šajā gadījumā uz laiku pagarinātie aprēķinu veidi sacenšas savā starpā ieraksta derīguma termiņa intervālā, t.i., piemēram, komandējuma aprēķins tips izspiež algas aprēķina veidu derīguma termiņam) un ““(tas ir tad, kad prēmijas aprēķina veids ir atkarīgs no iepriekšējo periodu algas aprēķina veida).

represijas mehānisms pēc darbības perioda«:

Šeit redzams, ka aprēķina veidam “Darījumu brauciens” ir ilgums un tas ir spēkā no 10.aprīļa līdz 20.aprīlim, “Darījumu brauciens” norādīts kā aizvietojošs aprēķina veids aprēķina veidam “Alga”. Arī “alga” pagarinās laika gaitā un ir spēkā no 1. aprīļa līdz 30. aprīlim. Tā kā “Darba brauciens” ir norādīts kā aizvietojošs aprēķina veids aprēķina veidam “Alga” (ir augstāka prioritāte nekā darba alga) un ir spēkā uz algas derīguma termiņu, tad darba samaksa tiek pārvietota ar komandējumu un veidojas “Algas faktiskais derīguma termiņš”.” Faktiskais algas derīguma termiņš “Tas ir algas derīguma termiņš pēc pārvietošanas komandējumā, mūsu gadījumā tas sastāv no 2 periodiem - no 1.aprīļa. līdz 9 un no 21. līdz 30. aprīlim un kopā ir 19 dienas. Periodā balstītais pārvietošanas mehānisms darbojas tikai ilgtermiņa aprēķinos.

Augšējā attēlā grafiski parādīts princips " atkarības mehānisms pēc bāzes perioda«:

Teiksim, 2017. gada aprīļa beigās vēlamies darbiniekam piešķirt prēmiju 10% apmērā no algas. Kā pamata aprēķina veids prēmijām norādīta alga.

Bet par “bāzi” prēmijas aprēķināšanai mēs neņemsim visu aprīļa mēnesi, bet gan tikai intervālu no 10. līdz 20. aprīlim (11 dienas). Aprēķināsim piemaksas bāzi, darbinieka alga 60 000 rubļu, mēnesī ir 30 dienas, dienas alga = 60 000/30 = 2 000 rubļu. Nākamais 2000*11 = 22000 rub. Prēmijas aprēķināšanas pamats ir 22 000 rubļu.

Aprēķināsim piemaksu: (22000/100)*10 = 2200 rubļu. Piemaksa 10% apmērā no algas ir 2200 rubļu.

Lietojumprogrammas metadatu objekts “Aprēķinu veidu plāns” ir cieši saistīts ar aprēķinu reģistru.

Aprēķinu veidu plāns (PVR)- konfigurācijas metadatu objekts, kas glabā informāciju par aprēķinu veidu veidiem un nosaka dažādu aprēķinu ietekmi vienam uz otru.

Vienu aprēķinu veidu plānu var izmantot vairākos aprēķinu reģistros, bet vienā aprēķinu reģistrā vienlaikus nevar izmantot vairākus aprēķinu veidu plānus.

Aprēķinu reģistrs ir tabula, kurā tiek glabāti aprēķinātie dati, un aprēķinu veidu ziņā tiek glabāti šo datu aprēķināšanas algoritmi. Aprēķinu reģistrā jābūt vismaz vienam dokumentu reģistratoram, kas veic kustības aprēķinu reģistrā (piemēram, Algas).

Aprēķinu mehānismi 1C Enterprise sistēmā ir izstrādāti tā, ka vispirms ir jāveic ieraksti aprēķinu reģistrā un tikai pēc tam jāveic aprēķins, pamatojoties uz šiem datiem. Piemēram, nav iespējams aprēķināt prēmiju, pamatojoties uz algu, kamēr šī alga nav ierakstīta aprēķinu reģistrā.

Prakse

Sīkāk apskatīsim aprēķinu reģistrus praksē:

1. darbība Sāksim ar aprēķinu veidu plānu. Pirms aprēķinu reģistra izveides ir jāizveido aprēķinu veida plāns. Aprēķinu veidu plānu veidojam pirms aprēķinu reģistra, jo pirms aprēķināto datu glabāšanas tabulas (t.i., aprēķinu reģistra) izveides ir nepieciešams norādīt šo datu aprēķināšanas algoritmus (t.i., aprēķinu veidu plānu).

Izveidosim plānu aprēķinu veidiem “Pamatmaksas”. Tūlīt pāriesim uz cilni "Aprēķins". Šeit mēs uzreiz redzam karogu " Izmanto derīguma termiņu", kad šis karodziņš ir iestatīts, tiks veikti visi šajā plānā iekļautie aprēķinu veidi garums laikā(piemēram, Alga, Komandējums), kā arī šim aprēķina veidu plānam, “ represijas mehānisms pēc darbības perioda". Ja karodziņš “Izmanto derīguma termiņu” nav iestatīts, tad aprēķinu veidiem nebūs laika pagarinājuma (piemēram, Bonuss, Fine) un nedarbosies “pārvietošanas mehānisms pēc derīguma termiņa”. Arī šajā cilnē ir sadaļas “Atkarība no bāzes” un “Aprēķinu veidu pamatplāni” - tās kalpo, lai ieviestu “ atkarības mehānisms pēc bāzes perioda", bet mēs par to runāsim vēlāk. Pagaidām atstāsim “Atkarība no bāzes” režīmā “Neatkarīgā”.

Izveidosim iepriekš definētu aprēķina veidu “Alga”. Cilnē “Pamata” viss ir vienkārši. Iestatiet aprēķina veida nosaukumu un kodu.

Pateicoties tam, ka mēs uzstādījām karogu " Izmanto derīguma termiņu"Tagad mums ir cilne" Izstumšana"un ieslēgts" uz periodu balstīts represiju mehānisms«.

Šajā cilnē mēs norādām aprēķinu veidus, kas pārvietos algu pēc derīguma termiņa (piemēram, komandējums).

Piezīme: sadaļā “Pārvietošana” var pievienot aprēķinu veidus, kas pieder tikai šim aprēķina veidu plānam.

Ir arī cilne " Prezentētāji»—norāda aprēķinu veidus, kurus mainot, ir jāpārrēķina pašreizējais aprēķinu veids. Šeit var norādīt arī aprēķinu veidus no citiem aprēķinu veidu plāniem. Piemēram, aprēķina veids “Alga” ir vadošais aprēķina veidam “Bonuss”, t.i. Mainoties algai, jāpārrēķina arī piemaksa, jo Prēmija tiek aprēķināta atkarībā no algas. Šajā gadījumā aprēķina veids “Alga” pieder pie “Pamata uzkrājumu” PRP, kurā tiek izmantots derīguma termiņš, un “Bonuss” aprēķina veids pieder pie “Papildu uzkrājumu” PRP, kurā netiek izmantots derīguma termiņš.

2. darbība.Izveidosim direktoriju “Charts” ar noklusējuma struktūru. Katalogā “Grafiki” uzglabāsim darbinieku darba laiku (piecu, sešu dienu utt.).

3. darbība.Nepieciešams arī objekts, kurā glabāsim Ražošanas kalendāru (darba dienās un brīvdienās). Šiem nolūkiem mēs izmantojam neperiodisku neatkarīgu informācijas reģistru.

Izveidosim neperiodisku neatkarīgas informācijas reģistru “Darba grafiki” ar 2 dimensijām “Datums” un “Grafiks” un resursu “Stundu skaits”.

Pateicoties informācijas reģistram “Darba grafiki”, no darba algas varēsim aprēķināt darba samaksu proporcionāli nostrādāto dienu skaitam.

4. darbība.Izveidojiet “Algu saraksta” dokumentu ar tālāk norādīto detalizētās informācijas struktūru.

Rekvizīti:

Darbības izpilde ir iestatīta uz “Aizliegt” jo nav jēgas periodisko norēķinu mehānismam 1C - mēs nekad nerēķinām prēmijas, algas vai soda naudas reāllaikā.

Izveidosim dokumenta formu ar noklusējuma iestatījumiem.

5. darbība. Beidzot mēs nonācām pie aprēķinu reģistru izveides.

Aprēķinu reģistra metadatu objekts atrodas konfiguratora filiālē “Aprēķinu reģistri”.

Izveidosim aprēķinu reģistru “Pamatmaksas”. Apskatīsim tālāk norādītos aprēķinu reģistra iestatījumus:

1. Laukā “Aprēķinu veidu plāns” norādiet 1. darbībā izveidoto PVR “Pamata maksas”.

2. Iestatiet karogu “Derīguma periods” uz “True”, jo 1. darbībā norādītajam PVR ir pagarinājums laikā.

Pēc šī karoga iestatīšanas mums uzreiz kļūst pieejami standarta dati “Action Period”, “Action PeriodStart”, “ActionPeriodEnd”, kas nozīmē, ka arī šajā aprēķinu reģistrā reģistrētajiem aprēķinu veidiem ir garums laikā un mums ir piekļuve " represijas mehānisms pēc darbības perioda«.

P.S. Ja norādāt PVR, kuram ir garums laikā RR, kura karodziņš “Derīguma periods” ir iestatīts uz “False”, šis PVR darbosies kā PVR, kuram nav pagarinājums laikā.

3. Pēc karoga “Derīguma periods” iestatīšanas uz “True”, mums kļūst pieejami lauki “Diagramma”, “Diagrammas vērtība”, “Diagrammas datums”.

Laukā “Grafiks” norādām 3. darbībā izveidoto informācijas reģistru “Darba grafiki”.

Laukā “Grafika vērtība” informācijas reģistrā “Darba grafiki” norādām resursu “Stundu skaits”.

Laukā “Grafika datums” norādām informācijas reģistra “Darba grafiki” dimensiju “Datums”.

4. Laukā “Biežums” norādām vērtību “Mēnesis”, tas nozīmē, ka dati tiks ievadīti reģistrā katru mēnesi.

Tālāk ir norādīta reģistra metadatu struktūra:

Kategorijas karodziņš “Pamata” ietekmē tikai veiktspēju; jums tas nav jāiestata, taču, ja to izdarīsit, lauks “Darbinieks” tiks indeksēts.

Dimensija "Darbinieks" — tā tiek izmantota sadaļā " represijas mehānisms, kas balstīts uz darbības periodu" Un " atkarības mehānisms no bāzes perioda«.

Resurss “Summa” - tur tiks ierakstīta aprēķinātā alga.

Atribūts “Diagramma” ir norādīts kā atribūts, nevis reģistra dimensija, jo ne tas, ne tas neko neizspiež - būtībā atsauces lauks. Svarīgs!!! Neaizmirstiet aizpildīt lauku "Grafika saite". pie atribūta “Grafiks” tur jānorāda informācijas reģistra “Darba grafiki” dimensija “Grafiks”, pretējā gadījumā algas apmērs netiks aprēķināts.

Atribūts “Parameter” saglabās algas vērtību.

Tagad, kad esam norādījuši saistību ar “Darba grafikiem” DV, aprēķināsim darbinieka algu proporcionāli nostrādāto dienu skaitam.

Mēs norādām dokumentu kā reģistratoru " Algu saraksts", kas izveidots 4. darbībā.

6. darbība. Kustības veicam pēc aprēķinu reģistra “Pamatmaksas”.

Atgriezīsimies pie 4. darbībā izveidotā dokumenta “Algu saraksts”.

Aprakstīsim grāmatošanas apstrādi dokumenta objekta modulī:

Dokumentu apstrādes apstrādes koda fragments

1C (kods)

Procedūra ApstrādeApstrāde(Failure, Processing Mode) // reģistrēt BasicAccruals of Movement.MainAccruals.Write = True; Movements.MainAccruals.Clear(); Reģistrācijas periods = mēneša sākums (datums); Katrai TechLineMainAccruals no MainAccruals cikla kustība = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Reģistrācijas periods; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Procedūras beigas

Apstrādes procedūra (kļūme, režīms)

// Galvenais uzkrājumu reģistrs

Kustības. Pamatuzkrājumi. rakstīt = patiess;

Kustības. Pamatuzkrājumi. Clear() ;

Reģistrācijas periods = mēneša sākums (datums) ;

Katram TechLine BasicAccrualsFrom BasicAccrualsCycle

Kustība = kustības. Pamatuzkrājumi. Pievienot() ;

Kustība. Storno= False;

Kustība. Aprēķina veids = TexLineMainUkrājumi. Aprēķina veids;

Kustība. PeriodActionStart = TechLineMainAccruals. Sākuma datums;

Kustība. ActionPeriodEnd=Beigu diena(TexLineMainAccruals.EndDate) ;

Kustība. Reģistrācijas periods = Reģistrācijas periods;

Kustība. Darbinieks = TechLineMainAccruals. Darbinieks;

Kustība. Diagramma = TechLineMainAccruals. Grafiks;

Kustība. Parametrs = TechStringMainAccruals. Izmērs;

EndCycle;

Procedūras beigas

Izveidosim testa dokumentu un palaidīsim to:

Dosimies uz “Dokumentu kustības”:

Redzam, ka reģistrācijas periods ir noteikts uz mēneša sākumu, jo RR biežums ir norādīts kā “Mēnesis”. Tāpat redzam, ka ir aizpildīti visi lauki, izņemot summu (alga vēl nav aprēķināta).

7. darbība.Rakstīsim algas aprēķina kodu.

Izveidosim vispārīgu moduli "Aprēķins" ar šādiem karodziņiem:

Pats aprēķins notiks šajā vispārīgajā modulī.

Modulī “Aprēķins” ierakstīsim eksportēšanas funkciju “Aprēķināt izmaksas”:

Tā kā RR iestatījumos “Pamatmaksas” aizpildījām laukus “Grafiks”, “Grafika vērtība”, “Grafika datums”, mums kļuva pieejama virtuālā aprēķinu reģistra tabula. DataGraphics, virtuālās tabulas vaicājumā mūs interesē šādi lauki:

“Faktiskā darbības perioda stundu skaits” — satur faktiski nostrādāto stundu skaitu, kas aprēķināts, pamatojoties uz grafika datiem

"Stundu skaits Darbības periods" - satur darba stundu skaitu, kas aprēķināts, pamatojoties uz grafika datiem aprēķina periodā

Algas aprēķināšanas kārtība

1C (kods)

Procedūra Aprēķināt uzkrājumus (reģistrators, ierakstu kopa) Eksportēt //Algas pieprasījums=Jauns pieprasījums; Query.Text="SELECT | ISNULL(PamatauzkrājumiGrafikasdati.Stundu skaitsFaktiskāsDarbībasPeriods, 0) AS StunduFakts, |PamataUzkrājumiGrafikasDati.Parametrs, |ISNULL(PamataUzkrājumiGrafikas dati,ASPAPlans ccrualsGraphicsData ica.Line Number |FROM |Aprēķins Reģistrs.Pamata uzkrājumi. Grafiskie dati (| Reģistrators = &Reģistrators | Un Aprēķina veids = &Aprēķinu veidsAlga) AS Pamata uzkrājumiDatiGrafika"; Request.SetParameter("Reģistrators", Ierakstītājs); // nodot dokumentu reģistratoram, lai meklēšana tiktu veikta tikai aktuālajā dokumentā Request.SetParameter("Aprēķinu veidsAlga", Aprēķinu veidu plāni. Pamatuzkrājumi. Alga); //iestatiet algas aprēķina veidu, jo aprēķināt algu Selection=Request.Run().Select(); SearchStructure=NewStructure; SearchStructure.Insert("RindasNumurs",0); //izveido struktūru datu meklēšanai aprēķiniem pēc rindas numura Katram ierakstam From RecordSet Cikls //pāriet cauri pašreizējā dokumenta ierakstu kopaiSearch Structure.LineNumber=Record.LineNumber; //aizpilda rindas numuru meklēšanai If Selection.FindNext(Search Structure) Tad //mēs paraugā meklējam datus aprēķiniem, pamatojoties uz pašreizējo rindas numuru Record.Sum =?(Selection.HoursPlan=0.0, Selection.HoursFact /Sample.HoursPlan * Sampling .Parameter); //aprēķināt algu proporcionāli nostrādātajām dienām, Parametrā - aktuālā alga EndIf; Selection.Reset(); //atiestatīt atlasi, mums ir nepieciešams nākamais ierakstu kopas ieraksts, lai meklētu atlasē pirmais EndCycle; Recordset.Write(, True); //ierakstīt aprēķinātos ierakstus datu bāzē, nodot parametru Replace = True EndProcedure

//Alga

Pieprasījums=Jauns pieprasījums;

Pieprasīt. Text = "ATLASĪT

| ISNULL(PamatauzkrājumiDatuGrafika.Stundu skaitsFaktiskaisDarbībasPeriods, 0) AS HoursFact,

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(PamatauzkrājumiDatuGrafika.Stundu skaitsDarbībasPeriods, 0) AS Stundu plāns,

| BasicAccrualsDataGraphics.NumberLines

|NO

| Aprēķinu reģistrs. Pamatuzkrājumi. Grafikas dati (

| Ierakstītājs = &Ierakstītājs

Labdien. Sen neesmu no jums dzirdējis :) Šodien vēlos noskaidrot ZUP 3.0 pārrēķinu iezīmes par pagājušajiem periodiem. Šajā rakstā ir runāts par to, kā tas darbojas iekšpusē, un attiecīgi jūs varat kontrolēt šo procesu. Galu galā, jūs, iespējams, esat saskāries ar faktu, ka programma personai negaidīti uzkrāj nezināmas summas, apvērš tās, parādās dažas atšķirības ... un jūs to nevēlējāties vai gribējāt. bet tas nenotika))

Sāksim. Pirmkārt, pārrēķini notiek brīdī, kad algu uzskatāt par “Algas” dokumentu. Šim nolūkam tiek nodrošināta cilne “Papildu uzkrājumi, pārrēķini”. Pirmā lieta, ko es vēlos jums ieteikt: vienmēr pārbaudiet datus uz etiķetes "Papildu uzkrājumi, pārrēķini" . Tie var parādīties tur bez jūsu ziņas, un jūs nesapratīsiet, kāpēc summa aprēķinā nav vienāda.

Teorētiski dokumenta galvenē vienmēr tiekam brīdināti, ka programma grasās kādu saskaitīt vai vajag to papildināt, jo... kāds netika ieskaitīts.

Kā programma zina, kas man ir jāskaita un par kuru mēnesi?

Viņa to nosaka, pamatojoties uz jūsu darbībām. Vai dokumentā norādījāt atpakaļejošu datumu? Raidījums aplūkoja darbiniekus, kuri bija šajā dokumentā, un ierakstīja viņu sarakstu. Vai veicāt labojumu dokumentā (piemēram, labojāt darba laika uzskaiti par iepriekšējo mēnesi)? Programma ir atcerējusies visus no šīs laika uzskaites uzskaites, un šis mēnesis tiks pārrēķināts. Tiek ietekmēti gandrīz visi dokumenti – gan personāla, gan algu saraksts. Šajā gadījumā programmai ir vienalga, vai jūsu pieskaršanās dokumentam ietekmēja jūsu algu vai nē.

Pieņemsim, ka jūs aizgājāt uz darba pieteikumu un uzrakstījāt tur komentāru, pēc kura jūs atkārtoti ievietojāt dokumentu. Ne algas, ne tikšanās datuma, ne amata... nekas netika aiztikts. Bet programma nezin kāpēc jūs pārrakstījāt iepriekšējā perioda dokumentu, tas nav telepāts, vienkārši ierakstīja šo darbinieku.

Otrais padoms (aka pirmais noslēpums): caur “visām funkcijām” dodieties uz informācijas reģistru “Algu pārrēķins”. Neesi slinks un kāp iekšā! Ieejiet tur pirms katra algas aprēķināšanas un pēc katra dokumenta ar atpakaļejošu datumu.

Daudzi grāmatveži šo padomu uztver kā tādu, ka viņiem ir jauns darbs, kura jau pietiek. Bet, ja jūs tur neuzkāpsiet, jūs nesapratīsit darba loģiku, un, ja programma jums ir kā melnā kaste, jūs ar to nesadraudzēsities. Draudzība sākas ar drauga iekšējās pasaules izpratni! Ja tev nerūp pretinieka iekšējā pasaule, viņš nav tavs draugs.

Tātad, vai esat iekāpis? Lieliski. Parasti tas ir tukšs un nav nevienas rindiņas, taču, tiklīdz kaut kam pieskarsities ar atpakaļejošu spēku, šeit parādīsies ieraksts, kurā būs norādīts darbinieks un mēnesis, kas jāpārrēķina.

Trešais padoms: ja nepiekrītat programmas nodomam saskaitīt darbinieku, izdzēsiet rindu no šī reģistra.

1. Vai jūs jau saprotat, kā parādās līnijas? Lieliski.

2. Aizpildot dokumentu “Algu saraksts” un grāmatojot pēc reģistra rindām, tiek veikts pārrēķins un tabulas aizpildīšana. "Papildu uzkrājumi, pārrēķini."

3. Pārrēķinātie darbinieki tiek izņemti no reģistra un tas paliek tukšs.

4. Atceļot “Algas” dokumentu, rindas tiek atgrieztas savās vietās, lai pēc atkārtotas aizpildīšanas viss nostātos savās vietās.

Ceturtais padoms (varbūt tas tiks labots): Pirms “Algas” dokumenta atkārtotas aizpildīšanas izklāj to!

Pamatojoties uz algoritmu, pēc dokumenta ievietošanas reģistrs tiek notīrīts. Ja jūs to uzpildīsit, to nenotīrot, programma nezinās, kas ir jāuzskaita, un tabulas daļa ar pārrēķiniem būs tukša. Tas attiecās uz 21. izlaidumu. Man vēl nav bijis laika to pārbaudīt 22. izdevumā.

Vēl viena nianse, ja dokumentā noklikšķināsiet uz personu saraksta pārrēķinam, tiks atvērta informācijas reģistra saraksta forma"Algu pārrēķins." Un būs arī poga, lai “dzēstu” vienu ierakstu.

P.S. (svarīgs)

Šīs izmeklēšanas iemesls bija nebeidzamie pārrēķini, pārsūtot sākotnējos datus no Grāmatvedības 3.0. Pārejas laikā jums būs jāpieskaras visiem paņēmieniem un tulkojumiem)) pēc tam izdzēsiet visu reģistra saturu " "Algas pārrēķins", pretējā gadījumā jūs saņemsiet visu pārrēķinu par visiem gadiem.Darba sākšana ZUP 3.0 ar datu pārsūtīšanu no Grāmatvedības 3.0

Tas notika demonstrācijas datu bāzē, kad viens darbs tika izpildīts atkārtoti. Un, pārsūtot 1C Accounting 3.0 uz 1C ZUP 3.0, jūs pārtaisīsit visu iespējamo:

Tas arī viss, jautājumi komentāros un nebaidieties no programmas, jums tas ir jāsaprot un tā jums par to ar mīlestību atmaksās.

Daudzi 1C programmētāji savā praksē nekad nav saskārušies ar komponentu “Aprēķins”, tāpēc, kad viņiem ir jākārto eksāmeni pie speciālista platformā 8.0, kur katrs uzdevums satur uzdevumu par sarežģītiem periodiskiem aprēķiniem, rodas grūtības, galvenokārt izpratnes grūtības.

Mēģināsim izdomāt šo komponentu 8.0 versijā. Tā vietā, lai risinātu dažādus aprēķinu uzdevumus, mēģināsim izprast šo komponentu, lai mēs varētu atrisināt jebkuru aprēķina uzdevumu. Izpētot šo rokasgrāmatu, jūs sapratīsit, kā tiek sakārtoti un darbojas aprēķinu reģistri.

Piemēram, mēs izmantosim eksāmenu laikā uzstādīto rāmja konfigurāciju.

Godīgi sakot, es ilgu laiku mēģināju izdomāt, kam vēl nepieciešami aprēķini, bet nevarēju izdomāt, tāpēc apskatīsim algu aprēķināšanas problēmu.

Kas ir aprēķini

Būtībā galīgais algas produkts ir algas reģistra ierakstu kopums šādā formā:

Darbinieks	Periods	Aprēķina veids	Rezultāts	Dati	Komentārs
Mērīšana	Oficiālā	Oficiālā			Rekvizīti

Vērtība ailē “Dati” atspoguļo darbinieka pamatalgu (saskaņā ar darba līgumu), bet šo summu var palielināt par piemaksām, samazināt ar naudas sodiem un darba kavējumiem u.c., tāpēc faktiskā izmaksājamā summa tiek ievadīta pēc aprēķinu kolonnā “Rezultāts”. Šis ir aprēķins. Ailē “Resurss” norādītā summa konkrētam darbiniekam ir viņam pienākošā alga.

Tādējādi aprēķinu reģistrs būtībā ir ierakstu kopums, kas pēc struktūras ir līdzīgs apgrozāmajam uzkrāšanas reģistram. Vienkārši, lai veiktu sarežģītus aprēķinus, tam tiek noteikti papildu iestatījumi, kas pēc tam ļauj izveidot daudzas virtuālās tabulas aprēķinu reģistram, lai gan būtībā šis reģistrs ir tikai attēlā norādīto ierakstu kopa.

Katrs ieraksts norēķinu reģistrā attiecas uz noteiktu norēķinu veidu un laika periodu.

Aprēķinu veidi

Katram aprēķina veidu ierakstam ir pakalpojuma atribūts - aprēķina veids.

Aprēķinu veidu var uzskatīt par īpašas atsauces grāmatas elementu, piemēram, “Aprēķinu veidu plāns” — tajā ir arī informācija, tabulas daļas, iepriekš noteikti un lietotāja izveidoti elementi. Sistēmā var būt vairāki šādi “direktoriji”.

Piemēram, izveidosim plānu aprēķinu veidiem Main un tajā iepriekš definētiem aprēķinu veidiem algu, bonuss, prombūtne, biznesa ceļojums.

Aprēķinu veidi tiek izmantoti funkcionāli, lai atspoguļotu aprēķinu reģistra ierakstu ietekmi viens uz otru. Bet īsumā viņi runā par aprēķinu veidu ietekmi viens uz otru:

Aprēķina veids	Apraksts	Piemērs
Pēc bāzes perioda	Atkarīgā perioda aprēķina rezultāts ir atkarīgs no bāzes perioda rezultāta. Ja mainās bāzes perioda rezultāts, ir jāpārrēķina atkarīgā perioda rezultāts.	Piemaksa ir atkarīga no bāzes perioda algas.
Tīrīšana pēc perioda	Atkarīgā perioda derīguma termiņš aizstāj bāzes perioda derīguma termiņu, tāpēc bāzes periodam ir faktiskais	Darba kavējumi ietekmē faktisko algas periodu.
Vadošie aprēķini	Aprēķins ir atkarīgs no vadošā aprēķina, bet ne tieši, bet netieši, t.i. aprēķins A ir atkarīgs no pamata aprēķina B, un aprēķins B ir atkarīgs no pamata aprēķina B, tāpēc A netieši ir atkarīgs no B, t.i. A ir atkarīgs no vadošā aprēķina B. Faktiski, mainoties aprēķinam C, var mainīties B un līdz ar to arī A. Sistēma automātiski neizseko šādas sarežģītas atkarības, tāpēc jānorāda, kuri aprēķini ir vadošie.	Piemaksa ir atkarīga no algas bāzes, bet netieši ir atkarīga arī no kavējumiem.

Šīs ietekmes dēļ norēķinu reģistra ieraksta derīguma termiņš ir sadalīts četros periodos:

Periods	Apraksts
Reģistrācijas periods	Kādā laika posmā notikums fiksēts, t.i. parasti, kad tiek ievadīts dokuments.
Derīgums	Kādā laika posmā pasākums darbojas, t.i. uz kādu periodu notikums pieder.
Bāzes periods	Nozīmīgs tikai periodiem, kuriem ir bāzes periods – raksturo bāzes perioda intervālu.
Faktiskais derīguma termiņš	Ja derīguma termiņu aizstāj citi aprēķinu veidi, tad faktiskais derīguma termiņš sastāv no vairākiem periodiem, kad šis aprēķinu veids faktiski ir spēkā.

Reģistrācijas periodu norāda viens skaitlis - perioda sākums, kas atbilst aprēķinu reģistra biežumam. Pat ja mēs šajā pakalpojuma laukā iestatīsim citu datumu, tas joprojām tiks aizstāts ar perioda sākumu. Atlikušos periodus norāda divi lauki - perioda sākums un beigas.Faktiskais derīguma termiņš ir periodu kopa, jo tas var sastāvēt no vairākiem datumu intervāliem.

Laika diagrammas

Sistēmai ir iespēja sasaistīt datus no aprēķinu reģistriem ar laika diagrammām, lai darba stundu skaitu varētu iegūt jebkuram periodam.

Laika skala ir vienkāršs informācijas reģistrs, kurā viena dimensija saglabā datumu, cita ir saistīta ar dimensiju, izmantojot aprēķinu reģistru, un viens no resursiem tiek izmantots laika izsekošanai.

Dimensija, kas kas saistīti ar aprēķinu reģistru parasti veic nozīmē "grafa veids".

datums	Diagrammas veids	Nozīme
11.01.05 Piekt	Piecas dienas
11.01.05 Piekt	Sešas dienas
12.01.05 sestdien	Piecas dienas
12.01.05 sestdien	Sešas dienas

Kāpēc izmantot datuma dimensiju, nevis periodisko detaļu reģistru? Viss ir ļoti vienkārši - ja piektdien, 11.janvārī, piecu dienu laikā mums ir 8 darba stundas, tas nenozīmē, ka nākamajā dienā mums atkal būs 8 darba stundas. Bet, ja mēs izmantotu periodisku reģistru, nākamās dienas vērtība tiktu ņemta no iepriekšējās dienas, ja ierakstu nebūtu.

Tādējādi ar noteiktu periodu (faktiskā darbība, reģistrācija, bāzes periods utt.) mēs varam automātiski iegūt stundu skaitu šim periodam atbilstoši grafikam.

Pārrēķins

Pārrēķins nedaudz atgādina secības robežu. Tā kā mums ir atkarīgie aprēķini, mainot to bāzes un vadošos aprēķinus, sistēmai kaut kā jāatzīmē, ka mums ir jāpārrēķina atkarīgie aprēķini.

Tam ir paredzēti pārrēķini.

Ja mēs aprēķinām bāzes ierakstus, sistēma piešķīrumos atzīmēs, ka mums ir jāaprēķina atkarīgie ieraksti. Kad mēs aprēķināsim atkarīgos ierakstus, piešķīrumi tiks notīrīti.

Būtībā pārrēķini ir aprēķinu reģistra ierakstu saraksts, kas ir jāpārrēķina.

Ja pārrēķinos neievadīsiet nekādus mērījumus, tad, mainoties pamata aprēķiniem, visi atkarīgie ieraksti tiks pievienoti pārrēķinu sarakstam.

Ja pārrēķinā veidojam dimensiju “Darbinieks”, tad, mainot pamataprēķinu darbiniekam, pārrēķiniem tiks pievienoti apgādājamie ieraksti tikai par šo darbinieku.

Praktisks uzdevums

Pietiek teorijas. Mēģināsim praktiski izpētīt detaļas. Par pamatu ņemsim rāmja konfigurāciju.

Problēmas formulējums:

Lai piemaksa tiek noteikta kā fiksēts procents no algas (atskaitot darba kavējumus un ceļa izdevumus).

Ļaujiet ceļa naudu izmaksāt dubultā algā + fiksēta maksājumu summa par katru ceļojuma dienu.

Ļaujiet darbiniekam iekasēt naudas sodu pusi algas apmērā par prombūtnes laiku par prombūtni.

Progress:

Sākotnējā apmācība

Izveidosim jaunu plānu aprēķinu veidiem “Galvenais”.

Definēsim aprēķinu veidus un atkarības starp tiem:

	Pamata	Izstumšana	Prezentētāji
Alga		Darba kavējumi, komandējums
Balva		Darba kavējumi, komandējums	Alga, Darba kavējumi, Komandējums
Biznesa ceļojums
Neierašanās

Pievienosim šos aprēķinu veidus aprēķinu tipu plānam “Galvenais” un iestatīsim aprēķinu tipu īpašību atkarības atbilstoši tabulai.

Algu aprēķina reģistrā izveidosim “Privātpersonu” tipa dimensiju “Darbinieks” - lai reģistrā būtu darbinieku analītiskā sadaļa.

Konfigurācijā jau ir dokuments “Algas saraksts”.

Tās galvenē ir divi datumi – “datums” un “reģistrācijas periods”, kā arī divi datumi “sākuma datums” un “beigu datums” katrā rindā.

Saprotams, ka datums ir vienkārši dokumenta noformēšanas datums, reģistrācijas periods norāda, par kuru mēnesi tiek skaitīta alga, un datumi katrā rindā raksturo katra aprēķina veida derīguma termiņu.

Dokumentu modulim pievienosim atribūta “Dati” sākotnējo iestatījumu - ievadīsim sākuma algu, nosakot reģistrācijas periodu, derīguma termiņu un bāzes periodu.

Dokumenta modulis izskatīsies apmēram šādi:

Priekš Katram TechStringList No saraksta cikla

// reģistrs Aprēķini

Kustība = kustības .Aprēķini.Pievienot();

Kustība .S torno= Nepatiesi;

Kustība .In idCalculation = TechStringList.CalculationType;

Kustība .PeriodActionsStart= Dienas sākums ( TechStringList.StartDate);

Kustība .PeriodActionEnd= Beigu diena();

Kustība .Reģistrācijas periods = Reģistrācijas periods;

Kustība .BasicPeriodStart= Dienas sākums ( TechStringList.StartDate);

Kustība .BasePeriodEnd= Beigu diena ( TechStringList.Beigu datums);

Kustība .Darbinieks = TechStringList.Employee;

Kustība .Grafiks = TechStringList.Graph;

Kustība .Rezultāts = 0;

Kustība .Dati = TechStringList.Size;

EndCycle ;

Atribūts Reversal ir nepieciešams, lai apgrieztu ierakstus (analoģiski mīnusa zīmei).

Mēs norādām aprēķina veidu un iestatām datumus uz dienas sākumu un beigām. Protams, bāzes periodu var ievadīt tikai no bāzes atkarīgiem aprēķinu veidiem, bet Datus var ievadīt tikai par algu, bet viss darbojas tā.

Visus dokumentus datēsim 20.01.2003, reģistrācijas periods tiks noteikts uz 01.02.2003 (konkrēti nenorādu sākuma un beigu datus, tam te nav nozīmes, vienalga, ierakstot Reģistrācijas periods pārrēķināts uz perioda sākumu 01/01/2003). Izmantojam 2003. gada janvāri, jo šim periodam tika noformēti darba grafiki.

Izveidosim pārrēķinu “Pārrēķins” un pievienosim tam dimensiju “Darbinieks”, kas saistīta ar dimensiju “Darbinieks”.

Spēlēšanās ar pārrēķiniem.

Lai spēlētu spēli, atveriet pieprasījumu konsoli - apstrāde " CustomRequest» rāmja konfigurācijā. Izveidosim jaunu vaicājumu, izmantojot vaicājumu konstruktoru un pievienosim tur virtuālo tabulu Pārrēķini, aprēķini, pārrēķini, pieprasījuma teksts būs šāds:

IZVĒLIES

AprēķiniPārrēķins.Par objektu Pārrēķins,

CalculationsRecalculation.In Aprēķina ID,

Aprēķini Pārrēķins No darbinieka

Aprēķinu reģistrs, aprēķini, pārrēķins KĀ AprēķiniPārrēķins

Ģenerēsim trīs dokumentus - vispirms uzkrāsim algas darbiniekiem A un B. Darbinieks A strādā no 1. līdz 31. janvārim, B strādā no 1. līdz 20. janvārim. Otrais darbiniekam B piešķirs piemaksu par laika posmu no 1. līdz 31.janvārim, trešais darbiniekam A piešķirs darba kavējumus no 20. līdz 25.janvārim.

Mēs spēlējam ar faktisko derīguma termiņu.

Izveidosim jaunu vaicājumu – šoreiz tam pievienosim tabulas datus Aprēķinu reģistri. Aprēķini. Faktiskais darbības periods.

Izveidosim pieprasījumu un skatīsimies, ka darbinieka A algas periods ir sadalīts divos periodos - no 1. līdz 19. janvārim un no 26. līdz 31. janvārim. Ceru, ka saprotat, ka periods tika sadalīts divās daļās, jo... darba kavējumi aizstāja algu.

Domāju, ka mūsu acu priekšā kļūst skaidrāki aprēķinu reģistra darbības mehānismi.

Izpētīsim grafikus.

Tagad mēģināsim aprēķināt algu, pamatojoties uz darbinieka algu.

Izveidosim jaunu vaicājumu aprēķinu reģistram, izmantojot virtuālo tabulu Aprēķinu reģistri. Aprēķini. DataGraphics. Šai virtuālajai tabulai var iestatīt parametru - piemēram, ierakstu atlases nosacījumu Darbinieks=&AtlasītDarbinieku Un Aprēķina veids=&Aprēķinu veids Un Graph=&ViewGraphic.

Pieprasījuma parametros iestatīsim konkrētus darbiniekus, aprēķinu veidus un grafikus un skatīsimies, cik stundu ir rezultāts.

Rezultātu kolonna	Nozīme
ValuePeriodAction	Uz kādu derīguma termiņu stundās bija ieraksts reģistrā.
ValueActualPeriodAction	Cik stundas darbinieks faktiski strādāja?
ValueBasePeriod	Par algu nav jēgas, par piemaksām - nostrādāto stundu skaitu bāzes periodā.
VērtībaReģistrācijas periods	Cik darba stundu ir reģistrācijas periodā (janvāris)

Pārrēķini ir algas aprēķina neatņemama sastāvdaļa. Informācija par darbinieku slimības atvaļinājumu, atvaļinājumiem vai darba kavējumiem, ko grāmatvedībā saņem ar zināmu kavēšanos, liek pārrēķināt algas un attiecīgi arī apdrošināšanas prēmijas. 1C eksperti stāsta par to, kā apdrošināšanas prēmiju aprēķini un pārrēķini tiek atspoguļoti grāmatvedībā un regulētajos pārskatos programmā 1C: Algas un personāla vadība 8, 3. izdevums.

Pārrēķinot darba samaksu, rodas nepieciešamība pārrēķināt apdrošināšanas prēmijas. Turklāt iemaksu pārrēķina iemesls var būt tarifa izmaiņas gada laikā vai kļūdu atklāšana, piemēram, aprēķina neiekļaušana apdrošināšanas prēmiju bāzē.

Šādos gadījumos grāmatvedim rodas jautājumi par nepieciešamību, pienākumu un tiesībām iesniegt atjaunināto informāciju Federālajam nodokļu dienestam.

Saskaņā ar Krievijas Federālā nodokļu dienesta 10.10.2016. rīkojuma Nr. ММВ-7-11/551@ Pielikumā Nr.2 Apdrošināšanas prēmiju aprēķina aizpildīšanas kārtības 1.2.punktu maksātājs ir pienākums veikt nepieciešamās izmaiņas Aprēķinos un iesniegt precizētu ziņojumu nodokļu administrācijai, ja ir nereģistrēta vai nepilnīga informācija, kā arī kļūdas, kuru dēļ maksājamo apdrošināšanas prēmiju apmērs ir novērtēts par zemu.

Lemjot, vai iesniegt precizētu aprēķinu, grāmatvedim ir jāatbild uz šādiem jautājumiem:

vai visa informācija tika atspoguļota;
vai ir pieļautas kļūdas un vai to dēļ maksājamo apdrošināšanas prēmiju apmērs tika novērtēts par zemu.

Atjaunota Aprēķina iesniegšana var būt pienākums, tiesības vai piespiedu nepieciešamība.

Atjaunots apdrošināšanas prēmiju aprēķins

Pienākums iesniegt precizētu aprēķinu rodas, ja pēc ziņojuma iesniegšanas Federālajā nodokļu dienestā atklājas, ka ir iesniegta nepilnīga vai nepareiza informācija par darbiniekiem vai ir atklātas kļūdas, kuru dēļ maksājamo apdrošināšanas prēmiju apmērs tika novērtēts par zemu.

Bieži sastopamo kļūdu veidi, kuru dēļ obligāti jāiesniedz atjaunināts aprēķins:

1. Darbinieks nekavējoties neziņoja par izmaiņām viņa personas datos, un Federālais nodokļu dienests sniedza nepatiesu informāciju par viņu Aprēķina 3. sadaļā.

2. Darbinieks strādāja nodaļā, kurai ir tiesības piemērot apdrošināšanas prēmiju atviegloto likmi. Pēc tam viņu pārcēla uz struktūrvienību, kurā tiek piemērota apdrošināšanas pamatmaksas likme. Informāciju par darbinieka pārcelšanu grāmatvedībā saņēma novēloti. Iemaksu aprēķins veikts nepareizi ar samazinātu likmi.

3. Programmas 1C: Alga un personāla vadība 8 sākotnējās iestatīšanas posmā tika pieļauta kļūda, izslēdzot prēmiju no apdrošināšanas prēmiju aprēķina bāzes. Izlabojot kļūdu, tiks iekasēta papildu maksa.

4. Nodaļa ar atvieglotu tarifu zaudē tiesības to izmantot, bet informācija pie algas menedžera nonāk ar kavēšanos. Pārrēķins pēc pamata tarifa noved pie maksājamo apdrošināšanas prēmiju apjoma palielināšanās.

5. Aprēķinot apdrošināšanas prēmijas, raidījums nenorādīja, ka amats ir iekļauts bīstamo profesiju sarakstā, uz kurām attiecas papildu tarifi. Pēc kļūdas atklāšanas un izlabošanas, pārrēķina rezultātā tika nesamaksātas apdrošināšanas prēmijas par papildu likmēm.

Apskatīsim apdrošināšanas prēmiju pārrēķināšanas iespējas “1C: Algas un personāla vadība 8” 3. izdevumā, izmantojot piemērus.

1. piemērs

Aprēķinot apdrošināšanas prēmijas nodaļai Krājumi tika piemērota atvieglota apdrošināšanas prēmiju likme Tehnoloģiju-inovāciju speciālās ekonomiskās zonas iedzīvotāji(cenas kods “05”). Šis tarifs paredz iemaksas Pensiju fondā 2018.gadā 13% apmērā; Sociālās apdrošināšanas fondā 2,9%; Federālajā obligātās medicīniskās apdrošināšanas fondā 5,1%. Tieši šādi tika aprēķinātas iemaksas darbiniekam V.S. Ivy. Ar ikmēneša ienākumiem 10 000 rubļu. Apdrošināšanas atskaitījumu summa mēnesī bija:

pensiju fondā - 1300 rubļu;
FFOMS - 510 rubļi;
Sociālās apdrošināšanas fondā - 290 rubļi.

Norādītās summas tika atspoguļotas apdrošināšanas prēmiju aprēķinā par 2018. gada pirmo ceturksni.

Kad izrādījās, ka nodaļa ir zaudējusi tiesības piemērot atviegloto likmi apdrošināšanas prēmijām, tad saskaņā ar Krievijas Federālā nodokļu dienesta 2017. gada 25. oktobra vēstulēm Nr. GD-4-11/21611@ un ministrijas Krievijas finanšu 2017. gada 18. decembra Nr.?03-15-06/ 84443 radās nepieciešamība iesniegt precizējošu Aprēķinu. Lai to veidotu, nepieciešams pārrēķināt apdrošināšanas prēmijas ar jaunām likmēm.

Kartē Divīzijas lauks ir jānotīra Preferenciālo tarifu bailes. iemaksas. Tagad nodaļai tiek piemērots organizācijai izmantotais un kartē norādītais tarifs Organizācijas uz grāmatzīmes Grāmatvedības politikas un citi iestatījumi saite Grāmatvedības politika laukā Tarifa veids.

1. piemērā organizācija ir iestatīta uz Apdrošināšanas pamatmaksas likme(tarifa kods “01”), paredzot iemaksu likmes 2018.gadā: Krievijas Federācijas pensiju fondā 22% apmērā; Sociālās apdrošināšanas fonds 2,9%; FFOMS 5,1%. Acīmredzami, ka Pensiju fonds ir “nepārmaksājis” 9% no iemaksām (22% - 13%), un ir mainījies tarifu kods.

Apskatāmajā 1. piemērā, lai pārrēķinātu iemaksas, būtu jāpārskata ienākumu uzskaites kārtība. Dokuments paredzēts, lai reģistrētu iepriekšējā perioda ienākumu uzskaites un apdrošināšanas prēmiju pārrēķina kārtību. (izvēlne Nodokļi un nodevas). Uz grāmatzīmes Informācija par ienākumiem ir nepieciešams manuāli noskaidrot visus darbinieku ienākumus. Tajā pašā laikā uz grāmatzīmes Paredzamās iemaksas Apdrošināšanas prēmijas tiks pārrēķinātas automātiski.

Darbinieka V.S. apdrošināšanas prēmiju pārrēķina rezultātā. Ivy ar ikmēneša ienākumiem 10 000 rubļu. Apdrošināšanas atskaitījumu summa mēnesī bija:

Krievijas pensiju fondā - 2200 rubļu;
Federālajā obligātās medicīniskās apdrošināšanas fondā un Sociālās apdrošināšanas fondā - summa nemainījās un bija attiecīgi 510 rubļu. un 290 rubļi.

Pēc apdrošināšanas prēmiju pārrēķina par pirmo ceturksni, jāsagatavo precizējošie Aprēķini. Izmantojot pakalpojumu 1C pārskati, nepieciešams izveidot jaunas atskaites par labojamajiem periodiem un par Titullapa norādīt Labojuma numurs(2. att.). Precizējumi skāra visus nodaļas darbiniekus, jo visiem bija mainījies tarifu kods. Līdz ar to 3. sadaļas aktualizētajā Aprēķinā tiek veidotas visiem nodaļas darbiniekiem. Citos gadījumos, kad atjaunināta Aprēķina veidošanu izraisa izmaiņas datos vai atsevišķu darbinieku uzkrājumi, 3. sadaļā tiek parādīti dati tikai par šiem darbiniekiem. Jebkurā gadījumā pārējās precizējošā aprēķina sadaļas ir aizpildītas ar pilnīgi jauniem datiem.

Rīsi. 2. Apdrošināšanas prēmiju precizējošā aprēķina titullapa par 2018.gada pirmo ceturksni

Tiesības iesniegt precizētu apdrošināšanas prēmiju aprēķinu

Apdrošinājuma ņēmēji var iesniegt inspekcijai precizētu Aprēķinu, ja konstatē kļūdas, kuru dēļ apdrošināšanas prēmiju apmērs ir pārvērtēts. Faktiski, veicot nākamo iemaksu aprēķinu kārtējā periodā, tiek veikts pārrēķins, un rezultāts tiek atspoguļots pārskatā par nākamo periodu. Situācijas opcijas, kas ļauj iesniegt atjauninātu aprēķinu:

1. Darbiniekam tika izmaksāta alga par visu nostrādāto mēnesi. Apdrošināšanas prēmiju aprēķins tika iesniegts Federālajā nodokļu dienestā, taču vēlāk izrādījās, ka darbinieks atrodas slimības atvaļinājumā vai atvaļinājumā par saviem līdzekļiem. Uzkrājums, kas nebija iekļauts prēmiju aprēķina bāzē, aizstāja uzkrājumu, uz kuru attiecas apdrošināšanas prēmijas, kā rezultātā radās prēmiju pārmaksa.

2. Jebkurš darbinieku uzkrājumu pārrēķins, kā rezultātā tiek pārrēķinātas apdrošināšanas prēmijas, lai tās samazinātu.

2. piemērs

Aprēķinot darba samaksu par jūniju darbiniekam S.S. Gorbunkovs tika apbalvots:

algas maksājums - 7500 rubļu;
komandējuma apmaksa (pamatojoties uz vidējo izpeļņu) par jūniju - 2500 rubļu.

Apdrošināšanas prēmijas aprēķinātas pēc bāzes likmes. Jūnijā iemaksas no S.S. algas. Gorbunkovs bija:

Krievijas pensiju fondā - 2200 rubļu;
FFOMS - 510 rubļi;
Sociālās apdrošināšanas fondā - 290 rubļi.

Šīs iemaksas ir veiktas un iekļautas 2018. gada pusgada kontā. Grāmatvedībā iesniegtais slimības atvaļinājums par periodu 25.06.2018-06.30.2018 nerada iemeslu precizēta Aprēķina veidošanai. Programmā reģistrēts dokuments Slimības atvaļinājums apvērš iepriekš uzkrāto ceļa izdevumu summu (3. att.).

Rīsi. 3. Ceļa izdevumu pārrēķins dokumentā “Slimības lapa”.

Slimības lapu organizācija saņēma jūlijā. Tā nav kļūda un neizraisa apdrošināšanas prēmiju nepietiekamu samaksu. Tā kā slimības atvaļinājumā uzkrātā summa nav apliekama ar apdrošināšanas iemaksām, radās iemaksu pārmaksa šādā apmērā:

Krievijas Federācijas pensiju fondā - 550 rubļi;
FFOMS - 127,50 rubļi;
Sociālās apdrošināšanas fondā - 72,50 rubļi.

Programmā Slimības atvaļinājums, reģistrēts 2018. gada jūlijs, ietekmē apdrošināšanas prēmiju aprēķinu kārtējā mēnesī, samazinot aprēķina bāzi.

Šādā situācijā nav juridisku prasību precizēta Aprēķina iesniegšanai. Visi pārrēķini notiek nākamajā periodā un tiek atspoguļoti nākamajos pārskatos. Bet tajā pašā laikā organizācijai ir tiesības precizēt pārskatu par pusgadu un paziņot Federālajam nodokļu dienestam par notikušo pārmaksu, iesniedzot precizējumu.

Tomēr pirms mēneša beigām nevajadzētu veikt pārsteidzīgus Aprēķina precizējumus. Galu galā visu mēnesi tiek reģistrēti dažādi dokumenti. Kādā brīdī dokuments Slimības atvaļinājums patiešām var apgriezt iepriekšējā mēneša ienākumus, un, pamatojoties uz mēneša algas aprēķina rezultātiem, citu dokumentu, piemēram, Algu un iemaksu aprēķins, veiks papildu uzkrājumus, kas pārsniedz iepriekšējā perioda apvērsuma ienākumus. Līdz ar to kārtējā mēneša ienākumi samazināsies par komandējuma apvērsuma summu, nepaliks mīnusi par iepriekšējo mēnesi un koriģējošajā pārskatā izmaiņas netiks rādītas.

Nepieciešamība iesniegt atjauninātu apdrošināšanas prēmiju aprēķinu

Vairākos gadījumos, neskatoties uz to, ka nav pienākuma iesniegt precizētu Aprēķinu, apdrošinājuma ņēmējam nav citas iespējas ziņot par savu prēmiju pārmaksu, izņemot precizējuma iesniegšanu:

1. Iemaksu pārrēķina rezultātā kārtējā periodā darbinieks saņem negatīvu summu. Pārskatu ar negatīvu summu nevar iesniegt Federālajam nodokļu dienestam. Tāpēc ir tikai viena izeja - ģenerēt atjauninātu pārskatu par iepriekšējo periodu.

2. Darbinieks strādāja bīstamu darbu. Apdrošināšanas prēmijas tika aprēķinātas pēc papildu likmes. Informācija par darbinieka pārcelšanu darbā normālos darba apstākļos grāmatvedībā saņemta novēloti. Pārrēķina rezultātā aprēķinātās iemaksas nav iespējams samazināt pēc papildlikmes, jo darbinieka uzkrājumi kārtējā periodā vairs netiek aplikti ar papildu likmi.

3. piemērs

Šajā gadījumā, atšķirībā no iepriekšējā 2. piemēra, negatīvā apdrošināšanas prēmiju summa, kas izriet no komandējuma atcelšanas, netiks kompensēta ar uzkrājumiem. Neskatoties uz to, ka citu darbinieku uzkrājumu dēļ apdrošināšanas prēmiju kopsumma būs pozitīva, 3.sadaļā darbiniekam paliks negatīvas vērtības, un tas ir nepieņemami. Un tāpēc grāmatvedim būs jāizveido dokuments Apdrošināšanas prēmiju pārrēķins, pārrēķiniet iemaksas par jūniju, izveidojiet un iesniedziet atjauninātu aprēķinu Federālajam nodokļu dienestam.

Programma 1C: Algas un personāla vadība 8 automatizē apdrošināšanas prēmiju pārrēķināšanas procesu. Izmantojot pakalpojumu 1C Pārskati Sākotnējie un precizējošie aprēķini apdrošināšanas prēmijām tiek ģenerēti automātiski. Tomēr lēmums par precizējošā aprēķina sagatavošanu paliek grāmatveža ziņā. Izanalizējis aprēķinus mainoša dokumenta reģistrēšanas sekas periodā, par kuru jau ir iesniegts pārskats, grāmatvedis vai nu pārrēķina apdrošināšanas prēmijas par iepriekšējo periodu, vai arī aprēķins notiek automātiski kārtējā mēnesī.

No redaktora. Rakstā lasiet par 1C:Enterprise 8 ieviesto mehānismu apdrošināšanas prēmiju aprēķina kontroles koeficientu pārbaudei, kurā ņemti vērā korekcijas aprēķinu dati.