1s preračunavanje. Ispravci i preračuni plaća. Pravo prvenstva prema roku valjanosti

Od ostalih - na primjer, bonus se može odrediti prema visini plaća za razdoblje. U tom slučaju je moguće da će se plaća promijeniti nakon obračuna bonusa. Prema zadanim postavkama, platforma ne kontrolira takve situacije. Ako programer smatra da je to potrebno pratiti, tada morate koristiti poseban podređeni objekt registra izračuna - Ponovni izračun:

Zapisi rekalkulacije pohranjuju se u posebnu tablicu. Oni ne jamče da je zavisni registar potrebno točno preračunati, ali služe kao signal takve potencijalne potrebe.

Općenito, unosi tablice ponovnog izračuna sadrže sljedeća polja:

• objekt rekalkulacije (evidencijski dokument čije podatke je potrebno rekalkulirati)
• tip obračuna - veza na tip obračuna iz Plana tipova obračuna definiranih za ovaj registar obračuna

Zapisi se mogu pohraniti detaljnije, u kontekstu jedne ili više dimenzija određenog obračunskog registra. Na primjer, matičar za plaće za cijeli odjel imao je stari datum; Štoviše, promjene su se odnosile samo na zaposlenika Ivanova. Dodavanje dimenzije zaposlenika u ponovni izračun omogućit će vam da to pratite. U ovom slučaju, dimenzija ponovnog izračuna mora biti povezana s dimenzijom registra izračuna:

Podaci iz tablice rekalkulacije generiraju se automatski ako pripadajući plan tipa obračuna ima postavljeno svojstvo Osnovno razdoblje. Ako svojstvo nije postavljeno, programer je odgovoran za generiranje zapisa.

Pitanje 14.41 ispita 1C: Platforma Professional. Podaci o ponovnom izračunu...

1. nisu unosi u registar obračuna
2. su unosi registra obračuna
3. su upisi u registar rekalkulacije
4. su zapisi stvarne tablice razdoblja valjanosti

Točan odgovor je prvi, uglavnom se pohranjuju u zasebne tablice.

Pitanje 14.42 ispita 1C: Platforma Professional. U prozoru svojstava dimenzije "Rekalkulacija", na kartici "Komunikacija", u svojstvu "Registriraj dimenziju", označite...

1. mjerenje osnovnog registra, kada se podaci mijenjaju, tekući zapis registra mora se ponovno izračunati
2. mjerenje tekućeg registra, čije unose treba preračunati kada se promijene podaci baznih registara
3. mjerenja baznih registara, kod kojih se podaci mijenjaju, trenutni zapis registra mora se ponovno izračunati

Točan odgovor je drugi. Sam rekalkulacija je potrebna kako bi se pratila potreba ažuriranja upisa u tekućem očevidniku.

Pitanje 14.43 ispita 1C: Platforma Professional. Tablica "Rekalkulacija" ispunjena je redovima od kojih svaki predstavlja...

1. skup podataka o vrsti obračuna i dokumentu-zapisniku upisa u registar obračuna koji je potrebno preračunati. Tablica će sadržavati i rekalkulacijske mjere
2. skup podataka o vrsti obračuna i dokumentu-upisniku obračunskog očevidnika koji je potrebno preračunati.
3. skup podataka o vrsti obračuna, broju retka upisničkog dokumenta i samom upisniku obračunskog upisnika koji je potrebno preračunati. Tablica će sadržavati i rekalkulacijske mjere
4. nema točnih odgovora

Prvi odgovor je točan, analiza gore.

Pitanje 14.45 ispita 1C: Platforma Professional. Izaberi točan odgovor:

1. U procesu rada s ponovnim izračunima, programer može "ignorirati" informacije koje sustav daje u tablici za ponovni izračun, odnosno odbiti revidirati rezultate izračuna
2. Načelo rada ponovnih izračuna u sustavu 1C:Enterprise 8 je "obavještavanje"
3. Programer konfiguracije ne može kontrolirati proces preračunavanja unosa u registar naselja, sustav radi sve automatski
4. Tvrdnje 1 i 2 su točne

Četvrti točan odgovor je da se rekalkulacijom samo prati potencijalna potreba za promjenom zavisnih podataka.

Pitanje 14.46 ispita 1C: Platforma Professional. Za jedan obračunski registar...

1. Može biti podržan samo jedan ponovni izračun
2. Mogu se podržati samo tri dodjele različitih struktura
3. Podržan je bilo koji broj ponovnih izračuna različitih struktura

Točan odgovor je treći, nema problema dodati bilo koji broj podređenih objekata Rekalkulacije u registar kalkulacija, njihova struktura se ni na koji način ne kontrolira.

Pitanje 14.57 ispita 1C: Platforma Professional. Učestalost obračuna je mjesečna. Odgovarajuće postavke su napravljene u registru izračuna. Za vrstu obračuna plaće navedena je vrsta obračuna izleta kao deformacijska vrsta obračuna. Dana 01.03.14. podaci o plaći su uneseni u informacijsku bazu, ali nije izvršen obračun. Dana 20.03.14. službeni put je unesen u informacijsku bazu i obračunat. Dana 30.03.14. pokrenut je obračun plaća. Hoće li se podaci o službenom putu uzimati u obzir pri obračunu plaće? Trebam li preračunati službeni put?

1. Bit će uzeto u obzir, ali će se službeni put morati ponovno izračunati
2. Bit će uzeto u obzir, nije potrebno ponovno izračunavanje putovanja
3. Neće se uzeti u obzir. Potrebno je stornirati obračun puta i ponovno izračunati obje vrste obračuna
4. Neće se uzeti u obzir. Da bi obračun bio točan, plaća i službeni put moraju biti u jednom dokumentu

Preračun nije potreban, evidencija službenog puta je unutar mjeseca.

U ovom ćemo članku razmotriti teorijske osnove rada s registrima obračuna, a također ćemo izračunati plaću zaposlenika proporcionalno broju odrađenih sati.

Teorija

Registar izračuna (RR)- konfiguracijski objekt metapodataka koji se koristi za implementaciju periodičnih izračuna u sustavu 1C. Očigledna područja primjene registara obračuna uključuju sljedeće: obračun plaća, obračun najamnine, obračun najamnine.

Po svojoj su strukturi obračunski registri slični akumulacijskim ili informacijskim registrima. Oni, kao i akumulacijski registri, imaju mjere, sredstva, detalje, ali je princip rada obračunskih registara potpuno drugačiji.

U svojoj srži, mjerenja u registru akumulacije služe kao " filtar» u sklopu kojeg dobivamo podatke iz registra akumulacija. Kao primjer, kada uzmemo „ostatke“ prema akumulacijskom očevidniku „Preostala roba“ u kontekstu određenog artikla ili „odsječak najnovijeg“ prema informacijskom registru „Plaće zaposlenika“ u kontekstu određenog zaposlenika . Za razliku od akumulacijskog registra, mjerenja u periodičnom obračunskom registru služe za implementaciju ““(to je kada se tipovi vremenski produljenih obračuna međusobno natječu u intervalu valjanosti zapisa, tj. npr. obračun službenog puta tip istiskuje tip obračuna plaće za razdoblje valjanosti) i ““(ovo je kada tip obračuna bonusa ovisi o tipu obračuna plaće za prethodna razdoblja).

mehanizam potiskivanja prema razdoblju djelovanja«:

Ovdje vidimo da tip obračuna “Službeni put” ima vremensko trajanje i vrijedi od 10. travnja do 20. travnja, “Službeni put” je naznačen kao istiskivajući tip obračuna za tip obračuna “Plaća”. “Plaća” se također proteže kroz vrijeme i vrijedi od 1. travnja do 30. travnja. Budući da je kod vrste obračuna “Plaća” kao zamjenska vrsta obračuna navedena “Službeni put” (ima veći prioritet od plaće) i vrijedi za razdoblje važenja plaće, onda je plaća zamijenjena službenim putovanjem i formira se “Stvarno razdoblje važenja plaće.” Stvarno razdoblje važenja plaće “Ovo je razdoblje važenja plaće nakon premještanja službenim putovanjem, kod nas se sastoji od 2 razdoblja - od 01.04. do 9. i od 21. do 30. travnja i ukupno je 19 dana. Mehanizam pomaka temeljen na razdoblju radi samo za dugoročne izračune.

Gornja slika grafički prikazuje princip " mehanizam ovisnosti po baznom razdoblju«:

Recimo da krajem travnja 2017. želimo zaposleniku dati bonus u iznosu od 10% njegove plaće. Kao osnovni oblik obračuna bonusa navedena je plaća.

No, kao “bazu” za izračun premije nećemo uzeti cijeli mjesec travanj, već samo interval od 10. travnja do 20. travnja (11 dana). Izračunajmo osnovicu za bonus, plaća zaposlenika je 60.000 rubalja, mjesec ima 30 dana, dnevna plaća = 60.000/30 = 2.000 rubalja. Sljedećih 2000 * 11 = 22000 rub. Osnova za izračun premije je 22.000 rubalja.

Izračunajmo premiju: (22000/100)*10 = 2200 rubalja. Bonus od 10% plaće iznosi 2200 rubalja.

Objekt metapodataka aplikacije “Plan tipova izračuna” usko je povezan s registrom izračuna.

Plan obračunskih vrsta (PVR)- konfiguracijski objekt metapodataka koji pohranjuje informacije o vrstama vrsta izračuna i određuje utjecaj različitih izračuna jednih na druge.

Jedan obračunski tip plana može se koristiti u više obračunskih registara, ali jedan obračunski registar ne može istovremeno koristiti više obračunskih tipova.

Registar obračuna je tablica u kojoj se pohranjuju izračunati podaci, a prema vrstama izračuna pohranjuju se algoritmi za izračun tih podataka. Registar obračuna mora imati najmanje jedan registrator dokumenata koji vrši kretanja u registru obračuna (npr. Obračun plaća).

Mehanizmi obračuna u sustavu 1C Enterprise osmišljeni su na način da je potrebno prvo izvršiti unose u registar obračuna, a tek onda izvršiti obračun na temelju tih podataka. Na primjer, nemoguće je obračunati bonus na osnovu plaće dok se ta ista plaća ne evidentira u registru obračuna.

Praksa

Pogledajmo pobliže registre izračuna u praksi:

Korak 1 Počnimo s planom za vrste izračuna. Morate izraditi plan vrste izračuna prije kreiranja registra izračuna. Plan vrsta obračuna izrađujemo prije registra obračuna jer je prije izrade tablice za pohranjivanje izračunatih podataka (tj. registra obračuna) potrebno zadati algoritme za izračun tih podataka (tj. plana obračunskih tipova).

Izradimo plan za vrste obračuna "Osnovni troškovi". Idemo odmah na karticu "Izračun". Ovdje odmah vidimo zastavu " Koristi razdoblje valjanosti", kada je ova zastavica postavljena, sve vrste izračuna uključene u ovaj plan će imati duljina u vremenu(npr. Plaća, Službeni put), a također i za ovaj plan vrsta obračuna, “ mehanizam potiskivanja prema razdoblju djelovanja". Ako oznaka "Koristi razdoblje valjanosti" nije postavljena, tada vrste izračuna neće imati produženje vremena (na primjer, Bonus, Fine) i "mehanizam pomaka prema razdoblju valjanosti" neće raditi. Također na ovoj kartici postoje odjeljci "Ovisnost o bazi" i "Osnovni planovi za vrste izračuna" - služe za implementaciju " mehanizam ovisnosti po baznom razdoblju“, ali o tome ćemo kasnije. Za sada ostavimo "Ovisnost o bazi" u "Nezavisnom" modu.

Kreirajmo unaprijed definiranu vrstu obračuna "Plaća". Na kartici "Osnovno" sve je jednostavno. Postavite naziv i šifru vrste obračuna.

Zahvaljujući tome što smo postavili zastavu" Koristi razdoblje valjanosti"Sada imamo karticu" Istiskujući"i uključio" mehanizam potiskivanja temeljen na razdoblju«.

Na ovoj kartici označavamo vrste obračuna koji će istisnuti plaću po roku valjanosti (npr. Službeno putovanje).

Bilješka: u “Premještanje” možete dodati tipove obračuna koji pripadaju samo ovom planu tipova obračuna.

Tu je i kartica " Prezenteri»—označuje tipove izračuna koji, kada se promijene, moraju ponovno izračunati trenutnu vrstu izračuna. Ovdje također možete specificirati tipove obračuna iz drugih planova tipa obračuna. Na primjer, tip obračuna “Plaća” je vodeći za tip obračuna “Bonus”, tj. Kad se promijeni plaća, moramo preračunati i bonus jer Bonus se obračunava ovisno o plaći. U ovom slučaju tip obračuna “Plaća” pripada PRP-u “Osnovna obračunska razdoblja” koji koristi rok valjanosti, a tip obračuna “Bonus” pripada PRP-u “Dodatna obračunska razdoblja” koji ne koristi rok valjanosti.

Korak 2.Stvorimo direktorij “Charts” sa zadanom strukturom. U direktoriju “Rasporedi” pohranit ćemo radno vrijeme zaposlenika (petodnevno, šestodnevno itd.).

3. korak.Potreban nam je i objekt u koji ćemo pohraniti Proizvodni kalendar (radnim danima i vikendima). U te svrhe koristimo neperiodični neovisni registar informacija.

Kreirajmo neperiodični neovisni registar informacija "Rasporedi rada" s 2 dimenzije "Datum" i "Raspored" i resursom "Broj sati".

Zahvaljujući informatičkom registru „Rasporedi rada“ iz plaće ćemo moći obračunavati plaće proporcionalno broju odrađenih dana.

Korak 4.Stvorite dokument "Platne liste" sa strukturom detalja prikazanom u nastavku:

Zahtjevi:

Operativno izvršenje je postavljeno na "Zabrani" jer nema smisla za mehanizam periodičnih nagodbi u 1C - nikada ne izračunavamo bonuse, plaće ili novčane kazne u stvarnom vremenu.

Kreirajmo obrazac dokumenta sa zadanim postavkama.

Korak 5. Konačno smo došli do točke stvaranja registara izračuna.

Objekt metapodataka registra izračuna nalazi se u grani konfiguratora “Registri izračuna”.

Kreirajmo registar obračuna "Osnovni troškovi". Pogledajmo postavke registra izračuna u nastavku:

1. U polju “Plan vrsta obračuna” označite PVR “Osnovne naknade” kreirane u 1. koraku.

2. Postavite oznaku “Validity period” na “True” jer PVR naveden u koraku 1 ima produženje u vremenu.

Nakon postavljanja ove zastavice odmah nam postaju dostupni standardni detalji “Action Period”, “Action PeriodStart”, “ActionPeriodEnd”, što znači da vrste kalkulacija registrirane u ovom registru kalkulacija također imaju duljina u vremenu i imamo pristup " mehanizam potiskivanja prema razdoblju djelovanja«.

p.s. Ako navedete PVR koji ima duljina u vremenu za RR s oznakom "Validity Period" postavljenom na "False", tada će ovaj PVR raditi kao PVR koji nema produženje u vremenu.

3. Nakon postavljanja zastavice "Validity period" na "True", polja "Chart", "Chart value", "Chart date" postaju nam dostupna.

U polju "Raspored" označavamo registar informacija "Rasporedi rada" kreiran u koraku 3.

U polju "Vrijednost rasporeda" označavamo resurs "Broj sati" u registru informacija "Rasporedi rada".

U polju “Datum rasporeda” označavamo dimenziju “Datum” registra informacija “Rasporedi rada”.

4. U polju „Učestalost“ označavamo vrijednost „Mjesec“, što znači da će se podaci u registar unositi mjesečno.

Ispod je struktura metapodataka registra:

Oznaka "Osnovno" za dimenziju utječe samo na izvedbu; ne morate je postaviti, ali ako to učinite, polje "Zaposlenik" bit će indeksirano.

Dimenzija "Zaposlenik" - koristi se u " mehanizam potiskivanja koji se temelji na razdoblju djelovanja"I" mehanizam ovisnosti o baznom razdoblju«.

Resurs “Iznos” - tamo će biti evidentirana obračunata plaća.

Atribut “Chart” je označen kao atribut, a ne dimenzija registra, jer niti ono niti ono ništa istiskuje – u biti referentno polje. Važno!!! Ne zaboravite ispuniti polje "Veza rasporeda". kod atributa „Raspored“ mora biti naznačena dimenzija „Raspored“ informatičkog registra „Rasporedi“, u suprotnom iznos plaće neće biti obračunat.

Atribut “Parametar” će pohraniti vrijednost plaće.

Sada kada smo naznačili vezu s MS „Rasporedi rada“, obračunat ćemo plaću zaposlenika proporcionalno broju odrađenih dana.

Dokument označavamo kao matičar " Platni spisak" stvoreno u koraku 4.

Korak 6. Kretanja vršimo prema obračunskom registru “Osnovni troškovi”.

Vratimo se na dokument “Platne liste” kreiran u koraku 4.

Opišimo obradu knjiženja u modulu objekta dokumenta:

Fragment koda obrade obrade dokumenata

1C (šifra)

Procedura ProcessingProcessing(Failure, Processing Mode) // registracija BasicAccruals of Movement.MainAccruals.Write = True; Kretanja.Glavna razgraničenja.Clear(); Razdoblje registracije = početak mjeseca (datum); Za svaki TechLineMainAccruals iz ciklusa MainAccruals Kretanje = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Razdoblje registracije; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Kraj postupka

ProcessingProcedure(Greška, Način) // Glavni registar vremenskih razgraničenja Pokreti. Osnovna razgraničenja. pisati = istina; Pokreti. Osnovna razgraničenja. Čisto() ; Razdoblje registracije = početak mjeseca (datum); Za svaki TechLine BasicAccrualsFrom BasicAccrualsCycle Kretanje = Kretanja. Osnovna razgraničenja. Dodati() ; Pokret. Storno= Netočno; Pokret. Vrsta izračuna=TexLineMainAccruals. Vrsta izračuna; Pokret. PeriodActionStart = TechLineMainAccruals. Početni datum; Pokret. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ; Pokret. Registration Period = Period registracije; Pokret. Zaposlenik = TechLineMainAccruals. Zaposlenik; Pokret. Grafikon = TechLineMainAccruals. Raspored; Pokret. Parametar = TechStringMainAccruals. Veličina; EndCycle; Kraj postupka

Kreirajmo testni dokument i pokrenimo ga:

Idemo na "Kretanje dokumenata":

Vidimo da je rok registracije postavljen na početak mjeseca jer Učestalost RR označena je kao "mjesec". Također vidimo da su popunjena sva polja osim iznosa (plaća još nije obračunata).

Korak 7.Idemo napisati šifru obračuna plaća.

Kreirajmo opći modul "Izračun" sa sljedećim oznakama:

Sam izračun odvijat će se u ovom općem modulu.

Napišimo funkciju izvoza "Izračunaj troškove" u modulu "Izračun":

Budući da smo u postavkama RR „Osnovni troškovi“ ispunili polja „Raspored“, „Vrijednost rasporeda“, „Datum rasporeda“, postala nam je dostupna virtualna tablica registra obračuna. DataGraphics, u upitu za virtualnu tablicu zanimaju nas sljedeća polja:

“Broj sati stvarnog razdoblja radnje” — sadrži broj stvarno odrađenih sati izračunat na temelju podataka rasporeda

"Broj sati Razdoblje akcije" - sadrži broj radnih sati izračunat na temelju podataka rasporeda u obračunskom razdoblju

Postupak obračuna plaća

1C (šifra)

Procedura CalculateAccruals(Matičar, Set of Records) Export //Zahtjev za plaću=Novi zahtjev; Query.Text="SELECT | ISNULL(OsnovniAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData.NumberofHoursActionPeriod, 0) AS HoursPlan, |OsnovniAccrualsG raphicsData ica.Broj reda |FROM |Registar obračuna.Osnovna razgraničenja. Grafički podaci(| Registrar = &Registrar | And Calculation Type = &Calculation TypeSalary) AS Basic AccrualsDataGraphics"; Request.SetParameter("Registrator", Snimač); // proslijediti dokument matičaru tako da se pretraga vrši samo na trenutnom dokumentu Request.SetParameter("Obračun VrstaPlaća", Planovi obračunskih vrsta. Osnovna razgraničenja. Plaća); //postavite vrstu obračuna plaće jer izračunajte plaću Selection=Request.Run().Select(); SearchStructure=Nova struktura; Struktura pretraživanja.Umetni("Broj reda",0); //stvori strukturu za pretraživanje podataka za izračun po broju retka za svaki zapis iz RecordSet ciklusa //kruži kroz skup zapisa trenutnog dokumentaSearch Structure.LineNumber=Record.LineNumber; //ispunite broj retka za pretraživanje If Selection.FindNext(Search Structure) Zatim //tražimo u uzorku podatke za izračun na temelju trenutnog broja retka Record.Sum =?(Selection.HoursPlan=0.0, Sampling.HoursFact /Sample.HoursPlan * Sampling .Parameter); //izračunaj plaću proporcionalno odrađenim danima, u Parametru - trenutna plaća EndIf; Odabir.Reset(); //poništavanje odabira, trebamo sljedeći zapis skupa zapisa za pretraživanje kroz odabir prvi EndCycle; Recordset.Write(, True); //zapišite izračunate zapise u bazu podataka, proslijedite parametar Replace = True EndProcedure

//Plaća Zahtjev=Novi zahtjev; Zahtjev. Text="SELECT | ISNULL(BasicAccrualsDataGraphics.NumberofHoursActualActionPeriod, 0) AS HoursFact, | BasicAccrualsDataGraphics.Parameter, | ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS Plan sati, | BasicAccrualsDataGraphics.NumberLines |OD | Registar obračuna Osnovna razgraničenja Grafički podaci ( | Snimač = &Snimač

Dobar dan. Dugo vas nisam čuo :) Danas želim razjasniti značajke rekalkulacija u ZUP-u 3.0 za prošla razdoblja. Ovaj članak govori o tome kako to radi iznutra i, sukladno tome, možete kontrolirati ovaj proces. Uostalom, vjerojatno ste se susreli s činjenicom da nekome program neočekivano prikupi nepoznate iznose, stornira ih, pojave se neke razlike... a vi to niste htjeli, ili htjeli. ali to se nije dogodilo))

Započnimo. Prvo, ponovni izračuni se događaju u trenutku kada plaću smatrate dokumentom "Payroll". U tu svrhu osigurava karticu „Dodatna razgraničenja, preračuni“. Prvo što vam želim savjetovati: uvijek provjerite podatke na etiketi "Dodatna razgraničenja, preračuni" . Mogu se tamo pojaviti bez vašeg znanja i nećete razumjeti zašto iznos u izračunu nije isti.

U teoriji, u zaglavlju dokumenta uvijek smo upozoreni da će program nekoga prebrojati ili da ga trebamo ponovno napuniti, jer... netko nije ubrojen.

Kako program zna koga trebam računati i za koji mjesec?

Ona to određuje na temelju vaših postupaka. Jeste li unatrag datirali dokument? Program je pogledao zaposlenike koji su bili u ovom dokumentu i zabilježio njihov popis. Jeste li ispravili dokument (na primjer, ispravili vremenski list za prošli mjesec)? Program je zapamtio sve iz ovog vremenskog lista i ovaj će se mjesec ponovno izračunati. Utječu na gotovo sve dokumente, i kadrovske i platne liste. U ovom slučaju, program ne mari je li vaše dodirivanje dokumenta utjecalo na vašu plaću ili ne.

Recimo da ste otišli na molbu za posao i tamo napisali komentar, nakon čega ste ponovno objavili dokument. Bez plaće, bez datuma imenovanja, bez pozicije... ništa se nije diralo. Ali program ne zna zašto ste prebrisali dokument iz prethodnog razdoblja, nije telepat, jednostavno je snimio ovog zaposlenika.

Drugi savjet (odnosno prva tajna): kroz “sve funkcije” idite na registar podataka “Preračun plaće”. Ne budite lijeni i popnite se! Uđite prije svakog obračuna plaće i nakon svakog dokumenta sa starim datumom.

Mnogi računovođe ovaj savjet doživljavaju kao da imaju novi posao, kojeg već imaju dovoljno. Ali ako se tamo ne popnete, nećete razumjeti logiku rada, a ako je program za vas poput crne kutije, onda se s njim nećete sprijateljiti. Prijateljstvo počinje razumijevanjem unutarnjeg svijeta prijatelja! Ako vam nije stalo do unutarnjeg svijeta vašeg protivnika, onda vam on nije prijatelj.

Dakle, jeste li se popeli? Sjajno. U pravilu je prazan i nema niti jednog retka, ali čim retroaktivno nešto dotaknete, ovdje će se pojaviti zapis u kojem je zaposlenik i mjesec koji treba preračunati.

Treći savjet: ako se ne slažete s namjerom programa da broji zaposlenika, izbrišite redak iz ovog registra.

1. Razumijete li već kako se crte pojavljuju? Sjajno.

2. Prilikom popunjavanja dokumenta „Plaća“ i knjiženja na temelju redova u očevidniku vrši se preračun i popunjavanje tablice. "Dodatna razgraničenja, preračuni."

3. Preračunati radnici brišu se iz očevidnika i isti postaje prazan.

4. Kada poništite dokument “Plaća”, linije se vraćaju na svoje mjesto tako da kada ih ponovno popunite, sve će doći na svoje mjesto.

Četvrti savjet (možda će se ovo popraviti): Prije popunjavanja dokumenta “Plaća” raširite ga!

Na temelju algoritma, nakon knjiženja dokumenta, vrši se brisanje registra. Ako ga ponovno napunite bez brisanja, program neće znati koga treba prebrojati, a tablični dio s ponovnim izračunima bit će prazan. To je vrijedilo za izdanje 21. Još nisam imao vremena provjeriti u 22. izdanju.

Još jedna nijansa, ako kliknete na popis ljudi za ponovni izračun u dokumentu, otvorit će se obrazac s popisom registra informacija"Preračun plaća." Također će postojati gumb za "brisanje" jednog unosa.

p.s. (važno)

Razlog ove istrage bila su beskrajna preračunavanja prilikom prijenosa izvornih podataka iz Računovodstva 3.0. Tijekom prijelaza morat ćete dodirnuti sve tehnike i prijevode)) nakon toga obrišite sav sadržaj registra " "Preračun plaće", inače ćete dobiti preračun svega za sve godine Početak rada u ZUP 3.0 s prijenosom podataka iz Računovodstva 3.0

Ovo se dogodilo u demo bazi podataka kada je jedan posao ponovno izvršen. A kada 1C Računovodstvo 3.0 prebacite u 1C ZUP 3.0, ponovit ćete sve što je moguće:

To je sve, pitanja u komentarima i ne bojte se programa, morate ga razumjeti i on će vam za to uzvratiti s ljubavlju.

Mnogi 1C programeri nikada se u svojoj praksi nisu susreli s komponentom "Izračun", stoga, kada moraju polagati ispite za specijalista na platformi 8.0, gdje svaki zadatak sadrži zadatak o složenim periodičkim izračunima, pojavljuju se poteškoće, prvenstveno poteškoće s razumijevanjem.

Pokušajmo shvatiti ovu komponentu u 8.0. Umjesto rješavanja raznih računskih problema, pokušajmo razumjeti ovu komponentu kako bismo mogli riješiti bilo koji računski problem. Nakon proučavanja ovog priručnika, razumjet ćete kako su računski registri uređeni i rade.

Na primjer, koristit ćemo konfiguraciju okvira instaliranu tijekom ispita.

Da budem iskren, dugo sam pokušavao shvatiti za što su još potrebni izračuni, ali nisam uspio shvatiti, pa razmislimo o problemu obračuna plaća.

Što su kalkulacije

U osnovi, konačni proizvod obračuna plaća skup je unosa u registar plaća u obliku:

Zaposlenik	Razdoblje	Vrsta izračuna	Proizlaziti	Podaci	Komentar
Mjerenje	Službeno	Službeno			Rekviziti

Vrijednost u stupcu “Podaci” odražava osnovnu plaću zaposlenika (prema ugovoru o radu), ali ovaj iznos se može povećati za bonuse, smanjiti za novčane kazne i izostanke, itd., stoga se stvarni iznos za isplatu upisuje nakon izračun u stupcu "Rezultat". Ovo je računica. Iznos u stupcu "Resursi" za određenog zaposlenika je plaća koja mu pripada.

Dakle, registar obračuna je u biti skup zapisa, po strukturi sličan ugovornom registru akumulacije. Radi se samo o tome da su za izvođenje složenih izračuna navedene dodatne postavke, koje vam zatim omogućuju izradu mnogih virtualnih tablica za registar izračuna, iako je, u biti, ovaj registar samo skup zapisa prikazanih na slici.

Svaki upis u registar naselja odnosi se na određenu vrstu naselja i vremensko razdoblje.

Vrste kalkulacija

Svaki zapis tipova obračuna ima servisni atribut - tip obračuna.

Vrsta kalkulacije može se smatrati elementom posebne referentne knjige kao što je „Plan vrsta kalkulacija” - također ima detalje, tabelarne dijelove, predefinirane i korisničke elemente. U sustavu može postojati nekoliko takvih "imenika".

Na primjer, napravimo plan za tipove izračuna Glavni i u njemu predefinirane vrste izračuna plaća, bonus, odsutnost, Poslovni put.

Vrste izračuna koriste se funkcionalno za odražavanje utjecaja unosa registra izračuna jednih na druge. Ali ukratko govore o međusobnom utjecaju vrsta izračuna:

Vrsta izračuna	Opis	Primjer
Po baznom razdoblju	Rezultat izračuna ovisnog razdoblja ovisi o rezultatu baznog razdoblja. Ako se rezultat baznog razdoblja promijeni, mora se ponovno izračunati rezultat ovisnog razdoblja.	Bonus ovisi o plaći u osnovnom razdoblju.
Brisanje po mjesečnici	Razdoblje valjanosti ovisnog razdoblja zamjenjuje razdoblje valjanosti osnovnog razdoblja, tako da osnovno razdoblje ima stvarni	Izostanak s posla utječe na stvarno razdoblje plaće.
Vodeći izračuni	Obračun ovisi o vodećem obračunu, ali ne izravno nego neizravno, tj. kalkulacija A ovisi o osnovnoj kalkulaciji B, a kalkulacija B ovisi o osnovnoj kalkulaciji B, dakle A neizravno ovisi o B, tj. A ovisi o vodećem izračunu B. Zapravo, kada se izračun C promijeni, B se može promijeniti, a time i A. Sustav ne prati automatski takve složene ovisnosti, pa morate naznačiti koji su izračuni vodeći.	Bonus ovisi o osnovici plaće, ali neizravno ovisi io izostancima s posla.

Zbog tog utjecaja rok valjanosti upisa u registar naselja podijeljen je u četiri razdoblja:

Razdoblje	Opis
Razdoblje registracije	U kojem razdoblju je zabilježen događaj, tj. obično kada se unosi dokument.
Valjanost	U kojem razdoblju događa događaj, tj. kojem razdoblju događaj pripada.
Bazno razdoblje	Značajno samo za razdoblja koja imaju bazno razdoblje - opisuje interval baznog razdoblja.
Stvarno razdoblje valjanosti	Ako je rok valjanosti zamijenjen drugim vrstama obračuna, tada se stvarni rok valjanosti sastoji od nekoliko razdoblja u kojima je ovaj tip obračuna stvarno na snazi.

Razdoblje registracije određuje se jednim brojem - početak razdoblja, koji odgovara učestalosti obračunskog registra. Čak i ako postavimo drugi datum u ovom servisnom polju, on će i dalje biti zamijenjen početkom razdoblja. Preostala razdoblja navedena su u dva polja - početak i kraj razdoblja. Stvarni rok valjanosti je skup razdoblja, jer može se sastojati od nekoliko datumskih intervala.

Vremenske karte

Sustav ima mogućnost povezivanja podataka iz obračunskih registara s vremenskim dijagramima tako da se može dobiti broj radnih sati za bilo koje razdoblje.

Vremenska linija je jednostavan informacijski registar u kojem jedna dimenzija pohranjuje datum, druga je povezana s dimenzijom registrom izračuna, a jedan od resursa se koristi za praćenje vremena.

Dimenzija koja povezan s računskim registrom obično nosišto znači "vrsta grafikona".

datum	Vrsta grafikona	Značenje
11.01.05 pet	Pet dana
11.01.05 pet	Šest dana
12.01.05 sub	Pet dana
12.01.05 sub	Šest dana

Zašto koristiti dimenziju datuma umjesto registra periodičnih detalja? Sve je vrlo jednostavno – ako u petak, 11. siječnja imamo 8 radnih sati u petodnevnom razdoblju, to ne znači da ćemo sljedeći dan opet imati 8 radnih sati. Ali ako bismo koristili periodični registar, vrijednost za sljedeći dan bila bi uzeta od prethodnog dana u nedostatku zapisa.

Dakle, imajući određeno razdoblje (stvarna radnja, prijava, osnovno razdoblje itd.) možemo automatski dobiti broj sati za to razdoblje prema rasporedu.

Preračunavanje

Ponovno izračunavanje donekle podsjeća na granicu niza. Budući da imamo zavisne kalkulacije, sustav mora pri promjeni njihove baze i vodećih kalkulacija nekako primijetiti da moramo ponovno izračunati zavisne kalkulacije.

Tome služe ponovni izračuni.

Ako izračunamo osnovne zapise, sustav će u dodjelama zabilježiti da trebamo izračunati zavisne zapise. Nakon što izračunamo zavisne zapise, dodjele će se izbrisati.

U suštini, ponovni izračuni su popis unosa registra obračuna koje je potrebno ponovno izračunati.

Ako u rekalkulacijama ne upisujete nikakve mjere, tada će se prilikom promjene osnovnih kalkulacija svi zavisni zapisi dodati u listu rekalkulacija.

Ako u rekalkulaciji kreiramo dimenziju “Zaposlenik”, onda kada se promijeni osnovna kalkulacija za zaposlenika, u rekalkulacije će se dodati ovisni zapisi samo za ovog zaposlenika.

Praktičan zadatak

Dosta teorije. Pokušajmo proučiti detalje u praksi. Uzmimo konfiguraciju okvira kao osnovu.

Formulacija problema:

Neka bonus bude fiksni postotak od plaće (minus izostanci i putni troškovi).

Neka se putni troškovi isplaćuju u dvostrukoj plaći + fiksni iznos isplata za svaki dan putovanja.

Neka se zaposleniku za izostanak na radu naplati novčana kazna u visini polovice plaće za vrijeme odsutnosti.

Napredak:

Početna obuka

Kreirajmo novi plan za vrste izračuna "Glavni".

Definirajmo vrste izračuna i ovisnosti između njih:

	Osnovni, temeljni	Istiskujući	Prezenteri
Plaća		Izostanak s posla, Poslovni put
Nagrada		Izostanak s posla, Poslovni put	Plaća, Apsentizam, Poslovni put
Poslovni put
Izostanak s posla

Dodajmo ove vrste izračuna u plan vrsta izračuna "Glavni" i postavimo ovisnosti u svojstvima vrsta izračuna prema tablici.

U registru obračuna plaća izradit ćemo dimenziju “Zaposlenik” tipa “Fizička lica” - kako bi registar imao dio analitike za zaposlenike.

Konfiguracija već sadrži dokument “Plaće”.

Ima dva datuma u zaglavlju - "datum" i "razdoblje registracije", kao i dva datuma "datum početka" i "datum završetka" u svakom retku.

Podrazumijeva se da je datum jednostavno datum izvršenja dokumenta, razdoblje registracije označava za koji mjesec obračunavamo plaću, a datumi u svakom retku opisuju razdoblje valjanosti svake vrste obračuna.

Dodajmo početnu postavku atributa "Podaci" u modul dokumenta - unijet ćemo početnu plaću, postavljajući u nju razdoblje registracije, razdoblje valjanosti i osnovno razdoblje.

Modul dokumenta izgledat će otprilike ovako:

Za Svakome TechStringList Iz ciklusa popisa

// registar Izračuni

Kretanje = Kretanja .Izračuni.Dodaj();

Pokret .S torno= Netočno;

Pokret .U idIzračunu = TechStringList.CalculationType;

Pokret .PeriodActionsStart= Početak dana ( TechStringList.StartDate);

Pokret .PeriodActionEnd= KrajDana();

Pokret .Prijavno razdoblje = Razdoblje registracije;

Pokret .OsnovniPeriodStart= Početak dana ( TechStringList.StartDate);

Pokret .BasePeriodEnd= Dan završetka ( TechStringList. Datum završetka);

Pokret .Zaposlenik = TechStringList.Employee;

Pokret .Raspored = TechStringList.Graph;

Pokret .Proizlaziti = 0;

Pokret .Podaci = TechStringList.Size;

Kraj ciklusa ;

Atribut Reversal je potreban za storniranje unosa (analogno znaku minus).

Označavamo vrstu obračuna, te postavljamo datume na početak i kraj dana. Naravno, bazno razdoblje se može unijeti samo za vrste obračuna ovisne o osnovici, a Podatak samo za plaću, ali sve tako funkcionira.

Sve ćemo dokumente datirati 20.1.2003., razdoblje registracije bit će postavljeno na 2.1.2003. (posebno ne navodim početne i završne podatke, to ovdje nije bitno, u svakom slučaju, kada snimate u Razdoblje registracije preračunato na početak razdoblja 1.1.2003.). Koristimo siječanj 2003. jer su planovi rada za ovo razdoblje završeni.

Kreirajmo ponovni izračun "Ponovni izračun" i dodajmo mu dimenziju "Zaposlenik" povezanu s dimenzijom "Zaposlenik".

Igranje s ponovnim izračunima.

Za igranje igrice otvorite konzolu zahtjeva - obrada " CustomRequest» u konfiguraciji okvira. Stvorimo novi upit pomoću konstruktora upita i dodamo virtualnu tablicu tamo Rekalkulacije. Kalkulacije. Rekalkulacije, tekst zahtjeva će biti ovakav:

BIRAJTE

IzračuniRekalkulacija.O objektu Rekalkulacija,

CalculationsRecalculation.In ID izračuna,

Obračuni Preračun.Od djelatnika

IZ

Registar obračuna. Kalkulacije. Preračun KAKO IzračuniPonovni izračun

Generirati ćemo tri dokumenta - prvo ćemo obračunati plaće zaposlenicima A i B. Zaposlenik A radi od 1. do 31. siječnja, B radi od 1. do 20. siječnja. Drugi će dodijeliti bonus zaposleniku B za razdoblje od 1. do 31. siječnja, treći će dodijeliti izostanak s posla zaposleniku A od 20. do 25. siječnja.

Igramo se sa stvarnim rokom valjanosti.

Kreirajmo novi upit - ovaj put ćemo mu dodati podatke iz tablice Registri izračuna Izračuni Stvarno razdoblje akcije.

Kreirajmo zahtjev i vidimo da je razdoblje plaće zaposlenika A podijeljeno u dva razdoblja - od 1. do 19. siječnja i od 26. do 31. siječnja. Nadam se da razumijete da je period podijeljen na dva, jer... izostanak s posla zamijenio plaću.

Mislim da nam pred očima postaju jasniji mehanizmi rada registra obračuna.

Proučavajmo grafove.

Pokušajmo sada izračunati plaću na temelju plaće zaposlenika.

Kreirajmo novi upit za registar izračuna koristeći virtualnu tablicu Računski registri. Izračuni. DataGraphics. Možete postaviti parametar za ovu virtualnu tablicu - uvjet za odabir zapisa, na primjer Zaposlenik=&Odaberi Zaposlenika I Vrsta izračuna=&Vrsta izračuna I Grafikon=&Prikaži Grafikon.

Postavimo određene zaposlenike, vrste obračuna i rasporede u parametrima zahtjeva i vidimo koliko je sati rezultat.

Stupac rezultata	Značenje
ValuePeriodAction	Za koji rok važenja u sati je bio upis u upisnik.
ValueActualPeriodAction	Koliko sati je zaposlenik stvarno radio?
ValueBasePeriod	Za plaću nema smisla, za bonuse - broj radnih sati u baznom razdoblju.
ValueRegistration Period	Koliko radnih sati ima upisni rok (mjesec siječanj)

Preračuni su sastavni dio obračuna plaća. Informacije o bolovanju, godišnjim odmorima ili izostancima zaposlenika koje računovodstvo primi s određenim zakašnjenjem dovode do ponovnog obračuna plaća i, sukladno tome, premija osiguranja. Stručnjaci 1C govore o tome kako se izračuni i ponovni izračuni premija osiguranja odražavaju u računovodstvu i reguliranom izvješćivanju u programu 1C: Plaće i upravljanje osobljem 8, izdanje 3.

Prilikom preračunavanja plaća potrebno je preračunati premije osiguranja. Osim toga, razlog za ponovni obračun doprinosa može biti promjena tarife tijekom godine ili otkrivanje pogrešaka, primjerice neuvrštavanje obračuna u osnovicu za premije osiguranja.

U tim slučajevima računovođa ima pitanja o potrebi, obvezi i pravu podnošenja ažuriranih podataka Federalnoj poreznoj službi.

Prema klauzuli 1.2 Postupka za ispunjavanje obračuna premija osiguranja, danog u Dodatku br. 2 nalogu Federalne porezne službe Rusije od 10.10.2016. br. MMV-7-11/551@, platitelj je dužni izvršiti potrebne izmjene u Obračunu i podnijeti ažurirano izvješće poreznom tijelu ako postoje neevidentirani ili nepotpuni podaci, kao i pogreške koje dovode do podcjenjivanja iznosa premija osiguranja koje se plaćaju.

Prilikom donošenja odluke o predaji ažuriranog obračuna računovođa mora odgovoriti na sljedeća pitanja:

• jesu li sve informacije prikazane;
• jesu li učinjene pogreške i jesu li dovele do podcjenjivanja iznosa plativih premija osiguranja.

Predaja ažuriranog obračuna može biti obveza, pravo ili prisilna potreba.

Ažuriran obračun premija osiguranja

Obveza podnošenja ažuriranog izračuna nastaje ako se nakon podnošenja izvješća Federalnoj poreznoj službi ispostavi da su dostavljeni nepotpuni ili netočni podaci o zaposlenicima ili su otkrivene pogreške koje su dovele do podcjenjivanja iznosa premija osiguranja koje se plaćaju.

Vrste uobičajenih pogrešaka koje zahtijevaju obvezno podnošenje ažuriranog izračuna:

1. Zaposlenik nije pravodobno prijavio promjene svojih osobnih podataka, a Federalna porezna služba je u odjeljku 3. obračuna o njemu dala lažne podatke.

2. Zaposlenik je radio u odjelu koji ima pravo primjenjivati ​​povlaštenu stopu premije osiguranja. Zatim je prebačen u jedinicu u kojoj se primjenjuje osnovna premija osiguranja. Informacija o premještaju djelatnika u računovodstvo je stigla kasno. Pogrešno je izvršen obračun doprinosa po sniženoj stopi.

3. U početnoj fazi postavljanja programa 1C: Plaće i upravljanje osobljem 8 napravljena je pogreška isključivanjem premije iz osnovice za obračun premija osiguranja. Ispravljanje pogreške rezultirat će dodatnim troškovima.

4. Odjel s povlaštenom tarifom gubi pravo korištenja iste, ali podaci do voditelja plaće dolaze sa zakašnjenjem. Preračunom prema osnovnoj tarifi povećava se iznos premije osiguranja.

5. Pri izračunu premija osiguranja program nije označio da je radno mjesto navedeno na popisu opasnih zanimanja koja podliježu dodatnim tarifama. Nakon što je pogreška otkrivena i ispravljena, ponovni izračun rezultirao je premalo plaćenom premijom osiguranja po dodatnim stopama.

Pogledajmo značajke ponovnog izračuna premija osiguranja u "1C: Plaće i upravljanje osobljem 8" izdanje 3 koristeći primjere.

Primjer 1

Pri obračunu premija osiguranja jedinice Zaliha primijenjena je povlaštena stopa premija osiguranja Stanovnici tehnološki inovativne posebne gospodarske zone(tarifni kod “05”). Ovom tarifom predviđeni su doprinosi za mirovinski fond u iznosu od 13% u 2018. godini; u Fondu socijalnog osiguranja 2,9%; u Federalnom fondu obveznog zdravstvenog osiguranja 5,1%. Upravo su tako obračunati doprinosi zaposlenici V.S. Bršljan. S mjesečnom zaradom od 10.000 rubalja. Iznos odbitaka osiguranja za mjesec bio je:

• u mirovinskom fondu - 1300 rubalja;
• u FFOMS - 510 rubalja;
• u Fondu socijalnog osiguranja - 290 rubalja.

Navedeni iznosi odraženi su u obračunu premija osiguranja za prvo tromjesečje 2018. godine.

Kada se ispostavilo da je odjel izgubio pravo na primjenu povlaštene stope premija osiguranja, tada je u skladu s dopisima Federalne porezne službe Rusije od 25. listopada 2017. br. GD-4-11/21611@ i Ministarstva financija Rusije od 18. prosinca 2017. br.? 03-15-06/ 84443 postojala je potreba za podnošenjem obračuna za pojašnjenje. Za njegovo formiranje potrebno je preračunati premije osiguranja s novim stopama.

U kartici Divizije polje treba očistiti Strah od povlaštenih tarifa. doprinosa. Sada podjela podliježe tarifi koja se koristi za organizaciju i navedena je na kartici organizacije na knjižnoj oznaci Računovodstvene politike i druge postavke veza Računovodstvena politika u polju Vrsta tarife.

U primjeru 1, organizacija je postavljena na Osnovna stopa premije osiguranja(tarifna oznaka "01"), predviđajući stope doprinosa u 2018. godini: u mirovinski fond Ruske Federacije u iznosu od 22%; Fond socijalnog osiguranja 2,9%; FFOMS 5,1%. Očito je da je mirovinski fond “podplatio” 9% doprinosa (22% - 13%), a promijenila se i tarifna oznaka.

U primjeru 1 koji se razmatra, za preračun doprinosa potrebno je revidirati postupak obračuna prihoda. Dokument je namijenjen registraciji postupka evidentiranja prihoda i preračunavanja premija osiguranja prethodnog razdoblja. (Jelovnik Porezi i naknade). Na knjižnoj oznaci Podaci o prihodima potrebno je ručno razjasniti sve prihode zaposlenika. Istovremeno, na knjižnoj oznaci Procijenjeni doprinosi Premije osiguranja automatski će se ponovno izračunati.

Kao rezultat ponovnog obračuna premija osiguranja zaposlenika V.S. Ivy s mjesečnom zaradom od 10.000 rubalja. Iznos odbitaka osiguranja za mjesec bio je:

• u mirovinskom fondu Rusije - 2200 rubalja;
• u Saveznom fondu za obvezno medicinsko osiguranje i Fondu za socijalno osiguranje - iznos se nije promijenio i iznosio je 510 rubalja, respektivno. i 290 rub.

Nakon preračunavanja premija osiguranja za prvo tromjesečje potrebno je pripremiti pojašnjavajući obračun. Korištenje usluge 1C-izvješćivanje, potrebno je izraditi nova izvješća za razdoblja koja se ispravljaju i za Naslovnica naznačiti Broj ispravka(slika 2). Pojašnjenja su se odnosila na sve zaposlenike odjela, budući da je svima promijenjena tarifna oznaka. Stoga se rubrika 3. u ažuriranom Obračunu formira za sve djelatnike odjela. U ostalim slučajevima, kada je formiranje ažuriranog obračuna uzrokovano promjenama u podacima ili vremenskim razgraničenjima pojedinih zaposlenika, u odjeljku 3 prikazuju se podaci samo za te zaposlenike. U svakom slučaju, preostali dijelovi obračuna za razjašnjenje popunjavaju se potpuno novim podacima.

Riža. 2. Naslovna stranica razjašnjavajućeg obračuna premije osiguranja za I. kvartal 2018. godine

Pravo na dostavu ažuriranog Obračuna premije osiguranja

Osiguranici mogu inspekciji dostaviti dopunjeni Izračun ako utvrde pogreške koje dovode do precijenjenog iznosa premije osiguranja. Naime, prilikom sljedećeg obračuna doprinosa u tekućem razdoblju vrši se ponovni izračun, a rezultat se odražava u izvješću za sljedeće razdoblje. Opcije situacije koje vam omogućuju da predstavite ažurirani izračun:

1. Zaposleniku je isplaćena plaća za cijeli odrađeni mjesec. Obračun premija osiguranja dostavljen je Federalnoj poreznoj službi, no kasnije se ispostavilo da je zaposlenik bio na bolovanju ili na godišnjem odmoru o svom trošku. Obračun koji nije uključen u osnovicu za obračun premije zamijenio je obračun koji podliježe premiji osiguranja, što je dovelo do preplate premije.

2. Svaki ponovni izračun obračuna zaposlenika, što dovodi do ponovnog izračuna premija osiguranja prema njihovom smanjenju.

Primjer 2

Prilikom obračuna plaće za lipanj zaposlenici S.S. Gorbunkov je nagrađen:

• isplata plaće - 7.500 rubalja;
• plaćanje službenog putovanja (na temelju prosječne zarade) za lipanj - 2500 rubalja.

Premije osiguranja obračunate su po osnovnoj stopi. U lipnju doprinosi iz plaće S.S. Gorbunkov su bili:

• u mirovinskom fondu Rusije - 2200 rubalja;
• u FFOMS - 510 rubalja;
• u Fondu socijalnog osiguranja - 290 rubalja.

Ovi doprinosi su plaćeni i uključeni u polugodišnji obračun 2018. godine. Bolovanje dostavljeno u računovodstvo za razdoblje 25.06.2018.-30.06.2018., ne predstavlja razlog za formiranje ažuriranog Obračuna. Dokument registriran u programu Bolovanje stornira prethodno obračunati iznos putnih naknada (slika 3).

Riža. 3. Preračun putnih naknada u dokumentu “Bolovanje”.

Bolovanje je organizacija primila u srpnju. Ovo nije pogreška i ne rezultira nedovoljnom uplatom premija osiguranja. Budući da se na iznos obračunatog na bolovanju ne plaćaju doprinosi za osiguranje, došlo je do preplate doprinosa u iznosu od:

• u mirovinskom fondu Ruske Federacije - 550 rubalja;
• u FFOMS - 127,50 rubalja;
• u Fondu socijalnog osiguranja - 72,50 rubalja.

U programu Bolovanje, registriran srpnja 2018, utječe na obračun premije osiguranja u tekućem mjesecu, smanjujući osnovicu za obračun.

U takvoj situaciji ne postoje zakonski uvjeti za dostavu ažuriranog obračuna. Sva ponovna izračunavanja događaju se u sljedećem razdoblju i odražavaju se u sljedećim izvješćima. Ali u isto vrijeme, organizacija ima pravo razjasniti izvješće za polugodište i obavijestiti Saveznu poreznu službu o preplaćivanju koje se dogodilo podnošenjem pojašnjenja.

Međutim, prije kraja mjeseca ne biste trebali ishitreno pojašnjavati izračun. Uostalom, razni dokumenti se registriraju tijekom cijelog mjeseca. U nekom trenutku dokument Bolovanje može doista stornirati dohodak prethodnog mjeseca, a na temelju rezultata obračuna plaće za mjesec drugi dokument, npr. Obračun plaća i doprinosa, izvršit će dodatna razgraničenja koja premašuju stornirani prihod prethodnog razdoblja. Time će se primanja tekućeg mjeseca umanjiti za iznos storniranja službenog puta, neće ostati nikakvi minus za prethodni mjesec, a u obračunu usklađivanja neće biti nikakvih promjena.

Potreba dostave ažuriranog Obračuna premije osiguranja

U određenom broju slučajeva, unatoč nepostojanju obveze dostave ažuriranog obračuna, ugovaratelj osiguranja nema drugu mogućnost prijaviti svoju preplatu premije osim dostave ažuriranog obračuna:

1. Kao rezultat ponovnog izračuna doprinosa u tekućem razdoblju, zaposlenik dobiva negativan iznos. Izvješće s negativnim iznosom ne može se podnijeti Federalnoj poreznoj službi. Stoga postoji samo jedan izlaz - generirati ažurirano izvješće za prethodno razdoblje.

2. Zaposlenik je radio na opasnom radu. Premije osiguranja obračunate su po dodatnoj stopi. Informacija o prelasku zaposlenika na rad u normalnim uvjetima rada u računovodstvo je stigla kasno. Uslijed preračunavanja nemoguće je umanjiti obračunate doprinose po dodatnoj stopi, jer se na obračune radnika u tekućem razdoblju više ne plaćaju doprinosi po dodatnoj stopi.

Primjer 3

U ovom slučaju, za razliku od prethodnog primjera 2, negativni iznos premije osiguranja koji proizlazi iz otkazivanja službenog putovanja neće biti nadoknađen vremenskim razgraničenjima. Unatoč činjenici da će zbog obračuna ostalih zaposlenika ukupan iznos premija osiguranja biti pozitivan, u odjeljku 3 zaposlenik će ostati negativne vrijednosti, a to je nedopustivo. Stoga će računovođa morati izraditi dokument Preračun premija osiguranja, ponovno izračunati doprinose za lipanj, generirati i dostaviti ažurirani izračun Federalnoj poreznoj službi.

Program 1C: Upravljanje plaćama i osobljem 8 automatizira proces ponovnog izračunavanja premija osiguranja. Korištenje usluge 1C-izvješćivanje početni i razjašnjavajući izračuni za premije osiguranja generiraju se automatski. Međutim, odluka o izradi razjašnjavajućeg obračuna ostaje na računovođi. Nakon analize posljedica evidentiranja dokumenta koji mijenja obračune u razdoblju za koje je izvješće već predano, računovođa ili preračunava premije osiguranja za prethodno razdoblje ili se obračun automatski događa u tekućem mjesecu.

Od urednika. U članku pročitajte o mehanizmu implementiranom u 1C:Enterprise 8 za provjeru kontrolnih omjera za izračun premija osiguranja, koji uzima u obzir podatke izračuna usklađenja.