1s ponovno izračunavanje. Korekcije i preračuni zarada. Preuzeće po periodu važenja

Od ostalih - na primjer, bonus se može odrediti prema visini plata za period. U tom slučaju je moguće da će se plata promijeniti nakon obračuna bonusa. Podrazumevano, platforma ne kontroliše takve situacije. Ako programer smatra da je potrebno ovo pratiti, tada morate koristiti poseban podređeni objekt registra izračuna - Ponovno izračunavanje:

Evidencija ponovnog izračuna pohranjuje se u posebnu tabelu. Oni ne garantuju da je zavisni registar potrebno tačno ponovo izračunati, ali služe kao signal takve potencijalne potrebe.

Općenito, unosi u tablicu ponovnog izračunavanja sadrže sljedeća polja:

objekat ponovnog izračuna (dokument evidencije čije podatke treba ponovo izračunati)
vrsta kalkulacije - veza sa vrstom obračuna iz Plana tipova obračuna definisanog za ovaj registar obračuna

Zapisi se mogu pohraniti detaljnije, u kontekstu jedne ili više dimenzija datog računskog registra. Na primjer, registrator platnog spiska za cijelo odjeljenje je bio zadnji dan; Štaviše, promene su bile samo za zaposlenog Ivanova. Dodavanje dimenzije Zaposleni u Rekalkulaciju će vam omogućiti da to pratite. U ovom slučaju, dimenzija Rekalkulacija mora biti povezana s dimenzijom registra izračuna:

Podaci iz tablice ponovnog izračunavanja se generiraju automatski ako plan odgovarajućeg tipa obračuna ima postavljeno svojstvo Osnovni period. Ako svojstvo nije postavljeno, tada je programer odgovoran za generiranje zapisa.

Pitanje 14.41 ispita 1C: Platform Professional. Podaci preračunavanja...

nisu unosi u registar obračuna
su unosi u registar obračuna
su unosi registra preračunavanja
su zapisi tabele stvarnog perioda važenja

Tačan odgovor je prvi, oni su uglavnom pohranjeni u odvojenim tabelama.

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

mjerenje osnovnog registra, kada se podaci mijenjaju, potrebno je ponovo izračunati tekući registarski zapis
mjerenje trenutnog registra, čije unose treba preračunati kada se mijenjaju podaci baznih registara
mjerenja baznih registara, kod kojih se podaci mijenjaju, potrebno je preračunati tekući registarski zapis

Tačan odgovor je drugi. Samo ponovno izračunavanje je potrebno za praćenje potrebe za ažuriranjem unosa u trenutnom registru.

Pitanje 14.43 ispita 1C: Platforma Professional. Tabela "Preračunavanje" je popunjena redovima od kojih svaki predstavlja...

skup informacija o vrsti obračuna i dokumentu-registratoru unosa obračunskog registra koji treba ponovo izračunati. Tabela će također sadržavati mjerenja preračunavanja
skup informacija o vrsti obračuna i dokumentu-registratoru unosa obračunskog registra koji treba ponovo izračunati
skup podataka o vrsti obračuna, broju reda registratorskog dokumenta i samom registratoru unosa obračunskog registra koji treba ponovo izračunati. Tabela će također sadržavati mjerenja preračunavanja
nema tačnih odgovora

Prvi odgovor je tačan, analiza iznad.

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

U procesu rada s ponovnim izračunima, programer može "ignorirati" informacije koje sistem pruža u tabeli preračunavanja, odnosno odbiti revidirati rezultate proračuna
Princip rada preračunavanja u sistemu 1C:Enterprise 8 je "obavještavanje"
Programer konfiguracije ne može kontrolisati proces ponovnog izračunavanja unosa u registar poravnanja, sistem sve radi automatski
Tvrdnja 1 i 2 su tačne

Četvrti tačan odgovor je da ponovno izračunavanje samo prati potencijalnu potrebu za promjenom zavisnih podataka.

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

Može se podržati samo jedno ponovno izračunavanje
Mogu se podržati samo tri alokacije različitih struktura
Podržan je bilo koji broj preračunavanja različitih struktura

Tačan odgovor je treći, nema problema sa dodavanjem bilo kojeg broja podređenih objekata Rekalkulacije u registar obračuna, njihova struktura se ni na koji način ne kontroliše.

Pitanje 14.57 ispita 1C: Platforma Professional. Učestalost obračuna je mjesečna. Odgovarajuće postavke su napravljene u registru proračuna. Za tip obračuna plaće, tip obračuna putovanja je specificiran kao tip obračuna pomjeranja. Dana 01.03.2014. podaci o platama su uneseni u bazu podataka, ali nije izvršen obračun. Dana 20.03.2014. službeno putovanje je uneseno u informacijsku bazu i obračunano. Dana 30.03.2014. godine pokrenut je obračun plata. Hoće li se prilikom obračuna plate uzeti u obzir podaci o službenom putu? Da li trebam preračunati svoje službeno putovanje?

Biće uzeto u obzir, ali će se službeno putovanje morati preračunati
Biće uzeto u obzir, nije potreban ponovni izračun putovanja
Neće se uzeti u obzir. Potrebno je poništiti obračun putovanja i preračunati oba tipa obračuna
Neće se uzeti u obzir. Za ispravan obračun, plata i službeno putovanje moraju biti u jednom dokumentu

Preračunavanje nije potrebno, evidencija o službenom putu je u roku od mjesec dana.

U ovom članku ćemo razmotriti teorijske osnove rada s računskim registrima, a također ćemo izračunati plaće zaposlenika srazmjerno broju odrađenih sati.

Teorija

Registar obračuna (RR)- objekat metapodataka konfiguracije koji se koristi za implementaciju periodičnih proračuna u 1C sistemu. Očigledna područja primjene registara obračuna uključuju sljedeće: obračun platnog spiska, obračun zakupnine, obračun zakupnine.

Po svojoj strukturi računski registri su slični registrima akumulacije ili informacionim registrima. Oni, kao i registri akumulacije, imaju mjerenja, resurse, detalje, ali je princip rada računskih registara potpuno drugačiji.

U svojoj osnovi, mjerenja u registru akumulacije služe kao “ filter» u okviru kojeg primamo podatke iz registra akumulacije. Kao primjer, kada uzmemo "ostatke" prema registru akumulacije "Preostala roba" u kontekstu određene stavke ili "odsječak najnovijeg" prema registru informacija "Plate zaposlenih" u kontekstu određenog zaposlenog . Za razliku od registra akumulacije, mjerenja u registru periodičnog obračuna služe za implementaciju „“ (ovo je kada se vremenski produženi tipovi obračuna međusobno takmiče u intervalu perioda važenja zapisa, odnosno, na primjer, obračun službenog putovanja tip zamjenjuje tip obračuna plate za period važenja) i ““ (ovo je kada tip obračuna bonusa zavisi od vrste obračuna plate za prethodne periode).

mehanizam potiskivanja prema periodu djelovanja«:

Ovdje vidimo da tip obračuna „Službeno putovanje“ ima vremensko trajanje i da važi od 10. aprila do 20. aprila, „Službeno putovanje“ je naznačeno kao pomjerni tip obračuna za obračunski tip „Plata“. „Plata“ se takođe vremenom produžava i važi od 1. do 30. aprila. S obzirom da je „Službeno putovanje“ naznačeno kao potiskivački tip obračuna za obračunski tip „Plata“ (ima veći prioritet od plate) i važi za period važenja plate, onda se plata zamjenjuje službenim putovanjem i formira se „stvarni period važenja plate.“ Stvarni period važenja plate „Ovo je period važenja plate nakon preseljenja službenim putovanjem, u našem slučaju se sastoji od 2 perioda - od 1. aprila do 9. i od 21. do 30. aprila i ukupno je 19 dana. Mehanizam pomaka zasnovan na periodu radi samo za dugoročne proračune.

Slika iznad grafički prikazuje princip " mehanizam zavisnosti po baznom periodu«:

Recimo da krajem aprila 2017. želimo zaposleniku dati bonus u iznosu od 10% njegove plate. Plata je navedena kao osnovna vrsta obračuna za bonuse.

Ali kao “osnovu” za obračun premije nećemo uzeti cijeli mjesec april, već samo interval od 10. aprila do 20. aprila (11 dana). Izračunajmo osnovicu za bonus, plata zaposlenog je 60.000 rubalja, ima 30 dana u mesecu, dnevna plata = 60.000/30 = 2.000 rubalja. Sljedećih 2000*11 = 22000 rub. Osnova za obračun premije je 22.000 rubalja.

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

Objekt metapodataka aplikacije “Plan tipova obračuna” usko je povezan sa registrom proračuna.

Plan tipova obračuna (PVR)- objekat metapodataka konfiguracije koji pohranjuje informacije o tipovima kalkulacija i određuje uticaj različitih proračuna jedni na druge.

Jedan plan obračunskog tipa može se koristiti u više računskih registara, ali jedan računski registar ne može istovremeno koristiti više planova obračunskih tipova.

Registar proračuna je tabela u kojoj se pohranjuju izračunati podaci, a u pogledu tipova proračuna pohranjuju se algoritmi za izračunavanje ovih podataka. Registar obračuna mora imati najmanje jedan registrator dokumenata koji vrši kretanje u registru obračuna (npr. Platni spisak).

Mehanizmi kalkulacije u sistemu 1C Enterprise dizajnirani su na način da prvo morate izvršiti unose u registar obračuna, a tek onda izvršiti proračun na osnovu ovih podataka. Na primjer, nemoguće je obračunati bonus na osnovu plate dok se ta ista plata ne upiše u registar obračuna.

Vježbajte

Pogledajmo bliže računske registre u praksi:

Korak 1 Počnimo s planom za vrste proračuna. Morate kreirati plan tipa obračuna prije kreiranja registra obračuna. Plan za tipove obračuna kreiramo prije obračunskog registra jer je prije kreiranja tabele za pohranjivanje izračunatih podataka (tj. registra proračuna) potrebno specificirati algoritme za izračunavanje ovih podataka (tj. plan za tipove proračuna).

Kreirajmo plan za vrste obračuna "Osnovni troškovi". Idemo odmah na karticu "Izračun". Ovdje odmah vidimo zastavu" Koristi period važenja“, kada se ova zastavica postavi, imat će sve vrste proračuna uključene u ovaj plan dužina u vremenu(na primjer, Plata, Službeno putovanje), kao i za ove vrste plana obračuna, “ mehanizam potiskivanja prema periodu djelovanja". Ako zastavica „Koristi period važenja“ nije postavljena, tada tipovi obračuna neće imati produženje vremena (na primjer, Bonus, Fine) i „mehanizam pomjeranja prema periodu važenja“ neće raditi. Na ovoj kartici se nalaze i odjeljci „Zavisnost od baze“ i „Osnovni planovi za vrste obračuna“ - služe za implementaciju „ mehanizam zavisnosti po baznom periodu“, ali o tome ćemo kasnije. Za sada, ostavimo "Ovisnost o bazi" u "Nezavisnom" načinu rada.

Kreirajmo unaprijed definirani tip obračuna "Plata". Na kartici "Osnovno" sve je jednostavno. Postavite naziv i šifru vrste proračuna.

Zahvaljujući činjenici da smo postavili zastavu" Koristi period važenja"Sada imamo karticu" Displasing"i uključen" mehanizam represije zasnovan na periodu«.

Na ovoj kartici označavamo vrste obračuna koji će pomjeriti platu po periodu važenja (na primjer, 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čava tipove proračuna koji, kada se promijene, moraju ponovo izračunati trenutni tip proračuna. Ovdje također možete odrediti tipove proračuna iz drugih planova tipova proračuna. Na primjer, tip obračuna “Plata” je vodeći za tip obračuna “Bonus”, tj. Kada se plata promijeni, moramo preračunati i bonus jer Bonus se obračunava u zavisnosti od plate. U ovom slučaju, tip obračuna “Plata” pripada PRP-u “Osnovna razgraničenja” koji koristi period važenja, a tip obračuna “Bonus” pripada PRP-u “Dodatna razgraničenja” koji ne koristi period važenja.

Korak 2.Kreirajmo direktorij “Charts” sa zadanom strukturom. U imenik „Rasporedi“ čuvamo radno vreme zaposlenih (petodnevno, šestodnevno, itd.).

Korak 3.Potreban nam je i objekat u koji ćemo pohraniti kalendar proizvodnje (radni dani i vikendi). U ove svrhe koristimo neperiodični nezavisni registar informacija.

Kreirajmo neperiodični nezavisni registar informacija “Rasporedi” sa 2 dimenzije “Datum” i “Raspored” i resursom “Broj sati”.

Zahvaljujući informacionom registru „Radni rasporedi“ moći ćemo da obračunavamo plate od plate proporcionalno broju odrađenih dana.

Korak 4.Kreirajte dokument “Payroll” sa strukturom detalja prikazanom u nastavku:

Rekviziti:

Operativno izvršenje je postavljeno na "Zabrani" jer nema smisla za mehanizam periodičnih poravnanja u 1C - nikada ne izračunavamo bonuse, plate ili kazne u realnom vremenu.

Kreirajmo obrazac dokumenta sa zadanim postavkama.

Korak 5. Konačno, došli smo do tačke kreiranja računskih registara.

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

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

1. U polju „Plan tipova obračuna“ naznačite PVR „Osnovne naknade“ kreirane u koraku 1.

2. Postavite zastavicu „Period važenja“ na „Tačno“ jer PVR specificiran u koraku 1 ima produženje u vremenu.

Nakon postavljanja ove zastavice, standardni detalji “Action Period”, “Action PeriodStart”, “ActionPeriodEnd” nam odmah postaju dostupni, što znači da tipovi kalkulacija registrovani u ovom registru obračuna takođe imaju dužina u vremenu i imamo pristup " mehanizam potiskivanja prema periodu djelovanja«.

P.S. Ako navedete PVR koji ima dužina u vremenu za RR sa zastavicom “Validity Period” postavljenom na “False”, tada će ovaj PVR raditi kao PVR koji nema produženje u vremenu.

3.Nakon postavljanja zastavice “Period važenja” na “Tačno”, polja “Grafikon”, “Vrijednost grafikona”, “Datum grafikona” postaju nam dostupna.

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

U polju “Vrijednost rasporeda” označavamo resurs “Broj sati” u registru informacija “Rasporedi”.

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

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

Ispod je struktura metapodataka registra:

Oznaka “Osnovno” za dimenziju utiče samo na performanse; ne morate je postaviti, ali ako to učinite, polje “Zaposleni” će biti indeksirano.

Dimenzija "Zaposleni" - koristi se u " mehanizam represije zasnovan na periodu djelovanja" i " mehanizam zavisnosti od baznog perioda«.

Resurs „Iznos“ - tu će biti evidentirana obračunata plata.

Atribut “Chart” je naznačen kao atribut, a ne dimenzija registra, jer ni ono ni ono ništa ne zamenjuje - u suštini referentno polje. Bitan!!! Ne zaboravite popuniti polje "Link za raspored". u atributu “Raspored”, dimenzija “Raspored” registra informacija “Rasporedi” mora biti tamo naznačena, inače se iznos plate neće izračunati.

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

Sada kada smo naznačili vezu sa MS „Radni rasporedi“, obračunaćemo platu zaposlenom srazmerno broju odrađenih dana.

Dokument označavamo kao registratora " Payroll" kreiran u koraku 4.

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

Vratimo se na dokument “Payroll” kreiran u koraku 4.

Hajde da opišemo obradu knjiženja u modulu objekta dokumenta:

Fragment koda za obradu dokumenata

1C (Kôd)

Procedure ProcessingProcessing(Failure, Processing Mode) // register BasicAccruals of Movement.MainAccruals.Write = True; Kretanja.MainAccruals.Clear(); Period registracije = Početak mjeseca (Datum); Za svaku TechLineMainAccruals iz MainAccruals ciklusa Kretanje = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Period registracije; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Kraj procedure

ProcessingProcedure(Failure, Mode)

// Glavni registar vremenskih razgraničenja

Pokreti. BasicAccruals. write = istina;

Pokreti. BasicAccruals. Clear() ;

Period registracije = Početak mjeseca (Datum) ;

Za svaku TechLine BasicAccrualsFrom BasicAccrualsCycle

Pokret = Pokreti. BasicAccruals. Dodati() ;

Pokret. Storno= False;

Pokret. Vrsta izračuna=TexLineMainAccruals. Calculation Type;

Pokret. PeriodActionStart = TechLineMainAccruals. Datum početka;

Pokret. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ;

Pokret. Period registracije = Period registracije;

Pokret. Zaposlenik = TechLineMainAccruals. Employee;

Pokret. Grafikon = TechLineMainAccruals. Raspored;

Pokret. Parametar = TechStringMainAccruals. Veličina;

EndCycle;

Kraj procedure

Kreirajmo probni dokument i pokrenimo ga:

Idemo na "Kretanje dokumenata":

Vidimo da je period registracije postavljen na početak mjeseca jer Učestalost RR-a je označena kao “Mjesec”. Takođe vidimo da su sva polja osim iznosa popunjena (plata još nije obračunata).

Korak 7.Napišimo šifru obračuna platnog spiska.

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

Sam proračun će se odvijati u ovom opštem modulu.

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

Pošto smo popunili polja “Raspored”, “Vrijednost rasporeda”, “Datum rasporeda” u postavkama RR “Osnovni troškovi”, postala nam je dostupna virtuelna tabela registra obračuna DataGraphics, u upitu za virtuelnu tabelu zanimaju nas sljedeća polja:

“Broj sati stvarnog perioda akcije” — sadrži broj stvarno odrađenih sati izračunat na osnovu podataka rasporeda

"Broj sati Period akcije" - sadrži broj radnih sati izračunat na osnovu podataka rasporeda u obračunskom periodu

Postupak obračuna platnog spiska

1C (Kôd)

Procedura CalculateAccruals(Registar, Skup zapisa) Izvoz //Zahtjev za platu=Novi zahtjev; Query.Text="SELECT | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData.RapAccrualsGraphicsData.AccruGours,AccPuGours,AccPuGours | icsData ica.Broj reda |IZ |Registar obračuna.Osnovna obračunavanja. Grafički podaci(| Registrator = &Registar | I Vrsta izračuna = &Tip izračuna Plaća) AS Basic AccrualsDataGraphics"; Request.SetParameter("Registrator", Snimač); // proslijediti dokument matičaru tako da se pretraga vrši samo na trenutnom dokumentu Request.SetParameter("Tip obračunaPlata", Planovi tipova obračuna. Osnovna obračunska razgraničenja. Plaća); //postaviti vrstu obračuna plaće jer izračunaj platu Selection=Request.Run().Select(); SearchStructure=Nova struktura; SearchStructure.Insert("RowNumber",0); //kreiramo strukturu za traženje podataka za izračunavanje po broju reda Za svaki zapis iz ciklusa skupa zapisa //kruži kroz skup zapisa trenutnog documentSearch Structure.LineNumber=Record.LineNumber; //popunite broj reda za pretragu If Selection.FindNext(Struktura pretrage) Zatim //tražimo u uzorku podatke za izračunavanje na osnovu trenutnog broja reda Record.Sum =?(Selection.HoursPlan=0.0, Sampling.HoursFact /Sample.HoursPlan * Uzorkovanje .Parameter); //izračunaj platu proporcionalno odrađenim danima, u Parametru - trenutna plata EndIf; Selection.Reset(); //resetuj selekciju, potreban nam je sledeći zapis skupa zapisa da pretražimo selekciju prvi EndCycle; Recordset.Write(, True); //upisujemo izračunate zapise u bazu podataka, prosljeđujemo parametar Replace = True EndProcedure

//Plata

Zahtjev=Novi zahtjev;

Zahtjev. Text="ODABIR

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

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS Plan sati,

| BasicAccrualsDataGraphics.NumberLines

|OD

| Registar obračuna. Osnovna razgraničenja. Grafički podaci (

| Snimač = &Rekorder

Dobar dan. Dugo se nisam čuo :) Danas želim da razjasnim karakteristike preračuna u ZUP-u 3.0 za protekla razdoblja. Ovaj članak govori o tome kako funkcionira iznutra i, shodno tome, možete kontrolirati ovaj proces. Uostalom, vjerovatno ste se susreli sa činjenicom da program neočekivano nagomilava nepoznate iznose osobi, preokreće ih, pojavljuju se neke razlike... a vi to niste htjeli, ili ste htjeli. ali ovo se nije desilo))

Počnimo. Prvo, preračuni se dešavaju u trenutku kada platu smatrate dokumentom „platne liste“. U tu svrhu pruža karticu „Dodatna razgraničenja, preračunavanja“. Prva stvar koju želim da vas posavetujem: uvijek provjerite podatke na etiketi "Dodatna razgraničenja, preračuni" . Tamo se mogu pojaviti bez vašeg znanja i nećete shvatiti zašto iznos u obračunu nije isti.

U teoriji, u zaglavlju dokumenta uvijek smo upozoreni da će program nekoga prebrojati ili da ga moramo dopuniti, jer... neko nije uračunat.

Kako program zna koga trebam brojati i za koji mjesec?

Ona to određuje na osnovu vaših postupaka. Da li ste dali dokument unazad? Program je pogledao zaposlene koji su bili u ovom dokumentu i evidentirao njihovu listu. Da li ste izvršili ispravku u dokumentu (na primjer, ispravili raspored za prošli mjesec)? Program je upamtio sve iz ovog rasporeda i ovaj mjesec će biti preračunat. Gotovo svi dokumenti, i kadrovski i platni spisak, su pogođeni. U ovom slučaju, program ne brine da li je vaše dodirivanje dokumenta uticalo na vašu platu ili ne.

Recimo da ste otišli na prijavu za posao i tamo napisali komentar, nakon čega ste ponovo objavili dokument. Bez plate, bez termina, bez pozicije... ništa nije dirano. Ali program ne zna zašto ste prepisali dokument iz prethodnog perioda, nije telepata, jednostavno je snimio ovog radnika.

Drugi savjet (poznat i kao prva tajna): kroz “sve funkcije” idite na registar informacija “Preračun plata”. Ne budite lijeni i penjite se! Uđite tamo prije svakog obračuna platnog spiska i nakon svakog dokumenta sa zadnjim datumom.

Mnogi računovođe ovaj savjet doživljavaju kao da imaju novi posao kojeg već imaju dovoljno. Ali ako se ne popnete tamo, nećete shvatiti logiku rada, a ako vam je program kao crna kutija, onda se nećete sprijateljiti s njim. Prijateljstvo počinje razumevanjem unutrašnjeg sveta prijatelja! Ako vam nije stalo do unutrašnjeg svijeta vašeg protivnika, onda on nije vaš prijatelj.

Pa, jeste li se popeli? Odlično. Po pravilu je prazan i nema ni jednog reda, ali čim retroaktivno dodirnete nešto, ovdje će se pojaviti zapis u kojem se nalazi zaposlenik i mjesec koji treba preračunati.

Treći savjet: ako se ne slažete sa namjerom programa da prebroji zaposlenika, obrišite red iz ovog registra.

1. Da li već razumijete kako se pojavljuju linije? Odlično.

2. Prilikom popunjavanja dokumenta “Platni spisak” i knjiženja na osnovu redova u registru vrši se preračun i popunjavanje tabele "Dodatna razgraničenja, preračunavanja."

3. Preračunati radnici se brišu iz registra i on postaje prazan.

4. Kada poništite dokument “Platni spisak”, redovi se vraćaju na svoje mjesto, tako da kada ih ponovo dopunite, sve će doći na svoje mjesto.

Četvrti savjet (možda će se ovo popraviti): Prije dopune dokumenta „platni spisak“, raširite ga!

Na osnovu algoritma, nakon knjiženja dokumenta, registar se briše. Ako ga dopunite bez brisanja, program neće znati koga treba prebrojati, a tabelarni dio sa preračunavanjem će biti prazan. Ovo je bilo tačno za izdanje 21. Još nisam imao vremena da ga provjerim u 22..

Još jedna nijansa, ako kliknete na listu ljudi za ponovni izračun u dokumentu, otvorit će se obrazac liste registra informacija"Preračun plata." Takođe će postojati dugme za „brisanje“ jednog unosa.

P.S. (bitan)

Razlog za ovu istragu bila su beskrajna preračunavanja prilikom prenošenja originalnih podataka iz računovodstva 3.0. Tokom tranzicije, morat ćete dodirnuti sve tehnike i prijevode)) nakon toga obrišite sav sadržaj registra " "Preračun plata", inače ćete dobiti preračun svega za sve godine Početak rada u ZUP-u 3.0 sa prijenosom podataka iz Računovodstva 3.0

Ovo se dogodilo u demo bazi podataka kada je jedan posao ponovo izvršen. A kada prenesete 1C Accounting 3.0 na 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 uzvratiti ljubavlju.

Mnogi 1C programeri nikada se u svojoj praksi nisu susreli sa komponentom „Računanje“, stoga, kada treba da polažu ispite za Specijalista na Platformi 8.0, gdje svaki zadatak sadrži zadatak o složenim periodičnim proračunima, nastaju poteškoće, prije svega poteškoće u razumijevanju.

Hajde da pokušamo da shvatimo 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 što proučite ovaj priručnik, shvatit ćete kako su registri proračuna uređeni i funkcioniraju.

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

Da budem iskren, dugo sam pokušavao da shvatim za šta su još potrebni proračuni, ali nisam mogao da shvatim, pa hajde da razmotrimo problem obračuna plata.

Šta su kalkulacije

U osnovi, konačni proizvod platnog spiska je skup unosa platnog spiska u obliku:

Zaposleni	Period	Vrsta obračuna	Rezultat	Podaci	Komentar
Measurement	Službeno	Službeno			Rekviziti

Vrijednost u koloni „Podaci“ odražava osnovnu platu zaposlenog (prema ugovoru o radu), ali se ovaj iznos može povećati za bonuse, umanjiti za novčane kazne i izostanke itd., stoga se stvarni iznos za isplatu upisuje nakon izračunavanje u koloni “Rezultat”. Ovo je računica. Iznos u koloni “Resurs” za datog zaposlenog je plata koja mu pripada.

Dakle, registar obračuna je u suštini skup zapisa, sličnih strukturi registru pregovaračke akumulacije. Samo da bi se izvršili složeni proračuni, za njega su specificirana dodatna podešavanja koja vam onda omogućavaju da napravite mnogo virtualnih tabela za registar proračuna, iako je, u suštini, ovaj registar samo skup zapisa prikazanih na slici.

Svaki upis u registar poravnanja odnosi se na određenu vrstu poravnanja i vremenski period.

Vrste proračuna

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

Vrsta proračuna se može smatrati elementom posebnog priručnika kao što je “Plan tipova proračuna” – on takođe ima detalje, tabele, unapred definisane i kreirane elemente od strane korisnika. Može postojati nekoliko takvih „direktorija“ u sistemu.

Na primjer, napravimo plan za tipove proračuna Main i u njemu unaprijed definirane tipove proračuna plata, bonus, odsustvo, poslovno putovanje.

Tipovi proračuna se koriste funkcionalno da odražavaju uticaj unosa registra proračuna jedan na drugog. Ali ukratko govore o uticaju tipova obračuna jedni na druge:

Vrsta obračuna	Opis	Primjer
Po baznom periodu	Rezultat obračuna zavisnog perioda zavisi od rezultata baznog perioda. Ako se rezultat baznog perioda promijeni, rezultat zavisnog perioda se mora ponovo izračunati.	Bonus zavisi od plate u baznom periodu.
Brisanje po periodu	Period važenja zavisnog perioda zamjenjuje period važenja baznog perioda, tako da bazni period ima stvarni	Izostanak s posla utiče na stvarni period plate.
Vodeće kalkulacije	Obračun zavisi od vodećeg proračuna, ali ne direktno nego indirektno, tj. proračun A zavisi od osnovnog proračuna B, a proračun B zavisi od osnovnog proračuna B, dakle A indirektno zavisi od B, tj. A zavisi od vodeće kalkulacije B. U stvari, kada se proračun C promeni, B se može promeniti i prema tome A. Sistem ne prati automatski tako složene zavisnosti, tako da morate da naznačite koji su proračuni vodeći.	Bonus zavisi od osnovice plate, ali indirektno zavisi od izostanaka.

Zbog ovog uticaja, rok važenja upisa u registar naselja podeljen je na četiri perioda:

Period	Opis
Period registracije	U kom periodu je zabeležen događaj, tj. obično kada se unese dokument.
Validnost	U kom periodu događaj funkcioniše, tj. kojem periodu događaj pripada.
Bazni period	Ima smisla samo za periode koji imaju bazni period - opisuje interval baznog perioda.
Stvarni rok važenja	Ako je period važenja zamijenjen drugim vrstama obračuna, onda se stvarni period važenja sastoji od nekoliko perioda kada je ova vrsta obračuna stvarno na snazi.

Period registracije je određen jednim brojem - početkom perioda, koji odgovara učestalosti obračunskog registra. Čak i ako postavimo drugačiji datum u ovom servisnom polju, on će i dalje biti zamijenjen početkom perioda. Preostali periodi su specificirani sa dva polja - početak i kraj perioda, a stvarni period važenja je skup perioda, jer može se sastojati od nekoliko datumskih intervala.

Vremenske karte

Sistem ima mogućnost povezivanja podataka iz računskih registara sa vremenskim grafikonima tako da se može dobiti broj radnih sati za bilo koji period.

Vremenska linija je jednostavan registar informacija u kojem jedna dimenzija pohranjuje datum, druga je povezana s dimenzijom pomoću računskog registra, a jedan od resursa se koristi za praćenje vremena.

Dimenzija koja povezan sa registrom obračuna obično nosišto znači "vrsta grafa".

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

Zašto koristiti dimenziju datuma, a ne periodični registar detalja? Sve je vrlo jednostavno - ako u petak 11. januara imamo 8 radnih sati u periodu od pet dana, to ne znači da ćemo sutradan opet imati 8 radnih sati. Ali ako bismo koristili periodični registar, vrijednost za sljedeći dan bi se uzimala iz prethodnog dana u nedostatku evidencije.

Dakle, imajući određeni period (stvarna akcija, registracija, bazni period itd.) možemo automatski dobiti broj sati za ovaj period prema rasporedu.

Preračunavanje

Ponovno izračunavanje donekle podsjeća na granicu sekvence. Pošto imamo zavisne proračune, pri promeni njihove osnovne i vodeće kalkulacije, sistem mora nekako da zabeleži da moramo ponovo izračunati zavisne proračune.

Tome služe preračuni.

Ako izračunamo osnovne zapise, sistem će zabilježiti u alokacijama da nam je potrebno da izračunamo zavisne zapise. Kada izračunamo zavisne zapise, alokacije će se obrisati.

U suštini, ponovni izračuni su lista unosa registra proračuna koje treba ponovo izračunati.

Ako ne unesete nijedno mjerenje u rekalkulacije, onda kada se osnovni proračuni promijene, svi zavisni zapisi će biti dodati na listu rekalkulacija.

Ako u rekalkulaciji kreiramo dimenziju „Zaposleni“, onda kada se promijeni osnovna kalkulacija za zaposlenog, zavisne evidencije samo za ovog zaposlenog će se dodati u preračune.

Praktični zadatak

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

Formulacija problema:

Neka se bonus odredi kao fiksni procenat plate (minus odsustva i putni dodaci).

Putne naknade neka se isplaćuju u duploj plaći + fiksni iznos plaćanja za svaki dan putovanja.

Neka se radniku za izostanak naplati novčana kazna u iznosu od polovine plate za vrijeme odsustva.

napredak:

Inicijalna obuka

Kreirajmo novi plan za tipove proračuna "Glavni".

Hajde da definišemo vrste proračuna i zavisnosti između njih:

	Basic	Displasing	Prezenteri
Plata		Izostanak, službeno putovanje
Nagrada		Izostanak, službeno putovanje	Plata, izostanak, službeno putovanje
Poslovno putovanje
Apsentizam

Dodajmo ove vrste proračuna u plan "Glavne" tipove proračuna i postavimo zavisnosti u svojstvima tipova proračuna prema tabeli.

U registru obračuna plata napravićemo dimenziju “Zaposleni” tipa “Pojedinci” - tako da će registar imati odjeljak za analitiku za zaposlene.

Konfiguracija već sadrži dokument “Payroll”.

U zaglavlju ima dva datuma - "datum" i "period registracije", kao i dva datuma "datum početka" i "datum završetka" u svakom redu.

Podrazumijeva se da je datum jednostavno datum kada je dokument izvršen, period registracije označava za koji mjesec računamo platu, a datumi u svakom redu opisuju period važenja svake vrste obračuna.

Dodajmo početnu postavku atributa “Podaci” u modul dokumenta - u njega ćemo unijeti početnu platu, podesiti period registracije, period važenja i bazni period.

Modul dokumenta će izgledati otprilike ovako:

Za Svakom TechStringList Iz ciklusa liste

// registar Izračuni

Pokret = Pokreti .Izračuni.Dodaj();

Pokret .S torno= False;

Pokret .U idCalculation = TechStringList.CalculationType;

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

Pokret .PeriodActionEnd= EndDay();

Pokret .Registracijski period = Period registracije;

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

Pokret .BasePeriodEnd= Krajnji dan ( TechStringList.End Date);

Pokret .Employee = TechStringList.Employee;

Pokret .Raspored = TechStringList.Graph;

Pokret .Rezultat = 0;

Pokret .Podaci = TechStringList.Size;

EndCycle ;

Atribut Reversal je potreban za poništavanje unosa (analogno znaku minus).

Označavamo vrstu obračuna, a datume postavljamo na početak i kraj dana. Naravno, bazni period se može uneti samo za vrste obračuna zavisne od osnovice, a podaci se mogu unositi samo za platu, ali sve tako funkcioniše.

Sve dokumente ćemo datirati 20.01.2003., period registracije će biti postavljen na 01.02.2003. Period registracije preračunato na početak perioda 01/01/2003). Koristimo januar 2003. jer su za ovaj period završeni rasporedi radova.

Kreirajmo "Preračunavanje" za ponovno izračunavanje i dodajmo mu dimenziju "Zaposleni" povezanu s dimenzijom "Zaposleni".

Igranje sa Rekalkulacijama.

Da biste igrali igru, otvorite konzolu zahtjeva - obrada " CustomRequest» u konfiguraciji okvira. Kreirajmo novi upit koristeći konstruktor upita i dodajmo virtuelnu tabelu tamo Rekalkulacije, kalkulacije, preračunavanje, tekst zahtjeva će biti ovakav:

ODABIR

CalculationsRecalculation.O objektu Recalculation,

CalculationsRecalculation.In Calculation ID,

Preračunavanje kalkulacija Od zaposlenog

Registar kalkulacije, kalkulacije, preračunavanje KAKO CalculationsRecalculation

Generisaćemo tri dokumenta - prvo ćemo obračunati plate zaposlenima A i B. Zaposleni A radi od 1. do 31. januara, B radi od 1. do 20. januara. Drugi će dodijeliti bonus zaposleniku B za period od 1. do 31. januara, treći će dodijeliti odsustvo zaposleniku A od 20. do 25. januara.

Igramo se sa stvarnim rokom važenja.

Kreirajmo novi upit - ovog puta ćemo mu dodati tabelarne podatke Registar kalkulacije, kalkulacije, stvarni period akcije.

Kreirajmo zahtjev i vidimo da je plata zaposlenog A podijeljena na dva perioda - od 1. do 19. januara i od 26. do 31. januara. Nadam se da razumete da je period podeljen na dva, jer... izostanak zamjenjuje platu.

Mislim da su nam mehanizmi rada računskog registra sve jasniji pred očima.

Hajde da proučavamo grafove.

Pokušajmo sada izračunati platu na osnovu plate zaposlenika.

Kreirajmo novi upit za registar proračuna koristeći virtuelnu tabelu Računski registri. Izračuni. DataGraphics. Možete postaviti parametar za ovu virtuelnu tabelu - uslov za odabir zapisa, na primer Employee=&Odaberite zaposlenika I Tip kalkulacije=&Tip izračuna I Graf=&Grafički prikaz.

Postavimo određene zaposlene, vrste kalkulacija i rasporeda u parametrima zahtjeva i vidimo koliko sati je rezultat.

Kolona rezultata	Značenje
ValuePeriodAction	Za koji rok važenja u satima je izvršen upis u registar.
ValueActualPeriodAction	Koliko je sati zaposleni zaista radio?
ValueBasePeriod	Za platu nema smisla, za bonuse - broj radnih sati u baznom periodu.
ValueRegistration Period	Koliko radnih sati ima u periodu registracije (mesec januar)

Preračuni su sastavni dio obračuna platnog spiska. Informacije o bolovanju, odmorima ili izostancima zaposlenih koje računovodstvo primi sa određenim zakašnjenjem dovode do ponovnog obračuna plata i, shodno tome, premija osiguranja. Stručnjaci 1C govore o tome kako se obračuni i ponovni obračuni premija osiguranja odražavaju na računovodstvo i regulirano izvještavanje u programu 1C: Plaće i upravljanje osobljem 8, izdanje 3.

Prilikom ponovnog obračuna zarada, potrebno je izvršiti ponovni obračun premija osiguranja. Osim toga, razlog za ponovni obračun doprinosa može biti promjena tarife tokom godine ili otkrivanje grešaka, na primjer, neuključivanje obračuna u osnovicu za premije osiguranja.

U ovim slučajevima, računovođa ima pitanja o potrebi, obavezi i pravu da dostavi ažurirane informacije Federalnoj poreznoj službi.

Prema tački 1.2 Procedure za popunjavanje obračuna premija osiguranja, datog u Dodatku br. 2 naredbe Federalne poreske službe Rusije od 10.10.2016. godine br. MMV-7-11/551@, obveznik je obavezan je izvršiti potrebne izmjene Obračuna i dostaviti ažurirani izvještaj poreskom organu ukoliko postoje neevidentirani ili nepotpuni podaci, kao i greške koje dovode do potcjenjivanja iznosa plativih premija osiguranja.

Prilikom odlučivanja da li će dostaviti ažurirani obračun, računovođa mora odgovoriti na sljedeća pitanja:

da li su sve informacije prikazane;
da li su napravljene greške i da li su dovele do potcjenjivanja iznosa premija osiguranja koje se plaćaju.

Podnošenje ažuriranog obračuna može biti obaveza, pravo ili iznuđena potreba.

Ažuriran obračun premija osiguranja

Obaveza dostavljanja ažuriranog obračuna nastaje ako se nakon podnošenja izvještaja Federalnoj poreznoj službi pokaže da su dostavljeni nepotpuni ili netačni podaci o zaposlenima ili su otkrivene greške koje su dovele do potcjenjivanja iznosa plativih premija osiguranja.

Vrste uobičajenih grešaka koje zahtijevaju obavezno podnošenje ažurirane kalkulacije:

1. Zaposlenik nije blagovremeno prijavio promjene u svojim ličnim podacima, a Federalna poreska služba je dala lažne podatke o njemu u Odjeljku 3. Obračuna.

2. Zaposleni je radio u odeljenju koje ima pravo da primenjuje povlašćenu stopu premije osiguranja. Zatim je premješten u jedinicu gdje se primjenjuje osnovna stopa premije osiguranja. Računovodstvo je sa zakašnjenjem primilo informaciju o premeštaju zaposlenog. Obračun doprinosa je izvršen pogrešno po smanjenoj stopi.

3. U početnoj fazi postavljanja programa 1C: Plate i upravljanje osobljem 8, napravljena je greška isključivanjem premije iz obračunske osnovice za premije osiguranja. Ispravljanje greške će rezultirati dodatnim naplatama.

4. Odeljenje sa povlašćenom tarifom gubi pravo da je koristi, ali informacija sa zakašnjenjem stiže do menadžera platnog spiska. Preračunavanje po osnovnoj tarifi dovodi do povećanja iznosa plativih premija osiguranja.

5. Prilikom obračuna premija osiguranja u programu nije naznačeno da je radno mjesto navedeno na listi opasnih profesija koje podliježu dodatnim tarifama. Nakon što je greška otkrivena i ispravljena, preračunavanje je rezultiralo nedostatkom uplaćenih premija osiguranja po dodatnim stopama.

Pogledajmo karakteristike ponovnog izračunavanja premija osiguranja u „1C: Plaće i upravljanje osobljem 8“ izdanje 3 na primjerima.

Primjer 1

Prilikom obračuna premija osiguranja za jedinicu Stock primijenjena je preferencijalna stopa premija osiguranja Stanovnici tehnološko-inovativne posebne ekonomske zone(kod tarife “05”). Ovom tarifom predviđeni su doprinosi Fondu PIO u iznosu od 13% u 2018. godini; u Fondu socijalnog osiguranja 2,9%; u Federalnom fondu obaveznog zdravstvenog osiguranja 5,1%. Upravo na taj način su obračunati doprinosi za zaposlenog V.S. Ivy. Sa mjesečnom zaradom od 10.000 rubalja. Iznos odbitka osiguranja za mjesec bio je:

u Penzionom fondu - 1.300 rubalja;
u FFOMS - 510 rubalja;
u Fondu socijalnog osiguranja - 290 rubalja.

Navedeni iznosi su odraženi u obračunu premija osiguranja za prvi kvartal 2018. godine.

Kada se ispostavilo da je odeljenje izgubilo pravo da primenjuje povlašćenu stopu premija osiguranja, tada je u skladu sa pismima Federalne poreske službe Rusije od 25. oktobra 2017. godine br. GD-4-11/21611@ i Ministarstva Finansije Rusije od 18. decembra 2017. br.?03-15-06/ 84443 postojala je potreba da se dostavi pojašnjavajući Obračun. Za njegovo formiranje potrebno je preračunati premije osiguranja sa novim stopama.

Na kartici Divizije polje treba očistiti Strah od preferencijalnih tarifa. doprinosi. Sada odjel podliježe tarifi koja se koristi za organizaciju i navedena u kartici Organizacije na obeleživaču Računovodstvene politike i druga podešavanja veza Računovodstvena politika u polju Vrsta tarife.

U primjeru 1, organizacija je postavljena na Osnovna stopa premije osiguranja(tarifna oznaka “01”), koja predviđa stope doprinosa u 2018. godini: Penzionom fondu Ruske Federacije u iznosu od 22%; Fond socijalnog osiguranja 2,9%; FFOMS 5,1%. Očigledno je da je Fond PIO „poduplatio“ 9% doprinosa (22% - 13%), a tarifni broj je promijenjen.

U primjeru 1 koji se razmatra, u cilju ponovnog obračuna doprinosa, treba revidirati postupak obračuna prihoda. Dokument je namijenjen registraciji postupka evidentiranja prihoda i ponovnog obračuna premija osiguranja iz prethodnog perioda. (meni Porezi i naknade). Na obeleživaču Podaci o prihodima potrebno je ručno razjasniti sva primanja zaposlenih. Istovremeno, na obeleživaču Procijenjeni doprinosi Premije osiguranja će se automatski preračunavati.

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

u Penzionom fondu Rusije - 2.200 rubalja;
u Federalnom fondu obaveznog zdravstvenog osiguranja i Fondu socijalnog osiguranja - iznos se nije promijenio i iznosio je 510 rubalja, respektivno. i 290 rub.

Nakon ponovnog obračuna premija osiguranja za prvi kvartal, potrebno je pripremiti pojašnjene Obračune. Korištenje usluge 1C-izvještavanje, potrebno je kreirati nove izvještaje za periode koji se koriguju i za Naslovna strana ukazati Broj ispravke(Sl. 2). Pojašnjenja su uticala na sve zaposlene u odeljenju, jer je svima promenjena tarifna oznaka. Stoga se odjeljci 3 u ažuriranom Obračunu formiraju za sve zaposlene u odjeljenju. U drugim slučajevima, kada je formiranje ažurirane kalkulacije uzrokovano promjenama podataka ili vremenskih razgraničenja pojedinih zaposlenika, odjeljak 3 prikazuje podatke samo za te zaposlenike. U svakom slučaju, preostale rubrike obračunskog obračuna popunjavaju se potpuno novim podacima.

Rice. 2. Naslovna strana pojašnjenog obračuna premija osiguranja za prvi kvartal 2018.

Pravo na dostavljanje ažuriranog Obračuna premija osiguranja

Osiguranici mogu dostaviti inspekciji ažurirani Obračun ako pronađu greške koje dovode do precjenjivanja iznosa premija osiguranja. Naime, prilikom sljedećeg obračuna doprinosa u tekućem periodu vrši se preračun, a rezultat se odražava u izvještaju za naredni period. Opcije situacije koje vam omogućavaju da predstavite ažuriranu kalkulaciju:

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

2. Svako preračunavanje obračuna zaposlenih, što dovodi do ponovnog obračuna premija osiguranja u pravcu njihovog smanjenja.

Primjer 2

Prilikom obračuna zarade za jun zaposlenom S.S. Gorbunkov je nagrađen:

isplata plate - 7.500 rubalja;
Isplata službenog puta (na osnovu prosječne zarade) za jun - 2.500 rubalja.

Premije osiguranja su obračunate po osnovnoj stopi. U junu doprinosi iz plate S.S. Gorbunkov su bili:

u Penzionom fondu Rusije - 2.200 rubalja;
u FFOMS - 510 rubalja;
u Fondu socijalnog osiguranja - 290 rubalja.

Ovi doprinosi su uplaćeni i uključeni u Polugodišnji račun za 2018. godinu. Bolovanje dostavljeno računovodstvu za period 25.06.2018-30.06.2018. godine ne predstavlja razlog za formiranje ažuriranog Obračuna. Dokument registrovan u programu Bolovanje poništava prethodno akumulirani iznos putnih naknada (slika 3).

Rice. 3. Preračunavanje putnih naknada u dokumentu „Bolovanje“.

Bolovanje je organizacija dobila u julu. Ovo nije greška i ne dovodi do nedovoljnog plaćanja premija osiguranja. S obzirom na to da se na bolovanje ne plaćaju doprinosi za osiguranje, došlo je do preplate doprinosa u iznosu od:

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

U programu Bolovanje, registrovan jul 2018, utiče na obračun premija osiguranja u tekućem mjesecu, umanjujući osnovicu za obračun.

U takvoj situaciji ne postoje zakonski zahtjevi za podnošenje ažurirane kalkulacije. Sva preračunavanja se dešavaju u narednom periodu i odražavaju se u narednim izvještajima. Ali u isto vrijeme, organizacija ima pravo da pojasni izvještaj za pola godine i obavijesti Federalnu poreznu službu o preplati koja je nastala podnošenjem pojašnjenja.

Međutim, prije kraja mjeseca ne biste trebali ishitreno pojašnjavati Obračun. Uostalom, razni dokumenti se registruju tokom cijelog mjeseca. U nekom trenutku dokument Bolovanje zaista može stornirati prihod iz prethodnog mjeseca, a na osnovu rezultata obračuna plaća za mjesec, drugi dokument, npr. Obračun plata i doprinosa, izvršit će dodatna razgraničenja koja prelaze prihod od ukidanja prethodnog perioda. Kao rezultat toga, prihod tekućeg mjeseca će se smanjiti za iznos storniranja službenog puta, neće ostati minusi za prethodni mjesec, a izvještaj o usklađivanju neće prikazati nikakve promjene.

Potreba za dostavljanjem ažuriranog Obračuna premija osiguranja

U određenom broju slučajeva, uprkos nepostojanju obaveze dostavljanja ažuriranog obračuna, ugovarač osiguranja nema drugu mogućnost da prijavi svoju preplatu premija, osim podnošenja ažuriranja:

1. Kao rezultat preračuna doprinosa u tekućem periodu, zaposleni dobija negativan iznos. Izvještaj sa negativnim iznosom ne može se podnijeti Federalnoj poreznoj službi. Stoga postoji samo jedan izlaz - generirati ažurirani izvještaj za prethodni period.

2. Zaposleni je radio na opasnim poslovima. Premije osiguranja su obračunate po dodatnoj stopi. Računovodstvo je sa zakašnjenjem primilo informaciju o prelasku radnika na posao u normalnim uslovima. Kao rezultat ponovnog obračuna, nemoguće je umanjiti obračunate doprinose po dodatnoj stopi, jer na obračune radnika u tekućem periodu više se ne plaćaju doprinosi po dodatnoj stopi.

Primjer 3

U ovom slučaju, za razliku od prethodnog primjera 2, negativan iznos premije osiguranja nastao kao rezultat otkazivanja službenog putovanja neće biti nadoknađen razgraničenjem. Uprkos činjenici da će zbog obračuna ostalih zaposlenih ukupan iznos premija osiguranja biti pozitivan, u Odjeljku 3 zaposleni će ostati negativne vrijednosti, što je nedopustivo. I stoga će računovođa morati kreirati dokument Preračunavanje premija osiguranja, preračunati doprinose za juni, generisati i dostaviti ažurirani Obračun Federalnoj poreskoj službi.

Program 1C: Upravljanje platama i osobljem 8 automatizira proces ponovnog obračuna premija osiguranja. Korištenje usluge 1C-Izvještavanje početni i pojašnjavajući obračuni za premije osiguranja se generišu automatski. Međutim, odluka o pripremi obračunskog obračuna ostaje na računovođi. Analizirajući posljedice registracije dokumenta kojim se mijenjaju obračuni u periodu za koji je izvještaj već dostavljen, računovođa ili preračunava premije osiguranja za prethodni period, ili se obračun automatski vrši u tekućem mjesecu.

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