Regnskapsinformasjon. Regnskapsinfo BP 3.0 kontroll av negative saldoer

Denne artikkelen er ment for 1C-implementere - og spesielt for de som forbereder seg på 1C-sertifiseringen: Plattformspesialist.

I dag skal vi se 2 metoder for å kontrollere saldoer - ikke bare saldoer på lageret, men også for eksempel gjensidige oppgjør ("Hva er kundens gjeldende gjeld og er det mulig å sende varer til ham?")

Begge metodene brukes i standardkonfigurasjoner og i sertifiseringsoppgaver. Og siden det er to av dem - du må tydelig forstå når den "nye" teknikken er anvendelig, og når bare den "gamle"..

Dette er grunnleggende kunnskap for 1C-programmerere; vi anbefaler ikke å etterlate hull i slike områder. Det bør ta deg å studere 15 minutter :)

Formulering av problemet

La oss ta en enkel konfigurasjon med dokumentene "Mottak av varer" og "Salg av varer":

For å redegjøre for saldoer brukes akkumuleringsregisteret "Fri saldoer":

Når du posterer dokumentet "Mottak av varer" utføres følgende bevegelser:

Behandlingsprosedyre (feil, modus)

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

Slutt på prosedyre

Behandling av postering av dokumentet "Mottak av varer" ble utført ved hjelp av bevegelsesdesigneren og er ikke av interesse, siden når det kommer til lageret, er det ikke nødvendig med kontroll av saldoene.

Noen ganger implementeres også saldokontroll for "varemottak"-dokumentet - slik at når dokumentet kanselleres eller bokføres på nytt, dannes det ikke en negativ saldo.

For eksempel kom 10 nye LG TV-er til lageret, 6 av dem ble solgt. Dersom kvitteringsdokumentet inneholder 10 stk. fiks med 5 stk. – det dannes en negativ saldo "minus 1 stk".

I standard UT 11 er slik kontroll aktivert ved å bruke det funksjonelle alternativet "Kontroller varer fra organisasjoner når du kansellerer kvitteringer."

Ved bokføring av dokumentet "Varesalg" det er nødvendig å organisere kontroll av rester. Hvis det ikke er nok produkt igjen, blir ikke dokumentet lagt ut, og det sendes en diagnosemelding. Dette er problemet som blir løst.

Vi jobber bevisst med et enkelt problem der avskrivningskostnaden ikke beregnes. Dette vil tillate oss å fokusere spesifikt på nyansene ved restkontroll.

Merk– Algoritmene som presenteres nedenfor er designet for trening og skal være så tydelige som mulig.
De kan optimaliseres, men da blir "forståelseskoeffisienten" lavere, så vi dveler ikke ved dette i denne artikkelen.

Naturligvis kan du optimalisere dem selv, eller ta kurset vårt om akselerasjon og optimalisering av 1C :)

Som du allerede har forstått, kan du løse problemet på to måter. La oss starte med en teknikk som har blitt brukt siden 1C:Enterprise 8.0.

Gammel metode for restkontroll

Prinsippet for den gamle restkontrollteknikken er som følger: Vi sjekker om det er gjenværende varer i ønsket mengde. Hvis det er det, avskriver vi det, hvis ikke rapporterer vi en feil..

Algoritmen i den gamle metoden består av flere blokker:

Forespørselen henter produktbalanser og dokumentdata
Syklusen overvåker tilstrekkeligheten av varer
Hvis det ikke er nok varer, blir ikke bilaget kontert
Hvis det er nok varer, utføres forbruksbevegelser

Slik ser programkoden ut:

// 1. Rydding av gamle registerbevegelser
Movements.FreeRemainders.Write = Sant;
Movements.Record();

// 3. Gjennomgå søkeresultater

// 4. Kontroll av tilstrekkeligheten av varer
Deficit = SampleProducts.Quantity - SampleProducts.Remaining;
Hvis underskudd>0 Da
Avslå = Sant;
Message.Text = "Produkt "+SelectionProducts.NomenclaturePresentation+" er ikke nok i antall "+Shortage+" stk.";
Message.Message();
slutt om;

// 5. Gå til begynnelsen av loopen hvis det var feil
Hvis feil da
Fortsette;
slutt om;

// 6. Utføre bevegelser inn i registre
Movement.Period = Dato;

EndCycle;

// 7. Sette flagget for registrering av bevegelser ved slutten av transaksjonen
Movements.FreeRemainders.Write = Sant;

Slutt på prosedyre

La oss kommentere nøkkelpunktene i algoritmen.

1. Rydding av gamle registerbevegelser

Nedenfor i algoritmen vil det være en forespørsel til resten av registeret.

Hvis det gjeldende dokumentet tidligere ble lagt ut, er det det sannsynlighet for å motta gamle dokumentbevegelser i en forespørsel– Dette er et alvorlig problem.

Når er en slik situasjon mulig? Når er dokumentdatoen beveger seg fremover.

La oss vise med et eksempel hva dette vil føre til:

Resterende bordlamper 10 stk.
Dokumentet datert 16.02.17 er under behandling, vi avskriver 6 lamper
Datoen i dokumentet endres til 02/17/17 (datoen kan flyttes frem med minst 1 sekund), la oss repostere dokumentet.

Hvis du ikke fjerner bevegelser, vil systemet rapportere en mangel på 2 stk. Hvorfor? Ja, fordi de gamle dokumentbevegelsene avskrev 6 av 10 eksisterende lamper. Deretter prøver systemet å avskrive 6 stykker til, men det er bare 4 igjen.

Problemet er løst i 3 linjer med kode:

Postsettet blir slettet (det kan ha blitt lest på skjemaet eller i tidligere behandlere)
Rekordsettet har "Skriv"-flagget satt
Alle sett som har "Record"-flagget er registrert.

Strengt tatt kan vi kontrollere oppryddingen av bevegelser når vi legger ut dokumenter:

Muligheten for å slette bevegelser ved avbrytelse av utførelsen anbefales - vi kontrollerer selv når det er nødvendig å faktisk slette bevegelser.

2. Mottak av dokumentdata og registersaldo etter forespørsel

Forespørselen består av to pakker:

I den første oppnås grupperte data fra tabelldelen - en midlertidig tabell opprettes
I den andre forespørselen legges restene fra registeret til dokumentdataene.

Hva du bør være oppmerksom på i denne forespørselen:

Når du oppretter en midlertidig tabell, indekseres feltet som sammenføyningen skal utføres på - dette gjøres for optimal ytelse
Øyeblikket for mottak av saldoer – tilsvarer posisjonen til dokumentet på tidsaksen
Det kan være at det ikke er noen rester i registeret - derfor utføres en venstre sammenføyning og "ECTNULL"-funksjonen brukes for "Quantity"-ressursen - NULL-verdien reduseres til null.

3. Omgå søkeresultater

Den utviklede forespørselen inneholder grupperte dokumentdata og saldo etter vareposter.

I en løkke går vi gjennom resultatet av denne forespørselen.

4. Sjekk for tilstrekkelig med varer

Vi bestemmer varemangelen.

Hvis underskuddet er større enn null, betyr det at det er mangel på varer:

Vi sender ut en diagnosemelding
Sett "Refusal"-parameteren for innleggingsbehandling til "True"

Hvis "Avslag" er lik "True", vil ikke resultatet av dokumentposteringstransaksjonen bli registrert. Enkelt sagt er dette en kommando til systemet om ikke å behandle dette dokumentet.

5. Gå til begynnelsen av syklusen hvis det var feil

Hvis det var feil ved dette eller tidligere trinn i syklusen (Feil = Sant), så er det ingen vits i å danne bevegelser. Likevel vil de ikke bli registrert i databasen.

6. Utføre bevegelser i registre

Hvis saldokontrollen var vellykket, oppretter vi utgiftsbevegelsen.

7. Sette bevegelsesregistreringsflagget på slutten av transaksjonen

Hvis dette flagget ikke er satt, vil bevegelser IKKE bli registrert.

På slutten av dokumentposteringstransaksjonen skrives bare de postsettene som har "Skriv"-flagget satt.

For å være rettferdig merker vi at å sette "Record"-egenskapen til et sett med poster er fornuftig under én betingelse - i dokumentegenskapen "Record movements during execution" må verdien "Record selected" spesifiseres:

Imidlertid er det "Record valgt"-verdien som er de facto-standarden:

Den brukes i standardløsninger
Angis som standard når du oppretter nye dokumenter.

En annen verdi av eiendommen - "Skriv modifisert" - er utdatert og forekommer praktisk talt aldri i moderne konfigurasjoner.

Ny metode for restkontroll

Den nye metoden bruker prinsippet: vi skriver av de nødvendige varene, og kontrollerer deretter om det er dannet negative saldoer for varene i dokumentet. Hvis ja, må du rulle tilbake dokumentet.

Som du kan se, er det en grunnleggende forskjell i øyeblikket for kontroll av balanser:

Den gamle metoden er å først sjekke saldoen, så avskrive den
Ny teknikk - først avskriver vi, så sjekker vi balansen.

Som et resultat vil programkoden se slik ut:

Behandlingsprosedyre (feil, modus)

// 2. Dannelse av bevegelser - registrer forbruk
Movements.FreeRemains.Clear();
SelectionProducts = Query Result.Select();
Mens SelectProducts.Next() Loop
Movement = Movements.Free Remainings.AddExpense();
Movement.Period = Dato;
Movement.Nomenclature = SelectionProducts.Nomenclature;
Movement.Quantity = SampleProducts.Quantity;
EndCycle;

// 3. Registrering av bevegelser i databasen
Movements.FreeRemainders.Write = Sant;
Movements.Record();

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

// 5. Vise meldinger om varemangel
Hvis ikke QueryResult.Empty() Da
Avslå = Sant;
ErrorSelect = QueryResult.Select();
Mens SelectErrors.Next() Loop
Message = New MessageToUser;
Message.Text = "Produktet "+SampleErrors.NomenclaturePresentation+" er ikke nok i antall "+SampleErrors.Deficiency+" stk.";
Message.Message();
EndCycle;
slutt om;

Slutt på prosedyre

La oss se på nøkkelpunktene i algoritmen.

1. Motta dokumentdata på forespørsel

Denne spørringen er nødvendig for å gruppere dataene i tabelldelen av dokumentet.

Merk at den første spørringen i partiet lager en midlertidig tabell - den vil bli brukt i neste spørring. Dette er mulig takket være den midlertidige tabellbehandleren som er opprettet for denne spørringen.

2. Dannelse av bevegelser - registrer forbruk

I syklusen skrives data fra dokumentet til registeret - det vil si at det utføres en ubetinget (uten verifisering) avskrivning av varer.

3. Registrering av bevegelser i databasen

For at saldoene i registeret skal endres, må bevegelser registreres.

4. Forespørsel som mottar negative rester fra registeret

Nå, med en enkel forespørsel, velger vi negative saldoer for dokumentvarer.

Det er her den midlertidige tabellen opprettet i det første trinnet brukes - en betingelse pålegges elementet (for dette oppretter vi ikke et nytt objekt av typen "Request", men bruker det som ble opprettet tidligere).

Vær oppmerksom på hvordan øyeblikket i tid overføres - datatypen "Boundary" brukes. Resterende saldoer må mottas på et tidspunkt umiddelbart ETTER gjeldende dokument.

Var det mulig å få saldo uten kant, for eksempel ved å legge til 1 sekund på dokumentdatoen?

Nei! Tross alt, på ett sekund kan det være et stort antall dokumenter. Derfor er det eneste riktige alternativet å bruke kanttypen "Inkludert".

5. Vise meldinger om varemangel

Hvis søkeresultatet ikke er tomt, er det negative rester - i dette tilfellet behandles ikke dokumentet og meldinger om alle feil vises.

Fordeler med restkontroll ved bruk av den nye metoden

Så begge algoritmene løser det samme problemet.

Forskjellen mellom algoritmene er synlige, men fordelene er ikke åpenbare.

Så la oss fremheve dem:

Du trenger ikke å fjerne gamle dokumentbevegelser. I hovedsak er dette operasjonen med å skrive et tomt sett med bevegelser til databasen og slette eksisterende bevegelser - dette er ganske ressurskrevende operasjoner
En spørring som henter data om negative saldoer, får bare tilgang til én tabell - det er ikke nødvendig å gjøre en venstresammenføyning med dokumentdataene og bruke "ISNULL()"-funksjonen

I tillegg, under det normale løpet av forretningsprosesser, angir brukeren en mengde som ikke overstiger saldoen på lageret.

I dette tilfellet vil den andre forespørselen ikke returnere noen data, og dokumentbehandlingen vil være så raskt som mulig.

Er disse millisekunderne virkelig så viktige?

På databaser med en liten mengde data og brukere vil forskjellen ikke være merkbar. Men i travle systemer med dusinvis av brukere er kostnaden for hvert millisekund høy.

I tillegg, under 1C:Platform Specialist-eksamenen, må du definitivt bruke en ny metode for å kontrollere balanser, hvis en spesifikk oppgave tillater det.

Ok, så du bør alltid bruke en ny teknikk, ikke sant?

Nei, det er ikke sant!

Den nye teknikken kan bare brukes hvis alle nødvendige data for å behandle dokumentet er i selve dokumentet.

Det vil si at for å innhente data trenger du ikke å ha tilgang til registrene som kontrollerer saldoene.

Så hvis for eksempel beløpet også ble tatt i betraktning i "Fri saldo"-registeret, ville den gamle kontrollmetoden måtte brukes.

Forresten, i standarden "1C: Trade Management 11" er balansekontroll implementert ved hjelp av den nye metoden, og i "1C: Accounting 8" - i henhold til den gamle metoden.

Men det er ikke alt!

Algoritmene presentert ovenfor kan kun brukes til pedagogiske formål. Poenget er at de ikke tar hensyn kontrollerte låser, som må brukes hvis det er mer enn én bruker på systemet.

Blokker for begge restkontrollmetodene er diskutert. Også i denne artikkelen løser vi et mer komplekst problem - i tillegg til å kontrollere saldoer, beregner vi kostnaden for avskrevne varer. Vi anbefaler at du studerer det nøye.

Og for det første, la oss bare si det å installere en lås i den nye metoden er veldig enkelt– og dette er en annen fordel med den nye metoden for restkontroll.

Resultater

La oss oppsummere kort.

Vi så på to restkontrollteknikker, som hver brukes i moderne typiske konfigurasjoner.

Hovedforskjellen mellom teknikkene i øyeblikket for kontroll av saldoene:

Gammel teknikk - kontroll før registrering av bevegelser i registre
Ny teknikk - kontroll etter registrering av bevegelser i registre

Generelt er den nye teknikken mer effektiv, men den er ikke alltid anvendelig.

Anvendbarhetskriterium– hvis det ikke er behov for å få tilgang til data fra et kontrollert register for å generere bevegelser, kan en ny teknikk brukes.

Hvis vi snakker om kontroll av produktbalanser, er bruk av en ny teknikk mulig når data om kostnads- og lagersaldoer lagres i forskjellige registre.

Og til slutt, eksempler fra typiske konfigurasjoner:

I UT 11 det er 2 hovedregistre for regnskapsføring av varer: Fri saldo (mengde) og varekostnad (kostnadsdata) - en ny metodikk brukes
I BP 3,0 data om kostnader og saldoer lagres i ett regnskapsregister - den gamle metoden for kontroll av saldoer brukes.

Enhver organisasjon må overvåke lagerbalanser. Og ofte oppstår det en situasjon når produktet faktisk er tilgjengelig, men det er ikke i programmet. Og så blir regnskapsføreren tvunget til å ta en avgjørelse:

la det selges;
utsette til det blir klart hvorfor denne situasjonen oppsto.

Beslutningen tas som regel ut fra den politikken som følges i organisasjonen i forhold til regnskapsføring av saldoer. Noen ganger kan du legge produktet til side og fortelle kjøperen at det ikke er mulig å selge det nå. Noen ganger er dette umulig å gjøre. For eksempel når kjøperen ser dette produktet eller allerede holder det i hendene.

Du kan selvfølgelig ganske enkelt generere et salgsdokument og ikke poste dokumentet, men ikke alle organisasjoner tillater dette. Derfor, i 1C 8.3-programmet (som i 8.2) er det mulig å deaktivere kontrollen av negative saldoer.

Hvis saldokontroll er aktivert, vil programmet gi følgende advarsel når du selger en vare som ikke er på lager (eller på den nødvendige kontoen):

«Antall»-kolonnen på linje 1 i «Produkter»-listen er feil utfylt.
Den angitte mengden overstiger saldoen. Gjenstående: 18; Mangler: 111.093

Få 267 videotimer på 1C gratis:

Deaktivere kontroll av negative saldoer i 1C 8.3

For å deaktivere eller aktivere balansekontroll i 1C, må du gå til "Hoved"-menyen, og deretter velge " " i delen "Innstillinger".

I noen versjoner av 1C Accounting er disse innstillingene plassert i menyen "Administrasjon - Dokumentposteringsinnstillinger".

I "Regnskapsparametere" må du gå til 1C "Beholdninger"-fanen og merke av for "Tillat avskrivning av varelager hvis det ikke er saldo i henhold til regnskapsdata":

Så er alt du trenger å gjøre å klikke på "Lagre og lukk"-knappen. Nå, ved avskrivning, vil ikke saldoene bli kontrollert.

Men en slik metode vil uunngåelig føre til utseendet til negative saldoer på lageret (som betyr i programmet). La oss se på hvordan vi skal håndtere dette.

Rapport "Kontroll av negative saldoer"

I det enkleste tilfellet trenger du bare å velge en periode og klikke på "Generer"-knappen. Og det var her den første overraskelsen ventet på meg.

Jeg simulerte spesifikt i testprogrammet en situasjon der jeg solgte flere varer enn jeg har på lager. Dessuten foretok han dette salget i 2013. Logisk sett har jeg fortsatt det samme produktet i minus nå, i 2016. Derfor rørte jeg ikke engang perioden, men klikket umiddelbart på «Generer». Det gikk ikke for meg. Det viser seg at rapporten kan vise informasjon om negative saldoer kun for den valgte perioden.

I videoopplæringene mine snakker jeg ofte om at 1C-databasen må forberedes for periodeavslutning og rapportering. Og et av de viktige punktene ved slik forberedelse er kontrollen av negative saldoer av varer, materialer og ferdige produkter. Hvilke rapporter bør du bruke for å sjekke statusen til lagerkontoer i 1C: Regnskap? La oss se på noen av dem.

1. Rapporter "Kontobalanse"

Mange regnskapsførere er vant til å jobbe med kontobalanser. Denne rapporten kan faktisk brukes til å kontrollere beholdningsbalanser, du trenger bare å sørge for at innstillingene er satt til å vise kvantitative indikatorer.
Klikk på "Vis innstillinger"-knappen og gå til fanen "Indikatorer".

Deretter går vi nøye gjennom rapporten og analyserer de oppdagede feilene

Balansen er praktisk fordi den lar deg evaluere ikke bare tilstedeværelsen av negative kvantitative saldoer, men også for å oppdage andre problematiske situasjoner:
- kvantitativ balanse av lagervarer uten beløp;
- total balanse uten mengde;
- negativ saldo.
Men hvis et stort antall vareposter er involvert i regnskapet, kan en slik sjekk være ganske arbeidskrevende. I tillegg vil SALT måtte genereres separat for hver regnskapskonto (10, 41, 43), noe som også kompliserer arbeidsprosessen noe.

2. Rapport "Kontroll av negative saldoer"

1C: Enterprise Accounting 8 utgave 3.0-konfigurasjonen gir en rapport som er ideell for å overvåke negative kvantitative saldoer for lagervarer. Rapporten finner du på fanen "Lager".

Vi angir periode, organisering og genererer en rapport.

Rapporten inkluderer kun de varepostene der det ble oppdaget en negativ kvantitativ saldo. Den store fordelen er at data på alle lagerkontoer blir analysert. Etter min mening er det mer praktisk å jobbe med rapporten enn med OSV.
Men det er også et minus - rapporten lar deg overvåke kun negative kvantitative saldoer, og etterlater andre problemer som SALT lar deg oppdage bak kulissene.

3. Rapport "Analyse av subconto"

Jeg har snakket om denne rapporten mer enn én gang. Subconto-analyse er en av mine favorittrapporter, som lar deg ikke bare oppdage feil, men også i mange situasjoner forstå årsakene deres.
Gå til delen "Rapporter" - "Subconto-analyse".

Velg underkontoen "Nomenklatur" og kontroller at visning av kvantitative indikatorer er aktivert i rapportinnstillingene.

Subconto-analyse er bra fordi den lar deg få informasjon om bevegelsen av varelager på tvers av alle regnskapskonti. For eksempel for å spore situasjoner der et produkt ankom én regnskapskonto, men ble solgt fra en annen.

Men med et stort antall elementer kan det være vanskelig å analysere dataene.
Jeg snakket mer om å jobbe med denne rapporten i videoopplæringen Hvordan jobbe med "Subconto Analysis"-rapporten i 1C - VIDEO.
Dermed har hver av de gjennomgåtte rapportene sine fordeler og ulemper. I mitt arbeid vil jeg anbefale å kombinere dem:
- finne grove feil ved å bruke rapporten "Kontroll av negative saldoer";
- så se SALT for alle inventarkontoer;
- for å identifisere årsakene til en feil saldo, bruk "Subconto Analysis"-rapporten.
Jeg diskuterte også interessante eksempler knyttet til å finne og rette feil ved regnskapsføring av varelager i to nyttige videoer:

Kontroll over lagersaldo er en obligatorisk regnskapsprosedyre for enhver bedrift som arbeider med varer. Ofte kan du støte på en situasjon der det ikke er noe produkt i programmet, men det faktisk er på lageret. I en slik situasjon er det to alternativer:

Send den for salg;
La den stå på lageret til omstendighetene i denne situasjonen er avklart.

Valget avhenger av flere faktorer, for eksempel organisasjonspolitikk eller den spesifikke situasjonen. Hvis produktet er på disken og kjøperen er interessert i det (holder det i hendene), er det ikke tilrådelig å nekte salget.

Noen virksomheter praktiserer å generere et salgsdokument uten å legge det ut, men ikke alle bruker denne praksisen. I slike situasjoner tilbyr 1C-programmet i sine nyeste versjoner muligheten til å deaktivere kontroll over negative saldoer.

Når kontroll er aktivert, vil salg av varer som ikke er på lager i henhold til programmet gi brukeren en advarsel: "Antall"-kolonnen i linje 1 i "Produkter"-listen er feil utfylt. "Den angitte mengden overstiger saldoen. Gjenstående: 18. Mangler 111.093.»

Deaktiverer kontroll av negative saldoer i 1C

Operasjonen med å slå på/av kontroll av saldoer i 1C utføres gjennom menyen "Hoved" - "Innstillinger" - "Regnskapsparametere" - "Beholdninger". Her må du merke av i boksen "Tillat avskrivning av beholdning hvis det ikke er beholdning i henhold til regnskapsdata."

Etter dette bekreftes handlingen med "Lagre og lukk"-knappen. I sin tur vil slike handlinger garantert bli grunnlaget for dannelsen av negative saldoer i regnskapet. De må elimineres.

Rapport "Kontroll av negative saldoer"

Denne rapporten genereres gjennom menyen "Lager" - "Rapporter", hvor dokumentet presenteres. Brukeren må bestemme forespørselsintervallet og klikke på "Generer"-knappen. Fraværet av en spesifisert periode vil ikke tillate deg å vise negative saldoer, som er en funksjon i systemet som krever obligatorisk fullføring av "Periode"-kolonnen.

Den ferdige rapporten har følgende utseende.

Et standardsett med filtre er tilgjengelig for selve rapporten, inkludert gruppering, sortering og andre datatransformasjoner i henhold til brukerens ønsker og behov. Ved å bruke "Vis innstillinger"-knappen kan du manuelt inkludere flere rader i rapporten.

Denne rapporten hjelper deg til enhver tid å få sammendrag eller detaljert informasjon om negative saldoer på 41 kontoer. Resultatet av rapporten vises med standarddetaljer (se fig. 1)

Fordi Siden rapporten er fullstendig skrevet ved hjelp av et dataoppsettskjema, vil det ikke være vanskelig for brukeren å endre rapportseksjoner fra brukermodus (se fig. 2)

Den eksterne rapporten er beregnet for konfigurasjonen "1C: Enterprise Accounting 8, utgave 3.0" og "utgave 3.0 (KORP)", kjører på plattformversjon 8.2 i "MANAGED APPLICATION"-modus.

Gratis støtteperiode: 1 måned.

Grunner til å kjøpe

Negative saldoer er alltid en hodepine for enhver regnskapsfører. Negative saldoer på 41 kontoer forverrer denne situasjonen dobbelt. Denne rapporten viser raskt og tydelig alt "rødhet" i 41 tellinger i en praktisk og visuell form. Dessuten lEventuell negativ saldo på 41 kontoer kan tydes ved hjelp av rapportene "Subconto Analysis" og "Account Card". Samtidig, ved å kombinere bruken av disse rapportene, er det mulig å gå rett ned på nivået av journaldokumentene som forårsaket vareflytting. For å gjøre dette klikker du bare på ønsket nummer i rapporten og velger rapporten for dekoding.

I følge en rekke forespørsler fra brukere ble det opprettet en egen versjon av rapporten "Kontroll av negative saldoer på lagerkontoer", som la til muligheten til å kontrollere negative saldoer, ikke bare for 41 kontoer, men også andre hovedkontoer for bevegelse av varelager varer:

Konto 07 Utstyr for montering
- Konto 08.04 Anskaffelse av anleggsmidler
- Konto 10 alle, unntatt 10.07 (materialer overført for behandling til tredjeparter)
- Konto 21 Halvfabrikat av egen produksjon
- Konto 41 alle, unntatt 41.12 (Varer i detaljhandel (i NTT til salgsverdi))
- Konto 42.01 Handelsmargin i automatiserte utsalgssteder
- Konto 43 Ferdige produkter

Husk også at negative saldoer ikke bare kan oppstå på lagerkontoer, men også på tolldeklarasjonskontoen. Hvis du også trenger å kontrollere denne kontoen, anbefaler vi at du gjør deg kjent med den eksterne rapporten

Fordeler

Tilkobling gjennom mekanismen for ekstern behandling og rapportering. Dette lar deg bruke rapporten uten å gjøre noen endringer i standardkonfigurasjonen. Det er også mulig å åpne en standardrapport via "Fil" -> "Åpne".
Mulighet for å tilpasse rapporten "for deg selv" fra brukermodus.

Pengene tilbake-garanti

Infostart LLC garanterer deg 100 % refusjon dersom programmet ikke samsvarer med den deklarerte funksjonaliteten fra beskrivelsen. Pengene kan returneres i sin helhet dersom du ber om dette innen 14 dager fra datoen pengene er mottatt på vår konto.

Programmet er så bevist å fungere at vi kan gi en slik garanti med full tillit. Vi ønsker at alle våre kunder skal være fornøyde med kjøpet.