Kaip iš naujo nustatyti registrus per 1s 8.3. Kaupimo registrų (UF) likučių ir judėjimų atstatymas

Nusprendėme kažkaip atkurti tvarką UT 11 versijos konfigūracijoje. O ten... Prekių likučiai nesutampa su organizacijų likučiais (naudojamos kelios organizacijos), o su prekių siuntomis jie visai nėra artimi, o ką gi. komisinė prekyba naudojamas kartu su įprastu. Trumpai tariant, viskas taip apleista, kad lengviau pradėti nuo nulio, BET... Nuo nulio pradėti negalima - yra ryšys su įmonės apskaita 3.0 (katalogai, dokumentai), o ten ataskaitos jau pateiktos. Buhalterijoje nusprendėme sutvarkyti reikalus atskirai, o buhalterijoje – atskirai. Konkrečiai UT nusprendėme: nulinėsime viską, kas susiję su prekėmis (prekės sandėlyje, organizacijų prekės, organizacijų prekių siuntos, plius su komisiniais susiję registrai), tada darome fiktyvų kvitą (įskaitant ir komisinį), ir koreguojame tarpusavio atsiskaitymus koreguodami tarpusavio atsiskaitymus. Iš pradžių pradėjau rašyti apdorojimą konkretiems registrams, o rašydamas galvojau maždaug per tiek pat laiko parašyti universalų, bet tiktų visiems registrams, kad vėliau nereikėtų dešimt kartų perrašyti. . Ji taip pat turėtų būti tinkama Retail 2, Complex ir kitoms valdomų formų konfigūrācijām. Išbandyta UT11.

Kaip naudoti. Pirmiausia rankiniu būdu sukuriame tuščią „registro koregavimo“ dokumentą, nustatome datą ir laiką (nustačiau 23:59:59 ketvirčio pabaigoje), registro likučiai bus perkelti tiksliai į šią poziciją (dokumento poziciją), bendras, iš dokumento mums reikia tik pozicijos ir reikia. Tada pasirenkame, kuriuos registrus reikia nulinti, ir spustelėkite „Generuoti“. Atsidarome koregavimą, žiūrime, tikriname registrus naudodami ataskaitas ir/ar universalią ataskaitą. Visų dimensijų ir visų išteklių likučiai uždaromi. Taip pat formoje yra pasirinkimas pagal organizaciją ir sandėlį (atmetimas iš pirminio varianto, bet veikia), kitų pasirinkimų nepridėjau (kadangi man visai nereikėjo), kam reikia, gali pridėkite pats, modulyje viskas aiškiai parašyta, o ne aš pradėjau naudoti, nes pvz., jei pasirinksite pagal organizaciją, tada registrui „Organizacijų prekės“ atranka veiks, o registrui „ Prekės sandėliuose“ to nebus (tokio matavimo nėra), todėl be atrankos nulinę.

Praėjo šiek tiek laiko...

Išėjo nauja versija, dabar apdorojimas išmoko (anksčiau davė klaidą - tai yra, iš tikrųjų dirbo tik su balanso registrais) pakeisti judesius apyvartinis registras kaupimas. Be to, judesiai yra atvirkštiniai, t.y. jei pažiūrėsi į registrą, tarkim, „Pardavimai“ UT11, tai po atšaukimo pardavimai iš viso nebus rodomi, t.y. lyg pardavimų visai nebūtų - viso laikotarpio apyvarta bus tuščia. Dar kartą - pasirodo, pavyzdžiui, pas mus buvo pardavimai sausio 1-30 d., 31 d. darau atšaukimą, po to jei pažiūrėsiu ataskaitą nuo 1 iki 30 - pamatysiu pardavimus, nuo 31 iki 31 d. 31 - Matysiu atbulinės eigos judesius, nuo 1 iki 31 - rodys tuščią. Pavyzdžiui, UT11 ir Retail 2.2 „Kasos“ registro judesius apverčiau atvirkščiai, kai turėjau sutvarkyti „Kasą“ (50 sąskaitų, kas žino).

Taip, pamiršau pasakyti, atsirado laukelis „Pradžios data“ - jame nustatoma apyvartos registrų laikotarpio pradžios data (likučiams, žinoma, netaikoma), dokumento pozicija „Regitro koregavimas“ naudojama kaip laikotarpio pabaigos data (apyvartos registrams) – t.y. kaip likučių registrui (likučiai pašalinami į dokumento padėtį). Apyvartos registruose „Pradžios data“ gali likti tuščia - šiuo atveju ji suvokiama kaip anksčiausia galinti egzistuoti data, o apyvartos registrui tai reikš, kad visi judėjimai nuo apskaitos pradžios iki „ Registrų tikslinimas“ dokumentas yra apverstas.

Geros naujienos – kaina taškais sumažėjo.

Mokymasis dirbti su registrais (1C: Apskaita 8.3, leidimas 3.0)

2016-12-08T13:50:45+00:00

Mieli skaitytojai, šioje pamokoje noriu paliesti nepaprastai svarbią temą dirbant 1C: Apskaita 8.3 - Registrai.

Iš karto parodysiu jums nedidelį pavyzdį, kodėl tai taip svarbu.

Pateikiame sausio mėnesio atlyginimų sąrašą:

Vasario pradžioje iš kasos sukuriame darbo užmokesčio žiniaraštį ir spaudžiame mygtuką „Pildyti“:

Ir mes gauname šiuos dalykus:

Bet sausio mėn.:

• Sukaupta 50 000 rublių
• Gyventojų pajamų mokestis 6500 rublių
• Iš viso mokėtina 43 500 rublių

Kur įsivėlė klaida? Kažkas nutiko? Ar tikrai dabar galima visada rankiniu būdu įvesti mokėtiną sumą?

Patyręs buhalteris iš karto balanso lapas 70-uoju numeriu:

Ir jis bus dar labiau sutrikęs, nes, remiantis ataskaita, dar turi sumokėti tie patys 43 500! O iš kur atsirado papildomi 5000 rublių?

Be to, tokia situacija (su bet kokiais skaičiavimais) gali atsitikti ir „trejetoje“, ir „dveje“.

Šiandien pabandysiu pakelti paslapties šydą – kodėl kartais programa taip keistai elgiasi. Aš jums pasakysiu, kaip tokiais atvejais rasti ir ištaisyti klaidą. Straipsnio pabaigoje išsiaiškinsime, iš kur atsirado šie 5000 rublių.

Taigi, eime!

Išmokti matyti registrus

Siųsdama dokumentus, 1C:Apskaita 8 daro įrašus į apskaitos sąskaitas (bet kurio dokumento mygtukas DtKt):

Būtent šių laidų pagrindu viskas yra pastatyta buhalterinės apskaitos ataskaitos: Sąskaitos analizė, Sąskaitos kortelė, Balansas...

Tačiau yra didžiulis duomenų sluoksnis, kurį programa įrašo lygiagrečiai su skelbimais ir kurie naudojami viskam kitam: KUDIR pildymui, pirkimų ir pardavimų knygai, reguliuojamoms ataskaitoms... mokėtinas darbo užmokestis, pagaliau

Kaip tikriausiai jau atspėjote, šis sluoksnis vadinamas registrai, štai jis:

Dabar nesileisiu į pačių registrų aprašymus, kad dar labiau jūsų nesupainiočiau.

Pasakysiu tik tiek, kad mums tiesiog gyvybiškai svarbu pamažu išmokti „matyti“ judesius šiuose registruose, kad galėtume geriau suprasti ir prireikus pakoreguoti programos elgesį.

Pažvelkime atidžiau į „Mokėtinų atlyginimų“ registrą – būtent tai prasminga išspręsti mūsų problemą su papildomais 5000:

Šiame registre matome du įrašus, padarytus atvykstant, tai yra pliusu. Jei slinksime į dešinę ekrano pusę, pirmoje eilutėje pamatysime mokėtiną sumą „-6 500“, o antroje „50 000“.

Likutis šiame registre -6 500 + 50 000 yra lygus 43 500, kuris turėtų būti įtrauktas į dokumentą „Mokėjimo iš kasos išrašas“, kai paspaudžiame mygtuką „Pildyti“.

Dar kartą kartoju - mokėjimo ataskaita nustato mūsų skolą už darbo užmokesčio darbuotojui ne pagal 70 sąskaitą, o pagal „Mokėtinų atlyginimų“ registrą.

Pasirodo, žinome, kad mokėtinas atlyginimas pildomas pagal šį registrą, tačiau net ir matydami registro įrašus negalime suprasti, kas negerai.

Greičiausiai nematome viso vaizdo (gal yra ir kitų šio registro įrašų) ir pasiūlo kažkoks registro analizės įrankis, panašus į apskaitos ataskaitas.

Išmokti analizuoti registrus

Ir yra toks įrankis, vadinamas " Universali ataskaita".

Eikite į skyrių „Ataskaitos“ ir pasirinkite „Universali ataskaita“:

Pasirinkite registro tipą „Kaupimo registras“, registrą „Mokėtinas atlyginimas“ ir spustelėkite mygtuką „Generuoti“:

Tai pasirodė nelabai informatyvu:

Taip yra todėl, kad reikia iš anksto nustatyti ataskaitą, spustelėkite mygtuką „Rodyti nustatymus“ ir skirtuke „Grupavimas“ pridėkite lauką „Darbuotojas“:

Skirtuke „Pasirinkimai“ pasirenkame savo organizaciją:

Spustelėkite mygtuką „Generuoti“:

Dabar tai įdomiau. Matome, kad mūsų darbuotojui mokėtinas likutis yra tas pats 48 500 rublių!

Dar kartą eikite į ataskaitos nustatymus ir skirtuke „Indikatoriai“ pridėkite naują lauką „Įrašytojas“:

Dar kartą generuojame ataskaitą:

Dabar aiškiai matome, kad 2014 m. gruodžio 31 d. po operacijos (matyt, įvedant likučius) atsirado 5 tūkst.

Ir mes turime arba pakeisti šią operaciją, arba rankiniu būdu koreguoti registrą „Mokėtini atlyginimai“ ir uždaryti šiuos 5000 rublių, pavyzdžiui, 2015 m. gruodžio 31 d.

Eikime antruoju keliu. Taigi, mūsų užduotis – pasirūpinti, kad 2016 metų pradžioje „Mokėtinų atlyginimų“ registre darbuotojui nebūtų įsiskolinimų.

Tai atliekama rankiniu būdu.

Mokymasis koreguoti registrus

Eikite į skyrių „Operacijos“ ir pasirinkite „Operacijos įvestos rankiniu būdu“:

Mes kuriame nauja operacija 2015 m. pabaiga:

Meniu „Daugiau“ pasirinkite „Pasirinkti registrus...“:

Nurodykite registrą „Mokėtinas atlyginimas“ ir spustelėkite Gerai:

Eikite į pasirodžiusį registro skirtuką ir sumokėkite 5000 rublių:

Tai darydami, mes tarsi atimame iš registro 5000 rublių vienam darbuotojui, kad iki 2016 m. pradžios pasiektume nulį.

Atliekame operaciją ir performuojame universali ataskaita:

Viskas pavyko! Matome, kad 2015 m. gruodžio 31 d. atliktas rankinis darbas atnešė likutį iki nulio, o mokėtinas atlyginimas po kaupimo yra lygus laukiamiems 43 500.

Nuostabu. O dabar tai patikrinsime mokėjimo ataskaitoje.

Tačiau pirmiausia noriu atkreipti jūsų dėmesį į kitą svarbų dalyką:

Atkreipkite dėmesį, kad likučiai pradžioje ir pabaigoje „Darbuotojų“ grupei rodo nesąmones. Tai nėra klaida, tai yra niuansas, į kurį reikia atsižvelgti architektūriniai bruožai 1s.

Prisiminti. Tuo atveju, kai bus rodoma universali ataskaita su detalumu iki dokumento (registratoriaus), likučiai pagal grupavimą parodys nesąmonę.

Jei reikalaujame likučių pagal darbuotojų grupavimą, pirmiausia turime pašalinti iš nustatymų pridėtą indikatorių „Regitras“.

Nusprendėme kažkaip atkurti tvarką UT 11 versijos konfigūracijoje. O ten... Prekių likučiai nesutampa su organizacijų likučiais (naudojamos kelios organizacijos), o su prekių siuntomis jie visai nėra artimi ir net komisinė prekyba naudojama kartu su įprasta prekyba. Trumpai tariant, viskas taip apleista, kad lengviau pradėti nuo nulio, BET... Nuo nulio pradėti negalima - yra ryšys su įmonės apskaita 3.0 (katalogai, dokumentai), o ten ataskaitos jau pateiktos. Buhalterijoje nusprendėme sutvarkyti reikalus atskirai, o buhalterijoje – atskirai. Konkrečiai UT nusprendėme: nulinėsime viską, kas susiję su prekėmis (prekės sandėlyje, organizacijų prekės, organizacijų prekių siuntos, plius su komisiniais susiję registrai), tada darome fiktyvų kvitą (įskaitant ir komisinį), ir koreguojame tarpusavio atsiskaitymus koreguodami tarpusavio atsiskaitymus. Iš pradžių pradėjau rašyti apdorojimą konkretiems registrams, o rašydamas galvojau maždaug per tiek pat laiko parašyti universalų, bet tiktų visiems registrams, kad vėliau nereikėtų dešimt kartų perrašyti. . Ji taip pat turėtų būti tinkama Retail 2, Complex ir kitoms valdomų formų konfigūrācijām. Išbandyta UT11.

Kaip naudoti. Pirmiausia rankiniu būdu sukuriame tuščią „registro koregavimo“ dokumentą, nustatome datą ir laiką (nustačiau 23:59:59 ketvirčio pabaigoje), registro likučiai bus perkelti tiksliai į šią poziciją (dokumento poziciją), bendras, iš dokumento mums reikia tik pozicijos ir reikia. Tada pasirenkame, kuriuos registrus reikia nulinti, ir spustelėkite „Generuoti“. Atsidarome koregavimą, žiūrime, tikriname registrus naudodami ataskaitas ir/ar universalią ataskaitą. Visų dimensijų ir visų išteklių likučiai uždaromi. Taip pat formoje yra pasirinkimas pagal organizaciją ir sandėlį (atmetimas iš pirminio varianto, bet veikia), kitų pasirinkimų nepridėjau (kadangi man visai nereikėjo), kam reikia, gali pridėkite pats, modulyje viskas aiškiai parašyta, o ne aš pradėjau naudoti, nes pvz., jei pasirinksite pagal organizaciją, tada registrui „Organizacijų prekės“ atranka veiks, o registrui „ Prekės sandėliuose“ to nebus (tokio matavimo nėra), todėl be atrankos nulinę.

Praėjo šiek tiek laiko...

Išleista nauja versija, dabar apdorojimas išmoko (anksčiau davė klaidą – tai yra faktiškai veikė tik su balanso registrais) pakeisti judesius cirkuliuojančiame kaupimo registre. Be to, judesiai yra atvirkštiniai, t.y. jei pažiūrėsi į registrą, tarkim, „Pardavimai“ UT11, tai po atšaukimo pardavimai iš viso nebus rodomi, t.y. lyg pardavimų visai nebūtų - viso laikotarpio apyvarta bus tuščia. Dar kartą - pasirodo, pavyzdžiui, pas mus buvo pardavimai sausio 1-30 d., 31 d. darau atšaukimą, po to jei pažiūrėsiu ataskaitą nuo 1 iki 30 - pamatysiu pardavimus, nuo 31 iki 31 d. 31 - Matysiu atbulinės eigos judesius, nuo 1 iki 31 - rodys tuščią. Pavyzdžiui, UT11 ir Retail 2.2 „Kasos“ registro judesius apverčiau atvirkščiai, kai turėjau sutvarkyti „Kasą“ (50 sąskaitų, kas žino).

Taip, pamiršau pasakyti, atsirado laukelis „Pradžios data“ - jame nustatoma apyvartos registrų laikotarpio pradžios data (likučiams, žinoma, netaikoma), dokumento pozicija „Regitro koregavimas“ naudojama kaip laikotarpio pabaigos data (apyvartos registrams) – t.y. kaip likučių registrui (likučiai pašalinami į dokumento padėtį). Apyvartos registruose „Pradžios data“ gali likti tuščia - šiuo atveju ji suvokiama kaip anksčiausia galinti egzistuoti data, o apyvartos registrui tai reikš, kad visi judėjimai nuo apskaitos pradžios iki „ Registrų tikslinimas“ dokumentas yra apverstas.

Geros naujienos – kaina taškais sumažėjo.

Pasitaiko situacijų, kai skaičiuojant paslaugą „Pagal skaitiklių rodmenis“ skaičiavimo metodu įvedamas vienas rodmuo, o apmokestinus paslaugą, išlaidos pasirodo visai kitos. Tokios situacijos gali susidaryti tais atvejais, kai vartotojas rankiniu būdu keičia duomenis „Skaitiklio rodmenų įvedimas“ ir „Įkrovimo paslaugos“ dokumentuose. Pažiūrėkime į pavyzdį.

• Įveskime sausio mėnesio paslaugos „Karšto vandens tiekimas“ skaitiklių rodmenis:

• Apmokestiname paslaugą:

IN tokiu atveju skaičiavimas buvo teisingas.

Suvartojimui pagal apskaitos prietaisus saugoti naudojamas akumuliacinis registras „Apskaitos prietaisų apskaičiavimas“. Atidarykime šį registrą meniu „Operacijos – Kaupimo registrai – Apskaitos prietaisų skaičiavimas“. Taip pat registrą galima atidaryti iš dokumentų „Skaitiklio rodmenų įvedimas“ arba „Paslaugų kaupimas“ paspaudus mygtuką „Eiti – Apskaitos prietaisų skaičiavimas“.

Kaupimo registre nustatykime pasirinkimą pagal Asmeninė paskyra ir paslauga:

Iš registro matyti, kad sausio mėnesio sąnaudos dokumente „Paslaugų kaupimas“ atitinka to paties mėnesio dokumente „Skaitiklio rodmenų įvedimas“ įrašytą rodmenį. Norint teisingai apskaičiuoti, suvartojimas turi atitikti įvestus kiekvieno mėnesio rodmenis.

• Atidarykime sausio mėnesio dokumentą „Skaitiklio rodmenų įvedimas“ ir pakeiskime rankiniu būdu įvestą rodmenį:

Tuo pačiu nepildysime sausio mėnesio „Paslaugų kaupimo“ dokumento.

• Įveskime vasario mėnesio skaitiklių rodmenis:

• Apmokestinkime paslaugą už vasario mėnesį:

Matyti, kad dokumente buvo įrašytos neteisingos išlaidos. Atsiverkime kaupimo registrą „Apskaitos prietaisų apskaičiavimas“ ir nustatykime pasirinkimą pagal asmeninę sąskaitą ir paslaugą:

Iš registro matyti, kad įrašyti rodmenys ir išlaidos neatitinka vienas kito.

IN šiame pavyzdyje„Paslaugų kaupimo“ dokumentus, žinoma, galite pildyti ir iš naujo įvesti, bet tai paprastas pavyzdys, realiai dokumentų gali būti labai daug, pildymas gali tik pabloginti situaciją.

Tokiu atveju būtina naudoti „AOB_ Kaupimo registrų likučių atstatymas“ apdorojimą.

PASTABA: Prieš naudojant gydymą, rekomenduojama atsarginė kopija informacinė bazė.

Norėdami ištaisyti šią situaciją, atliksime šiuos veiksmus:

1. Režimu „1C:Enterprise“ atidarykite apdorojimą „AOB_Resetting the Balances of Accumulation Registrs“ naudodami meniu „Failas - Atidaryti“;

2. Lauke „Judėjimo dokumentas“ pasirinkite sausio mėnesio dokumentą „Paslaugų kaupimas“.

PASTABA: pasirenkamas dokumentas, esantis prieš dokumentą, kuriame reikia gauti teisingus duomenis. Šiuo atveju vasario mėnesio dokumentą „Paslaugų kaupimas“ taisysime, todėl judėjimo dokumentu pasirenkamas sausio mėnesio dokumentas „Paslaugų kaupimas“.

3. Lauke „Atstatyti registrą“ pasirinkite registrą „Matavimo prietaisų skaičiavimas“:

PASTABA: Apdorojimo metu gali būti atrenkami likučiai. Pasirinkimo kriterijai sukonfigūruoti lentelėje.

4. Spustelėkite mygtuką „Vykdyti“.
Paspaudus šį mygtuką, kaupimo registro „Apskaitos prietaisų apskaičiavimas“ duomenys vizualiai nepasikeis, tačiau likučiai bus atstatyti į nulį.

5. Užpildykime vasario mėnesio dokumentą „Paslaugų kaupimas“:

Matyti, kad panaudojus apdorojimą skaičiavimas tapo teisingas.

Neteisingi dydžiai kaupimo registre „Apskaitos prietaisų apskaičiavimas“ taip pat gali būti suformuoti rankiniu būdu pakeitus duomenis „Paslaugų kaupimo“ dokumente arba įvedus kelis dokumentus „Skaitiklio rodmenų įvedimas“ arba „Sumavimo paslaugos“ laikotarpiui.