Revolverande ackumuleringsregister ”Försäljning. Frågor om ström- och restackumuleringsregister Skapa ett ackumuleringsregister 1c

Ackumuleringsregister i 1C:Enterprise-systemet är indelade i två typer: ackumuleringsregister matrester och ackumuleringsregister revolutioner.

Registertypen väljs när den skapas i konfiguratorn

Som namnet antyder är vissa utformade för att ta emot saldon för ett visst datum, och den andra för att få omsättning under en vald period. Beroende på typen av ackumuleringsregister genererar 1C:Enterprise-plattformen en annan uppsättning virtuella tabeller. I den här artikeln kommer vi att överväga att arbeta med virtuella tabeller med ackumuleringsregister. För att göra detta kommer vi att skapa ett register för ackumulering av saldon - Varor Återstår och omsättningsregistret - Varuomsättning.

Låt oss nu titta på vilka virtuella tabeller plattformen tillhandahåller för vart och ett av dessa register.

Omsättningsregister

För tydlighetens skull, låt oss öppna och se vilka tabeller som finns tillgängliga för registret Varuomsättning. Detta är tabellen för själva registret − Varuomsättning, som finns fysiskt i databasen, och en virtuell tabell - Varuomsättning Omsättning

Allt är klart med standardtabellen. Låt oss ta en närmare titt på virtuell verklighet.

Virtuell tabellomsättning

Denna tabell låter dig få omsättningen av resurser i samband med mätningar. I vårt fall har vi två dimensioner: Stock och Produkt. Och en resurs Kvantitet

Låt vårt register ha följande poster

Låt oss gå tillbaka till frågebyggaren och börja med att helt enkelt välja från tabellen Varuomsättning Omsättning alla områden

Följaktligen kommer begäran att se ut så här:

VÄLJ GodsomsättningOmsättning.Lager, GodsomsättningOmsättning.Varor,VaromsättningOmsättning.MängdOmsättning FRÅN Registret Accumulation.GoodsOmsättning.Omsättning(,) AS GoodsTurnoversOmsättningar

Frågeresultatet ser ut så här:

Det vill säga att vi fick omsättning i varu- och lagersammanhang under hela tiden. Antag att vi inte är intresserade av lager och vi vill få omsättning endast i varusammanhang.

För att göra detta, exkludera dimensionen från frågan Stock

CHOOSE GoodsTurnoversOmsättningar.Produkt, GoodsTurnoversOmsättningar.QuantityOmsättning FRÅN RegisterAccumulation.GoodsTurnovers.Turnovers(,) AS GoodsTurnoversOmsättningar

och som ett resultat kommer vi bara att ha två rader

Men som regel krävs inte att man tar emot omsättningar under hela tiden registret existerar. I grund och botten behövs de för en specifik period: månad, kvartal, år, etc. Dessutom behöver du vanligtvis val efter dimensioner (produkt, lager). Detta uppnås med hjälp av virtuella tabellparametrar. Det är bekvämt att fylla i parametrarna från konstruktören. Med knapp Virtuella bordsalternativ en dialogruta öppnas där du kan registrera allt vi behöver:

Efter det kommer vår ursprungliga fråga att ha följande form

VÄLJ VaruomsättningOmsättning.Lager, VaruomsättningOmsättning.Produkt, VaruomsättningOmsättning.MängdOmsättning FRÅN Ackumuleringsregister.Varomsättning.Omsättning(&Periodens början, &Slutet av Perioden,Varulager).

Som du kan se är skillnaden att parametrar dök upp inom parentes efter namnet på den virtuella tabellen, som måste fyllas i innan frågan körs.

För den som precis har börjat arbeta med virtuella tabeller är det ofta frestande att ställa in valet på vanligt sätt istället för att använda parametrar:

FRÅN Ackumuleringsregister.Varomsättning.Omsättning(,) AS GoodsTurnoversOmsättning WHERE GoodsTurnoversTurnovers.Warehouse = &Warehouse

När vi fyllde i parametrarna missade vi Periodicitet. Låt oss öppna listan och välja från mängden av möjliga alternativ Månad. Vi tar bort alla andra parametrar för att inte bli förvirrade.

Efter det ser vi att ett fält dök upp i tabellens fält Period.

Om vi ​​lägger till det i de valda fälten får vi följande frågetext:

VÄLJ GodsomsättningOmsättning.Period, GodsomsättningOmsättning.Lager, GodsomsättningOmsättning.Produkt, GodsomsättningOmsättning.MängdOmsättning FRÅN Ackumuleringsregistret.Varomsättning.Omsättning.Månader,Omsättningar,Omsättningar)

Vi utför begäran:

Således kan vi inom det valda tidsintervallet bryta omsättningen i mindre intervall i enlighet med den valda frekvensen.

Balansackumuleringsregister

Precis som med det omvända registret, låt oss se i frågebyggaren vilka virtuella tabeller som är tillgängliga för saldoackumuleringsregistret

Som du kan se finns tre virtuella tabeller tillgängliga för saldoackumuleringsregistret: Omsättningar, Resterna, Rester och omsättningar. Låt oss överväga var och en av dem separat.

Virtuell tabellomsättning

Även om registertypen är Resterna, vi kan fortfarande få omsättning på det. Dessutom har vi två ytterligare resurser här: Kommande och Konsumtion

Låt mig påminna om att när en anteckning görs i saldoregistret anges typen av ackumulering (inkomst eller kostnad), medan för omsättningsregistret inte typen av rörelse anges. Därför har vi här en extra bonus i form av en möjlighet att få inte bara omsättningen för perioden som helhet utan även intäkter med utgifter separat. Men visst, om det finns ett omsättningsregister i metadata med en liknande uppsättning mätningar, då är det bättre att använda det för att få omsättningar. I allmänhet liknar arbetet med den här virtuella tabellen som att arbeta med en virtuell tabell Omsättningar omsättningsregister som diskuterats ovan.

Virtuella tabellsaldon

Denna tabell används för att erhålla de återstående resurserna i form av dimensioner. I tabellparametrarna kan vi ange datumet för vilket vi får saldona och ställa in filtren:

Låt oss överväga ett litet exempel. Vi har följande registerposter:

Vi väljer alla tillgängliga fält och anger slutet av juni som datum för att ta emot saldona. Vi kommer inte att fastställa urval genom mått. Då kommer förfrågningstexten att se ut så här:

VÄLJ GoodsRemainsRemains.Warehouse, GoodsRemainsRemains.Product, GoodsRemainsRemains.QuantityBalance FROM Accuulation Register.ProductsRemains.Remains(&RemainsDate,) AS GoodsRemainsRemains

Och efter att ha utfört det får vi följande resultat

Virtuellt bord

Denna tabell kombinerar de två tidigare diskuterade och låter dig få omsättningen för den valda tidsperioden, samt saldon i början och slutet av perioden. Du kan också ställa in ett urval.

Användningen av denna tabell kan motiveras när det är nödvändigt att samtidigt få både omsättningar och saldon i början och slutet av perioden i en rapport. I andra fall bör dess användning inte missbrukas.

kostnaden för det material som finns tillgängligt i organisationen, kommer vi att behöva komma åt dokumenten, se var och en av dem, skriva ut nödvändiga uppgifter och sedan sammanfatta dem och skaffa nödvändiga uppgifter. Detta tillvägagångssätt är obekvämt - det är för långsamt både för vårt imaginära "manuella" fall och för automatiserad redovisning.

Det vore mer logiskt att utöver dokumenten föra särskilda tabeller i vilka man vid mottagning och avskrivning av material kan ange kortfattad information om detta. Om, säg, på en daglig basis, för att summera dessa tabeller och visa det återstående materialet, då, för att säga hur mycket och vilket material som finns tillgängligt i organisationen vid ett visst datum, räcker det att hänvisa till motsvarande kolumn av bordet. I 1C:Enterprise-systemet är sådana tabeller ackumuleringsregister. Som namnet antyder är de utformade för att återspegla, ackumulera, vissa indikatorer. Och reflektionen i registren över in- och utgifter för material är ett av de typiska exemplen på deras användning.

Vår organisation för register över material i förhållande till de ansvariga personer som tar emot det och från vilka detta material skrivs av när det släpps i produktion. Vi behöver lagra information om mängden material och deras kostnad, och även, vid avskrivning till produktion, ha information om vilken speciell mästare dessa material överfördes till. Dessa överväganden gör att vi kan designa en struktur ackumuleringsregister som vi nu ska skapa.

När du planerar kompositionen ackumuleringsregister vi måste förstå vilken typ av data vi ska lagra i den och sedan "bryta ner" denna data till mätningar, resurser och registerdetaljer.

Så vi måste lagra följande data:

• Nomenklaturens ställning
• Ansvarig person för denna tjänst
• Artikel kvantitet
• Varans kostnad
• Information om befälhavaren till vilken materialet överfördes för användning.

Registrera mått, eller avsnitt där uppgifter lagras, låter oss svara på frågor om vilken typ av uppgifter som lagras i registret. I vårt fall måste vi känna till två huvudegenskaper - det här är vad ansvarsfull person fixade det ena eller det andra nomenklaturposition. Självklart kommer dimensionerna från vår datalista att vara nomenklaturpositionen och ansvarig medarbetare.

Registrera resurserär alltid numeriska värden som kännetecknar lagrad data. Numeriska värden är kvantiteten och mängden, och de kommer att vara resurserna i vårt register.

Registrera detaljer spelar en extra roll, och i vårt fall skulle det vara logiskt att lagra information om befälhavaren som tog emot materialet för arbete i registret - om vi skulle behöva ta reda på vem som exakt använde dessa material.

En annan viktig fråga att ta ställning till när man utformar ett register är om detta register kommer att göra det balansregister eller omsättningsregister. Vi är intresserade av både information om materialbalansen och information om omsättning, därför bör du, när du upprättar registret, ange typen av register - Resterna. Registrera dig med utsikt Resterna gör att vi kan arbeta med saldon och omsättningar

Den struktur som föreslås här ackumuleringsregister- detta är bara ett av alternativen för hur du kan organisera lagringen av de beskrivna data. Ett sådant redovisningssystem kan implementeras t.ex. med hjälp av ett par register, varav det ena används enbart i syfte att lagra den totala saldot av material - det vill säga de data som behövs för finansiella rapporter, det andra - för att lagra uppgifter om ansvarscentra. I vilket fall som helst kan varje specifikt redovisningssystem kräva sin egen registerstruktur, och vårt exempel är bara en demonstration av ett av de möjliga alternativen.

Efter att ha diskuterat den teoretiska delen av frågan, låt oss gå vidare till praktiken. Låt oss skapa en ny ackumuleringsregister, låt oss kalla det Restermaterial, parameter Registreringstyp lämna det i meningen Resterna, ris. 6.12.

Ris. 6.12.

Sätta på ackumuleringsregister in i delsystemet Operativt redovisningsmaterial.

På fliken Data Låt oss skapa följande mått, resurser och attribut:

mätningar:

namn: Nomenklatur, Typ: DirectoryReference.Nomenclature, Förbud mot tomma värden – ställ in.

namn: ResponsibleEmployee, Typ: DirectoryReference.Employees, Förbud mot tomma värden - ställ in.

Resurser

namn: Kvantitet, Typ: antal, längd 10, precision 3

namn: Summa, Typ: antal, längd 10, precision 2

Förutsättningar:

namn: Materialmottagare, Typ: DirectoryLink.Employees

Var uppmärksam på namnen på dessa detaljer, deras typer, såväl som standardregisterdetaljerna (Fig. 6.13.) - dessa data kommer att vara användbara för oss när vi arbetar med proceduren dokumentera.

Låt oss utesluta det allmänna attributet från sammansättningen av registeruppgifterna Organisation. Nu behövs det inte. För att organisera lagringen av data i registret i olika organisationers sammanhang skulle vi behöva en ny dimension - Organisation, tack vare vilken vi skulle kunna arbeta med material från olika organisationer.

Låt oss gå till fliken Registratorer objektredigeringsfönster och välj dokument som registrardokument - Kvittomaterial och Semestermaterial Till Master.

I detta skede, inställningen ackumuleringsregister avslutat, låt oss gå vidare till dokumentinställningarna. Låt oss börja med dokumentet Kvittomaterial.

Öppna objektredigeringsfönstret för detta dokument, gå till fliken rörelser(Fig. 6.14.) och tryck på knappen

Ris. 6.14.

I konstruktorn väljer du typen av registerrörelse - Kommande, i fält tabelldel ange den tabellformade delen av dokumentet material, klicka på knappen Fyll uttryck. Den automatiska mekanismen för att upprätta en överensstämmelse mellan dokument och registerdata fungerar inte alltid korrekt (i händelse av att den inte entydigt kan bestämma överensstämmelsen, eller när den korrespondens som den bestämmer enligt dess logik skiljer sig från den önskade), så låt oss kontrollera riktigheten av de etablerade korrespondenserna. Som ett resultat, fönstret Konstruktör registrera rörelser ska se ut som den som visas i fig. 6.15.

Ris. 6.15.

Efter att ha tryckt på OK-knappen genereras följande procedur för att bearbeta postningen i dokumentobjektmodulen (så här ser det ut efter att du tagit bort kommentarerna om att koden byggdes av rörelsedesignern):

Procedur HandlingPerforming(Failure, Mode) // registrera Rester av material Ankomst av rörelse.Rester av material.Skriv = Sant; För varje TechStringMaterials From Materials Loop Movement = Movements.RemaindersMaterials.Add(); Movement.MovementType = MovementTypeAccumulation.Incoming; Movement.Period = Datum; Movement.Nomenclature = TekStringMaterials.Nomenclature; Movement.ResponsibleEmployee = ResponsibleEmployee; Movement.Quantity = CurrentStringMaterials.Quantity; Movement.Amount = CurrentStringMaterials.Amount; EndCycle; Slutprocedur

Denna procedur deklareras i objektmodulen, den exekveras på

För att spegla olika affärsverksamheter i program baserade på 1C: Enterprise använder användarna dokument. Från dem kan du få all nödvändig information, till exempel om saldot av medel på företagets konton, antalet varor som sålts under en viss tidsperiod.

Under arbetets gång kan det finnas ett ganska stort antal sådana dokument. Här kan vi inte tala om hundratals dokument, utan om tusentals och tiotusentals. Naturligtvis är det mycket långt, mödosamt och ineffektivt att bygga rapporter och annan data från ett så stort antal dokument.

Föreställ dig bara att när du registrerar försäljningen av någon produkt sitter revisorn och väntar på att programmet ska kontrollera de tidigare inlagda dokumenten och beräkna om det finns tillräckligt med saldo på lagret för att skriva av.

För att lösa sådana problem i 1C finns det speciella konfigurationsobjekt - ackumuleringsregister. När de utför dokument gör de poster i dem, och först då från dessa register kan du snabbt få all nödvändig information, inklusive saldon och omsättningar. Det vill säga, ackumuleringsregister lagrar inte bara data, utan låter dig också snabbt bearbeta den.

Som nämnts tidigare kan ackumuleringsregister göra att du snabbt kan ta emot saldon och omsättningar. Denna funktion är direkt relaterad till typen av register. Det kan ändras på fliken "Grundläggande" i formuläret för att redigera ett specifikt register.

• Omsättningsackumuleringsregister låter dig endast få omsättning under en viss tidsperiod. I det här fallet är det inte möjligt att ta emot resten. Ackumuleringsregistret med typen "Omsättning" skapar endast en virtuell tabell i systemet - omsättning.
• Ackumuleringsregister med typen "Remainders" gör det möjligt för utvecklaren att ta emot både saldon och omsättningar. I det här fallet kommer tre virtuella tabeller att skapas: saldon, omsättningar, saldon och omsättningar. Ett exempel på ett sådant register kan vara ett register över saldon av varor och material i lager, kassaflöden på organisationens avräkningskonton.

notera att trots att balansregistret är allmängiltigt när det gäller att få fram både saldon och omsättningar, har det också sina nackdelar. Vid mottagande av omsättningar i balansregistret sänks prestandan avsevärt. I detta avseende rekommenderas det starkt inte att använda balansregistret i de fall du bara behöver omsättningar (till exempel försäljningsomsättning). Du bör inte ställa in registertypen på rester "för säkerhets skull", eftersom registren är designade för att påskynda programmet, och tvärtom kommer du att sakta ner denna process.

Ackumuleringsregisterdata

mätningar

Mätningar av ackumuleringsregister innebär vissa nedskärningar som du kommer att kunna få information om i framtiden. I vårt fall, som mätningar av registret "Product Release" är: organisation, ordning, specifikation, division och andra.

Vi kommer när som helst att kunna ta emot saldon, till exempel för hela organisationen som helhet, för en specifik order.

Dimensionsegenskaper

Varje dimension har sin egen uppsättning egenskaper, vilket avsevärt kan påverka driften av registret som helhet. Liknande egenskaper finns också i resurser med attribut.

I händelse av att du planerar att ställa in valet av någon dimension ganska ofta i framtiden. I vårt fall kommer vi inte att använda indexering för organisationen.

Här kan du även ange om dimensionen ska fyllas i, om fulltextsökning ska användas och andra inställningar.

Resurser

Resurser är numeriska data som lagrar viss information. Det är detta som vi kommer att få fram i framtiden i olika avsnitt. Till exempel, i ackumuleringsregistret "Produktutgång" kommer endast kvantitet att fungera som en resurs. I det här fallet kommer vi att kunna få antalet produkter som tillverkas vid en viss tidpunkt, till exempel för en viss division.

Ett annat enkelt exempel. Låt oss anta att vi utför alla operationer i kassan enligt ackumuleringsregistret. Resurserna kommer att vara den summa pengar som antingen tas emot (kvitto) eller utfärdas (utgift) från kassan. Dimensionen kan till exempel vara en motpart/rapporterande enhet. Som ett resultat kommer vi att kunna få uppgifter om saldon och omsättningar för både kassaregistret som helhet och för enskilda motparter.

Förutsättningar

Till skillnad från dimensioner och resurser används inte rekvisita lika ofta. De lagrar de uppgifter som behövs för den informativa kompletteringen av registret (anm.). Data kommer att användas som rekvisita om det varken är en resurs eller en dimension.

Standarddetaljer

Utöver de vanliga kraven som utvecklaren kan lägga till på egen hand, finns det även standardkrav. Du kan inte ta bort eller lägga till nya till den här listan. Du kan gå till standarddetaljerna genom att klicka på knappen med samma namn på fliken "Data".

Aggregat

Aggregat är endast tillgängliga i ackumuleringsregister med typen "Omsättning". Du kan komma åt dem från fliken Data. Aggregat används i databaser med stora mängder data för att påskynda rapporteringen. Vi kommer inte att överväga denna mekanism i detalj, eftersom detta är ett ganska omfattande ämne.

Rörelser i ackumuleringsregister

Varje ackumuleringsregister kan ha en eller flera registratorer. En handling fungerar som registrator, under vilken en motsvarande anteckning bildas i ackumulationsregistret.

Du kan se listan över ackumuleringsregistratorer på fliken med samma namn i form av själva registret. I det här exemplet kan rörelser i registret ”Product Release” genereras när fyra olika dokument bokförs.

I själva dokumenten, som är registratorer, finns listan över register genom vilka de gör rörelser på fliken "Förflyttningar". En rörelsekonstruktor är också tillgänglig här, som hjälper till att skapa sådana procedurer (lägga upp och ångra). Jämförelse av dokument- och registerdata görs genom att jämföra datatyper.

Alla ändringar som görs i databasen lagras i lämpliga tabeller. För 1C är det tabeller över dokument, dokumentjournaler, kataloger och register. Typerna av 1C-register, funktionerna och finesserna i deras användning kommer att diskuteras i vår artikel.

Bildande av register i register

En av de första frågorna relaterade till register är: varför?

Varför behöver du skapa separata tabeller, ofta duplicera befintliga poster?

Svaret här är ganska enkelt. Naturligtvis är det möjligt att göra komplexa och tidskrävande frågor till tabeller med källdokument genom att lista urvalsvillkoren, kontrollera dem för raderingsmärken och ledning, men det är mycket lättare och mindre mödosamt att skapa en viss del av postuppsättningen direkt. när du sparar dokumentet och lagrar det i en separat tabell genom att komma åt honom vid behov.

Således fick vi reda på att ett av sätten att skapa en registerpost är att skriva med hjälp av en registrar (dokument). Detta alternativ finns i alla typer av register.

Processen att generera registerposter baserat på ett dokument kallas vanligtvis för att posta ett dokument. Ett ej postat registrardokument har inga registerförflyttningar, det är i själva verket ett utkast eller en blankett.

Det andra alternativet för att generera en post är direkt, utan att skapa ett registreringsdokument. Du kan skapa poster på detta sätt endast i informationsregister, medan i registrets egenskaper måste attributet "Record mode" ha det lämpliga värdet (Fig. 1).

Gemensamt för alla register

Den interna strukturen för vilket register som helst kan visas i fig. 2

Fig.2

Låt oss överväga det mer detaljerat:

• Dimensioner – registrera egenskaper som bestämmer i vilka sektioner viktig information lagras;
• Resurser - de innehåller information som behöver systematiseras;
• Krav - postfält som innehåller ytterligare information;
• Forms är en egenskap som innehåller grafisk information om utseendet på en lista, ett element osv. och deras interna moduler;
• Layouter - tryckta former av register.

Informationsregister

Eftersom vi pratar om informationsregister ovan, låt oss prata om dem.

Detta är förmodligen den enklaste och mest begripliga typen av register. En vanlig tabell som innehåller kolumner och kolumner som lagrar information.

Listan över viktiga egenskaper hos informationsregistret är liten (fig. 3), låt oss prata om de viktigaste:

Fig.3

1. Periodicitet, det indikerar i vilken utsträckning postens unikhet kontrolleras (inom en minut, timme, dag, år, i enlighet med det valda värdet kan det inte finnas två poster med samma mätningar), det kan också ta värdet "Av registrar", men för detta måste du välja lämpligt inspelningsläge;
2. Inspelningsläget är egentligen ett val av två värden: "Oberoende" och "Underordnad registraren".
   1. Det är viktigt att förstå att valet av ett oberoende läge inte betyder att en post inte kan bildas av ett dokument, bara urval av registrator och kontroll av postens unikhet kommer att vara omöjligt;
3. Tillåt totaler del av den första och Tillåt totaler del av den sista: (kombinera två poster till en) - när motsvarande kryssrutor är markerade kan en begäran till informationsregistret göras på ytterligare tabeller (del av den första och del av den last), som innehåller motsvarande datamängder, som en av Parametrarna i dessa tabeller är det datum då det är nödvändigt att göra ett urval av data.

Ackumuleringsregister

Vi såg strukturen för en av dem i Fig.2. Den huvudsakliga egenskapen som starkt påverkar registrets utseende, liksom dess interna struktur, är "Registrets typ" (fig. 4)

Beroende på kraven för den lagrade informationen kan den anta följande värden:

• Resterna;
• Omsättningar.

I det första fallet kommer databasen att innehålla information inte bara om resursernas rörelser i samband med mätningar, utan också om typen av operation (kvitto eller kostnad). När du skapar en fråga kommer dessutom en extra tabell som innehåller totalsummorna att vara tillgänglig.

Ett av de största problemen som nybörjare möter när de använder tabellerna Balanser och Balanser Och Omsättningar i frågor är att när en fråga tar emot saldon för ett visst datum kan data i dessa tabeller skilja sig åt. Och här finns det en nyans: när du anger ett visst värde som slutdatum för perioden tar plattformen data från balanstabellen utan att inkludera detta värde i urvalsperioden.

Om du behöver data som inkluderar slutet av perioden kan du:

• Använd tabellen Saldon och omsättningar;
• Gör ett val för ett datum som är 1 sekund större än det angivna (dvs inte den 31/12/16 23:59:59, utan den 01/01/17 00:00:00);
• Använd Boundary-metoden, som hjälper till att konfigurera alternativet att inkludera en tidpunkt i den aktuella perioden (användningsfall: Boundary(EndDate,Including).

Bokföringsregister

Tillräckligt specialiserade register, till sin utformning liknar ackumuleringsregister. Den största skillnaden från andra typer av register på 1C-plattformen är närvaron i egenskapsstrukturen för parametern Kontoplan (Fig. 5).

Fig. 5

Kontoplanen är ett separat metadataobjekt som kräver en separat diskussion. Beroende på kontoplanen innehåller moderna typiska 1C-konfigurationer 4 huvudbokföringsregister:

1. Budgetering;
2. Internationell;
3. beskatta;
4. Självförsörjande.

Den andra parameteregenskapen för redovisningsregister är "Korrespondens".

Genom att markera denna ruta kan du skapa dubbla poster som innehåller kreditkontot AccountKt och debetkontot AccountDt och analysen (subconto) som motsvarar dessa konton. Om kryssrutan inte är markerad kommer endast ett konto att anges i registerposterna.

Beräkningsregister

Dessa är förmodligen de svåraste registren att förstå. Samtidigt, i sin essens, är de mycket som ackumuleringsregister av typen "Omsättning".

Den definierande skillnaden mellan beräkningsregistret och andra register är närvaron i dess egenskaper av parametern "Plan av beräkningstyp". Dessutom är beräkningsregistret, liksom informationsregistret, periodiskt.

I varje beräkningsregister kan möjligheten att koppla inmatningen till det tidschema som anges i motsvarande informationsregister möjliggöras. Detta tillåter kod för att hämta arbetstidsdata.

Utöver de dimensioner, resurser och formulär som finns i andra reskontratyper kan beräkningsregister ges ett Omberäkningsobjekt för att lagra information om poster som är inaktuella och behöver revideras.

Deras huvudsakliga användning i typiska 1C-konfigurationer är att registrera och underlätta arbetet med periodiseringar för anställda i organisationen.

Hej kära läsare, idag fick jag idén att berätta om 1С register. Ja, jag har ännu inte skrivit om referensböcker, dokument, men vi kommer att överväga detta senare.

Och låt oss nu titta på syftet med register, typer av register, skildra hur register ser ut, prata om deras utformning och datalagring.

Syftet med registren

Register är avsedda att öka hastigheten för att läsa vissa (analytiska) indikatorer på företagets aktiviteter. Indikatorer lagras i register i vissa avsnitt, med hänsyn tagen till frekvensen. De där. registrerar butikstid, till exempel kan du få reda på saldot på lagret för en viss produkt för en månad sedan.

Registrera- en struktur av en viss typ, som gör att du kan ta emot data med samma hastighet, oavsett storleken på databasen, utan dem kommer resultatet av resultatet att vara långsamt.

Schema för att använda register i 1C:Enterprise
Dokument => Register => Rapporter

Av schemat framgår att register ligger till grund för rapporter och data läggs till register först när dokument läggs upp.

Typer av analytiska indikatorer

Register är utformade för att lagra olika indikatorer:
SPARAINDIKATORER: Rester och omsättningar. Ackumuleringsregister är utformade för att redogöra för dem.

• Ackumuleringsregister(resterande). Ökar vid mottagandet och minskar vid försäljning. Vid varje tidpunkt måste registret komma ihåg balansen för denna produkt.

Vissa indikatorer kan bara växa i en riktning (omsättningsindikator).

• Ackumuleringsregister(omvänd). Till exempel försäljningsdata (negativ försäljning kan inte vara). Om en produkt returneras kommer den att registreras med negativt tecken.

STÄLLANDE INDIKATORER, en egenskap hos ett objekt, avses ett register över uppgifter.

• Informationsregister, har absolut vilken datatyp som helst. Detta värde är giltigt tills nästa tillståndsändring.

Det finns andra typer av register: redovisningsregister, beräkning.

Bildregister

De indikatorer som lagras i registret kallas resurser. Analytiska snitt - mätningar.
nyckel- registrera uppgift– Lagring av indikatorer i samband med mätningar och i termer av tid

Om vi ​​representerar registret som ett koordinatsystem får vi:
Axlar - registermått
Separat axel för förändring över tid
Korsningsindikatorer - Resurser

Som exempel visar figuren lagring av varor i lager

Antalet mätningar i registret kan vara ganska stort. I detta fall kan registret representeras som en tabell, där varje kolumn motsvarar en dimension och det finns även kolumner med resurser.

Register: Resterande varor
Mått: Vara, Lager
Resurser: Kvantitet, Kostnad

Registrera Design

Den överdrivna strukturen i registret leder till en ökning av databasens volym, tiden det tar att skriva till registret ökar (dokument behandlas längre) och komplexiteten i utvecklingen ökar. Registrets struktur måste bestämmas omedelbart, eftersom dess förändring i framtiden är en mycket komplex process.

När man bestämmer mätningar Det rekommenderas att ange referensdatatypen (för kataloger, dokument, uppräkningar). Ordning mätningar påverkar hastigheten för att hämta data från registret. När man utformar ett register är det därför viktigt att förstå hur ofta användaren kommer att få rester för varje dimension. Alla mått är i sin ordning.

Resurser- numeriska data som kännetecknar vissa indikatorer (informationsregistrets resurs kan ha vilken typ av data som helst). Resurser är värden som lagras i skärningspunkten mellan en dimension.

Rekvisita- någon ytterligare egenskap hos registret, visas inte när summan tas emot. Registeruppgifter kan vara av vilken datatyp som helst.

Lagring av data i register

Register kan representeras av en eller flera tabeller. Tabellernas sammansättning beror på registrets egenskaper. Det finns inga klasser som RegisterReference eller RegisterObject för att arbeta med register, eftersom registerlagringsstrukturen skiljer sig från objekttabeller. Informationen lagras i form av register. En registerpost kan inte markeras för radering.

Du kan se innehållet i registret i användarläge med hjälp av huvudmenyknappen "Alla funktioner".

Detta är slutet på den lilla recensionen. 1С register om du har några förslag, tillägg då skriv i kommentarerna.

1C Programmer var med dig, jag hjälper dig med .

P.S. Flickan dansar