1c újraszámítások. Fizetéskorrekciók és újraszámítások

Az újraszámítások a bérszámfejtés szerves részét képezik. Az alkalmazottak betegszabadságáról, szabadságáról vagy távollétéről szóló információk, amelyeket a számviteli osztály némi késéssel kapnak meg, a fizetések és ennek megfelelően a biztosítási díjak újraszámítását eredményezik. Az 1C szakértői arról beszélnek, hogy a biztosítási díjak számításai és újraszámításai hogyan tükröződnek a számvitelben és a szabályozott jelentésekben az 1C: Fizetések és személyzeti menedzsment 8 program 3. kiadásában.

A bérek újraszámítása során szükségessé válik a biztosítási díjak újraszámítása. Ezen túlmenően a járulékok újraszámításának oka lehet a díjszabás év közbeni változása vagy hibák feltárása, például a számításnak a biztosítási díjalapba való be nem adása.

Ezekben az esetekben a könyvelőnek kérdései vannak a szövetségi adószolgálatnak történő frissített információk benyújtásának szükségességével, kötelezettségével és jogával kapcsolatban.

Az Oroszországi Szövetségi Adószolgálat 2016.10.10-i, ММВ-7-11/551@ számú végzésének 2. számú mellékletében található, a biztosítási díjak számításának kitöltésére vonatkozó eljárás 1.2. pontja szerint a kifizető köteles a Kalkulációban a szükséges változtatásokat elvégezni, és az adóhatóságnak aktualizált jelentést benyújtani, ha az adatok nem rögzítettek vagy hiányosak, valamint olyan hibákat észleltek, amelyek a fizetendő biztosítási díj összegének alulbecsléséhez vezettek.

A frissített számítás benyújtásának eldöntésekor a könyvelőnek meg kell válaszolnia a következő kérdéseket:

• hogy minden információ tükröződött-e;
• elkövettek-e hibákat, és nem vezettek-e ezek a fizetendő biztosítási díjak összegének alulbecsléséhez.

Az aktualizált kalkuláció benyújtása lehet kötelezettség, jog vagy kényszerűség.

A biztosítási díjak frissítése

A frissített számítás benyújtásának kötelezettsége akkor merül fel, ha a jelentésnek a Szövetségi Adószolgálathoz történő benyújtása után kiderül, hogy hiányos vagy helytelen információkat nyújtottak be az alkalmazottakkal kapcsolatban, vagy olyan hibákat fedeztek fel, amelyek a fizetendő biztosítási díjak alulbecsléséhez vezettek.

Gyakori hibák típusai, amelyekhez frissített kalkulációt kell benyújtani:

1. A munkavállaló nem jelentette azonnal a személyes adataiban bekövetkezett változásokat, és a Szövetségi Adószolgálat hamis adatokat közölt róla a számítás 3. szakaszában.

2. A munkavállaló kedvezményes mértékű biztosítási díj alkalmazására jogosult osztályon dolgozott. Aztán átkerült egy olyan egységhez, ahol a biztosítási alapdíj mértékét alkalmazzák. A munkavállaló áthelyezéséről későn érkezett információ a számviteli osztályhoz. A járulékok csökkentett kulcson történő számítása hibásan történt.

3. Az 1C: Fizetések és személyzeti menedzsment 8 program kezdeti beállítási szakaszában hiba történt, amikor a díjat kizárták a biztosítási díjak számítási alapjából. A hiba kijavítása további díjakat von maga után.

4. A kedvezményes tarifával rendelkező osztály elveszti igénybevételi jogát, de az információ késéssel jut el a bérszámfejtőhöz. Az alaptarifa szerinti átszámítás a fizetendő biztosítási díjak növekedéséhez vezet.

5. A program a biztosítási díjak számítása során nem jelezte, hogy a beosztás szerepelne a többlettarifa alá eső veszélyes szakmák listáján. A hiba feltárása és kijavítása után az újraszámítás a biztosítási díjak többletdíjas alulfizetését eredményezte.

Nézzük meg példákon keresztül a biztosítási díjak újraszámításának jellemzőit az „1C: Fizetések és személyzeti menedzsment 8” 3. kiadásában.

1. példa

Egy egység biztosítási díjának kiszámításakor Készlet kedvezményes biztosítási díjtételt alkalmaztak A technológiai-innovációs különleges gazdasági övezet lakói(„05-ös tarifakód”). Ez a tarifa 2018-ban 13%-os hozzájárulást ír elő a nyugdíjalapba; a Társadalombiztosítási Alapban 2,9%; a Szövetségi Kötelező Egészségbiztosítási Alapban 5,1%. Pontosan így számították ki a járulékokat a munkavállaló V.S. Borostyán. 10 000 rubel havi keresettel. A havi biztosítási levonások összege:

• a nyugdíjalapban - 1300 rubel;
• FFOMS-ben - 510 rubel;
• a Társadalombiztosítási Alapban - 290 rubel.

A feltüntetett összegek a 2018. első negyedévi biztosítási díjszámításban is tükröződtek.

Amikor kiderült, hogy a részleg elvesztette a kedvezményes biztosítási díjak alkalmazásának jogát, az Oroszországi Szövetségi Adószolgálat 2017. október 25-i, GD-4-11/21611@ sz. levelének és a minisztériumnak megfelelően Oroszország Pénzügyeinek 2017. december 18-i száma 03-15-06/ 84443 pontosító kalkuláció benyújtására volt szükség. Megalakításához szükséges a biztosítási díjak új díjtételekkel történő újraszámítása.

A kártyában Osztályok a mezőt meg kell tisztítani Kedvezményes tarifális félelem. hozzájárulások. Most a részlegre a szervezetnél használt és a kártyán meghatározott tarifa vonatkozik Szervezetek a könyvjelzőn Számviteli politika és egyéb beállítások link Számviteli politika mezőben Tarifa típusa.

Az 1. példában a szervezet a következőre van állítva Alapbiztosítási díj mértéke(„01 tarifakód”), amely 2018-ban járulékkulcsokat ír elő: az Orosz Föderáció Nyugdíjalapjába 22% összegben; Társadalombiztosítási Alap 2,9%; FFOMS 5,1%. Nyilvánvaló, hogy a Nyugdíjpénztár a járulékok 9%-át „alulfizette” (22% - 13%), és megváltozott a tarifakód.

A vizsgált 1. példában a járulékok újraszámítása érdekében felül kell vizsgálni a jövedelemelszámolási eljárást. A dokumentum az előző időszak bevételeinek nyilvántartására és a biztosítási díjak újraszámítására vonatkozó eljárás nyilvántartására szolgál. (menü Adók és díjak). A könyvjelzőn Jövedeleminformáció minden munkavállalói jövedelmet manuálisan kell tisztázni. Ugyanakkor a könyvjelzőn Becsült hozzájárulások A biztosítási díjak automatikusan újraszámításra kerülnek.

A munkavállaló biztosítási díjainak újraszámítása eredményeként V.S. Ivy 10 000 rubel havi keresettel. A havi biztosítási levonások összege:

• az oroszországi nyugdíjalapban - 2200 rubel;
• a Szövetségi Kötelező Egészségbiztosítási Alapban és a Társadalombiztosítási Alapban - az összeg nem változott, és 510 rubelt tett ki. és 290 dörzsölje.

Az első negyedévre vonatkozó biztosítási díjak újraszámítása után pontosító Kalkulációkat kell készíteni. A szolgáltatás használata 1C-jelentés,új jelentéseket kell készíteni a javítandó időszakokra és a Címlap jelezze Javítási szám(2. ábra). A pontosítások az osztály valamennyi dolgozóját érintették, mivel mindenki tarifakódja megváltozott. Ezért a frissített számítás 3. szakaszai az osztály összes alkalmazottjára vonatkoznak. Más esetekben, amikor a frissített Számítás kialakítását az egyes alkalmazottak adataiban vagy időbeli elhatárolásában bekövetkezett változások okozzák, a 3. szakasz csak ezekre a munkavállalókra vonatkozóan jelenít meg adatokat. Mindenesetre a pontosító számítás többi része teljesen új adatokkal töltődik ki.

Rizs. 2. A 2018. I. negyedévi biztosítási díjak pontosító számításának címlapja

Frissített biztosítási díjkalkuláció benyújtásának joga

A szerződők frissített Kalkulációt nyújthatnak be az ellenőrzésnek, ha olyan hibákat találnak, amelyek a biztosítási díjak túlbecsléséhez vezetnek. Valójában az aktuális időszak következő járulékszámítása során újraszámítás történik, és az eredmény megjelenik a következő időszakra vonatkozó jelentésben. Szituációs lehetőségek, amelyek lehetővé teszik egy frissített számítás bemutatását:

1. A munkavállaló a teljes ledolgozott hónapra fizetést kapott. A biztosítási díjak kiszámítását benyújtották a Szövetségi Adószolgálathoz, de később kiderült, hogy a munkavállaló betegszabadságon vagy szabadságon volt saját költségén. A díjszámítási alapban nem szereplő passzív időbeli elhatárolás váltotta fel a biztosítási díjköteles passzív időbeli elhatárolást, amely díjtúlfizetéshez vezetett.

2. A munkavállalói időbeli elhatárolások bármilyen újraszámítása, amely a biztosítási díjak újraszámítását eredményezi annak csökkentésére.

2. példa

A júniusi bérek kiszámításakor az alkalmazott S.S. Gorbunkovot díjazták:

• fizetés kifizetése - 7500 rubel;
• üzleti út kifizetése (átlagkereset alapján) júniusban - 2500 rubel.

A biztosítási díjak alapdíjjal kerültek kiszámításra. Júniusban S. S. fizetéséből származó járulékok. Gorbunkov voltak:

• az oroszországi nyugdíjalapban - 2200 rubel;
• FFOMS-ben - 510 rubel;
• a Társadalombiztosítási Alapban - 290 rubel.

Ezeket a hozzájárulásokat befizették, és a 2018-as félévi számlában szerepeltetik. A 2018-06-25-2018-06-30 időszakra a számviteli osztályhoz benyújtott betegszabadság nem ad okot aktualizált Kalkuláció kialakítására. A programban regisztrált dokumentum Betegszabadság megfordítja a korábban felhalmozott utazási költségtérítés összegét (3. ábra).

Rizs. 3. Az utazási költségtérítés újraszámítása a „Betegszabadság” bizonylatban

A betegszabadságot júliusban kapta meg a szervezet. Ez nem hibahelyzet, és nem eredményezi a biztosítási díjak alulfizetését. Mivel a betegszabadságra felhalmozott összeget nem kell biztosítási járulékfizetési kötelezettség alá vonni, így járulék túlfizetés történt a következő összegben:

• az Orosz Föderáció Nyugdíjalapjában - 550 rubel;
• az FFOMS-ben - 127,50 rubel;
• a Társadalombiztosítási Alapban - 72,50 rubel.

Egy programban Betegszabadság, regisztrált 2018. július, a tárgyhavi biztosítási díjak számítását érinti, csökkenti a számítási alapot.

Ilyen helyzetben nincs jogszabályi előírás a frissített kalkuláció benyújtására. Minden újraszámítás a következő időszakban történik, és a következő jelentésekben is megjelenik. Ugyanakkor a szervezetnek jogában áll pontosítani a féléves jelentést, és pontosítás benyújtásával értesíteni a Szövetségi Adószolgálatot a túlfizetésről.

A hónap vége előtt azonban nem szabad elhamarkodottan pontosítania a számítást. Hiszen a hónap folyamán különféle dokumentumokat regisztrálnak. Valamikor a dokumentum Betegszabadság valóban megfordíthatja az előző havi jövedelmet, és a havi bérszámítás eredménye alapján egy másik dokumentum, pl. Bérek és járulékok számítása, további elhatárolásokat fog végezni, amelyek meghaladja az előző időszak visszaírási bevételét. Emiatt a tárgyhavi bevétel az üzleti út visszafordításával csökken, az előző havi mínuszok nem maradnak, és a korrekciós jelentés sem mutat változást.

Frissített biztosítási díjkalkuláció benyújtásának szükségessége

Számos esetben a szerződőnek az aktualizált kalkuláció benyújtási kötelezettségének hiánya ellenére nincs más lehetősége a díjtúlfizetés bejelentésére, kivéve a frissítés benyújtását:

1. A tárgyidőszaki járulékok újraszámítása következtében a munkavállaló negatív összeget kap. Negatív összegű jelentést nem lehet benyújtani a Szövetségi Adószolgálathoz. Ezért csak egy kiút van - frissített jelentést készíteni az előző időszakról.

2. A munkavállaló veszélyes munkát végzett. A biztosítási díjakat pluszkulcs alapján számították ki. A munkavállaló normál munkakörülmények között történő munkába való áthelyezéséről szóló tájékoztatás későn érkezett a számviteli osztályhoz. Az újraszámítás eredményeként a számított járulékok pótlólagos csökkentése nem lehetséges, mert a munkavállaló tárgyidőszaki időbeli elhatárolásaira már nem kell pótlólagos járulékot fizetni.

3. példa

Ebben az esetben az előző 2. példától eltérően az üzleti út lemondásából eredő biztosítási díj negatív összegét nem kompenzálják időbeli elhatárolásokkal. Annak ellenére, hogy a többi munkavállaló elhatárolása miatt a biztosítási díj főösszege pozitív lesz, a 3. pontban a munkavállaló negatív értékek maradnak, és ez elfogadhatatlan. Ezért a könyvelőnek dokumentumot kell készítenie Biztosítási díjak újraszámítása, újraszámolja a júniusi járulékokat, generál és küldjön el egy frissített kalkulációt a Szövetségi Adószolgálatnak.

Az 1C: Fizetés és személyzeti menedzsment 8 program automatizálja a biztosítási díjak újraszámításának folyamatát. A szolgáltatás használata 1C-jelentés A biztosítási díjak kezdeti és pontosító számításai automatikusan generálódnak. Az egyértelműsítő számítás elkészítésének döntése azonban a könyvelőnél marad. Miután elemezte egy olyan bizonylat nyilvántartásba vételének következményeit, amely megváltoztatja a számításokat abban az időszakban, amelyre vonatkozóan már jelentést nyújtottak be, a könyvelő vagy újraszámolja az előző időszak biztosítási díjait, vagy a számítás automatikusan megtörténik az aktuális hónapban.

A szerkesztőtől. A cikkben olvassa el az 1C:Enterprise 8-ban bevezetett mechanizmust a biztosítási díjak kiszámításának ellenőrzési arányainak ellenőrzésére, amely figyelembe veszi a korrekciós számítások adatait.

Jó napot. Rég nem hallottam felőled :) Ma szeretném tisztázni a ZUP 3.0-ban az elmúlt időszakokra vonatkozó újraszámítások jellemzőit. Ez a cikk arról szól, hogyan működik belülről, és ennek megfelelően irányíthatja ezt a folyamatot. Hiszen valószínűleg Ön is találkozott már azzal, hogy a program váratlanul ismeretlen összegeket halmoz fel az embernek, megfordítja azokat, eltérések jelennek meg... és ezt nem akarta, vagy akarta. de ez nem így történt))

Kezdjük. Először is, az újraszámítások abban a pillanatban történnek, amikor a fizetést „bérszámfejtési” dokumentumnak tekinti. Erre a célra egy „További elhatárolások, újraszámítások” fület biztosít. Az első dolog, amit tanácsolni szeretnék: mindig ellenőrizze a táblán lévő adatokat "További elhatárolások, újraszámítások" . Előfordulhat, hogy az Ön tudta nélkül megjelennek ott, és nem fogja megérteni, hogy a számításban szereplő összeg miért nem ugyanaz.

Elméletileg a dokumentum fejlécében mindig figyelmeztetnek minket, hogy a program megszámlál valakit, vagy újra kell töltenünk, mert... valakit nem számoltak be.

Honnan tudja a program, hogy kit kell számolnom és melyik hónapra?

Ezt a tetteid alapján határozza meg. Visszadátumozta a dokumentumot? A program megvizsgálta azokat az alkalmazottakat, akik ebben a dokumentumban szerepeltek, és rögzítették a listájukat. Javított a bizonylaton (például javította a múlt havi munkaidő-nyilvántartást)? A program mindenkire emlékezett ebből a munkaidő-nyilvántartásból, és ezt a hónapot újraszámolják. Szinte minden dokumentum, mind a személyi, mind a bérszámfejtés érintett. Ebben az esetben a programot nem érdekli, hogy a dokumentum érintése befolyásolta-e a fizetését vagy sem.

Tegyük fel, hogy elmentél az álláspályázathoz, és oda írtál egy megjegyzést, ami után újra feltetted a dokumentumot. Se fizetés, se kinevezési dátum, se pozíció... semmihez nem nyúltak. De a program nem tudja, hogy miért írta felül az előző időszak dokumentumát, nem telepata, egyszerűen rögzítette ezt az alkalmazottat.

Második tipp (más néven első titok): az „összes funkción” keresztül lépjen be a „Bérezés újraszámítása” információs regiszterbe. Ne légy lusta és mássz be! Jelentkezzen be minden bérszámfejtés előtt és minden visszamenőleges dokumentum után.

Sok könyvelő ezt a tanácsot úgy érzékeli, hogy új munkája van, amiből már elege van. De ha nem mássz oda, akkor nem fogod megérteni a munka logikáját, és ha neked a program olyan, mint egy fekete doboz, akkor nem fogsz megbarátkozni vele. A barátság a barát belső világának megértésével kezdődik! Ha nem törődsz ellenfeled belső világával, akkor ő nem a barátod.

Szóval, bemásztál? Nagy. Általában üres és egy sor sincs benne, de amint visszamenőleg hozzáérsz valamihez, megjelenik itt egy rekord, amely tartalmazza a munkavállalót és az újraszámolandó hónapot.

Harmadik tipp: ha nem ért egyet a program azon szándékával, hogy beszámítsa a munkavállalót, törölje a sort ebből a nyilvántartásból.

1. Érted már, hogyan jelennek meg a vonalak? Nagy.

2. A „Bérszámfejtés” bizonylat kitöltésekor és a nyilvántartásban szereplő sorok alapján történő feladásakor újraszámításra és a táblázat kitöltésére kerül sor. – További elhatárolások, újraszámítások.

3. Az újraszámított munkavállalók törlésre kerülnek a nyilvántartásból, és az üressé válik.

4. A „Bérszámfejtés” bizonylat törlésekor a sorok visszakerülnek a helyükre, így az újratöltéskor minden a helyére kerül.

Negyedik tipp (talán javítják): A „Bérszámfejtés” bizonylat újratöltése előtt terítse szét!

Az algoritmus alapján a bizonylat feladása után a nyilvántartás törlődik. Ha törlés nélkül tölti fel, akkor a program nem fogja tudni, hogy kit kell számolni, és az újraszámításokkal ellátott táblázatos rész üres lesz. Ez igaz volt a 21. kiadásra. Még nem volt időm megnézni a 22. kiadásban.

Egy másik árnyalat, ha a dokumentumban az újraszámításhoz szükséges személyek listájára kattint, megnyílik az információs nyilvántartási lista űrlapja– A fizetések újraszámítása.És lesz egy gomb is egy bejegyzés „törlésére”.

P.S. (fontos)

A vizsgálat oka a számviteli 3.0-s eredeti adatok átvitele során a végtelen újraszámítás volt. Az átállás során meg kell érintenie az összes technikát és fordítást)) ezt követően törölje a nyilvántartás összes tartalmát " "Bérek újraszámítása", különben minden évről újrakalkulációt kapsz Kezdő lépések a ZUP 3.0-ban a Accounting 3.0-ból való adatátvitellel

Ez történt a demo adatbázisban, amikor egy feladatot újra végrehajtottak. És amikor átviszi az 1C Accounting 3.0-t az 1C ZUP 3.0-ba, mindent újra megtesz, ami lehetséges:

Ennyi, kérdések kommentben és ne féljetek a programtól, meg kell érteni és szeretettel fizet érte.

Ebben a cikkben megvizsgáljuk a számítási nyilvántartásokkal való munka elméleti alapjait, és kiszámítjuk a munkavállaló bérét a ledolgozott órák számával arányosan.

Elmélet

Számítási regiszter (RR)- egy konfigurációs metaadat objektum, amelyet az 1C rendszerben végzett időszakos számítások végrehajtására használnak. A számítási nyilvántartások kézenfekvő alkalmazási területei a következők: bérszámfejtés, bérleti díj számítás, bérleti díj számítás.

A számítási regiszterek felépítésükben hasonlóak a halmozási regiszterekhez vagy információs regiszterekhez. Ezek, akárcsak a felhalmozási regiszterek, rendelkeznek mérésekkel, erőforrásokkal, részletekkel, de a számítási regiszterek működési elve teljesen más.

Az akkumulációs regiszterben végzett mérések lényegében a következőképpen szolgálnak: szűrő» melynek keretében a felhalmozási nyilvántartásból kapunk adatokat. Példaként, amikor a felhalmozási nyilvántartás szerinti „maradványokat” vesszük egy bizonyos tételhez kapcsolódóan „Fennmaradó áruk” vagy egy „Munkavállalók fizetése” információs nyilvántartás szerinti „legfrissebb darabot” egy adott munkavállaló vonatkozásában. . A felhalmozási regiszterrel ellentétben az időszakos számítási regiszterben végzett mérések a „” megvalósítását szolgálják (ilyenkor az idõtartamú számítási típusok versenyeznek egymással a rekord érvényességi idõtartamában, azaz például az üzleti út számítása típus kiszorítja az érvényességi időszakra vonatkozó bérszámítási típust) és „“(ekkor a bónuszszámítás típusa a korábbi időszakokra vonatkozó bérszámítás típusától függ).

elfojtási mechanizmus hatásperiódus szerint«:

Itt azt látjuk, hogy az „Üzleti utazás” számítási típus időbeli időtartammal rendelkezik, és április 10-től április 20-ig érvényes, a „Bérek” számítási típusnál kiszorító számítási típusként az „Üzleti utazás” van feltüntetve. A „bér” idővel is kiterjed, és április 1-től április 30-ig érvényes. Mivel a „Bérezés” számítási típusnál az „Üzleti út” kiszorító számítási típusként van feltüntetve (nagyobb prioritású, mint a fizetés), és az illetmény érvényességi idejére érvényes, akkor az illetmény kiszorításra kerül egy üzleti út, ill. a „Bér tényleges érvényességi ideje” alakul ki.” Az illetmény tényleges érvényességi ideje „Ez az illetmény üzleti út miatti kitelepítés utáni érvényességi ideje, esetünkben 2 időszakból áll - április 1-től 9-ig és április 21-től 30-ig, összesen pedig 19 nap. A periódusalapú eltolási mechanizmus csak hosszú távú számításoknál működik.

A fenti ábra grafikusan mutatja a " függőségi mechanizmus bázisidőszakonként«:

Tegyük fel, hogy 2017. április végén a fizetés 10%-ának megfelelő jutalmat szeretnénk adni egy alkalmazottnak. A bónusz számításának alaptípusaként a fizetés szerepel.

De a prémium kiszámításának „alapjaként” nem a teljes április hónapot vesszük, hanem csak az április 10-től április 20-ig tartó időszakot (11 nap). Számítsuk ki a bónusz alapját, a munkavállaló fizetése 60 000 rubel, egy hónapban 30 nap van, napi fizetés = 60 000/30 = 2 000 rubel. Következő 2000*11 = 22000 dörzsölje. A prémium kiszámításának alapja 22 000 rubel.

Számítsuk ki a prémiumot: (22000/100)*10 = 2200 rubel. A fizetés 10%-ának megfelelő bónusz 2200 rubel.

Az alkalmazás metaadat-objektuma „Számítási típusok terve” szorosan kapcsolódik a számítási regiszterhez.

Számítási típusok terve (PVR)- konfigurációs metaadat objektum, amely információkat tárol a számítási típusok típusairól, és meghatározza a különböző számítások egymásra gyakorolt ​​hatását.

Egy számítási típusterv több számítási regiszterben is használható, de egy számítási regiszter nem használhat egyszerre több számítási típustervet.

A számítási regiszter egy táblázat, amelyben a számított adatokat tárolják, és számítási típusok szerint az adatok kiszámítására szolgáló algoritmusokat tárolják. A számítási nyilvántartásnak rendelkeznie kell legalább egy okmánynyilvántartóval, amely mozgásokat végez a számítási nyilvántartásban (például Bérszámfejtés).

Az 1C Enterprise rendszerben a számítási mechanizmusok úgy vannak kialakítva, hogy először bejegyzéseket kell tenni a számítási regiszterben, és csak ezután kell elvégezni a számítást ezen adatok alapján. Például lehetetlen egy fizetés alapján jutalmat kiszámítani mindaddig, amíg ugyanez a fizetés nincs rögzítve a számítási nyilvántartásban.

Gyakorlat

Nézzük meg közelebbről a számítási regisztereket a gyakorlatban:

1. lépés Kezdjük a számítási típusok tervével. Számítási regiszter létrehozása előtt létre kell hoznia egy számítási típustervet. A számítási típusokhoz a számítási regiszter előtt készítünk egy tervet, mivel a számított adatok tárolására szolgáló táblázat (azaz számítási regiszter) létrehozása előtt meg kell adni az ezen adatok kiszámítására szolgáló algoritmusokat (azaz a számítási típusok tervet).

Készítsünk tervet az „Alapdíjak” számítási típusaira. Azonnal menjünk a „Számítás” fülre. Itt azonnal látjuk a zászlót" Érvényességi időt használ", ha ez a jelző be van állítva, a tervben szereplő összes számítási típus rendelkezik hossz az időben(például Fizetés, Üzleti út), és ehhez a számítási típusú tervhez is: „ elfojtási mechanizmus hatásperiódus szerint". Ha az „Érvényességi időszakot használja” jelző nincs beállítva, akkor a számítási típusoknak nem lesz időhosszabbítása (például Bónusz, Finom), és az „Érvényességi időszak szerinti eltolási mechanizmus” nem működik. Ezen a lapon találhatók a „Függőség az alaptól” és „A számítási típusok alapvető tervei” szakaszok is - ezek a „ függőségi mechanizmus bázisidőszakonként", de erről később beszélünk. Egyelőre hagyjuk a „Függetlenség az alaptól” funkciót „Független” módban.

Hozzon létre egy előre definiált „Bérek” számítási típust. Az „Alap” lapon minden egyszerű. Állítsa be a számítási típus nevét és kódját.

Hála annak, hogy kitűztük a zászlót" Érvényességi időt használ"Most van egy lapunk" Kiszorítás"és bekapcsolva" időszak alapú elnyomási mechanizmus«.

Ezen a lapon feltüntetjük azokat a számítási típusokat, amelyek érvényességi idő szerint kiszorítják a fizetést (például üzleti út).

jegyzet: a „Kiszorításban” olyan számítási típusokat adhat hozzá, amelyek csak ehhez a számítási típustervhez tartoznak.

Van egy lap is " Előadók»—azokat a számítási típusokat jelzi, amelyek megváltoztatásakor újra kell számítani az aktuális számítási típust. Itt más számítási típusú tervekből is megadhat számítási típusokat. Például a „Bónusz” számítási típusnál a „Bér” számítási típus a vezető, pl. A fizetés változásakor a bónuszt is újra kell számolnunk, mert A bónusz számítása a fizetés függvényében történik. Ebben az esetben a „Bér” számítási típus az „Alap felhalmozás” PRP-hez tartozik, amely érvényességi időszakot használ, a „Bónusz” számítási típus pedig a „További elhatárolások” PRP-hez, amely nem használ érvényességi időt.

2. lépés. Hozzunk létre egy „Charts” könyvtárat az alapértelmezett struktúrával. Az „Ütemterv” könyvtárban tároljuk a dolgozók munkaidejét (öt napos, hatnapos stb.).

3. lépés.Szükségünk van egy objektumra is, amelyben a Gyártási naptárat tároljuk (munkanapokon és hétvégén). Ebből a célból egy nem időszakos független információnyilvántartást használunk.

Hozzunk létre egy nem időszakos független információs regisztert „Munkaütemezések”, 2 dimenzióval: „Dátum” és „Ütemezés”, valamint az „Órák száma” erőforrással.

A „Munkarendek” információs nyilvántartásnak köszönhetően a munkabérből a ledolgozott napok arányában tudunk majd bért számolni.

4. lépés.Hozzon létre egy „Bérszámfejtési” dokumentumot az alábbiakban látható részletes szerkezettel:

Követelmények:

Az operatív végrehajtás „Tiltásra” van állítva mert nincs értelme az 1C-ben az időszakos elszámolások mechanizmusának - soha nem számoljuk valós időben a bónuszokat, fizetéseket vagy bírságokat.

Hozzon létre egy dokumentum űrlapot alapértelmezett beállításokkal.

5. lépés. Végül elérkeztünk a számítási regiszterek létrehozásához.

A számítási regiszter metaadat-objektuma a konfigurátor „Számítási regiszterek” ágában található.

Készítsünk egy számítási regisztert „Alapdíjak”. Nézzük meg az alábbi számítási regiszter beállításait:

1. A „Számítási típusok terve” mezőben jelölje meg az 1. lépésben létrehozott „Alapdíjak” PVR-t.

2. Állítsa az „Érvényességi időszak” jelzőt „Igaz” értékre, mert Az 1. lépésben meghatározott PVR rendelkezik időbeli meghosszabbítás.

A jelző beállítását követően azonnal elérhetővé válnak számunkra az „Action Period”, „Action PeriodStart”, „ActionPeriodEnd” szabványos adatok, ami azt jelenti, hogy a számítási regiszterben regisztrált számítástípusok is rendelkeznek hossz az időbenés hozzáférésünk van " elfojtási mechanizmus hatásperiódus szerint«.

P.S. Ha olyan PVR-t ad meg, amely rendelkezik hossz az időben ha az „Érvényességi időszak” jelzője „False”-ra van állítva, akkor ez a PVR olyan PVR-ként fog működni, amely nem rendelkezik időbeli meghosszabbítás.

3. Az „Érvényességi időszak” jelző „Igaz” értékre állítása után a „Chart”, „Chart value”, „Chart date” mezők elérhetővé válnak számunkra.

Az „Ütemterv” mezőben a 3. lépésben létrehozott „Munkarendek” információs nyilvántartást jelöljük.

Az „Ütemezési érték” mezőben a „Munkaütemek” információs regiszter „Óraszáma” erőforrását jelöljük.

Az „Ütemezés dátuma” mezőben adja meg a „Munkarendek” információs regiszter „Dátum” dimenzióját.

4. A „Gyakoriság” mezőben a „Hónap” értéket jelöljük, ez azt jelenti, hogy az adatok havonta kerülnek be a nyilvántartásba.

Alább látható a rendszerleíró adatbázis metaadat-struktúrája:

A dimenzió „Alap” jelzője csak a teljesítményt befolyásolja; nem kell beállítania, de ha megteszi, az „Alkalmazott” mező indexelésre kerül.

Az „Alkalmazott” dimenzió – a következőben használatos elfojtási mechanizmus a cselekvési periódus alapján"És" a bázisidőszaktól való függés mechanizmusa«.

Erőforrás „Összeg” - ott rögzítésre kerül a kiszámított fizetés.

A „Chart” attribútum attribútumként van feltüntetve, nem pedig regiszterdimenzióként, mert sem ez, sem nem mozdít ki semmit – lényegében referenciamező. Fontos!!! Ne felejtse el kitölteni az „Ütemezési hivatkozás” mezőt az „Ütemterv” attribútumnál ott kell feltüntetni a „Munkarendek” információs regiszter „Ütemterv” dimenzióját, ellenkező esetben a bérösszeg nem kerül kiszámításra.

A „Paraméter” attribútum tárolja a fizetés értékét.

Most, hogy jeleztük a kapcsolatot a „Munkarendekkel” MS-vel, a munkavállaló bérét a ledolgozott napok számának arányában számoljuk ki.

A dokumentumot iktatóként tüntetjük fel" Bérszámfejtés" létrehozva a 4. lépésben.

6. lépés. A mozgásokat az „Alapdíjak” számítási regiszter szerint végezzük.

Térjünk vissza a 4. lépésben létrehozott „Bérszámfejtés” dokumentumhoz.

Leírjuk a könyvelés feldolgozását a dokumentumobjektum modulban:

Dokumentumfeldolgozási feldolgozási kód töredéke

1C (kód)

Procedure ProcessingProcessing(Failure, Processing Mode) // regisztrálja BasicAccruals of Movement.MainAccruals.Write = True; Movements.MainAccruals.Clear(); Regisztrációs időszak = Hónap kezdete (dátum); Minden TechLineMainAccruals From MainAccruals ciklushoz Movement = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Regisztrációs időszak; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; Az eljárás vége

Feldolgozási eljárás (hiba, mód) // Fő felhalmozási nyilvántartás Mozdulatok. Alapvető elhatárolások. írás = igaz; Mozdulatok. Alapvető elhatárolások. Egyértelmű() ; Regisztrációs időszak = Hónap eleje (dátum) ; Minden egyes TechLine BasicAccrualsFrom BasicAccrualsCycle esetén Mozgás = mozgások. Alapvető elhatárolások. Add() ; Mozgalom. Storno= hamis; Mozgalom. Calculation Type=TexLineMainAccruals. Számítás típusa; Mozgalom. PeriodActionStart = TechLineMainAccruals. Kezdő dátum; Mozgalom. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ; Mozgalom. Regisztrációs időszak = Regisztrációs időszak; Mozgalom. Alkalmazott = TechLineMainAccruals. Munkavállaló; Mozgalom. Diagram = TechLineMainAccruals. Menetrend; Mozgalom. Paraméter = TechStringMainAccruals. Méret; EndCycle; Az eljárás vége

Hozzon létre egy tesztdokumentumot, és futtassa:

Menjünk a „Dokumentummozgások” részhez:

Úgy látjuk, hogy a regisztrációs időszak a hónap elejére van beállítva, mert Az RR gyakorisága „Hónap”-ként van jelölve. Azt is látjuk, hogy az összegen kívül minden rovat kitöltve (a bért még nem számolták ki).

7. lépés.Írjuk fel a bérszámfejtési kódot.

Hozzunk létre egy általános "Számítás" modult a következő jelzőkkel:

Maga a számítás ebben az általános modulban történik.

A „Számítás” modulba írjuk be a „Díjszámítás” exportfüggvényt:

Mivel az RR „Alapdíjak” beállításainál kitöltöttük az „Ütemezés”, „Ütemezési érték”, „Ütemezés dátuma” mezőket, így elérhetővé vált a számítási regiszter virtuális táblázata. DataGraphics, egy virtuális tábla lekérdezésében a következő mezőkre vagyunk kíváncsiak:

„A tényleges cselekvési időszak órák száma” — tartalmazza az ütemezési adatok alapján számított ténylegesen ledolgozott órák számát

"Akcióidőszak órák száma" - a számítási időszakban a beosztási adatok alapján számított munkaórák számát tartalmazza

Bérszámfejtési eljárás

1C (kód)

Eljárás CalculateAccruals (Regisztrátor, Nyilvántartási készlet) Export //Bérekérés=Új kérelem; Query.Text="SELECT | ISNULL(BasicAccrualsGraphicsData.Numberof HoursActualActionPeriod, 0) AS HoursFact, |AlapvetőAccrualsGraphicsData.Parameter, |ISNULL(BasicAccrualsGraphicsData,APAPersona ccrualsGraphicsData ica.Line Number |FROM |Számítási nyilvántartás.Alap elhatárolások. Grafikus adatok (| Nyilvántartó = &Regisztrátor | És a számítás típusa = &Számítás típusaBér) AS Basic AccrualsDataGraphics"; Request.SetParameter("Regisztrátor", Rögzítő); // adja át a bizonylatot az anyakönyvvezetőnek, hogy a keresés csak az aktuális bizonylaton történjen. Request.SetParameter("SzámítástípusBérek", Számítási típusok tervei. Alap elhatárolások. Fizetés); //beállítja a számítási fizetés típusát, mert a fizetés kiszámítása Selection=Request.Run().Select(); SearchStructure=NewStructure; SearchStructure.Insert("Sorszám",0); //struktúra létrehozása a sorszám alapján történő számításhoz szükséges adatok kereséséhez Minden rekordhoz a RecordSet ciklusból //ciklus az aktuális dokumentum rekordjai között.Search Structure.LineNumber=Record.LineNumber; //töltsük ki a sorszámot a kereséshez If Selection.FindNext(Search Structure) Ezután //a mintában keresünk adatokat a számításhoz az aktuális sorszám alapján Record.Sum =?(Selection.HoursPlan=0.0, Selection.HoursFact /Sample.HoursPlan * Mintavétel .Parameter); //bér számítása a ledolgozott napok arányában, Paraméterben - aktuális fizetés EndIf; Selection.Reset(); //visszaállítja a kijelölést, szükségünk van a rekordkészlet következő rekordjára, hogy a kijelölésen keresztül kereshessünk először EndCycle; Recordset.Write(, True); //írja a számított rekordokat az adatbázisba, adja át a Replace = True EndProcedure paramétert

//Fizetés Request=Új kérés; Kérés. Text="SELECT | ISNULL(BasicAccrualsDataGraphics.Numberof HoursActualActionPeriod, 0) AS HoursFact, | BasicAccrualsDataGraphics.Parameter, | ISNULL(Basic AccrualsDataGraphics.Numberof HoursActionPeriod, 0) AS HoursPlan, | BasicAccrualsDataGraphics.NumberLines |FROM | Számítási nyilvántartás. Alapvető elhatárolások. Grafikus adatok ( | Felvevő = &Rögzítő

Küldje el ezt a cikket az e-mail címemre

Ebben a cikkben megvizsgáljuk, hogyan kell újraszámítani a nyaralási fizetést az 1C ZUP-ban. Az ilyen helyzetek különféle okokból adódhatnak. Például az információs rendszerben lévő adatok megváltoztak, vagy könyvelési hiba miatt. Azonnal meg kell jegyezni, hogy számos javítási lehetőség létezik. Ha a felhalmozási hónap még nyitva van, akkor közvetlenül magán a bizonylaton végezhet javításokat, majd újra feladhatja. Ellenkező esetben korrekciókat kell végezni, különben számviteli eltérések adódhatnak.

Vegyük például azt az esetet, amikor a szabadság a tényleges időpontnál korábban megszűnt. A munkavállaló kezdetben szabadságdíjat halmozott fel az október elsejétől harmadikig tartó időszakra.

Például valamilyen oknál fogva a munkavállaló korábban - október másodikán - kénytelen volt szabadságot venni. A művelet tükrözéséhez és az összeg újraszámításához nyissa meg az eredeti dokumentumot, és kattintson a megfelelő „Helyes” hivatkozásra a dokumentum alján.

Ebben az esetben új dokumentum jön létre, amelyben meg kell jelölni a szervezet alkalmazottjának a szabadságról való visszatérésének új dátumát.

Lépjen az „Előző időszak újraszámítása” fülre. Úgy látjuk, hogy a korábban felhalmozott összeg vissza lesz fordítva.

Ezután elkészítjük a dokumentumot. Figyelembe kell venni, hogy kifizetés nem következik, mivel az újraszámított összeg meghaladja a felhalmozási összeget. A kiszámított adót viszont újra kell számítani. Az ebből eredő személyi jövedelemadó túlfizetést a következő bérszámfejtéskor veszik figyelembe. A számított adó összege csökken a szabadság újraszámítása kapcsán felmerült túlfizetés összegével. A 6-NDFL jelentés nem jeleníti meg a visszatartott vagy túlutalt adó összegét, de a következő bér kifizetésekor az átutalandó adó összege ezt a túlfizetést veszi figyelembe. Ezt követően a következő banki vagy pénztári kimutatásban a korábban teljesített túlfizetés figyelembevételével kerül átutalásra a személyi jövedelemadó, amely utólag biztosítja a személyi jövedelemadó elszámolás helyes megjelenítését a 6 fős szja-bevallásban.

Ha kérdései vannak az 1C ZUP nyaralási díjának újraszámításával kapcsolatban, kérdezze meg őket a cikk alatti megjegyzésekben, szakembereink megpróbálnak válaszolni rájuk.

Ezután nézzük a második példát. A szervezet munkatársa szabadságkérelmet írt október 1-től október 14-ig. Hasonlóképpen a szabadságot a nyilatkozaton keresztül számították ki és fizették ki. De az előző havi - szeptember - béreket még nem lehetett kiszámítani, mivel ez az aktuális hónap. A hónap végén és a szeptemberi bérszámításkor szükségessé válik a szabadságdíj újraszámítása. Nyissuk meg az eredeti vakációs dokumentumot, amelyben olyan információkkal rendelkezünk, amelyekre az átlagkeresetre vonatkozó információkat kell kitöltenünk. Ez azt jelenti, hogy az adatok megváltoztak.

Ugyanígy kattintson a „Helyes” linkre, aminek eredményeként egy új „Szabadság” bizonylat is készül, amelyben a korábban felhalmozott összeg kerül visszafordításra, valamint a „Felhatárolt (részletek)” fülre, új szabadságelhatárolás készül az új számítási feltételek figyelembevételével. A díjkülönbözetre új személyi jövedelemadó kerül kiszámításra. Ezután elkészítjük a dokumentumot.

Másoktól - például a bónuszt az adott időszak fizetésének összege határozhatja meg. Ebben az esetben előfordulhat, hogy a bónusz kiszámítása után a fizetés módosul. Alapértelmezés szerint a platform nem szabályozza az ilyen helyzeteket. Ha a fejlesztő szükségesnek tartja ennek nyomon követését, akkor a számítási regiszter egy speciális alárendelt objektumát kell használnia - Újraszámítás:

Az újraszámítási rekordokat külön táblázatban tároljuk. Nem garantálják, hogy a függő regisztert pontosan újra kell számítani, hanem egy ilyen lehetséges igény jelzésére szolgálnak.

Az újraszámítási táblázat bejegyzései általában a következő mezőket tartalmazzák:

• újraszámítási objektum (rekord dokumentum, amelynek adatait újra kell számolni)
• számítási típus - hivatkozás a számítási típusra az ehhez a számítási regiszterhez definiált számítási típusok tervéből

A rekordok részletesebben, egy adott számítási regiszter egy vagy több dimenziójával összefüggésben tárolhatók. Például az egész osztály bérnyilvántartója visszamenőleges volt; Ráadásul a változtatások csak Ivanov alkalmazottra vonatkoztak. Ha hozzáadja az Employee dimenziót az Újraszámításhoz, akkor ezt nyomon követheti. Ebben az esetben az Újraszámítás dimenziót a számítási regiszter dimenzióhoz kell kapcsolni:

Az újraszámítási tábla adatai automatikusan generálódnak, ha a megfelelő számítási típusú terv rendelkezik az Alapidőszak tulajdonsággal. Ha a tulajdonság nincs beállítva, akkor a fejlesztő felelős a rekordok létrehozásáért.

Az 1C vizsga 14.41. kérdése: Platform Professional. Újraszámítási adatok...

1. nem számítási nyilvántartási bejegyzések
2. számítási regiszterbejegyzések
3. újraszámítási nyilvántartás bejegyzései
4. a tényleges érvényességi időszak táblázatának rekordjai

A helyes válasz az első, ezeket általában külön táblázatokban tároljuk.

Az 1C vizsga 14.42. kérdése: Platform Professional. Az "Újraszámítás" dimenzió tulajdonságai ablakban, a "Kommunikáció" lapon a "Dimenzió regisztrálása" tulajdonságban adja meg...

1. alapregiszter mérése, amelynek adatai megváltoznak, az aktuális regiszterrekordot újra kell számolni
2. az aktuális regiszter mérése, melynek bejegyzéseit az alapregiszterek adatainak megváltozásakor újra kell számolni
3. alapregiszterek mérései, amelyek adatainak változása esetén az aktuális regiszterrekordot újra kell számolni

A helyes válasz a második. Magára az újraszámításra azért van szükség, hogy nyomon kövesse az aktuális nyilvántartás bejegyzéseinek frissítésének szükségességét.

Az 1C vizsga 14.43. kérdése: Platform Professional. Az "Újraszámítás" táblázat tele van sorokkal, amelyek mindegyike a...

1. a számítás típusáról és az újraszámítandó számítási nyilvántartási bejegyzés bizonylatrögzítőjéről szóló információkészlet. A táblázat az újraszámítási méréseket is tartalmazza
2. információkészlet a számítás típusáról és az újraszámítandó számítási nyilvántartási bejegyzés bizonylat-nyilvántartójáról
3. a számítás típusára, az iktatói bizonylat sorszámára és magára az újraszámítandó számítási nyilvántartási bejegyzés iktatójára vonatkozó információkészlet. A táblázat az újraszámítási méréseket is tartalmazza
4. nincsenek helyes válaszok

Az első válasz helyes, elemzés fent.

Az 1C vizsga 14.45. kérdése: Platform Professional. Válaszd ki a megfelelő választ:

1. Az újraszámításokkal végzett munka során a fejlesztő „figyelmen kívül hagyhatja” a rendszer által az újraszámítási táblázatban megadott információkat, azaz megtagadhatja a számítási eredmények felülvizsgálatát
2. Az 1C:Enterprise 8 rendszerben az újraszámítások működési elve „értesítés”
3. A településnyilvántartási bejegyzések újraszámításának folyamatát a konfiguráció fejlesztője nem tudja szabályozni, a rendszer mindent automatikusan csinál
4. Az 1. és 2. állítás igaz

A negyedik helyes válasz az, hogy az újraszámítás csak a függő adatok esetleges megváltoztatásának szükségességét figyeli.

Az 1C vizsga 14.46. kérdése: Platform Professional. Egy számítási regiszterhez...

1. Csak egy újraszámítás támogatható
2. Csak három különböző struktúrájú kiosztás támogatható
3. A különböző struktúrák tetszőleges számú újraszámítása támogatott

A helyes válasz a harmadik, nem probléma tetszőleges számú alárendelt Recalculation objektum hozzáadása a számítási regiszterhez, ezek szerkezete semmilyen módon nem szabályozott.

Az 1C vizsga 14.57. kérdése: Platform Professional. Az elszámolások gyakorisága havi. A megfelelő beállításokat elvégezték a számítási regiszterben. A Bér számítási típusnál az Utazás számítási típusa van megadva kiszorító számítási típusként. 03.01.14-én az információs bázisba bekerültek a fizetési adatok, de számítás nem történt. 2014.03.20-án az üzleti út bekerült az információs adatbázisba és kiszámításra került. 14.03.30-án indult a bérszámítás. Az üzleti utakra vonatkozó adatokat figyelembe veszik a fizetés kiszámításakor? Újra kell számolnom az üzleti utamat?

1. Figyelembe veszik, de az üzleti utat újra kell számolni
2. Figyelembe vesszük, nincs szükség utazási újraszámításra
3. Nem veszik figyelembe. Az útszámítást törölni kell, és mindkét számítási típust újra kell számítani
4. Nem veszik figyelembe. A helyes számításhoz a fizetésnek és az üzleti útnak egy dokumentumban kell lennie

Újrakalkuláció nem szükséges, az üzleti út nyilvántartása egy hónapon belül van.