Revolverende register over akkumulering «Salg. Spørsmål om strøm- og restakkumuleringsregistre Opprette et akkumuleringsregister 1s

Akkumulasjonsregistre i 1C:Enterprise-systemet er delt inn i to typer: akkumuleringsregistre rester og akkumuleringsregistre revolusjoner.

Registertypen velges når den opprettes i konfiguratoren

Som navnet tilsier, er noen designet for å motta saldo for en bestemt dato, og den andre for å motta omsetning for en valgt periode. Avhengig av typen akkumuleringsregister, genererer 1C:Enterprise-plattformen et annet sett med virtuelle tabeller. I denne artikkelen vil vi vurdere å jobbe med virtuelle tabeller over akkumuleringsregistre. For å gjøre dette vil vi opprette et register for akkumulering av saldoer - Rester av varer og o- Vareomsetning.

La oss nå se på hvilke virtuelle tabeller plattformen tilbyr for hvert av disse registerene.

Omsetningsregister

For klarhet, la oss åpne og se hvilke tabeller som er tilgjengelige for registeret Vareomsetning. Dette er tabellen over selve registeret − Vareomsetning, som finnes fysisk i databasen, og en virtuell tabell - Vareomsetning Omsetning

Alt er klart med standardtabellen. La oss se nærmere på virtuell virkelighet.

Virtuelle bordomsetninger

Denne tabellen lar deg få omsetning av ressurser i sammenheng med målinger. I vårt tilfelle har vi to dimensjoner: Lager og Produkt. Og én ressurs Mengde

La vårt register ha følgende oppføringer

La oss gå tilbake til spørringsbyggeren og starte med å velge fra tabellen Vareomsetning Omsetning alle felt

Følgelig vil forespørselen se slik ut:

VELG VareomsetningOmsetning.Lager, VareomsetningOmsetning.Varer, VareomsetningOmsetning.MengdeOmsetning FRA RegisterAkkumulering.Vareomsetning.Omsetning(,) AS GoodsTurnoversOmsetninger

Spørreresultatet ser slik ut:

Det vil si at vi fikk omsetning i vare- og lagersammenheng for hele tiden. Anta at vi ikke er interessert i varehus og vi ønsker å få omsetning kun i varesammenheng.

For å gjøre dette, ekskluder dimensjonen fra spørringen Lager

VELG VareomsetningOmsetning.Produkt, VareomsetningOmsetning.MengdeOmsetning FRA RegisterAkkumulering.Vareomsetning.Omsetning(,) AS VareomsetningOmsetning

og som et resultat vil vi bare ha to linjer

Men som regel er det ikke påkrevd å motta omsetning i hele tiden registerets eksistens eksisterer. I utgangspunktet er de nødvendige for en bestemt periode: måned, kvartal, år, etc. I tillegg trenger du vanligvis valg etter dimensjoner (produkt, lager). Dette oppnås ved hjelp av virtuelle tabellparametere. Det er praktisk å fylle ut parameterne fra konstruktøren. Med knapp Virtuelle bordalternativer en dialogboks åpnes der du kan registrere alt vi trenger:

Etter det vil vår opprinnelige forespørsel ha følgende skjema

SELECT GoodsTurnoversTurnovers.Warehouse, GoodsTurnoversTurnovers.Product, GoodsTurnoversTurnovers.QuantityTurnover FROM Akkumuleringsregister.GoodsTurnovers.Turnovers(&Begynnelsen av perioden, &Perodens slutt, Varehusomsetningen ASTsWarehousenovers)

Som du kan se, er forskjellen at parametere dukket opp i parentes etter navnet på den virtuelle tabellen, som må fylles ut før du utfører spørringen.

For de som akkurat har begynt å jobbe med virtuelle tabeller, er det ofte fristende å sette utvalget på vanlig måte i stedet for å bruke parametere:

FRA Akkumulasjonsregister.Vareomsetning.Omsetning(,) AS VareomsetningOmsetning HVOR VareomsetningOmsetning.Lager = &Lager

Når vi fylte inn parameterne, gikk vi glipp av Periodisitet. La oss åpne listen og velge fra massen av mulige alternativer Måned. Vi vil fjerne alle andre parametere for ikke å bli forvirret.

Etter det ser vi at et felt dukket opp i feltene i tabellen Periode.

Når vi legger den til i de valgte feltene, får vi følgende spørretekst:

VELG VareomsetningOmsetning.Periode, VareomsetningOmsetning.Lager, VareomsetningOmsetning.Produkt, VareomsetningOmsetning.MengdeOmsetning FRA Akkumulasjonsregister.Vareomsetning.Måned,omsetning,)AS

Vi utfører forespørselen:

Dermed kan vi innenfor det valgte tidsintervallet bryte omsetningen i mindre intervaller i henhold til valgt frekvens.

Balanseakkumuleringsregister

Akkurat som med det omvendte registeret, la oss se i spørringsbyggeren hvilke virtuelle tabeller som er tilgjengelige for balanseakkumuleringsregisteret

Som du kan se, er tre virtuelle tabeller tilgjengelige for balanseakkumuleringsregisteret: Omsetning, Rester, Rester og omsetninger. La oss vurdere hver av dem separat.

Virtuelle bordomsetninger

Selv om registertypen er Rester, kan vi fortsatt få omsetning fra det. I tillegg har vi to ekstra ressurser her: Kommer og Forbruk

La meg minne om at når det foretas en oppføring i saldoregisteret, angis type bevegelse av akkumulering (inntekt eller utgift), mens for omsetningsregisteret er ikke bevegelsesart angitt. Derfor har vi her en tilleggsbonus i form av en mulighet til å motta ikke bare omsetningen for perioden sett under ett, men også inntekter med utgifter separat. Men selvfølgelig, hvis det er et omsetningsregister i metadataene med et lignende sett med målinger, så er det bedre å bruke det for å få omsetninger. Generelt sett ligner det å jobbe med denne virtuelle tabellen som å jobbe med en virtuell tabell Omsetning omsetningsregister omtalt ovenfor.

Virtuelle tabellbalanser

Denne tabellen brukes for å få de gjenværende ressursene når det gjelder dimensjoner. I tabellparametrene kan vi spesifisere datoen vi mottar saldoene for og angi filtrene:

La oss vurdere et lite eksempel. Vi har følgende registeroppføringer:

Vi velger alle tilgjengelige felt og setter slutten av juni som dato for mottak av saldoene. Vi vil ikke etablere utvalg ved målinger. Da vil forespørselsteksten se slik ut:

VELG Rester av varer. Lager, Rester av varer. Rester. Produkt, Rester av varer. Kvantitet Balanse FRA Akkumuleringsregister. Produkter Rester. Rester(&Resterdato,) AS Rester av varer.

Og etter å ha utført det, får vi følgende resultat

Virtuelt bord

Denne tabellen kombinerer de to tidligere omtalte og lar deg få omsetningen for den valgte tidsperioden, samt saldo ved begynnelsen og slutten av perioden. Du kan også angi et valg.

Bruken av denne tabellen kan begrunnes når det er nødvendig å samtidig innhente både omsetning og saldo ved begynnelsen og slutten av perioden i én rapport. I andre tilfeller bør bruken ikke misbrukes.

kostnadene for materialet som er tilgjengelig i organisasjonen, må vi få tilgang til dokumentene, se hvert av dem, skrive ut de nødvendige dataene og deretter oppsummere dem, skaffe de nødvendige dataene. Denne tilnærmingen er upraktisk - den er for treg både for vår imaginære "manuelle" sak og for automatisert regnskap.

Det vil være mer logisk, i tillegg til dokumentene, å oppbevare spesielle tabeller der man ved mottak av materialer og avskriving kan legge inn kort informasjon om dette. Hvis, for eksempel på en daglig basis, for å summere disse tabellene og vise de gjenværende materialene, så, for å si hvor mye og hvilke materialer som er tilgjengelig i organisasjonen på en bestemt dato, er det nok å referere til den tilsvarende kolonnen av bordet. I 1C:Enterprise-systemet er slike tabeller akkumuleringsregistre. Som navnet tilsier, er de designet for å reflektere, akkumulere visse indikatorer. Og refleksjonen i registrene av mottak og utgifter til materialer er et av de typiske eksemplene på bruken av dem.

Vår organisasjon fører journal over materialer i forhold til de ansvarlige personene som mottar dem og som disse materialene avskrives fra når de slippes ut i produksjon. Vi må lagre informasjon om mengden materialer og kostnadene deres, og også, når vi avskriver til produksjon, ha informasjon om hvilken master disse materialene ble overført til. Disse hensyn tillater oss å designe en struktur akkumuleringsregister som vi nå skal lage.

Når du planlegger komposisjonen akkumuleringsregister vi må forstå hva slags data vi skal lagre i den, og deretter "dekomponere" disse dataene til målinger, ressurser og registerdetaljer.

Så vi må lagre følgende data:

• Nomenklaturposisjon
• Ansvarlig person for denne stillingen
• Vareantall
• Varekostnad
• Informasjon om mesteren som materialene ble overført til for bruk.

Registrer mål, eller seksjoner der data lagres, lar oss svare på spørsmål om hva slags data som er lagret i registeret. I vårt tilfelle trenger vi å vite to hovedkjennetegn - dette er hva ansvarlig person fikset det ene eller det andre nomenklaturposisjon. Dimensjonene fra vår dataliste vil åpenbart være nomenklaturstillingen og den ansvarlige medarbeideren.

Registrer ressurser er alltid numeriske verdier som kjennetegner de lagrede dataene. Numeriske verdier er mengden og mengden, og de vil være ressursene til registeret vårt.

Registrer detaljer spille en hjelperolle, og i vårt tilfelle ville det være logisk å lagre informasjon om mesteren som mottok materialene for arbeid i registeret som kreves - i tilfelle vi trenger å finne ut hvem som nøyaktig brukte disse materialene.

Et annet viktig spørsmål å ta stilling til ved utforming av et register er om dette registeret vil balanseregister eller omsetningsregister. Vi er interessert i både informasjon om materialbalansen og informasjon om omsetning, derfor bør du spesifisere type register når du setter opp registeret - Rester. Registrer deg med utsikt Rester lar oss jobbe med balanser og omsetninger

Strukturen som er foreslått her akkumuleringsregister- dette er bare ett av alternativene for hvordan du kan organisere lagringen av de beskrevne dataene. Et slikt regnskapsopplegg kan implementeres for eksempel ved å bruke et par registre, hvorav det ene brukes utelukkende for å lagre den totale balansen av materialer - det vil si dataene som er nødvendig for økonomiske rapporter, det andre - for å lagre data om ansvarssentraler. Uansett kan hver enkelt regnskapsordning kreve sin egen registerstruktur, og vårt eksempel er bare en demonstrasjon av et av de mulige alternativene.

Etter å ha diskutert den teoretiske delen av problemet, la oss gå videre til praksis. La oss lage en ny akkumuleringsregister, la oss kalle det Rester av materialer, parameter Registreringstype la det ligge i meningen Rester, ris. 6.12.

Ris. 6.12.

Slå på akkumuleringsregister inn i delsystemet Operasjonelt regnskapsmateriale.

På fanen Data La oss lage følgende målinger, ressurser og attributter:

målinger:

Navn: Nomenklatur, Type: DirectoryReference.Nomenclature, Forbud mot tomme verdier – satt.

Navn: ResponsibleEmployee, Type: DirectoryReference.Employees, Forbud mot tomme verdier - satt.

Ressurser

Navn: Antall, Type: antall, lengde 10, presisjon 3

Navn: Sum, Type: tall, lengde 10, presisjon 2

Requisites:

Navn: Materialmottaker, Type: DirectoryLink.Employees

Vær oppmerksom på navnene på disse detaljene, deres typer, samt standardregisterdetaljene (fig. 6.13.) - disse dataene vil være nyttige for oss når du arbeider med prosedyren dokument.

La oss ekskludere det generelle attributtet fra sammensetningen av registerdetaljene Organisasjon. Nå trengs det ikke. For å organisere lagringen av data i registeret i sammenheng med ulike organisasjoner, ville vi trenge en ny dimensjon – Organisasjon, takket være denne vil vi kunne jobbe med materialer fra ulike organisasjoner.

La oss gå til fanen Registratorer objektredigeringsvindu og velg dokumenter som registrardokumenter - Kvitteringsmaterialer og FeriemateriellTil Mester.

På dette stadiet, innstillingen akkumuleringsregister ferdig, la oss gå videre til dokumentinnstillingene. La oss starte med dokumentet Kvitteringsmaterialer.

Åpne objektredigeringsvinduet for dette dokumentet, gå til fanen bevegelser(Fig. 6.14.) og trykk på knappen

Ris. 6.14.

I konstruktøren velger du type registerbevegelse - Kommer, i felt tabelldel spesifiser den tabellformede delen av dokumentet materialer, klikk på knappen Fyll uttrykk. Den automatiske mekanismen for å etablere en korrespondanse mellom dokument- og registerdata fungerer ikke alltid riktig (i tilfelle den ikke entydig kan bestemme korrespondansen, eller når korrespondansen bestemt av den i henhold til dens logikk er forskjellig fra den ønskede), så la oss sjekke riktigheten av de etablerte korrespondansene. Som et resultat, vinduet Konstruktør registrere bevegelser skal se ut som vist på fig. 6.15.

Ris. 6.15.

Etter å ha trykket på OK-knappen vil følgende prosedyre for å behandle postingen genereres i dokumentobjektmodulen (slik ser det ut etter fjerning av kommentarene om at koden ble bygget av bevegelsesdesigneren):

Prosedyre HandlingPerforming(Failure, Mode) // registrer Rester av materialer Ankomst av bevegelse.Rester av materialer.Skriv = True; For hver TechStringMaterials From Materials Loop Movement = Movements.RemaindersMaterials.Add(); Movement.MovementType = MovementTypeAccumulation.Incoming; Movement.Period = Dato; Movement.Nomenclature = TekStringMaterials.Nomenclature; Movement.ResponsibleEmployee = ResponsibleEmployee; Movement.Quantity = CurrentStringMaterials.Quantity; Movement.Amount = CurrentStringMaterials.Amount; EndCycle; Sluttprosedyre

Denne prosedyren er deklarert i objektmodulen, den utføres på

For å reflektere ulike forretningsdrift i programmer basert på 1C: Enterprise, bruker brukere dokumenter. Fra dem kan du få alle nødvendige data, for eksempel om saldoen på midler i selskapets kontoer, antall solgte varer i en viss periode.

I prosessen med arbeidet kan det være et ganske stort antall slike dokumenter. Her kan vi ikke snakke om hundrevis av dokumenter, men om tusenvis og titusenvis. Naturligvis er det svært langt, arbeidskrevende og ineffektivt å bygge rapporter og andre data fra et så stort antall dokumenter.

Bare forestill deg at når du registrerer salg av et hvilket som helst produkt, sitter regnskapsføreren og venter på at programmet skal sjekke de tidligere innlagte dokumentene og beregne om det er nok saldo på lageret til å avskrive.

For å løse slike problemer i 1C er det spesielle konfigurasjonsobjekter - akkumuleringsregistre. Når de utfører dokumenter, gjør de oppføringer i dem, og først da fra disse registrene kan du raskt få alle nødvendige data, inkludert saldoer og omsetninger. Det vil si at akkumuleringsregistre ikke bare lagrer data, men lar deg også raskt behandle dem.

Som nevnt tidligere kan akkumuleringsregistre gjøre at du raskt kan motta saldo og omsetning. Denne funksjonaliteten er direkte relatert til typen register. Det kan endres på fanen "Grunnleggende" i skjemaet for å redigere et spesifikt register.

• Omsetningsregistre lar deg kun få omsetning i en viss tidsperiode. I dette tilfellet er det ikke mulig å motta resten. Akkumuleringsregisteret med typen "Omsetning" lager kun én virtuell tabell i systemet - omsetning.
• Akkumuleringsregistre med typen «Rester» gjør at utvikleren kan motta både saldo og omsetning. I dette tilfellet vil tre virtuelle tabeller bli opprettet: saldoer, omsetninger, saldoer og omsetninger. Et eksempel på et slikt register kan være et register over saldo av varer og materialer i varehus, kontantstrømmer på oppgjørskontoene til organisasjonen.

Merk at til tross for universaliteten til balanseregisteret når det gjelder å oppnå både saldo og omsetning, har det også sine ulemper. Ved mottak av omsetninger i balanseregisteret reduseres ytelsen betydelig. I denne forbindelse anbefales det på det sterkeste ikke å bruke saldoregisteret i tilfeller der du kun trenger omsetning (for eksempel salgsomsetning). Du bør ikke sette registertypen til rester "i tilfelle", fordi registrene er designet for å øke hastigheten på programmet, og tvert imot vil du bremse denne prosessen.

Akkumulasjonsregisterdata

målinger

Målinger av akkumuleringsregistre betyr visse kutt som du vil kunne få informasjon om i fremtiden. I vårt tilfelle, som målinger av registeret "Product Release" er: organisasjon, rekkefølge, spesifikasjon, divisjon og andre.

Vi vil til enhver tid kunne motta saldo, for eksempel for hele organisasjonen som helhet, for en bestemt ordre.

Dimensjonsegenskaper

Hver dimensjon har sitt eget sett med egenskaper, som kan påvirke driften av registeret som helhet betydelig. Lignende egenskaper finnes også i ressurser med attributter.

I tilfelle du planlegger å angi utvalget etter en hvilken som helst dimensjon ganske ofte i fremtiden. I vårt tilfelle vil vi ikke bruke indeksering for organisasjonen.

Du kan også angi her om dimensjonen skal fylles ut, om fulltekstsøk skal brukes og andre innstillinger.

Ressurser

Ressurser er numeriske data som lagrer noe informasjon. Det er dette vi skal få tak i i fremtiden i ulike seksjoner. For eksempel, i akkumuleringsregisteret "Produktutgang" vil kun kvantitet fungere som en ressurs. I dette tilfellet vil vi kunne få antall produkter produsert på et bestemt tidspunkt, for eksempel for en bestemt divisjon.

Et annet enkelt eksempel. La oss anta at vi utfører alle operasjoner på kassa i henhold til akkumuleringsregisteret. Ressursene vil være beløpet som enten mottas (kvittering) eller utstedes (utgift) fra kassa. Dimensjonen kan for eksempel være en motpart/rapporterende enhet. Som et resultat vil vi kunne innhente data om saldo og omsetning til både kassaapparatet som helhet og for enkeltmotparter.

Requisites

I motsetning til dimensjoner og ressurser, brukes ikke rekvisitter så ofte. De lagrer dataene som trengs for informativ utfylling av registeret (merknad). Data vil bli brukt som rekvisitter hvis det verken er en ressurs eller en dimensjon.

Standard detaljer

I tillegg til de vanlige rekvisita som utvikleren kan legge til på egen hånd, er det også standardkrav. Du kan ikke slette eller legge til nye til denne listen. Du kan gå til standarddetaljene ved å klikke på knappen med samme navn på fanen "Data".

Aggregater

Aggregater er kun tilgjengelig i akkumuleringsregistre med typen "Omsetning". Du kan få tilgang til dem fra fanen Data. Aggregater brukes i databaser med store datamengder for å fremskynde rapporteringen. Vi vil ikke vurdere denne mekanismen i detalj, siden dette er et ganske omfattende emne.

Bevegelser i akkumuleringsregistre

Ethvert akkumuleringsregister kan ha en eller flere registrarer. Et dokument fungerer som en registrar, hvor det dannes en tilsvarende oppføring i akkumuleringsregisteret.

Du kan se listen over akkumuleringsregistratorer på fanen med samme navn i form av selve registeret. I dette eksemplet kan bevegelser i «Produktfrigivelse»-registeret genereres ved kontering av fire forskjellige dokumenter.

I selve dokumentene, som er registrarer, er listen over registre som de foretar bevegelser av, plassert på fanen "Bevegelser". En bevegelseskonstruktør er også tilgjengelig her, som vil hjelpe til med å lage slike prosedyrer (poste og angre). Sammenligning av dokument- og registerdata utføres ved å sammenligne datatyper.

Alle endringer som gjøres i databasen lagres i de aktuelle tabellene. For 1C er dette tabeller over dokumenter, dokumentjournaler, kataloger og registre. Typene 1C-registre, funksjonene og finessene ved bruken vil bli diskutert i vår artikkel.

Dannelse av poster i registre

Et av de første spørsmålene knyttet til registre er: hvorfor?

Hvorfor trenger du å lage separate tabeller, ofte duplisere eksisterende poster?

Svaret her er ganske enkelt. Selvfølgelig er det mulig å gjøre komplekse og tidkrevende forespørsler til tabeller med kildedokumenter ved å liste opp utvalgsbetingelsene, sjekke dem for slettemerker og ledning, men det er mye enklere og mindre arbeidskrevende å lage en bestemt del av postsettet direkte når du lagrer dokumentet og lagrer det i en egen tabell ved å få tilgang til ham etter behov.

Dermed fant vi ut at en av måtene å opprette en registeroppføring på er å skrive ved hjelp av en registrar (dokument). Dette alternativet finnes i alle typer registre.

Prosessen med å generere registeroppføringer basert på et dokument kalles vanligvis poste et dokument. Et upostert registrardokument har ikke registerbevegelser, det er faktisk et utkast eller et tomt.

Det andre alternativet for å generere en post er direkte, uten å opprette et registreringsdokument. Du kan opprette poster på denne måten kun i informasjonsregistre, mens i egenskapene til registeret må attributtet "Record mode" ha passende verdi (fig. 1).

Felles for alle registre

Den interne strukturen til ethvert register kan vises i fig.2

Fig.2

La oss vurdere det mer detaljert:

• Dimensjoner – registrer egenskaper som bestemmer i hvilke seksjoner viktig informasjon lagres;
• Ressurser - de inneholder informasjon som må systematiseres;
• Requisites - postfelt som inneholder tilleggsinformasjon;
• Forms er en egenskap som inneholder grafisk informasjon om utseendet til en liste, et element osv. og deres interne moduler;
• Layouts - trykte former for registre.

Informasjonsregistre

Siden vi snakker om informasjonsregistre ovenfor, la oss snakke om dem.

Dette er sannsynligvis den enkleste og mest forståelige typen registre. En vanlig tabell som inneholder kolonner og kolonner som lagrer informasjon.

Listen over viktige egenskaper til informasjonsregisteret er liten (fig. 3), la oss snakke om de viktigste:

Fig.3

1. Periodisitet, det indikerer i hvilken grad postens unike er kontrollert (innen et minutt, time, dag, år, i samsvar med den valgte verdien, kan det ikke være to poster med samme målinger), den kan også ta verdien "Av registrar", men for dette må du velge riktig opptaksmodus;
2. Opptaksmodusen er faktisk et valg mellom to verdier: "Uavhengig" og "Underordnet registraren".
   1. Det er viktig å forstå at valget av en uavhengig modus ikke betyr at en post ikke kan dannes av et dokument, bare valg av registrator og kontroll av postens unikhet vil være umulig;
3. Tillat totaler del av den første og Tillat totaler del av den siste: (kombiner to elementer til ett) - når de tilsvarende avmerkingsboksene er valgt, kan en forespørsel til informasjonsregisteret gjøres på flere tabeller (Slice of the first og Del av last), som inneholder de tilsvarende datasettene, som en av Parametrene i disse tabellene er datoen da det er nødvendig å foreta et utvalg av data.

Akkumulasjonsregistre

Vi så strukturen til en av dem i Fig.2. Hovedegenskapen som sterkt påvirker utseendet til registeret, så vel som dets interne struktur, er "Type register" (fig. 4)

Avhengig av kravene til den lagrede informasjonen, kan den ha følgende verdier:

• Rester;
• Omsetning.

I det første tilfellet vil databasen inneholde informasjon ikke bare om bevegelser av ressurser i sammenheng med målinger, men også om typen operasjon (mottak eller utgift). I tillegg, når du oppretter en spørring, vil en ekstra tabell som inneholder totalsummene være tilgjengelig.

Et av hovedproblemene som nybegynnere møter når de bruker tabellene Balances and BalancesAnd Turnovers i spørringer, er at når en spørring mottar saldo for en bestemt dato, kan dataene i disse tabellene variere. Og her er det en nyanse: når du spesifiserer en viss verdi som sluttdato for perioden, tar plattformen data fra balansetabellen uten å inkludere denne verdien i valgperioden.

Hvis du trenger data som inkluderer slutten av perioden, kan du:

• Bruk tabellen Saldo og omsetning;
• Gjør et valg for en dato som er 1 sekund større enn den gitte (dvs. ikke 31.12.16 23:59:59, men 01.01.17 00:00:00);
• Bruk Boundary-metoden, som hjelper deg med å konfigurere alternativet for å inkludere et tidspunkt i perioden som vurderes (brukstilfelle: Boundary(EndDate,Including).

Regnskapsregistre

Tilstrekkelig spesialiserte registre, i utforming ligner akkumuleringsregistre. Hovedforskjellen fra andre typer registre på 1C-plattformen er tilstedeværelsen av kontoplanparameteren i eiendomsstrukturen (fig. 5).

Fig.5

Kontoplanen er et eget metadataobjekt som krever en egen diskusjon. Avhengig av kontoplanen inneholder moderne typiske 1C-konfigurasjoner 4 hovedregnskapsregistre:

1. Budsjettering;
2. Internasjonal;
3. avgift;
4. Selvbærende.

Den andre parameteren, typisk for regnskapsregistre, er "Korrespondanse".

Ved å krysse av i denne boksen kan du opprette doble oppføringer som inneholder kredittkontoen AccountKt og debetkontoen AccountDt og analysene (subconto) som tilsvarer disse kontoene. Hvis avkrysningsboksen ikke er merket, vil kun én konto legges inn i registeroppføringene.

Beregningsregistre

Dette er nok de registrene som er vanskeligst å forstå. I mellomtiden ligner de i sin essens veldig på akkumuleringsregistre av typen "Omsetning".

Den definerende forskjellen til beregningsregisteret fra andre registre er tilstedeværelsen i egenskapene til parameteren "Plan for beregningstypen". I tillegg er beregningsregisteret, samt informasjonsregisteret, periodisk.

I hvert beregningsregister kan det aktiveres muligheten for å koble oppføringen med tidsskjemaet angitt i det tilsvarende informasjonsregisteret. Dette gjør at kode kan hente arbeidstidsdata.

I tillegg til dimensjonene, ressursene og skjemaene som finnes i andre reskontrotyper, kan beregningsregistre gis et Omberegningsobjekt for å lagre informasjon om poster som er utdaterte og må revideres.

Hovedbruken deres i typiske 1C-konfigurasjoner er å registrere og lette arbeid med periodisering for ansatte i organisasjonen.

Hei kjære lesere, i dag fikk jeg ideen til å fortelle dere om 1С registrerer. Ja, jeg har ennå ikke skrevet om oppslagsverk, dokumenter, men vi skal vurdere dette senere.

Og la oss nå se på formålet med registre, typer registre, skildre hvordan registre ser ut, snakke om deres design og datalagring.

Formål med registre

Register er mentå øke hastigheten på å lese visse (analytiske) indikatorer på virksomheten til virksomheten. Indikatorer er lagret i registre i visse seksjoner, tatt i betraktning frekvensen. De. registrerer butikktid, for eksempel kan du finne ut saldoen på lageret til et bestemt produkt for en måned siden.

Registrere- en struktur av en bestemt type, som lar deg motta data med samme hastighet, uavhengig av størrelsen på databasen, uten dem vil resultatet av resultatet være tregt.

Ordning med bruk av registre i 1C:Enterprise
Dokumenter => Register => Rapporter

Det kan ses av diagrammet at registre er grunnlaget for rapporter, og data legges til registre først når dokumenter bokføres.

Typer analytiske indikatorer

Registrene er designet for å lagre ulike indikatorer:
SPAREINDIKATORER: Rester og omsetninger. Akkumulasjonsregistre er laget for å redegjøre for dem.

• Akkumulasjonsregister(rest). Øker ved mottak og avtar ved salg. På hvert tidspunkt må registeret huske saldoen til dette produktet.

Noen indikatorer kan vokse bare i én retning (omsetningsindikator).

• Akkumulasjonsregister(omvendt). For eksempel salgsdata (negativt salg kan ikke være). Hvis et produkt returneres, vil det bli registrert med negativt fortegn.

STATSINDIKATORER, en egenskap ved et objekt, er et informasjonsregister ment.

• Informasjonsregister, har absolutt hvilken som helst datatype. Denne verdien er gyldig til neste tilstandsendring.

Det finnes andre typer registre: Regnskapsregistre, Beregning.

Bilderegistre

Indikatorene som er lagret i registeret kalles ressurser. Analytiske snitt - målinger.
nøkkel registrere oppgave– lagring av indikatorer i sammenheng med målinger og tidsmessig

Representerer vi registeret som et koordinatsystem får vi:
Akser - registerdimensjoner
Separat akse for endring over tid
Kryssindikatorer - Ressurser

Som eksempel viser figuren oppbevaring av varer i lager

Antall målinger i registeret kan være ganske stort. I dette tilfellet kan registeret representeres som en tabell, hvor hver kolonne tilsvarer en dimensjon og det er også kolonner med ressurser.

Register: Resterende varer
Mål: Vare, Lager
Ressurser: Mengde, kostnad

Registrer design

Den overdrevne strukturen i registeret fører til en økning i volumet av databasen, tiden det tar å skrive til registeret øker (dokumenter behandles lengre), og kompleksiteten i utviklingen øker. Oppbyggingen av registeret må fastsettes umiddelbart, fordi endringen i fremtiden er en svært kompleks prosess.

Når man bestemmer målinger Det anbefales å angi referansedatatypen (for kataloger, dokumenter, oppregninger). Rekkefølge målinger påvirker hastigheten på innhenting av data fra registeret. Derfor, når du designer et register, er det viktig å forstå hvor ofte brukeren vil motta rester for hver dimensjon. Alle mål er i orden.

Ressurser- numeriske data som karakteriserer noen indikatorer (ressursen til informasjonsregisteret kan ha alle typer data). Ressurser er verdier som er lagret i skjæringspunktet mellom en dimensjon.

Rekvisitter- noen tilleggskarakteristika for registeret, vises ikke ved mottak av totaler. Registerdetaljer kan være av hvilken som helst datatype.

Lagring av data i registre

Registrene kan representeres av en eller flere tabeller. Sammensetningen av tabellene avhenger av registerets egenskaper. Det er ingen klasser som RegisterReference eller RegisterObject for å jobbe med registre, fordi registerlagringsstrukturen er forskjellig fra objekttabeller. Informasjonen lagres i form av poster. En registeroppføring kan ikke merkes for sletting.

Du kan se innholdet i registeret i brukermodus ved å bruke hovedmenyknappen "Alle funksjoner".

Dette er slutten på den lille anmeldelsen. 1С registrerer hvis du har noen forslag, tillegg da skriv i kommentarfeltet.

1C Programmer var med deg, jeg skal hjelpe med .

P.S. Jenta danser