Regnskabsoplysninger. Regnskabsinfo Kontrol af negative saldi i 1s 8.2 regnskab

Kontrol over lagersaldi er en obligatorisk regnskabsprocedure i enhver virksomhed, der arbejder med varer. Ofte kan du støde på en situation, hvor der ikke er noget produkt i programmet, men det faktisk er på lageret. I en sådan situation er der to muligheder:

Send det til salg;
Lad det blive på lageret, indtil omstændighederne i denne situation er afklaret.

Valget afhænger af flere faktorer, såsom organisationspolitikker eller den konkrete situation. Hvis produktet er på disken, og køberen er interesseret i det (holder det i hænderne), er det ikke tilrådeligt at nægte salget.

Nogle virksomheder øver sig i at generere et salgsdokument uden at bogføre det, men ikke alle bruger denne praksis. I tilfælde af sådanne situationer giver 1C-programmet i dets seneste versioner mulighed for at deaktivere kontrollen af negative saldi.

Når kontrol er aktiveret, vil salg af varer, der ikke er på lager i henhold til programmet, give brugeren en advarsel: "Mængde"-kolonnen i linje 1 på "Produkter"-listen er udfyldt forkert. "Den angivne mængde overstiger saldoen. Tilbage: 18. Mangler 111.093.”

Deaktivering af styring af negative saldi i 1C

Operationen med at tænde/slukke kontrol af saldi i 1C udføres gennem menuen "Hoved" - "Indstillinger" - "Regnskabsparametre" - "Beholdninger". Her skal du markere afkrydsningsfeltet "Tillad afskrivning af beholdning, hvis der ikke er nogen beholdning i henhold til regnskabsdata."

Herefter bekræftes handlingen med knappen "Gem og luk". Til gengæld er sådanne handlinger garanteret grundlaget for dannelsen af negative saldi i regnskabet. De skal elimineres.

Rapport "Kontrol af negative saldi"

Denne rapport genereres via menuen "Lager" - "Rapporter", hvor dokumentet præsenteres. Brugeren skal bestemme anmodningsintervallet og klikke på knappen "Generer". Fraværet af en bestemt periode vil ikke tillade dig at vise negative saldi, hvilket er en funktion i systemet, der kræver obligatorisk udfyldelse af kolonnen "Periode".

Den færdige rapport har følgende udseende.

Et standardsæt af filtre er tilgængeligt for selve rapporten, herunder gruppering, sortering og andre datatransformationer i overensstemmelse med brugernes ønsker og behov. Ved at bruge knappen "Vis indstillinger" kan du manuelt inkludere yderligere rækker i rapporten.

I mine video tutorials taler jeg ofte om, at 1C databasen skal forberedes til periodeafslutning og rapportering. Og et af de vigtige punkter i en sådan forberedelse er kontrollen af negative saldi af varer, materialer og færdige produkter. Hvilke rapporter skal du bruge til at kontrollere status for lagerkonti i 1C: Regnskab? Lad os se på nogle af dem.

1. Rapporter "Kontobalance"

Mange revisorer er vant til at arbejde med kontobalancer. Denne rapport kan faktisk bruges til at kontrollere lagersaldi, du skal blot sørge for, at indstillingerne er indstillet til at vise kvantitative indikatorer.
Klik på knappen "Vis indstillinger", og gå til fanen "Indikatorer".

Derefter gennemgår vi omhyggeligt rapporten og analyserer de opdagede fejl

Balancen er praktisk, fordi den giver dig mulighed for ikke kun at evaluere tilstedeværelsen af negative kvantitative saldi, men også at opdage andre problematiske situationer:
- kvantitativ balance af lagerposter uden beløb;
- samlet saldo uden mængde;
- negativ saldo.
Men hvis et stort antal vareposter er involveret i regnskabet, så kan en sådan kontrol være ret arbejdskrævende. Derudover vil SALT skulle genereres separat for hver regnskabskonto (10, 41, 43), hvilket også komplicerer arbejdsprocessen noget.

2. Rapport "Kontrol af negative saldi"

1C: Enterprise Accounting 8 edition 3.0-konfigurationen giver en rapport, der er ideel til overvågning af negative kvantitative saldi af lagervarer. Rapporten er placeret på fanen "Lager".

Vi angiver periode, organisation og genererer en rapport.

Rapporten omfatter kun de postposter, for hvilke der er konstateret en negativ kvantitativ saldo. Den store fordel er, at data på alle lagerkonti analyseres. Efter min mening er det mere bekvemt at arbejde med rapporten end med OSV.
Men der er også et minus - rapporten giver dig mulighed for kun at overvåge negative kvantitative saldi, hvilket efterlader andre problemer bag kulisserne, som SALT giver dig mulighed for at opdage.

3. Rapport "Analyse af subconto"

Jeg har talt om denne betænkning mere end én gang. Subconto-analyse er en af mine yndlingsrapporter, som giver dig mulighed for ikke kun at opdage fejl, men også i mange situationer at forstå deres årsager.
Gå til afsnittet "Rapporter" - "Subconto Analyse".

Vælg underkontoen "Nomenklatur", og kontroller, at visningen af kvantitative indikatorer er aktiveret i rapportindstillingerne.

Subconto-analyse er god, fordi den giver dig mulighed for at få information om bevægelsen af lagervarer på tværs af alle regnskabskonti. For eksempel for at spore situationer, hvor et produkt ankom til én regnskabskonto, men blev solgt fra en anden.

Men med et stort antal poster kan det være svært at analysere dataene.
Jeg talte mere om at arbejde med denne rapport i videovejledningen Sådan arbejder du med rapporten "Subconto Analysis" i 1C - VIDEO.
Hver af de gennemgåede rapporter har således sine fordele og ulemper. I mit arbejde vil jeg anbefale at kombinere dem:
- find grove fejl ved hjælp af rapporten "Kontrol af negative saldi";
- se derefter SALT for alle lagerkonti;
- for at identificere årsagerne til en ukorrekt saldo, brug rapporten "Subconto Analysis".
Jeg diskuterede også interessante eksempler relateret til at finde og rette fejl, når der tages højde for lagervarer i to nyttige videoer:

Hvordan kontrollerer man lagersaldi i 1C 8.3 Regnskabsprogrammet?

Enhver organisation skal overvåge lagerbalancer. Og det er ikke ualmindeligt, at der opstår en situation, når et produkt faktisk er tilgængeligt, men det er ikke i programmet. Og så er revisor tvunget til at træffe en beslutning:

tillade den at blive solgt
udsætte, indtil det står klart, hvorfor denne situation opstod

Beslutningen træffes som udgangspunkt ud fra den politik, der følges i organisationen i forhold til regnskabsføring af mellemværender. Nogle gange kan du lægge en vare til side og fortælle køberen, at vi ikke kan sælge den til dig nu. Nogle gange er dette umuligt at gøre. For eksempel i detailhandlen, når køberen ser dette produkt eller allerede har det i sine hænder.

Du kan selvfølgelig blot generere et salgsdokument og ikke bogføre dokumentet, men det er ikke alle organisationer, der tillader dette. Derfor er det i 1C 8.3-programmet (som i 8.2) muligt at deaktivere kontrollen af negative saldi.

Hvis saldokontrol er aktiveret, vil programmet udsende en lignende advarsel, når du sælger et produkt, der ikke er på lager (eller på den påkrævede konto):

Kolonnen "Mængde" i linje 1 på listen "Produkter" er udfyldt forkert.

Den angivne mængde overstiger saldoen. Resterende: 18; Mangler: 111.093

Deaktivering af kontrol med negative saldi i 1C 8.3

For at deaktivere eller aktivere balancekontrol i 1C, skal du gå til menuen "Hoved" og derefter vælge "Regnskabsparametre" i afsnittet "Indstillinger".

I nogle versioner af 1C Accounting er disse indstillinger placeret i menuen Administration - Dokumentbogføringsindstillinger.

I "Regnskabsparametre" skal du gå til fanen 1C "Beholdninger" og markere afkrydsningsfeltet "Tillad afskrivning af varebeholdninger, hvis der ikke er saldi i henhold til regnskabsdata":

Så skal du blot klikke på knappen "Gem og luk". Nu, når der afskrives, vil saldi ikke blive kontrolleret.

Men en sådan metode vil uundgåeligt føre til udseendet af negative saldi på lageret (hvilket betyder i programmet). Lad os se på, hvordan man håndterer dette.

Rapport "Kontrol af negative saldi"

I det enkleste tilfælde skal du blot vælge en periode og klikke på knappen "Generer". Og det var her, den første overraskelse ventede mig.

Jeg simulerede specifikt i testprogrammet en situation, hvor jeg solgte flere varer, end jeg har på lager. Desuden foretog han dette salg i 2013. Logisk set har jeg stadig det samme produkt i minus nu, i 2016. Derfor rørte jeg ikke engang perioden, men trykkede straks på "Generer". Det lykkedes ikke for mig. Det viser sig, at rapporten kun kan vise oplysninger om negative saldi for den valgte periode.

Dette bør tages i betragtning, fordi jeg ofte stødte på spørgsmålet i foraene "Hvorfor viser rapporten mig ikke noget?" Svarene var forskellige, mest om forkert installerede filtre, men jeg er aldrig stødt på noget om perioden.

Efter jeg havde indstillet den ønskede periode, blev rapporten genereret korrekt:

Alle andre indstillinger er standard, du kan indstille forskellige filtre, tilføje grupperinger, ændre sortering, tilføje yderligere felter (knappen "Vis indstillinger").

Baseret på materialer fra: programmist1s.ru

Hos handels- eller produktionsvirksomheder "dukker negative saldi op" i regnskabssystemet. De afspejler alt for meget afskrevne varer/materialer.

Hvad er årsagerne til deres forekomst?

Ingen ankomst

Ofte kan den mest almindelige årsag være manglende varemodtagelse eller indførsel af startsaldi. For eksempel har du købt et produkt, men det er endnu ikke lykkedes at registrere det i systemet, men det er allerede lykkedes at sælge det. Det, der sker, er, at varerne blev registreret, derefter flyttet til butikken og solgt, men nogen annullerede kvitteringsdokumentet.

I denne situation ville den korrekte fremgangsmåde være at kontrollere tilstedeværelsen af kvitteringsdokumentet i databasen. Hvis det er der og ikke er bogført, så tjek fyldet og post det. Ligger kvitteringsdokumentet slet ikke i databasen, skal du indtaste det med tilbagevirkende kraft. Det er nødvendigt at forstå, at tilføjelse af dokumenter med tilbagevirkende kraft i en lukket afgiftsperiode kan føre til ændringer i afgiftsbeløb, især moms.

Omklassificering

En anden almindelig årsag til det fænomen, vi overvejer, er fejlvurdering eller overskud af én type produkt (materiale) og samtidig mangel på en anden. For eksempel er der i programmet kun markeret en sort pung i mængden af 10 styks på lager, men i en butik sælger sælgeren en rød pung og registrerer sit salg i databasen i mængden af 5 styks. Som et resultat falder saldoen af sorte punge i databasen ikke, men vores saldo vises i røde punge.

I dette tilfælde løses korrektion af saldi på følgende måde: registrering af et produkt og afskrivning af et andet registreres. For at gøre dette oprettes et dokument "Kontering af varer", og 5 varer aktiveres i det. røde tegnebøger. Dernæst oprettes et dokument "Afskrivning af varer", og der afskrives 5 varer i det. sorte punge.

Når der i 1C:Regnskab 3.0 er en negativ saldo for et produkt (materialer), så vises en informationsmeddelelse ved bogføring af "Varesalg"-bilaget om, at det ikke er muligt at bogføre dette bilag, da antallet af enheder vist i tabeldelen af dokumentet overstiger saldoen.

Fig. 1 Meddelelse i dokumentet, når der ikke er balance på lageret

Advarselssignaler i balancen - negative saldi er fremhævet med rødt!

Fig.2 Sporing af OSV

Sådan aktiveres eller deaktiveres kontrol af negative saldi i 1C BP 3.0

Du kan konfigurere kontrol i afsnittet "Administration" og derefter klikke på linket "Send dokumenter".

Fig.3 Indstilling

For at deaktivere kontrol skal du aktivere flaget på parameteren "Tillad lagerafskrivning, hvis der ikke er saldi i henhold til regnskabsdata."

Fig. 4 Tilladelse til at afskrive enheder med negative saldoindikatorer

Det sker, at for hurtigt at sælge et produkt, der også akut skal sendes, skal du midlertidigt deaktivere kontrollen. "Implementeringer"-dokumentet bogføres i systemet, og derefter aktiveres kontrol igen. Så skal du huske at analysere saldierne for at rette op på den regnskabsfejl, der forårsagede det negative produkt.

For at kontrollere saldi efter lager, skal du opsætte analyser for dem i "Kontoindstillinger" gennem "Administration".

Fig.5 Parametre

Klik på "Opsæt kontoplan".

Fig.6 Indstilling af parameter

Klik på "Efter vare, partier og lagre (efter mængde og mængde)".

Fig.7 Beholdningsregnskabsparametre

Når du installerer analytics, vælger vi ved at klikke på "Efter varehuse (lagersteder)", hvordan vi skal føre optegnelser.

Fig.8 Aktivering af lageranalyse

Hvis indstillingen "efter mængde og beløb" er valgt, vil regnskabet følgelig være i kvantitativ og total bogføring for lagre separat, og hvis "efter mængde", så kun kvantitativ i forbindelse med hvert lager, og afskrivningsbeløbene er bestemmes ved at dividere prisen på lager med hele mængden på alle lagre.

Kontrolrapporter

Rapporten "Kontrol af negative saldi" bruges til at analysere opdagede negative saldi af organisationers varer. Du kan åbne den via "Lager - Kontrol af negative saldi".

Fig. 9 Rapporter til kontrol af saldi

Fig.10 Kontrolrapportskema

I rapportindstillingerne kan du angive, hvilke data rapporten skal bygges på, f.eks. gruppere data efter Organisation, Lager, Afskrivningsdokument, Vare osv.

Fig.11 Indstillinger for kontrolrapport

I udvalget kan du angive, hvilke data der skal genereres en rapport om, for eksempel for et specifikt lager eller for en problematisk vare.

Fig. 12 Valg i kontrolrapporten

Fig. 13 Generering af en kontrolrapport

Negative saldi er en slags indikator for regnskabsfejl. Det er vigtigt konstant at overvåge lagersaldi og rette dem rettidigt. Eksisterende ukorrekte saldi skaber problemer for brugernes operationelle arbejde og kan også forårsage forkert beregning af omkostninger, opskrivning og andre vigtige regnskabsindikatorer.

Denne artikel er beregnet til 1C implementere - og især til dem, der forbereder sig til 1C Certification: Platform Specialist.

I dag kigger vi 2 metoder til at kontrollere saldi - ikke kun saldi på lageret, men også for eksempel gensidige afregninger ("Hvad er kundens nuværende gæld, og er det muligt at sende varer til ham?")

Begge metoder bruges i standardkonfigurationer og i certificeringsopgaver. Og da der er to af dem - du skal klart forstå, hvornår den "nye" teknik er anvendelig, og hvornår kun den "gamle"..

Dette er grundlæggende viden for 1C-programmører, vi anbefaler ikke at efterlade huller i sådanne områder. Det burde tage dig at studere 15 minutter :)

Redegørelse for problemet

Lad os tage en simpel konfiguration med dokumenterne "Modtagelse af varer" og "salg af varer":

Til opgørelse af saldi anvendes akkumuleringsregisteret "Fri saldi":

Ved bogføring af dokumentet "Varemodtagelse" udføres følgende bevægelser:

Behandlingsprocedure (fejl, tilstand)

For hver TechString-produkter fra produktcyklus
Movement = Movements.FreeRemains.Add();
Movement.MovementType = AccumulationMovementType.Incoming;
Movement.Period = Dato;
Movement.Nomenclature = TechStringProducts.Nomenclature;
Movement.Quantity = TechStringProducts.Quantity;
EndCycle;

Afslutning af procedure

Behandling af bogføring af dokumentet "Modtagelse af varer" blev udført ved hjælp af bevægelsesdesigneren og er ikke af interesse, da det ikke er nødvendigt at kontrollere saldi, når det ankommer til lageret.

Nogle gange implementeres der også saldokontrol for "varemodtagelse"-dokumentet - således at når bilaget annulleres eller bogføres igen, dannes der ikke en negativ saldo.

For eksempel ankom 10 nye LG TV'er til lageret, 6 af dem blev solgt. Hvis kvitteringsdokumentet indeholder 10 stk. fiks med 5 stk. – der dannes en negativ saldo "minus 1 stk".

I standarden UT 11 er en sådan kontrol aktiveret ved hjælp af den funktionelle mulighed "Kontrol varer fra organisationer ved annullering af kvitteringer."

Ved bogføring af bilaget "Varesalg" det er nødvendigt at organisere kontrol med rester. Hvis der ikke er nok produkt tilbage, bogføres dokumentet ikke, og der udsendes en diagnosemeddelelse. Dette er problemet, der bliver løst.

Vi arbejder med vilje på et simpelt problem, hvor afskrivningsomkostningen ikke beregnes. Dette vil give os mulighed for at fokusere specifikt på nuancerne af restkontrol.

Note– algoritmerne præsenteret nedenfor er designet til træning og skal være så tydelige som muligt.
De kan optimeres, men så bliver "forståelseskoefficienten" lavere, så det dvæler vi ikke ved i denne artikel.

Du kan naturligvis optimere dem selv, eller tage vores kursus i Acceleration og Optimering af 1C :)

Som du allerede har forstået, kan problemet løses på to måder. Lad os starte med en teknik, der er blevet brugt siden 1C:Enterprise 8.0.

Gammel metode til restkoncentrationsbekæmpelse

Princippet for den gamle restkontrolteknik er som følger: Vi tjekker om der er varer tilbage i den nødvendige mængde. Hvis der er, afskriver vi det, hvis ikke, melder vi en fejl..

Algoritmen i den gamle metode består af flere blokke:

Forespørgslen henter produktbalancer og dokumentdata
Kredsløbet overvåger varernes tilstrækkelighed
Hvis der ikke er nok varer, bogføres bilaget ikke
Hvis der er varer nok, udføres forbrugsbevægelser

Sådan ser programkoden ud:

// 1. Rydning af gamle registerbevægelser
Movements.FreeRemainders.Write = Sand;
Movements.Record();

// 3. Gennemgang af forespørgselsresultater

// 4. Kontrol af varernes tilstrækkelighed
Deficit = SampleProducts.Quantity - SampleProducts.Remaining;
Hvis Underskud>0 Så
Afvise = Sandt;
Message.Text = "Produkt "+SelectionProducts.NomenclaturePresentation+" er ikke nok i antal "+Shortage+" stk.";
Message.Message();
endIf;

// 5. Gå til begyndelsen af løkken, hvis der var fejl
Hvis Fejl Så
Fortsætte;
endIf;

// 6. Udførelse af bevægelser ind i registre
Movement.Period = Dato;

EndCycle;

// 7. Indstilling af flag for registrering af bevægelser ved slutningen af transaktionen
Movements.FreeRemainders.Write = Sand;

Afslutning af procedure

Lad os kommentere nøglepunkterne i algoritmen.

1. Rydning af gamle registerbevægelser

Nedenfor i algoritmen vil der være en anmodning til resten af registret.

Hvis det aktuelle dokument tidligere var bogført, så er der sandsynlighed for at modtage gamle dokumentbevægelser i en anmodning- det er et alvorligt problem.

Hvornår er en sådan situation mulig? Hvornår er dokumentdatoen bevæger sig fremad.

Lad os vise med et eksempel, hvad dette vil føre til:

Resterende bordlamper 10 stk.
Dokumentet dateret 16.02.17 er under behandling, vi afskriver 6 lamper
Datoen i dokumentet ændres til 02/17/17 (datoen kan flyttes frem med mindst 1 sekund), lad os genposte dokumentet.

Hvis du ikke klarer bevægelser, vil systemet melde om mangel på 2 stk. Hvorfor? Ja, fordi de gamle dokumentbevægelser afskrev 6 ud af 10 eksisterende lamper. Dernæst forsøger systemet at afskrive 6 stykker mere, men der er kun 4 tilbage.

Problemet er løst i 3 linjer kode:

Recordsettet ryddes (det kan være blevet læst på formularen eller i tidligere behandlere)
Rekordsættet har "Skriv"-flaget sat
Alle sæt, der har "Record"-flaget, bliver optaget.

Strengt taget kan vi kontrollere oprydningen af bevægelser, når vi poster dokumenter:

Muligheden for at slette bevægelser ved annullering af udførelsen anbefales - vi styrer selv hvornår det er nødvendigt rent faktisk at slette bevægelser.

2. Modtagelse af dokumentdata og registersaldi efter anmodning

Anmodningen består af to pakker:

I den første opnås grupperede data fra tabeldelen - en midlertidig tabel oprettes
I den anden anmodning tilføjes resten af registret til dokumentdataene.

Hvad du skal være opmærksom på i denne anmodning:

Når du opretter en midlertidig tabel, indekseres feltet, som joinforbindelsen skal udføres på - dette gøres for optimal ydeevne
Tidspunktet for modtagelse af saldi – svarer til dokumentets position på tidsaksen
Der er muligvis ingen rester i registeret - derfor udføres en venstre join, og "ECTNULL" funktionen bruges til "Quantity" ressourcen - NULL værdien reduceres til nul.

3. Omgå forespørgselsresultater

Den udviklede anmodning indeholder grupperede bilagsdata og saldi efter vareposter.

I en løkke gennemgår vi resultatet af denne anmodning.

4. Kontroller, om varer er tilstrækkelige

Vi bestemmer varemangelen.

Hvis underskuddet er større end nul, betyder det, at der er mangel på varer:

Vi udsender en diagnosticeringsmeddelelse
Indstil "Afvisning"-parameteren for bogføringsbehandling til "True"

Hvis "Afvisning" er lig med "True", så vil resultatet af dokumentposteringstransaktionen ikke blive registreret. Enkelt sagt er dette en kommando til systemet om ikke at behandle dette dokument.

5. Gå til begyndelsen af cyklussen, hvis der var fejl

Hvis der var fejl på dette eller tidligere trin i cyklussen (Fejl = Sand), så nytter det ikke noget at danne bevægelser. Alligevel vil de ikke blive registreret i databasen.

6. Udførelse af bevægelser i registre

Hvis kontrollen af saldi var vellykket, opretter vi udgiftsbevægelsen.

7. Indstilling af bevægelsesoptagelsesflaget ved slutningen af transaktionen

Hvis dette flag ikke er sat, vil bevægelser IKKE blive registreret.

Ved slutningen af dokumentposteringstransaktionen skrives kun de sæt poster, der har "Skriv"-flaget sat.

For at være retfærdig bemærker vi, at indstilling af "Record"-egenskaben for et sæt poster giver mening under én betingelse - i dokumentegenskaben "Record movements under execution" skal værdien "Record selected" angives:

Det er dog værdien "Optag valgt", der er de facto-standarden:

Det bruges i standardløsninger
Indstillet som standard ved oprettelse af nye dokumenter.

En anden værdi af ejendommen - "Skriv modificeret" - er forældet og forekommer praktisk talt aldrig i moderne konfigurationer.

Ny metode til restkoncentrationsbekæmpelse

Den nye metode bruger princippet: vi afskriver de nødvendige varer, og kontrollerer derefter, om der er dannet negative saldi for dokumentets varer. Hvis ja, skal du rulle dokumentet tilbage.

Som du kan se, er der en grundlæggende forskel i tidspunktet for kontrol af balancer:

Den gamle metode er først at tjekke saldoen og derefter afskrive den
Ny teknik - først afskriver vi, så tjekker vi balancen.

Som et resultat vil programkoden se sådan ud:

Behandlingsprocedure (fejl, tilstand)

// 2. Dannelse af bevægelser - register forbrug
Movements.FreeRemains.Clear();
SelectionProducts = Query Result.Select();
Mens SelectProducts.Next() Loop
Movement = Movements.Free Remanings.AddExpense();
Movement.Period = Dato;
Movement.Nomenclature = SelectionProducts.Nomenclature;
Movement.Quantity = SampleProducts.Quantity;
EndCycle;

// 3. Registrering af bevægelser i databasen
Movements.FreeRemainders.Write = Sand;
Movements.Record();

Control Border = New Boundary(TimePoint(), BorderView.Including);
Request.SetParameter("TimePoint", kontrolgrænse);
RequestResult = Request.Execute();

// 5. Visning af meddelelser om mangel på varer
Hvis ikke QueryResult.Empty() Så
Afvise = Sandt;
ErrorSelect = QueryResult.Select();
Mens SelectErrors.Next() Loop
Message = New MessageToUser;
Message.Text = "Produktet "+SampleErrors.NomenclaturePresentation+" er ikke nok i antal "+SampleErrors.Deficiency+" stk.";
Message.Message();
EndCycle;
endIf;

Afslutning af procedure

Lad os se på nøglepunkterne i algoritmen.

1. Modtagelse af dokumentdata efter anmodning

Denne forespørgsel er nødvendig for at gruppere dataene i tabeldelen af dokumentet.

Bemærk, at den første forespørgsel i partiet opretter en midlertidig tabel - den vil blive brugt i den næste forespørgsel. Dette er muligt takket være den midlertidige tabelmanager, der er oprettet til denne forespørgsel.

2. Dannelse af bevægelser - registrer forbrug

I cyklussen skrives data fra dokumentet til registret - det vil sige, at der udføres en ubetinget (uden verifikation) afskrivning af varer.

3. Registrering af bevægelser i databasen

For at saldierne i registret kan ændre sig, skal bevægelser registreres.

4. Forespørgsel modtagelse af negative saldi fra registeret

Nu vælger vi med en simpel anmodning negative saldi for dokumentvarer.

Det er her den midlertidige tabel, der blev oprettet i det første trin, bruges - en betingelse pålægges varen (til dette opretter vi ikke et nyt objekt af typen "Request", men bruger det, der blev oprettet tidligere).

Vær opmærksom på, hvordan tidspunktet transmitteres - datatypen "Boundary" bruges. Resterende saldi skal modtages på et tidspunkt umiddelbart EFTER det aktuelle dokument.

Var det muligt at få saldi uden grænse, for eksempel ved at tilføje 1 sekund til dokumentdatoen?

Ingen! På et sekund kan der trods alt være et stort antal dokumenter. Derfor er den eneste rigtige mulighed at bruge kanttypen "Inkluderer".

5. Visning af beskeder om mangel på varer

Hvis forespørgselsresultatet ikke er tomt, betyder det, at der er negative rester - i dette tilfælde behandles dokumentet ikke, og meddelelser om alle fejl vises.

Fordele ved restkoncentrationskontrol ved hjælp af den nye metode

Så begge algoritmer løser det samme problem.

Forskellen mellem algoritmerne er synlig, men fordelene er ikke indlysende.

Så lad os fremhæve dem:

Ingen grund til at rydde gamle dokumentbevægelser. I bund og grund er dette operationen med at skrive et tomt sæt bevægelser til databasen og slette eksisterende bevægelser - det er ret ressourcekrævende operationer
En forespørgsel, der henter data om negative saldi, får kun adgang til én tabel - der er ingen grund til at lave en venstre joinforbindelse med dokumentdataene og bruge funktionen "ISNULL()".

Derudover angiver brugeren under det normale forløb af forretningsprocesser en mængde, der ikke overstiger saldoen på lageret.

I dette tilfælde vil den anden anmodning ikke returnere nogen data, og dokumentbehandlingen vil være så hurtig som muligt.

Er disse millisekunder virkelig så vigtige?

På databaser med en lille mængde data og brugere vil forskellen ikke være mærkbar. Men i travle systemer med snesevis af brugere er omkostningerne for hvert millisekund høje.

Derudover skal du under 1C:Platform Specialist-eksamenen helt sikkert bruge en ny metode til at kontrollere balancer, hvis en specifik opgave tillader det.

Ok, så du bør altid bruge en ny teknik, ikke?

Nej, det er ikke sandt!

Den nye teknik kan kun bruges, hvis alle nødvendige data til behandling af dokumentet er i selve dokumentet.

Det vil sige, at man for at indhente data ikke behøver at tilgå de registre, der kontrollerer saldi.

Så hvis beløbet f.eks. også blev taget i betragtning i registret "Fri saldi", så skulle den gamle kontrolmetode anvendes.

Forresten, i standarden "1C: Trade Management 11" er balancekontrol implementeret ved hjælp af en ny metode, og i "1C: Accounting 8" - i henhold til den gamle metode.

Men det er ikke alt!

Algoritmerne præsenteret ovenfor kan kun bruges til uddannelsesformål. Pointen er, at de ikke tager hensyn kontrollerede låse, som skal bruges, hvis der er mere end én bruger på systemet.

Blokke for begge restkontrolmetoder diskuteres. Også i denne artikel løser vi et mere komplekst problem - udover at kontrollere saldi, beregner vi omkostningerne til afskrevne poster. Vi anbefaler, at du studerer det omhyggeligt.

Og for det første, lad os bare sige det at installere en lås i den nye metode er meget enkel– og det er endnu en fordel ved den nye metode til restkoncentrationsbekæmpelse.

Resultater

Lad os kort opsummere.

Vi så på to restkontrolteknikker, som hver især bruges i moderne typiske konfigurationer.

Nøgleforskellen mellem teknikkerne på tidspunktet for kontrol af saldi:

Gammel teknik - kontrol før registrering af bevægelser i registre
Ny teknik - kontrol efter registrering af bevægelser i registre

Generelt er den nye teknik mere effektiv, men den er ikke altid anvendelig.

Anvendelighedskriterium– hvis der ikke er behov for at få adgang til data fra et kontrolleret register for at generere bevægelser, kan en ny teknik bruges.

Hvis vi taler om kontrol af produktbalancer, så er brugen af en ny teknik mulig, når data om omkostnings- og lagersaldi er lagret i forskellige registre.

Og endelig eksempler fra typiske konfigurationer:

I UT 11 der er 2 hovedregistre til bogføring af poster: Frie saldi (mængde) og Vareomkostninger (omkostningsdata) - en ny metode anvendes
I BP 3,0 data om omkostninger og saldi gemmes i ét regnskabsregister - den gamle metode til kontrol af saldi anvendes.