hjem » Produksjon » Akkumulasjonsregister, salgsberegninger. Ordning for utfylling av kjøpsbok og salgsbok

Akkumulasjonsregister, salgsberegninger. Ordning for utfylling av kjøpsbok og salgsbok

a) Type verdi Varer dannes av Salg, Kontraktsdimensjonen er tom.
1) kvittering – går inn i salgsboken, fanen «På salg»
2) forbruk
b) Type verdi Forskudd
1) kvittering – dannes av en faktura for forskuddsbetaling
2) utgift – dannet av salgsboken, «Forskudd»-fanen

Akkumuleringsregister "MVA på forskudd"

1) kvittering – generert av dokumentet "Faktura" for forskuddsbetaling, eller "Legg inn opprinnelige mva-saldo",
2) utgift – generert av dokumentet "Opprette en kjøpsbok", fanen "Forskudd".

Kjøpers forskuddsdokument

for eksempel innkommende betalingsordre
genererer inntekt i henhold til akkumuleringsregisteret "Beregning av salg (regnskap)" som indikerer betalingskonto (62.01, 62.02)

Dokument "Faktura" for forskuddsbetaling

genererer inntekt i henhold til akkumuleringsregisteret «MVA påløpt», «Type verdi»-dimensjonen er Forskudd, «Kontrakt»-dimensjonen fylles ut. Beløpet er lik beløpet på dokumentet inkludert mva.
skjemaer, inkl. postering BU 76.AV – 68,02 for mva.

Dokument "Salg av varer og tjenester"

genererer utgifter i henhold til registeret "Beregning på salg (regnskap)" og akkumuleringsregisteret "MVA påløpt", dimensjonen "Type verdi" - Produkt, dimensjonen "Kontrakt" er ikke utfylt. For beløpet av dokumentet, som kan være mindre enn forskuddsbetalingen.

Dokument "Mottak av varer og tjenester"

genererer inntekter i henhold til registeret «Mva presentert» og registeret «Ervervsoppgjør (regnskap)».

Dokument "Opprette en kjøpsbok"

Fanen "Mva fradrag på kjøpte verdisaker" fylles ut med saldoene fra registeret "Mva presentert", uten å velge i henhold til kontrakten.
fanen “Mva fradrag fra forskudd” - fylles ut med saldoene per dato for dokumentet i registeret “Mva fra forskudd”, “Type verdi” - forskudd mottatt, i form av stenging (!) registeret "Beregning av salg (regnskap)", dvs. omsetning ved ankomst. Det er her feil ofte oppstår.
genererer utgiften "krevd mva".
genererer omsetning i henhold til "MVA-kjøp"-registeret
genererer utgiften til "moms på forskudd"

Dokument "Opprette en salgsbok"

"På salg"-fanen fylles ut med "påløpt mva"-saldo, der verditypen er Produkt. Ingen kontraktsvalg.
fanen «Fra forskudd» - fylt ut med saldoen «påløpt merverdiavgift», hvor verditypen er Forskudd.
Fanen «Recovery for advances» fylles ut i henhold til saldoene i registeret «MVA på forskudd» og saldoene til «Kjøpsoppgjør (AC)». Når det gjelder den positive forskjellen til det andre minus det første registeret. Når det gjelder analysefaktura (i merverdiavgiftsregisteret på forskudd)<->Dokument (regnskap for erverv i registeret).
genererer utgiften for «påløpt moms», type verdi Produkt
genererer omsetning i henhold til "MVA Salg"-registeret
genererer utgiften for «påløpt moms», type verdi Forskudd

Ved å sammenligne forespørselen med 62.02. og 62,32 (analytics Subconto1, Subconto2), DO for perioden og alle bokførte dokumenter "Opprette en kjøpsbok", fanen "Forskudd" (analytics Motpart, Avtale), beløp med mva - du kan identifisere feil i kjøpsboken.

For å bruke denne rapporten riktig og forstå hvorfor den er nødvendig, anbefales det at du leser fortsettelsen.

I konfigurasjonene «Complex Automation 1.1», «Manufacturing Enterprise Management 1.3» utføres faktisk regnskapsføring av gjensidige oppgjør med leverandører og kunder ikke i regnskapsregisteret «Cost Accounting» (grovt sett på kontoplanen), men på spesielle akkumuleringsregistre som gir dypere detaljer og optimalisert tilgang.

Nesten all automatisering av dokumentbehandling for oppgjør med leverandører og kunder er basert på data fra disse registrene, og regnskapsregisteret gjenspeiler kun de endelige syntetiske resultatene i form av konteringer. Av denne grunn er det tilrådelig å stenge kontrollaktiviteter knyttet til å kontrollere riktigheten av gjensidige oppgjør til disse registrene, og ikke til regnskaps- og konteringsregisteret.

Men hvis det finnes et standard sett med regnskapsrapporter for regnskapsregisteret (omsetningsbalanse, kontoanalyse etc.), så er det ikke en eneste standardrapport som tyder de aktuelle akkumuleringsregistrene i konfigurasjonene.

For dette formålet kan du bruke standard universelle rapporter, men av flere grunner er dette upraktisk:

mangel på kobling av navnet på rapporten (element i menyen) til arten av de utførte handlingene;
problemer med å angi tilgangsrettigheter;
I registeret "Beregninger for salg" føres saldo og omsetning "innsiden ut", med et "minus"-tegn.
manglende støtte for eiendommer og kategorier i en universell rapport basert på SKD, mangel på sammensatte grupperinger i en rapport basert på «rapportbyggeren»;
tvunget frem separate innstillinger for kontroll av oppgjør med leverandører og kunder (siden ulike registre).

I forbindelse med de ovennevnte omstendighetene, ved å bruke den universelle rapportmotoren på tilgangskontrollsystemet, ble denne rapporten utviklet, blottet for de ovenfor beskrevne manglene.

Rapporten er bygget opp i form av en enkel oppgave som samler saldo og omsetning fra begge registre. Plasseringen av data i et bestemt register kan bestemmes/velges av verdien i feltet "Type oppgjør" - "Ved anskaffelse" eller "Ved salg". Startsaldo, inntekt, utgift og sluttsaldo for beløpet i valutaen for regulert regnskap og i valutaen for gjensidige oppgjør vises. Inntekt tilsvarer debet, utgift til kreditt. Et eksempel på den genererte rapporten er vist i figuren.

Med hensyn til pkt. 4 i denne rapporten foreslås det en rekke kontrolltiltak. Før du utfører dem, er det nødvendig å gjenopprette sekvensen av gjensidige oppgjør.

1. Kontrollere at registeret som brukes med avtaletypen.

Sett valget til posisjonen i henhold til figurene, la resten av innstillingene stå som standard. Generer først en rapport for alternativ a), deretter for b).

Rapporten skal vise et tomt resultat. Enhver oppgjørsnode som vises med disse innstillingene er feil ved at avtaletypen ikke samsvarer med registeret. For eksempel avtale med leverandør, og register for oppgjør med kunder.

Utskriften fra opptakeren vil vise dokumentene som genererte feilbevegelser. Det er sannsynligvis feil utførte justeringer for å registrere oppføringer, eller det er et resultat av feil automatisert utfylling av dokumenter under utveksling og nedlasting (under prosessen ble dataene ikke verifisert av dokumentskjemaer).

2. Kontrollere tilstedeværelsen av kontrakter av en viss type på de aktuelle kontoene for gjensidige oppgjør.

Dette gjøres ved å sette opp valg omtrent som følger:

Motpartsavtale Type avtale = "Med kjøper". Poeng ikke i en gruppe fra listen: 62, 76,06

Motpartsavtale Type avtale = "Med leverandør". Poeng ikke i en gruppe fra listen: 60, 76,05

Som et resultat vil den genererte rapporten vise hvilke oppgjørsnoder som har en form som ikke samsvarer med formålet med regnskapskontoen. Utskriften fra opptakeren vil vise dokumentene som genererte feilbevegelser. Det er imidlertid mer hensiktsmessig å utføre denne kontrollen ved å bruke regnskapsrapporten "Analyse av subconto" (for subconto Motparter, Kontrakter), og sette den opp analogt.

3. Kontrollere likheten mellom valutaen for gjensidige oppgjør og valutaen for regulert regnskap for kontrakter som oppgjøres for i rubler.

Sett valget til tilstanden som vist på bildet. Resten av innstillingene er standard. Generer en rapport.

Rapporten skal vise et tomt resultat. Enhver node som vises med disse innstillingene er feil ved at når du foretar rubelbetalinger i henhold til en avtale, er dens totale omsetning i valutaen for gjensidige oppgjør ikke lik omsetningen i valutaen for regulert regnskap.

Utskriften fra opptakeren vil vise dokumentene som genererte feilbevegelser. Sannsynligvis:

i betalingsdokumenter i beløp etter valuta reg. regnskap og valuta for gjensidige oppgjør (i form av et dokument - til venstre og til høyre) er det forskjellige verdier, eller valutakursen er ikke lik;
gjeldsjusteringer ble gjort feil (med samme problem - i tabelldelene er det 3 kolonner med beløp, for rubelkontrakter skal de være like);
med manuell regnskapsføring ved bruk av oppgjørsdokumenter, et forsøk på å tilbakebetale en gjeld / motregne en forskuddsbetaling, hvis saldo ikke er tilgjengelig på tidspunktet for dokumentet.
Det er feil utførte justeringer for å registrere oppføringer.

Dessverre kan saldo under valutakontrakter og kontrakter i konvensjonelle enheter ikke kontrolleres på denne måten, på grunn av at de avstemte beløpene per definisjon er i forskjellige valutaer.

4. Kontrollere saldoene til gjensidige oppgjør for riktig valg av gjeld/forskuddsunderkonto og tilstedeværelsen av en motsaldo på dem.

Still inn innstillingene i henhold til følgende plan:

Kryssbord, Radgrupperinger: Kontrakten til motparten, Kolonnegrupperinger: Kryss av, Enger: Eventuell rest (kon.) (fjern grupper og ekstra felt). Utvalg: Poengsum i gruppen fra listen: 60, 62.

Rapporten skal vise data som må inspiseres visuelt for følgende:

a) Saldoene for hver underkonto må ha tilsvarende fortegn (60.01, 60.21, 60.31, 62.02, 62.22, 62.32 - negativ, 60.02, 60.22, 60.32, 62.01, 62.21, -62). Det anbefales sterkt å fargelegge dette betingede designet for raskt å identifisere feil.

b) Under en avtale skal det ikke være motsaldo på ulike underkontoer til samme konsernkonto (60.01 / 60.02), noe som betyr at det er både forskudd og gjeld.

Figuren viser feilalternativene a) og b)

Hvis regnskap for transaksjoner er aktivert på kontrakten, utfør nøyaktig samme kontroll i den private transkripsjonen av kontrakten i "Transaksjon"-feltet (dobbeltklikk - dekrypter - Transaksjon): for hver transaksjon skal det bare være enten et forskudd eller en gjeld, mens på selve kontrakten i Generelt kan en motbalanse være tilstede.

I massetilfelle av regnskap for transaksjoner, kan du bruke en forbedret innstilling: angi "Transaksjon"-feltet i linjegrupperingene, og "Motpartsavtale"-betingelsen i utvalget.

Du kan også tyde hvilken som helst linje opp til dokumentet som forskuddet og gjelden er inkludert i, noe som kan være nyttig hvis det utføres manuell regnskapsføring på avtalen basert på oppgjørsdokumenter med en hvilken som helst logikk som ikke er i samsvar med FIFO-prinsippet .

5. Kontrollere riktigheten av automatisk regnskap basert på oppgjørsdokumenter (etter FIFO-prinsippet).

Det er tilrådelig å utføre denne kontrollhendelsen selektivt, fordi ellers kan mengden data som må analyseres visuelt være for stor.

Som utvalg kan du bruke en motpart (avtale) som det ble avdekket feil for i kontrolltiltak nr. 3, eller et utvalg av typen Avtale.Nyheter om oppgjørsdokumenter = Ja. Det anbefales også å velge bare én kontogruppe (60 eller 62, eller 76.05 eller 76.06)

Still inn de resterende innstillingene i henhold til figuren:

Sjekk de mottatte rapporteringsdataene visuelt for følgende:

a) Innenfor hver gruppering av en konto må alle innledende saldoer være på de første dokumentene (eller fraværende), og sluttsaldoene må være på de siste (eller fraværende). Det vil si at overholdelse av FIFO-prinsippet er visuelt verifisert.

b) Saldoene i sammenheng med dokumenter under én avtale må ha samme fortegn (pluss eller minus) og stå enten på gjeldskontoen eller på forskuddskontoen (for 76.xx - rett og slett ha samme fortegn). Med unntak hvis regnskap utføres i forbindelse med transaksjoner, eller med spesiell logikk - manuelt i henhold til oppgjørsdokumenter.

Hvis regnskap i henhold til avtalen utføres i sammenheng med transaksjoner, legg til "Transaksjon" i innstillingene, i grupperingen av linjer, over "Dokument". Hvis manuell regnskapsføring utføres ved bruk av oppgjørsdokumenter, kontroller i henhold til logikken som er akseptert i din organisasjon for denne avtalen.

Hvert dokument i denne rapporten er ikke en registrar, men en analyse for lagring av saldoer. Du kan dechiffrere hvilken som helst av dem til registraren for å sjekke hvilke dokumenter og når forskuddet ble lest opp (gjelden ble tilbakebetalt) etter gruppe.

Regelmessig implementering av disse kontrolltiltakene vil minimere metodiske og tekniske feil ved regnskapsføring av gjensidige oppgjør med leverandører og kunder, og sikre samsvar av regnskapsregisterdata med akkumuleringsregistrene.

Beskrivelse av mekanismen.

Følgende registre er involvert i registrering av data om gjensidige oppgjør med leverandører:

Regnskapsregister

Selvbærende

Akkumulasjonsregistre

Gjensidige oppgjør med motparter
Gjensidige oppgjør med motparter ved bruk av oppgjørsdokumenter
Anskaffelsesberegninger (regnskap)

For å kunne kontrollere betalingen av hver spesifikke faktura, inneholder kontraktskortet det nødvendige - " Ifølge dokumenter av oppgjør med motparter". Ved å opprettholde gjensidige oppgjør i henhold til oppgjørsdokumenter kan du kontrollere tidspunktet for betalinger og betaling for spesifikke forsyninger, spore fordringer etter gjeldsvilkår. Hvis du setter dette flagget, angir du at i dokumentene som er involvert i regnskapsføring av gjensidige oppgjør med motparten, vil du være gitt muligheten til å velge et oppgjørsdokument:

I betalingsdokumenter i tabelldelen " Betalingsdekryptering"i tillegg til avtalen og transaksjonen (ordren), kan du spesifisere informasjon om oppgjørsdokumentet (forsendelsesdokument, kvittering) som betalingen skal bokføres for. Dersom oppgjørsdokumentet ikke er spesifisert, vil programmet vurdere denne betalingen som et forskudd innbetaling.
En tabelldel er lagt til alle anskaffelsesdokumenter som berører gjensidige oppgjør ("Mottak av varer og tjenester" etc.) Forskuddsbetaling" ("Dokumenter for oppgjør med motparter") for å angi informasjon om betalingsdokumentet som betalingen ble utført med, mengden av gjensidige oppgjør og beløpet i valutaen for regulert regnskap. Dersom oppgjørsdokumentet ikke er spesifisert, vurderer programmet at det dannes gjeld til motparten under denne avtalen.

Det er ingen «oppgjørsbilag»-analyse i regnskapsjournalen for transaksjoner, men ved kontering av et leverings- eller betalingsbilag vil systemet generere transaksjoner med hensyn til oppgjørsdokumentene og basert på informasjon om saldo i styringsregistre.

Oppgjørsdokumenter fastsettes av registeret "Gjensidig oppgjør i henhold til oppgjørsdokumenter" dersom kontrakten har attributtet "I henhold til oppgjørsdokumenter med motpart", hvis denne avkrysningsboksen ikke er krysset av, vil oppgjørsdokumentene bli bestemt av registeret "Oppgjør for anskaffelse (regnskap)".

ALTERNATIV 1: "I henhold til dokumenter om oppgjør med motparten" er ikke angitt

Betalingsdokumenter vil bli fastsatt av registeret "Anskaffelsesoppgjør (regnskap)"

Når du posterer et betalingsdokument:

Dersom registersaldoene er negative(oppgjørsdokumenter er kvitteringsdokumenter - det er gjeld til motpart) - da vil systemet velge kvitteringer tilgjengelig på saldo som oppgjørsbilag.

Hvis du ser på SALT - lånesaldoen er 60,01 - 8000 rubler

Betaling gjøres i mengden 9000 rubler

Bevegelsesretning	Registrar	Beregningsdokument		Betalingsbruker
	Betaling 1	Opptak 1	traktat 1
	Betaling 1	Opptak 2	traktat 1
	Betaling 1	Betaling 1	traktat 1

I følge regnskapssystemet - debetsaldo 60,02 - 1000 rubler

Hvis restene er positive- dvs. under denne avtalen er det et forskudd

Hvis du ser på SALT - saldoen på Dt er 60,02

Da vil selve betalingsdokumentet bli et oppgjørsdokument – for hele det innbetalte beløpet.

Det ble - etter betaling for 9000

2. Ved gjennomføring av opptak

Dersom registersaldoene er positive(oppgjørsdokumenter er betalingsdokumenter - det er forskuddsbetaling i henhold til kontrakten)

Hvis du ser på SALT - debetsaldoen er 60,02 - 8000 rubler

Materialer ankom i mengden 9000 rubler

I eks. Bevegelsesregisteret vil være som følger:

Bevegelsesretning	Registrar	Beregningsdokument		Betalingsbruker
	Opptak 1	Betaling 1	traktat 1
	Opptak 1	Betaling 2	traktat 1
	Opptak 1	Opptak 1	traktat 1

Og resten vil allerede se slik ut:

I følge regnskapssystemet - balansen i henhold til Kt 60.01 er 1000 rubler

Hvis saldoene er negative- det vil si at det er en gjeld under denne avtalen

Hvis du ser på SALT - balansen i henhold til Kt 60.01

Da vil selve leveringsdokumentet bli et oppgjørsdokument - for hele kvitteringsbeløpet.

Det ble - etter levering av 9000

ALTERNATIV 2: Avmerkingsboksen "I henhold til dokumenter om oppgjør med motparten" er valgt.

Beregningsdokumenter legges inn manuelt. Men ved bokføring av et bilag vil systemet fortsatt søke etter oppgjørsdokumentet - basert på registeret "Gjensidig oppgjør med motparter i henhold til oppgjørsdokumenter" og dersom oppgjørsdokumentet er feil spesifisert vil det generere en feil.

Regler for valg av oppgjørsdokumenter

Når du fyller ut "Oppgjørsdokument"-detaljer i gjensidige oppgjørsdokumenter, må følgende regler tas i betraktning:

Datoen for oppgjørsdokumentet (registrator) må være senere enn datoen for oppgjørsdokumentet - selv om systemet lar deg velge et hvilket som helst dokument som et oppgjørsdokument, inkludert datoen som er betydelig større enn datoen for oppgjørsdokumentet - systemet vil generere en feil når det er ferdig.
I gjensidig oppgjørsdokumenter er det obligatorisk å fylle ut regnskapsregnskap. Ellers vil ikke systemet kunne lukke beregningsdokumentet på riktig måte.
Tingsmannen og oppgjørsdokumentet skal utføres regnskapsmessig.

For å kontrollere korrektheten av beregningsdokumentene kan du se på bevegelsene i registeret "Kjøpsoppgjør (regnskap)". Spesielt må verdien av ressursen "Regnskapsbeløp" være lik verdien av ressursen "Beløp av gjensidige oppgjør" tatt i betraktning dokumentets valutakurs. Hvis beløpet er regnskapsmessig regnskap er mindre enn beløpet for gjensidige oppgjør - dette betyr at i henhold til dette oppgjørsdokumentet er den uavsluttede saldoen mindre enn beløpet som er tildelt den. Du må spesifisere et annet oppgjørsbilag, eller dele opp beløpet i flere oppgjørsbilag.

"Doble" saldoer under avtalen er også uakseptable - hvis gjensidige oppgjør utføres "under avtalen som helhet." De. Det er uakseptabelt at leverings- og betalingsoppgjørsdokumenter er åpne samtidig. Dersom kontrakten utføres "i henhold til ordre" - innenfor rammen av kontrakten kan det være både forskudd og gjeld - men for ulike ordre - skal det ikke være "dobbelt" saldo innenfor samme ordre.

Oppgaven til ethvert regnskapssystem er å lagre og raskt vise informasjon for brukeren, dvs. Målet med ethvert systemdesign er å raskt gi brukeren en rapport. Ved hjelp av innhentede data tas som regel ledelsesbeslutninger i virksomheter.

La oss anta at vi har 1000 ulike dokumenter: varemottak, avskrivning, retur, salg, etc. Og hvert av dokumentene endrer mengden av et bestemt produkt på lageret. For å få informasjon om gjeldende kvantum på lageret, må du gå gjennom alt: noen øker varemengden, noen reduserer, noen kan øke eller redusere. Og om det i tillegg er nødvendig å ta hensyn til lageret, organisasjonen?.. Et slikt system er svært ressurskrevende.

For å forenkle denne prosessen kom 1C-utviklere opp med spesielle konfigurasjonsobjekter. De brukes for å gjøre det enklere å lagre og hente informasjon i 1C 8.3 og 8.2 brukes alle typer registre i denne artikkelen vi vil snakke spesielt om Akkumulasjonsregistre.

Selve akkumuleringsregisteret er en tabell med informasjon som samler alle bevegelser (kvitteringer/avskrivninger eller omsetning) av enkelte dokumenter. La oss se på hvordan bevegelsestabellen ser ut ved å bruke eksempelet på et typisk akkumuleringsregister "Varer i varehus" i "Trade Management 10.3"-konfigurasjonen:

Her ser vi at 1C "Salg"-dokumenter reduserer mengden av et bestemt produkt på et bestemt lagringssted, og mottaksdokumenter øker tvert i mot. Som et resultat får vi et helhetsbilde der vi tydelig kan se hva, når og i hvilket kvantum som ble mottatt (avskrevet) regnskapsmessig. Det er mye mer praktisk å bygge en rapport ved å bruke en slik tabell.

Akkumuleringsregister i konfiguratoren

Hva er et akkumuleringsregister med tanke på konfigurasjonsutvikling? La oss starte med å se på feltene i akkumuleringsregisteret i:

Få 267 videotimer på 1C gratis:

Akkumuleringsregisteret har Dimensjoner, ressurser, detaljer og standarddetaljer.

La oss først vurdere standarddetaljene til akkumuleringsregisteret:

periode— datoen for flyttingen trenger ikke å være sammenfallende med datoen for dokumentet;
registrar- et dokument som gjør en oppføring i registeret;
linjenummer— serienummeret til linjen i postsettet, unikt i registraren;
aktivitet— er ansvarlig for å få poster inn i virtuelle tabeller (mer om dem nedenfor);
utsiktbevegelse- inntekt eller utgift.

Akkumulasjonsregistermålinger

En dimensjon er en seksjon der journaler oppbevares. I eksemplet ovenfor er regnskapsdelen: lager, nomenklatur, produktegenskaper, produktserier, kvalitet. Det vil si at ved å spesifisere målingene vi er interessert i, kan vi skaffe mengden – ressursen – når som helst. I sammenheng med forskjellige dimensjoner, i fremtiden, for eksempel, kan du få saldo for en bestemt dato.

Akkumulasjonsregisterressurs

En ressurs er et numerisk felt der informasjon lagres i sammenheng med dimensjonene beskrevet ovenfor.

Ellers kan samspillet mellom dimensjoner/ressurser skjematisk avbildes som et koordinatsystem:

To dimensjoner - abscisse og ordinat av koordinatsystemet, dvs. i dette eksemplet er dimensjonene lager og vare. I skjæringspunktet mellom dimensjoner kan vi få en mengde - en ressurs. For eksempel, på "hoved" lageret for produktet "blyant" er det 1 stk på lager.

Detaljer om akkumuleringsregisteret 1C

Akkumulasjonsregisterdetaljer fungerer som en "kommentar" eller tilleggsinformasjon når det gjelder målinger, saldo/omsetning kan ikke innhentes. Brukt ganske sjelden.

Typer akkumuleringsregister

Det finnes to typer akkumuleringsregister − omsetning og saldo.

Dersom formålet med akkumuleringsregisteret ikke er å få saldo, er det nødvendig å bruke typen akkumuleringsregister - rpm. Et typisk eksempel på bruk av omsetningsregister er registrering av salgsvolum. I dette tilfellet trenger vi bare å vite hva salget var over en viss tidsperiode i dette tilfellet gir ikke mening.

Dersom formålet med bruk av akkumuleringsregisteret er å få saldo for en viss periode, trenger vi et register med skjemaet rester. Denne typen lar deg motta både saldo og omsetning. For et slikt register beregner systemet automatisk saldo. Et eksempel på et "restregister" er varer på lager, penger i kassa.

Bruke en registertype rester hvor du kan klare deg rpm, anses som en feil i utformingen av akkumuleringsregisteret fra et systemytelsesperspektiv.

Avhengig av type register vil systemet lage ulike virtuelle tabeller for akkumuleringsregisteret. En virtuell tabell er en rask måte å få profilinformasjon fra registre.

For akkumuleringsregisteret er det:

Rester;
revolusjoner;
Rester og omsetninger.

For løsningsutvikleren er dataene hentet fra én (virtuell) tabell, men faktisk tar 1C-plattformen dem fra mange tabeller og transformerer dem til den nødvendige formen.

Riktig utforming av akkumuleringsregistre

Akkumulasjonsregistre skal utformes fra de påkrevde rapportene. Det vanskeligste i 1C 8.3-systemet er å lagre informasjon riktig slik at den enkelt kan hentes frem når som helst.

Blant funksjonene til registerdesign, bør det bemerkes behovet for å ordne dimensjonene riktig i registeret. Fremfor alt må du legge inn målene som oftest vil bli forespurt i systemet.

Indeksering av

Akkumulasjonsregistermålinger har egenskapen "indeksering". Denne egenskapen må settes til målinger i tilfeller der det er planlagt å bruke utvalg ofte på målingen ved mottak av data og denne målingen kan ha et stort antall verdialternativer.

Registeret er for eksempel "ProductsInWarehouses", dimensjonene er "Warehouse, Nomenclature", ressursen er "Quantity".

Det er mer riktig å indeksere "Nomenklaturen", men feltet "Warehouse" bør ikke indekseres, fordi antallet varehus i systemet som regel ikke er signifikant.

Navnløst dokument

Forberedelse til 1C: Profesjonell og spesialist i SCP for dummies.

Leksjon 15. Vi studerer bevegelser etter registre. MVA fremlagt.

For å forstå godt hvordan du jobber med SCP, må du forstå hvilke bevegelser dokumentene gjør og hvorfor. Så la oss gjøre dette. Vi vil vurdere registre i to moduser: normal og RAUSE (Advanced Cost Accounting Analytics). Du har sannsynligvis et spørsmål: "Hvordan skiller RAUZ seg fra den vanlige SCP-modusen?" Hovedforskjellen er at RAUZ bruker metoden for å løse systemer med lineære ligninger når man beregner produksjonskostnader og justerer bevegelsene til varelager, og fører heller ikke batch-registreringer over varelager. Det er andre forskjeller som vi vil se på i fremtidige leksjoner.

Og så, la oss begynne, kanskje. La oss sjekke hvilken modus UPPen vår er i. For å gjøre dette, bytt til "Accounting Manager"-grensesnittet:

Deretter, gjennom menyen "Regnskapsinnstillinger" -> "Kontoinnstillinger", åpner du innstillingsvinduet:

I den, la oss gå til "Kostnader og kostnader"-fanen og sørge for at vår SCP fungerer som vanlig. Hvis ikke, deaktiver RAUZ:

Nå kan du begynne å lære om registre. Og så oppretter vi et nytt dokument "Kvitteringer av varer og tjenester" eller legger ut det du allerede har opprettet i tidligere leksjoner (for eksempel og): vi ser på hvilke registre dokumentet ble postet i:

Og så, som vi kunne se, er fakturaen bokført i følgende registre:

Akkumulasjonsregister "MVA presentert"

Akkumulasjonsregister "Forsendelser av varer på lager (regnskap)"

Akkumulasjonsregister "Forsendelser av varer på lager (driftsregnskap)"

Regnskapsregister "Transaksjonsjournal (regnskap)"

Akkumuleringsregister "Kjøpsoppgjør (regnskap)"

Akkumuleringsregister "Kjøp"

Akkumulasjonsregister "Gjensidig oppgjør med motparter"

Akkumulasjonsregister "Forsendelser av varer på lager (skatteregnskap)"

Akkumulasjonsregister "Oppgjør med motparter"

Akkumuleringsregister "Varer på lager"

Regnskapsregister "Transaksjonsjournal (skatteregnskap)"

Akkumuleringsregister "Organisasjoners varer"

La oss nå se på dem i detalj. Og så, "MVA presentert"-registeret. Dette er et underregister som tar hensyn til inngående merverdiavgift på innkjøpte varer eller materialer. Dette akkumuleringsregisteret benyttes i Analyserapporten Inngående mva. Den kan åpnes fra grensesnittet for regnskap og skatteregnskap.

gjennom menyen "MVA" -> "Rapporter" -> "Analyse av inngående moms":

Denne rapporten viser oss sammenligninger av betalt og kreditert mva.:

En annen rapport, kalt "MVA-erklæring presentert av leverandøren" vil vise oss innholdet i samme register, men i vilkårlige grupperinger (dette angis i rapportinnstillingene). Hans vei er "MVA" -> "Rapporter" -> "Mva-oppgave presentert av leverandøren":

Vel, sier du, hvor ellers brukes dette registeret, bortsett fra rapporter? Det er klart at det ikke ble oppfunnet bare for dem, fordi rapporter også kan konstrueres basert på regnskapspostene til konto 19.

Jeg vil svare:

Den brukes til å lage en kjøpsbok.

La oss se hvordan det hele er gjort. La oss først legge inn en faktura basert på vår faktura. Dette kan gjøres enten ved å bruke "2Water on base"-knappen:

Eller i selve dokumentet, klikk på inskripsjonen: "Skriv inn faktura":

Samtidig vil vi ha et fakturaregistreringsskjema åpent, der vi må legge inn nummer og dato på den innkommende fakturaen, siden de ikke sammenfaller med det interne nummeret og datoen som er tildelt av systemet:

Etter å ha lagt inn fakturaen, vil påskriften "Skriv inn faktura" bli til informasjon om den oppgitte fakturaen, og når du klikker på den, åpnes skjemaet beskrevet ovenfor: