Bokföringsinformation. Bokföringsinfo BP 3.0 kontroll av negativa saldon

Den här artikeln är avsedd för 1C-implementerare - och speciellt för dem som förbereder sig för 1C-certifieringen: Plattformsspecialist.

Idag ska vi titta 2 metoder för att kontrollera saldon - inte bara saldon i lagret, utan också till exempel ömsesidiga avräkningar ("Vad är kundens nuvarande skuld och är det möjligt att skicka varor till honom?")

Båda metoderna används i standardkonfigurationer och i certifieringsuppgifter. Och eftersom det finns två av dem - du måste tydligt förstå när den "nya" tekniken är tillämplig och när bara den "gamla"..

Detta är grundläggande kunskaper för 1C-programmerare, vi rekommenderar att du inte lämnar luckor i sådana områden. Det borde ta dig att studera 15 minuter :)

Formulering av problemet

Låt oss ta en enkel konfiguration med dokumenten "Mottagning av varor" och "Varuförsäljning":

För att redovisa saldon används ackumuleringsregistret "Fria saldon":

När du bokför dokumentet "Mottagning av varor" utförs följande rörelser:

Bearbetningsprocedur (fel, läge)


För varje TechString-produkter från produktcykeln
Movement = Movements.FreeRemains.Add();
Movement.MovementType = AccumulationMovementType.Incoming;
Movement.Period = Datum;
Movement.Nomenclature = TechStringProducts.Nomenclature;
Movement.Quantity = TechStringProducts.Quantity;
EndCycle;

Slut på procedur

Bearbetning av bokföring av dokumentet "Mottagning av varor" utfördes med hjälp av rörelsedesignern och är inte av intresse, eftersom det inte behövs kontroll av saldon när det anländer till lagret.

Ibland implementeras även saldokontroll för dokumentet "Varumottagning" - så att ett negativt saldo inte bildas när dokumentet avbryts eller bokförs på nytt.

Till exempel kom 10 nya LG-TV-apparater till lagret, 6 av dem såldes. Om kvittohandlingen innehåller 10 st. fixa med 5 st. – ett negativt saldo "minus 1 styck" bildas.

I standarden UT 11 är sådan kontroll aktiverad med det funktionella alternativet "Kontrollera varor från organisationer vid avbokning av kvitton."

När du bokför dokumentet "Varuförsäljning" det är nödvändigt att organisera kontroll av rester. Om det inte finns tillräckligt med produkt kvar, postas inte dokumentet och ett diagnostiskt meddelande utfärdas. Detta är problemet som löses.

Vi arbetar medvetet med ett enkelt problem där avskrivningskostnaden inte beräknas. Detta kommer att tillåta oss att fokusera specifikt på nyanserna av restkontroll.

Notera– Algoritmerna nedan är designade för träning och ska vara så tydliga som möjligt.
De kan optimeras, men då blir "förståelseskoefficienten" lägre, så vi uppehåller oss inte vid detta i den här artikeln.

Naturligtvis kan du optimera dem själv, eller ta vår kurs om acceleration och optimering av 1C :)

Som du redan förstått kan problemet lösas på två sätt. Låt oss börja med en teknik som har använts sedan 1C:Enterprise 8.0.

Gammal metod för kontroll av rester

Principen för den gamla restkontrolltekniken är följande: Vi kontrollerar om det finns kvarvarande varor i erforderlig kvantitet. Om det finns skriver vi av det, om inte rapporterar vi ett fel..

Algoritmen i den gamla metoden består av flera block:

  1. Begäran hämtar produktsaldon och dokumentdata
  2. Kretsloppet övervakar varornas tillräcklighet
  3. Om det inte finns tillräckligt med varor så bokförs inte dokumentet
  4. Om det finns tillräckligt med varor utförs konsumtionsrörelser

Så här ser programkoden ut:

// 1. Rensa gamla registerrörelser
Movements.FreeRemainders.Write = Sant;
Movements.Record();

// 2. Mottagande av dokumentdata och registersaldon på begäran
Request = Ny begäran;
Request.Text =
"VÄLJA

|PLACE produkter
|FRÅN
| VAR
| Products.Link = &Länk
|GRUPP EFTER
| Produkter.Nomenklatur
|INDEXERA EFTER
| Nomenklatur
|;

|VÄLJ
,
| REPRESENTATIONLINK(Products.Nomenclature) AS NomenclatureRepresentation,
| Products.Quantity AS Quantity,
| ISNULL(Remaining.NumberRemaining, 0) AS Remainder
|FRÅN
| Produkter AS Produkter
| LEFT JOIN RegisterAccumulations.FreeRemains.Remains(
| &Ögonblick,
| Nomenklatur B
| (VÄLJA
| Products.Nomenclature AS Nomenclature
| FRÅN
| Software Products.Nomenclature = Remaining.Nomenclature";
Request.SetParameter("TimePoint", TimePoint());

// 3. Gå igenom frågeresultat

// 4. Kontroll av varornas tillräcklighet
Deficit = SampleProducts.Quantity - SampleProducts.Remaining;
Om Underskott>0 Då
Vägra = Sant;
Message.Text = "Produkt "+SelectionProducts.NomenclaturePresentation+" är inte tillräckligt i antal "+Shortage+" st.";
Message.Message();
endIf;

// 5. Gå till början av loopen om det fanns fel
Om misslyckande då
Fortsätta;
endIf;

// 6. Utföra rörelser i register
Movement.Period = Datum;

EndCycle;

// 7. Inställning av flaggan för registrering av rörelser i slutet av transaktionen
Movements.FreeRemainders.Write = Sant;

Slut på procedur

Låt oss kommentera nyckelpunkterna i algoritmen.

1. Rensa gamla registerrörelser

Nedan i algoritmen kommer det att finnas en begäran till resten av registret.

Om det aktuella dokumentet tidigare har lagts upp, så finns det sannolikheten att ta emot gamla dokumentförflyttningar i en begäran– Det här är ett allvarligt problem.

När är en sådan situation möjlig? När är dokumentdatumet går framåt.

Låt oss visa med ett exempel vad detta kommer att leda till:

  1. Resterande bordslampor 10 st.
  2. Dokumentet daterat 16.02.17 behandlas, vi skriver av 6 lampor
  3. Datumet i dokumentet ändras till 02/17/17 (datumet kan flyttas framåt med minst 1 sekund), låt oss posta om dokumentet.

Om du inte rensar rörelser kommer systemet att rapportera en brist på 2 stycken. Varför? Ja, eftersom de gamla dokumentrörelserna skrev av 6 av 10 befintliga lampor. Därefter försöker systemet skriva av ytterligare 6 stycken, men det finns bara 4 kvar.

Problemet löses i 3 rader kod:

  • Postuppsättningen rensas (den kan ha lästs i formuläret eller i tidigare hanterare)
  • Rekordet har flaggan "Write".
  • Alla uppsättningar som har flaggan "Record" spelas in.

Strängt taget kan vi kontrollera rensningen av rörelser när vi lägger upp dokument:

Möjligheten att ta bort rörelser vid avbrytande av utförandet rekommenderas - vi styr själva när det är nödvändigt att faktiskt radera rörelser.

2. Mottagande av dokumentdata och registersaldon på begäran

Förfrågan består av två paket:

  • I den första erhålls grupperade data från tabelldelen - en tillfällig tabell skapas
  • I den andra begäran läggs resterna från registret till dokumentuppgifterna.

Vad du bör vara uppmärksam på i denna begäran:

  1. När du skapar en temporär tabell indexeras fältet där sammanfogningen kommer att utföras - detta görs för optimal prestanda
  2. Tidpunkten för mottagande av saldon – motsvarar dokumentets position på tidsaxeln
  3. Det kanske inte finns några rester i registret - därför utförs en vänsterkoppling och "ECTNULL"-funktionen används för "Quantity"-resursen - NULL-värdet reduceras till noll.

3. Förbigå frågeresultat

Den framtagna begäran innehåller grupperade dokumentdata och saldon per post.

I en slinga går vi igenom resultatet av denna begäran.

4. Kontrollera om varorna är tillräckliga

Vi fastställer bristen på varor.

Om underskottet är större än noll betyder det att det råder brist på varor:

  • Vi skickar ett diagnostiskt meddelande
  • Ställ in parametern "Refusal" för postningsbearbetning till "True"

Om "Refusal" är lika med "True", kommer resultatet av dokumentbokföringstransaktionen inte att registreras. Enkelt uttryckt är detta ett kommando till systemet att inte bearbeta detta dokument.

5. Gå till början av cykeln om det fanns fel

Om det fanns fel vid detta eller tidigare steg i cykeln (Fejl = Sant), så är det ingen idé att bilda rörelser. Ändå kommer de inte att registreras i databasen.

6. Utföra rörelser i register

Om kontrollen av saldon lyckades skapar vi utgiftsrörelsen.

7. Ställa in rörelseregistreringsflaggan i slutet av transaktionen

Om denna flagga inte är inställd kommer rörelser INTE att registreras.

I slutet av dokumentbokföringstransaktionen skrivs endast de uppsättningar poster som har flaggan "Skriv".

För att vara rättvis noterar vi att inställningen av "Record"-egenskapen för en uppsättning poster är meningsfull under ett villkor - i dokumentegenskapen "Record movements under exekvering" måste värdet "Record selected" anges:

Det är dock värdet "Record selected" som är de facto-standarden:

  • Det används i standardlösningar
  • Ställs in som standard när du skapar nya dokument.

Ett annat värde på fastigheten – "Skriv modifierad" – är föråldrat och förekommer praktiskt taget aldrig i moderna konfigurationer.

Ny metod för resthaltskontroll

Den nya metoden använder principen: vi skriver av de nödvändiga varorna och kontrollerar sedan om negativa saldon har bildats för varorna i dokumentet. Om ja, måste du rulla tillbaka dokumentet.

Som du kan se finns det en grundläggande skillnad i ögonblicket för kontroll av balanser:

  • Den gamla metoden är att först kontrollera saldot och sedan skriva av det
  • Ny teknik - först skriver vi av, sedan kontrollerar vi balansen.

Som ett resultat kommer programkoden att se ut så här:

Bearbetningsprocedur (fel, läge)

// 1. Ta emot dokumentdata på begäran
Request = Ny begäran;
Query.TemporaryTableManager = NewTemporaryTableManager;
Request.Text =
"VÄLJA
| Products.Nomenclature AS Nomenclature,
| SUM(Artikel. Kvantitet) SOM Kvantitet
|PLACE produkter
|FRÅN
| Dokument Försäljning av varor och tjänster Goods AS Varor
| VAR
| Products.Link = &Länk
|GRUPP EFTER
| Produkter.Nomenklatur
|INDEXERA EFTER
| Nomenklatur
|;
|////////////////////////////////////////////////////////////////////////////////
|VÄLJ
| Products.Nomenclature AS Nomenclature,
| Products.Quantity AS Quantity
|FRÅN
| Produkter AS Produkter";
Request.SetParameter("Länk", Länk);
RequestResult = Request.Execute();

// 2. Bildande av rörelser - registrera konsumtion
Movements.FreeRemains.Clear();
SelectionProducts = Query Result.Select();
Medan SelectProducts.Next() Loop
Movement = Movements.Free Remainings.AddExpense();
Movement.Period = Datum;
Movement.Nomenclature = SelectionProducts.Nomenclature;
Movement.Quantity = SampleProducts.Quantity;
EndCycle;

// 3. Registrera rörelser i databasen
Movements.FreeRemainders.Write = Sant;
Movements.Record();

// 4. Fråga som tar emot negativa rester från registret
Request.Text =
"VÄLJA
| Remains. Nomenclature AS Nomenclature,
| REPRESENTATIONLINK(Remains.Nomenclature) AS NomenclatureRepresentation,
| -Remaining.QuantityRemaining AS Underskott
|FRÅN
| RegisterAccumulations.FreeRemains.Remains(
| &Ögonblick,
| Nomenklatur B
| (VÄLJA
| Products.Nomenclature AS Nomenclature
| FRÅN
| Produkter AS Produkter)) AS Rester
| VAR
| Remaining.QuantityRemaining< 0";

Control Border = New Boundary(TimePoint(), BorderView.Including);
Request.SetParameter("TimePoint", kontrollgräns);
RequestResult = Request.Execute();

// 5. Visar meddelanden om brist på varor
Om inte QueryResult.Empty() Då
Vägra = Sant;
ErrorSelect = QueryResult.Select();
Medan SelectErrors.Next() Loop
Message = New MessageToUser;
Message.Text = "Produkten "+SampleErrors.NomenclaturePresentation+" räcker inte till i antal "+SampleErrors.Deficiency+" st.";
Message.Message();
EndCycle;
endIf;

Slut på procedur

Låt oss titta på nyckelpunkterna i algoritmen.

1. Ta emot dokumentdata på begäran

Denna fråga behövs för att gruppera data i tabelldelen av dokumentet.

Observera att den första frågan i partiet skapar en tillfällig tabell - den kommer att användas i nästa fråga. Detta är möjligt tack vare den tillfälliga tabellhanteraren som skapas för denna fråga.

2. Bildande av rörelser - registrera konsumtion

I cykeln skrivs data från dokumentet till registret - det vill säga en ovillkorlig (utan verifiering) avskrivning av varor utförs.

3. Registrera rörelser i databasen

För att saldona i registret ska ändras måste rörelser registreras.

4. Fråga som tar emot negativa rester från registret

Nu, med en enkel begäran, väljer vi negativa saldon för dokumentvaror.

Det är här den temporära tabellen som skapades i det första steget används - ett villkor läggs på objektet (för detta skapar vi inte ett nytt objekt av typen "Request", utan använder det som skapats tidigare).

Var uppmärksam på hur ögonblicket i tiden överförs - datatypen "Boundary" används. Återstående saldon måste tas emot vid en tidpunkt omedelbart EFTER det aktuella dokumentet.

Var det möjligt att få saldon utan gräns, till exempel genom att lägga till 1 sekund på dokumentdatumet?

Nej! När allt kommer omkring, på en sekund kan det finnas ett stort antal dokument. Därför är det enda korrekta alternativet att använda gränstypen "Inkluderande".

5. Visa meddelanden om brist på varor

Om frågeresultatet inte är tomt, finns det negativa rester - i det här fallet bearbetas inte dokumentet och meddelanden om alla fel visas.

Fördelar med resthaltskontroll med den nya metoden

Så båda algoritmerna löser samma problem.

Skillnaden mellan algoritmerna är synlig, men fördelarna är inte uppenbara.

Så låt oss lyfta fram dem:

  1. Inget behov av att rensa gamla dokumentrörelser. I huvudsak är detta operationen att skriva en tom uppsättning rörelser till databasen och ta bort befintliga rörelser - det är ganska resurskrävande operationer
  2. En fråga som hämtar data om negativa saldon kommer bara åt en tabell - det finns ingen anledning att göra en vänsterkoppling med dokumentdata och använda funktionen "ISNULL()".

Dessutom anger användaren under normala affärsprocesser en kvantitet som inte överstiger saldot i lagret.

I det här fallet kommer den andra begäran inte att returnera några uppgifter och dokumentbehandlingen kommer att ske så snabbt som möjligt.

Är dessa millisekunder verkligen så viktiga?

På databaser med en liten mängd data och användare kommer skillnaden inte att märkas. Men i upptagna system med dussintals användare är kostnaden för varje millisekund hög.

Dessutom, under 1C:Platform Specialist-examen, måste du definitivt använda en ny metod för att kontrollera balanser, om en specifik uppgift tillåter det.

Ok, så du bör alltid använda en ny teknik, eller hur?

Nej det är inte sant!

Den nya tekniken kan endast användas om all nödvändig data för att behandla dokumentet finns i själva dokumentet.

Det vill säga att för att få data behöver du inte komma åt de register som kontrollerar saldon.

Så om beloppet till exempel även beaktades i registret "Fria saldon" skulle den gamla kontrollmetoden behöva användas.

Förresten, i standarden "1C: Trade Management 11" implementeras balanskontroll med en ny metod, och i "1C: Accounting 8" - enligt den gamla metoden.

Men det är inte allt!

Algoritmerna som presenteras ovan kan endast användas för utbildningsändamål. Poängen är att de inte tar hänsyn kontrollerade lås, som måste användas om det finns mer än en användare på systemet.

Block för båda restkontrollmetoderna diskuteras. Även i den här artikeln löser vi ett mer komplext problem - förutom att kontrollera saldon, beräknar vi kostnaden för avskrivna poster. Vi rekommenderar att du studerar det noggrant.

Och till att börja med, låt oss bara säga det att installera ett lås i den nya metoden är mycket enkelt– och detta är ytterligare en fördel med den nya metoden för kontroll av rester.

Resultat

Låt oss sammanfatta kort.

Vi tittade på två restkontrolltekniker, som var och en används i moderna typiska konfigurationer.

Huvudskillnaden mellan teknikerna vid tidpunkten för kontroll av saldon:

  • Gammal teknik - kontroll innan rörelser registreras i register
  • Ny teknik - kontroll efter registrering av rörelser i register

I allmänhet är den nya tekniken mer effektiv, men den är inte alltid tillämpbar.

Tillämplighetskriterium– om det inte finns något behov av att komma åt data från ett kontrollerat register för att generera rörelser, kan en ny teknik användas.

Om vi ​​talar om kontroll av produktbalanser, så är användningen av en ny teknik möjlig när data om kostnads- och lagersaldon lagras i olika register.

Och slutligen exempel från typiska konfigurationer:

  • I UT 11 det finns 2 huvudregister för redovisning av poster: Fria saldon (kvantitet) och Varukostnad (kostnadsdata) - en ny metod används
  • I BP 3,0 uppgifter om kostnader och saldon lagras i ett redovisningsregister - den gamla metoden för kontroll av saldon används.

Varje organisation måste övervaka lagersaldon. Och ofta uppstår en situation när produkten faktiskt är tillgänglig, men den finns inte i programmet. Och då tvingas revisorn fatta ett beslut:

  • låt det säljas;
  • skjuta upp tills det står klart varför denna situation uppstod.

Beslutet fattas som regel utifrån den policy som följs i organisationen i förhållande till redovisning av saldon. Ibland kan man lägga produkten åt sidan och säga till köparen att det inte går att sälja den nu. Ibland är detta omöjligt att göra. Till exempel när köparen ser den här produkten eller redan håller den i sina händer.

Du kan givetvis helt enkelt generera ett försäljningsdokument och inte lägga upp dokumentet, men det är inte alla organisationer som tillåter detta. Därför är det i 1C 8.3-programmet (som i 8.2) möjligt att inaktivera kontrollen av negativa saldon.

Om saldokontroll är aktiverat kommer programmet att utfärda följande varning när du säljer en vara som inte finns i lager (eller på det konto som krävs):

Kolumnen "Mängd" på rad 1 i listan "Produkter" är felaktigt ifylld.
Den angivna mängden överstiger saldot. Återstående: 18; Saknas: 111 093

Få 267 videolektioner på 1C gratis:

Inaktivera kontroll av negativa saldon i 1C 8.3

För att inaktivera eller aktivera balanskontroll i 1C, måste du gå till "Huvud"-menyn och sedan välja " " i avsnittet "Inställningar".

I vissa versioner av 1C Accounting finns dessa inställningar i menyn "Administration - Dokumentbokföringsinställningar".

I "Redovisningsparametrar" måste du gå till 1C-fliken "Inventarier" och markera kryssrutan "Tillåt avskrivning av varulager om det inte finns några saldon enligt redovisningsdata":

Sedan är allt du behöver göra att klicka på knappen "Spara och stäng". Nu, vid avskrivning, kommer saldon inte att kontrolleras.

Men en sådan metod kommer oundvikligen att leda till uppkomsten av negativa saldon i lagret (vilket betyder i programmet). Låt oss titta på hur man hanterar detta.

Rapportera "Kontroll av negativa saldon"

I det enklaste fallet behöver du bara välja en period och klicka på knappen "Generera". Och det var här som den första överraskningen väntade mig.

Jag simulerade specifikt i testprogrammet en situation där jag sålde fler varor än vad jag har i lager. Dessutom gjorde han denna försäljning 2013. Logiskt sett har jag fortfarande samma produkt i minus nu, 2016. Därför rörde jag inte ens perioden utan klickade direkt på "Generera". Det gick inte för mig. Det visar sig att rapporten endast kan visa information om negativa saldon för den valda perioden.

I mina videohandledningar pratar jag ofta om att 1C-databasen måste förberedas för periodavslutning och rapportering. Och en av de viktiga punkterna med sådan förberedelse är kontrollen av negativa saldon av varor, material och färdiga produkter. Vilka rapporter ska du använda för att kontrollera statusen för lagerkonton i 1C: Redovisning? Låt oss titta på några av dem.

1. Rapportera "Kontobalansräkning"

Många revisorer är vana vid att arbeta med kontobalansräkningar. Denna rapport kan verkligen användas för att kontrollera lagersaldon, du behöver bara se till att inställningarna är inställda för att visa kvantitativa indikatorer.
Klicka på knappen "Visa inställningar" och gå till fliken "Indikatorer".

Sedan går vi noggrant igenom rapporten och analyserar de upptäckta felen

Balansräkningen är bekväm eftersom den låter dig utvärdera inte bara närvaron av negativa kvantitativa saldon, utan också för att upptäcka andra problematiska situationer:
- kvantitativ saldo av inventarier utan belopp;
- total balans utan kvantitet;
- negativt saldo.
Men om ett stort antal poster är inblandade i redovisningen, kan en sådan kontroll vara ganska arbetskrävande. Dessutom kommer SALT att behöva genereras separat för varje redovisningskonto (10, 41, 43), vilket också komplicerar arbetsprocessen något.

2. Rapportera "Kontroll av negativa saldon"

Konfigurationen 1C: Enterprise Accounting 8 edition 3.0 ger en rapport som är idealisk för att övervaka negativa kvantitativa saldon för lagerartiklar. Rapporten finns på fliken "Lager".

Vi anger period, organisation och genererar en rapport.

Rapporten inkluderar endast de poster för vilka ett negativt kvantitativt saldo upptäcktes. Den stora fördelen är att data på alla lagerkonton analyseras. Enligt min mening är det bekvämare att arbeta med rapporten än med OSV.
Men det finns också ett minus - rapporten låter dig övervaka endast negativa kvantitativa saldon, och lämnar bakom kulisserna andra problem som SALT låter dig upptäcka.

3. Rapport "Analys av subconto"

Jag har pratat om denna rapport mer än en gång. Subconto-analys är en av mina favoritrapporter, som gör att du inte bara kan upptäcka fel utan också, i många situationer, förstå deras orsaker.
Gå till avsnittet "Rapporter" - "Subconto Analysis".

Välj subconto "Nomenklatur" och kontrollera att visningen av kvantitativa indikatorer är aktiverad i rapportinställningarna.

Subconto-analys är bra eftersom det gör att du kan få information om rörelsen av lagerartiklar över alla redovisningskonton. Till exempel för att spåra situationer där en produkt kommit till ett konto, men sålts från ett annat.

Men med ett stort antal poster kan det vara svårt att analysera data.
Jag pratade mer om att arbeta med den här rapporten i videohandledningen Hur man arbetar med rapporten "Subconto Analysis" i 1C - VIDEO.
Således har var och en av de granskade rapporterna sina för- och nackdelar. I mitt arbete skulle jag rekommendera att kombinera dem:
- hitta grova fel med hjälp av rapporten "Kontroll av negativa saldon";
- se sedan SALT för alla lagerkonton;
- för att identifiera orsakerna till ett felaktigt saldo, använd rapporten "Subconto Analysis".
Jag diskuterade också intressanta exempel relaterade till att hitta och korrigera fel vid redovisning av inventarier i två användbara videor:

Kontroll över lagersaldon är ett obligatoriskt redovisningsförfarande för alla företag som arbetar med varor. Ofta kan du stöta på en situation där det inte finns någon produkt i programmet, utan det faktiskt finns på lagret. I en sådan situation finns det två alternativ:

  • Skicka den till försäljning;
  • Lämna det på lagret tills omständigheterna i denna situation är klarlagda.

Valet beror på flera faktorer, såsom organisationspolicyer eller den specifika situationen. Om produkten finns på disken och köparen är intresserad av den (håller den i sina händer), är det inte tillrådligt att vägra försäljning.

Vissa företag övar på att skapa ett försäljningsdokument utan att posta det, men alla använder inte denna praxis. I sådana situationer erbjuder 1C-programmet i sina senaste versioner möjligheten att inaktivera kontrollen av negativa saldon.

När kontrollen är aktiverad kommer försäljningen av varor som inte finns i lager enligt programmet att ge användaren en varning: Kolumnen "Mängd" på rad 1 i listan "Produkter" är felaktigt ifylld. "Den angivna kvantiteten överstiger balansen. Kvar: 18. Saknas 111.093.”

Inaktiverar kontroll av negativa saldon i 1C

Operationen för att slå på/av kontroll av saldon i 1C utförs via menyn "Huvud" - "Inställningar" - "Redovisningsparametrar" - "Inventarier". Här måste du markera rutan "Tillåt avskrivning av lager om det inte finns något lager enligt redovisningsdata."

Efter detta bekräftas åtgärden med knappen "Spara och stäng". I sin tur kommer sådana åtgärder garanterat att bli grunden för bildandet av negativa saldon i redovisningen. De kommer att behöva elimineras.

Rapportera "Kontroll av negativa saldon"

Denna rapport genereras via menyn "Lager" - "Rapporter", där dokumentet presenteras. Användaren måste bestämma förfrågningsintervallet och klicka på knappen "Generera". Frånvaron av en angiven period tillåter dig inte att visa negativa saldon, vilket är en funktion i systemet som kräver obligatoriskt ifyllande av kolumnen "Period".

Den färdiga rapporten har följande utseende.

En standarduppsättning filter finns tillgänglig för själva rapporten, inklusive gruppering, sortering och andra datatransformationer i enlighet med användarens önskemål och behov. Med knappen "Visa inställningar" kan du manuellt inkludera ytterligare rader i rapporten.

Denna rapport hjälper till att få sammanfattande eller detaljerad information om negativa saldon på 41 konton när som helst. Resultatet av rapporten visas med standarddetaljer (se fig. 1)

Därför att Eftersom rapporten är helt skriven med hjälp av ett datalayoutschema kommer det inte att vara svårt för användaren att ändra rapportavsnitt från användarläge (se fig. 2)

Den externa rapporten är avsedd för konfigurationen "1C: Enterprise Accounting 8, edition 3.0" och "edition 3.0 (KORP)", som körs på plattformsversion 8.2 i läget "MANAGED APPLICATION".

Gratis supportperiod: 1 månad.

Skäl att köpa

Negativa saldon är alltid en huvudvärk för alla revisorer. Negativa saldon på 41 konton förvärrar denna situation dubbelt. Denna rapport visar snabbt och tydligt allt "rodnad" i 41 punkter i en bekväm och visuell form. Dessutom lEventuellt negativt saldo på 41 konton kan dechiffreras med hjälp av rapporterna "Subconto Analysis" och "Account Card". Samtidigt, genom att kombinera användningen av dessa rapporter, är det möjligt att gå rakt ner till nivån för de registerhandlingar som orsakade varurörelsen. För att göra detta klickar du bara på önskat nummer i rapporten och väljer rapporten för avkodning.

Enligt många förfrågningar från användare skapades en separat version av rapporten "Kontroll av negativa saldon på lagerkonton", som lade till möjligheten att kontrollera negativa saldon, inte bara för 41 konton, utan även andra huvudkonton för lagerförflyttning föremål:

Konto 07 Utrustning för installation
- Konto 08.04 Förvärv av anläggningstillgångar
- Konto 10 alla, utom 10.07 (material överfört för bearbetning till tredje part)
- Konto 21 Halvfabrikat av egen tillverkning
- Konto 41 alla, utom 41.12 (Varor i detaljhandeln (i NTT till försäljningsvärde))
- Konto 42.01 Handelsmarginal i automatiserade butiker
- Konto 43 Färdiga produkter

Kom också ihåg att negativa saldon inte bara kan uppstå på lagerkonton utan även på tulldeklarationskontot. Om du också behöver kontrollera detta konto rekommenderar vi att du bekantar dig med den externa rapporten

Fördelar

  1. Anslutning genom mekanismen för extern bearbetning och rapportering. Detta gör att du kan använda rapporten utan att göra några ändringar i standardkonfigurationen. Det är också möjligt att öppna en standardrapport via "Arkiv" -> "Öppna".
  2. Möjlighet att anpassa rapporten "för dig själv" från användarläget.

Pengar tillbaka garanti

Infostart LLC garanterar dig 100 % återbetalning om programmet inte motsvarar den deklarerade funktionaliteten från beskrivningen. Pengarna kan återbetalas i sin helhet om du begär detta inom 14 dagar från det datum pengarna mottagits på vårt konto.

Programmet har visat sig fungera så pass att vi kan ge en sådan garanti med full tillförsikt. Vi vill att alla våra kunder ska vara nöjda med sitt köp.