Računovodstvene informacije. Računovodstveni podaci BP 3.0 kontrola negativnih stanja

Ovaj članak je namijenjen implementatorima 1C - a posebno onima koji se pripremaju za 1C sertifikaciju: stručnjak za platforme.

Danas ćemo pogledati 2 metode za kontrolu stanja - ne samo stanja u skladištu, već i, na primjer, međusobna obračuna („Koliki je trenutni dug klijenta i da li mu je moguće poslati robu?“)

Obje metode se koriste u standardnim konfiguracijama i u zadacima certifikacije. A pošto ih ima dvoje - morate jasno razumjeti kada je primjenjiva “nova” tehnika, a kada samo “stara”..

Ovo je osnovno znanje za 1C programere; preporučujemo da ne ostavljate praznine u takvim područjima. Trebalo bi da te odvede na učenje 15 minuta :)

Formulacija problema

Uzmimo jednostavnu konfiguraciju s dokumentima "Prijem robe" i "Prodaja robe":

Za obračun stanja koristi se registar akumulacije „Slobodna stanja“:

Prilikom knjiženja dokumenta „Prijem robe“ vrše se sljedeća kretanja:

ProcessingProcedure(Failure, Mode)

Za svaki ciklus proizvoda TechStringProducts From Products
Pokret = Pokreti.FreeRemains.Add();
Movement.MovementType = AccumulationMovementType.Incoming;
Pokret.Period = Datum;
Movement.Nomenclature = TechStringProducts.Nomenclature;
Movement.Quantity = TechStringProducts.Quantity;
EndCycle;

Kraj procedure

Obrada knjiženja dokumenta „Prijem robe“ izvršena je pomoću dizajnera kretanja i nije od interesa, jer kada stigne u skladište nije potrebna kontrola stanja.

Ponekad se kontrola stanja provodi i za dokument „Prijem robe” - tako da se prilikom poništenja ili ponovnog knjiženja dokumenta ne formira negativno stanje.

Na primjer, u skladište je stiglo 10 novih LG televizora, od kojih je 6 prodato. Ako dokument o prijemu sadrži 10 komada. popraviti za 5 kom. – formira se negativan saldo “minus 1 komad”.

U standardu UT 11 takva kontrola je omogućena pomoću funkcionalne opcije „Kontrola robe organizacija prilikom poništenja računa“.

Prilikom knjiženja dokumenta “Prodaja robe” potrebno je organizovati kontrolu rezidua. Ako nema dovoljno proizvoda, dokument se ne knjiži i izdaje se dijagnostička poruka. Ovo je problem koji se rješava.

Namjerno radimo na jednostavnom problemu gdje se ne obračunava trošak otpisa. To će nam omogućiti da se posebno fokusiramo na nijanse kontrole rezidua.

Bilješka– algoritmi predstavljeni u nastavku su dizajnirani za obuku i trebaju biti što jasniji.
Mogu se optimizirati, ali će tada „koeficijent razumijevanja“ biti manji, tako da se o tome nećemo zadržavati u ovom članku.

Naravno, možete ih sami optimizirati ili pohađati naš kurs o ubrzanju i optimizaciji 1C :)

Kao što ste već shvatili, rješavanje problema može se obaviti na dva načina. Počnimo s tehnikom koja se koristi još od dana 1C:Enterprise 8.0.

Stara metoda kontrole rezidua

Princip stare tehnike kontrole ostataka je sljedeći: Provjeravamo da li ima preostale robe u traženoj količini. Ako postoji, otpisujemo, ako nema, prijavljujemo grešku..

Algoritam u staroj metodi sastoji se od nekoliko blokova:

Zahtjev dohvaća stanja proizvoda i podatke o dokumentima
Ciklus prati dovoljnost robe
Ako nema dovoljno robe, onda se dokument ne knjiži
Ako ima dovoljno robe, vrše se kretanja potrošnje

Ovako izgleda programski kod:

// 1. Brisanje pokreta starog registra
Movements.FreeRemainders.Write = Tačno;
Movements.Record();

// 3. Prelazak rezultata upita

// 4. Provjera dovoljnosti robe
Deficit = SampleProducts.Quantity - SampleProducts.Remaining;
Ako je deficit>0 onda
Odbiti = Tačno;
Message.Text = "Proizvod "+SelectionProducts.NomenclaturePresentation+" nije dovoljan u količini "+Shortage+" kom.";
Message.Message();
endIf;

// 5. Idite na početak petlje ako je bilo grešaka
Ako neuspjeh onda
Nastavi;
endIf;

// 6. Izvođenje kretanja u registre
Pokret.Period = Datum;

EndCycle;

// 7. Postavljanje zastavice za snimanje kretanja na kraju transakcije
Movements.FreeRemainders.Write = Tačno;

Kraj procedure

Hajde da prokomentarišemo ključne tačke algoritma.

1. Brisanje kretanja starih registara

Ispod u algoritmu će biti zahtjev za ostatak registra.

Ako je trenutni dokument prethodno objavljen, onda postoji vjerovatnoća primanja starih kretanja dokumenata u zahtjevu– ovo je ozbiljan problem.

Kada je takva situacija moguća? Kada je datum dokumenta kreće napred.

Pokažimo na primjeru do čega će to dovesti:

Ostatak stolnih lampi 10 kom.
Dokument od 16.02.17. je u obradi, otpisujemo 6 lampi
Datum u dokumentu je promijenjen u 02/17/17 (datum se može pomjeriti barem 1 sekundu unaprijed), hajde da ponovo objavimo dokument.

Ako ne očistite pokrete, sistem će prijaviti manjak od 2 komada. Zašto? Da, jer su stari dokumenti kretanja otpisali 6 od 10 postojećih lampi. Zatim sistem pokušava otpisati još 6 komada, ali su ostala samo 4.

Problem je riješen u 3 linije koda:

Skup zapisa se briše (možda je pročitan na obrascu ili u prethodnim rukovaocima)
Set zapisa ima postavljenu zastavicu “Write”.
Svi setovi koji imaju postavljenu zastavicu “Record” se snimaju.

Strogo govoreći, možemo kontrolirati čišćenje kretanja prilikom postavljanja dokumenata:

Opcija brisanja pokreta prilikom otkazivanja izvršenja je preporučljiva - sami kontrolišemo kada je potrebno stvarno obrisati pokrete.

2. Prijem podataka o dokumentima i evidenciji stanja na zahtjev

Zahtjev se sastoji od dva paketa:

U prvom se dobijaju grupirani podaci iz tabelarnog dela - kreira se privremena tabela
U drugom zahtjevu uz podatke o dokumentu prilažu se i ostaci iz registra.

Na šta treba obratiti pažnju u ovom zahtjevu:

Prilikom kreiranja privremene tabele, polje na kojem će se izvršiti spajanje se indeksira - to se radi za optimalne performanse
Trenutak prijema stanja – odgovara poziciji dokumenta na vremenskoj osi
U registru možda neće biti ostataka - stoga se vrši lijevo spajanje i funkcija "ECTNULL" se koristi za resurs "Količina" - NULL vrijednost se smanjuje na nulu.

3. Zaobilaženje rezultata upita

Izrađeni zahtjev sadrži grupisane podatke dokumenta i stanja po stavkama.

U petlji prolazimo kroz rezultat ovog zahtjeva.

4. Provjerite dovoljnost robe

Mi utvrđujemo nestašicu robe.

Ako je deficit veći od nule, to znači da postoji manjak robe:

Izdajemo dijagnostičku poruku
Postavite parametar "Odbijanje" za obradu objavljivanja na "Tačno"

Ako je “Odbijanje” jednako “Tačno”, rezultat transakcije knjiženja dokumenta neće biti zabilježen. Jednostavno rečeno, ovo je naredba sistemu da ne obrađuje ovaj dokument.

5. Idite na početak ciklusa ako je bilo grešaka

Ako je bilo grešaka u ovom ili prethodnim koracima ciklusa (Failure = True), onda nema smisla formirati pokrete. Svejedno, oni neće biti evidentirani u bazi podataka.

6. Izvođenje kretanja u registrima

Ako je provjera stanja bila uspješna, kreiramo kretanje troškova.

7. Postavljanje oznake za snimanje pokreta na kraju transakcije

Ako ova zastavica nije postavljena, pokreti se NEĆE snimati.

Na kraju transakcije knjiženja dokumenta, upisuju se samo oni skupovi zapisa koji imaju postavljenu zastavicu “Write”.

Da bismo bili pošteni, napominjemo da postavljanje svojstva “Record” skupa zapisa ima smisla pod jednim uslovom - u svojstvu dokumenta “Snimanje kretanja tokom izvršavanja” mora biti navedena vrijednost “Spis odabran”:

Međutim, vrijednost "Odabrani zapis" je de facto standard:

Koristi se u standardnim rješenjima
Postavite prema zadanim postavkama prilikom kreiranja novih dokumenata.

Druga vrijednost svojstva – “Write modified” – je zastarjela i praktički se nikada ne pojavljuje u modernim konfiguracijama.

Nova metoda za kontrolu rezidua

Nova metoda koristi princip: otpisujemo potrebnu robu, zatim provjeravamo da li su za robu dokumenta formirana negativna stanja. Ako jeste, onda morate vratiti dokument.

Kao što vidite, postoji fundamentalna razlika u trenutku kontrole bilansa:

Stara metoda je prvo provjeriti stanje, a zatim ga otpisati
Nova tehnika - prvo otpisujemo, pa provjeravamo stanje.

Kao rezultat, programski kod će izgledati ovako:

ProcessingProcedure(Failure, Mode)

// 2. Formiranje kretanja - registar potrošnje
Movements.FreeRemains.Clear();
SelectionProducts = Query Result.Select();
Dok SelectProducts.Next() petlja
Kretanje = Pokreti.Free Remainings.AddExpense();
Pokret.Period = Datum;
Movement.Nomenclature = SelectionProducts.Nomenclature;
Movement.Quantity = SampleProducts.Quantity;
EndCycle;

// 3. Snimanje kretanja u bazi podataka
Movements.FreeRemainders.Write = Tačno;
Movements.Record();

Kontrolna granica = Nova granica(TimePoint(), BorderView.Including);
Request.SetParameter("TimePoint", Kontrolna granica);
RequestResult = Request.Execute();

// 5. Prikaz poruka o nestašici robe
Ako nije QueryResult.Empty() Onda
Odbiti = Tačno;
ErrorSelect = QueryResult.Select();
Dok SelectErrors.Next() petlja
Poruka = New MessageToUser;
Message.Text = "Proizvod "+SampleErrors.NomenclaturePresentation+" nije dovoljan u količini "+SampleErrors.Deficiency+" kom.";
Message.Message();
EndCycle;
endIf;

Kraj procedure

Pogledajmo ključne tačke algoritma.

1. Prijem podataka dokumenta na zahtjev

Ovaj upit je potreban za grupisanje podataka u tabelarnom dijelu dokumenta.

Imajte na umu da prvi upit u grupi kreira privremenu tabelu - ona će se koristiti u sljedećem upitu. To je moguće zahvaljujući privremenom upravitelju tablica koji je kreiran za ovaj upit.

2. Formiranje kretanja - registar potrošnje

U ciklusu se podaci iz dokumenta upisuju u registar - odnosno vrši se bezuslovni (bez provjere) otpis robe.

3. Snimanje kretanja u bazi podataka

Da bi se stanje u registru promijenilo potrebno je evidentirati kretanje.

4. Upit prima negativne ostatke iz registra

Sada, jednostavnim zahtjevom, odabiremo negativna stanja za dokumentnu robu.

Tu se koristi privremena tabela kreirana u prvom koraku - na stavku se nameće uslov (za to ne kreiramo novi objekat tipa „Zahtjev“, već koristimo onaj ranije kreiran).

Obratite pažnju na to kako se prenosi trenutak u vremenu - koristi se tip podataka “Boundary”. Preostala sredstva se moraju primiti u trenutku, odmah NAKON trenutnog dokumenta.

Da li je bilo moguće dobiti stanje bez okvira, na primjer, dodavanjem 1 sekunde datumu dokumenta?

Ne! Uostalom, u jednoj sekundi može biti veliki broj dokumenata. Stoga je jedina ispravna opcija korištenje tipa okvira „Uključujući“.

5. Prikaz poruka o nestašici robe

Ako rezultat upita nije prazan, tada ima negativnih ostataka - u ovom slučaju dokument se ne obrađuje i prikazuju se poruke o svim greškama.

Prednosti kontrole rezidua upotrebom nove metode

Dakle, oba algoritma rješavaju isti problem.

Razlika između algoritama je vidljiva, ali prednosti nisu očigledne.

Pa da ih istaknemo:

Nema potrebe za brisanjem starih kretanja dokumenata. U suštini, ovo je operacija pisanja praznog skupa pokreta u bazu podataka i brisanja postojećih pokreta - to su operacije koje zahtijevaju dosta resursa
Upit koji dohvaća podatke o negativnim saldama pristupa samo jednoj tabeli - nema potrebe za spajanjem lijevo s podacima dokumenta i korištenjem funkcije “ISNULL()”.

Osim toga, tokom normalnog odvijanja poslovnih procesa korisnik naznači količinu koja ne prelazi stanje u skladištu.

U tom slučaju, drugi zahtjev neće vratiti nikakve podatke i obrada dokumenta će biti što je brže moguće.

Da li su ove milisekunde zaista toliko važne?

Na bazama podataka sa malom količinom podataka i korisnika razlika neće biti primjetna. Ali u zauzetim sistemima sa desetinama korisnika, cijena svake milisekunde je visoka.

Osim toga, tokom ispita 1C:Platform Specialist, svakako morate koristiti novu metodu kontrole stanja, ako to dozvoljava određeni zadatak.

Ok, znači uvijek treba koristiti novu tehniku, zar ne?

Ne, to nije istina!

Nova tehnika se može koristiti samo ako se svi potrebni podaci za obradu dokumenta nalaze u samom dokumentu.

Odnosno, da biste dobili podatke, ne morate pristupiti registrima koji kontrolišu stanja.

Tako, na primjer, ako je iznos uzet u obzir i u registru „Slobodna stanja“, tada bi se morao koristiti stari način kontrole.

Inače, u standardu "1C: Upravljanje trgovinom 11" kontrola bilansa implementirana je novom metodom, au "1C: Računovodstvo 8" - po staroj metodi.

Ali to nije sve!

Gore navedeni algoritmi mogu se koristiti samo u obrazovne svrhe. Poenta je da oni ne uzimaju u obzir kontrolisane brave, koji se mora koristiti ako postoji više od jednog korisnika na sistemu.

Razmatraju se blokovi za obje metode kontrole ostataka. Također u ovom članku rješavamo složeniji problem - osim kontrole stanja, obračunavamo i troškove otpisanih stavki. Preporučujemo da ga pažljivo proučite.

I za početak, recimo to ugradnja brave na novu metodu je vrlo jednostavna– i to je još jedna prednost nove metode kontrole rezidua.

Rezultati

Hajde da ukratko sumiramo.

Pogledali smo dvije tehnike kontrole ostataka, od kojih se svaka koristi u modernim tipičnim konfiguracijama.

Ključna razlika između tehnika u trenutku kontrole stanja:

Stara tehnika - kontrola prije upisivanja kretanja u registre
Nova tehnika - kontrola nakon evidentiranja kretanja u registrima

Općenito, nova tehnika je efikasnija, ali nije uvijek primjenjiva.

Kriterijum primenljivosti– ako nema potrebe za pristupom podacima iz kontroliranog registra za generiranje kretanja, može se koristiti nova tehnika.

Ako govorimo o kontroli stanja proizvoda, onda je moguća upotreba nove tehnike kada se podaci o troškovima i stanju skladišta pohranjuju u različite registre.

I na kraju, primjeri iz tipične konfiguracije:

IN UT 11 postoje 2 glavna registra za računovodstvo stavki: Slobodna stanja (količina) i Troškovi robe (podaci o troškovima) - koristi se nova metodologija
IN BP 3.0 podaci o troškovima i bilansima se pohranjuju u jedan računovodstveni registar - koristi se stari način kontrole stanja.

Svaka organizacija mora pratiti stanje zaliha. I često se javlja situacija kada je proizvod zaista dostupan, ali nije u programu. I tada je računovođa prisiljen donijeti odluku:

dozvoliti da se proda;
odgoditi dok ne postane jasno zašto je došlo do ove situacije.

Odluka se, po pravilu, donosi na osnovu politike koja se vodi u organizaciji u pogledu računovodstva stanja. Ponekad možete ostaviti proizvod na stranu i reći kupcu da ga sada nije moguće prodati. Ponekad je to nemoguće učiniti. Na primjer, kada kupac vidi ovaj proizvod ili ga već drži u rukama.

Možete, naravno, jednostavno generirati prodajni dokument i ne objaviti dokument, ali to ne dozvoljavaju sve organizacije. Stoga je u programu 1C 8.3 (kao u 8.2) moguće onemogućiti kontrolu negativnih stanja.

Ako je omogućena kontrola stanja, tada će pri prodaji artikla koji nije na zalihama (ili na potrebnom računu) program izdati sljedeće upozorenje:

Kolona “Količina” u redu 1 liste “Proizvodi” je pogrešno popunjena.
Navedena količina premašuje stanje. Preostalo: 18; Nestalo: 111.093

Nabavite 267 video lekcija na 1C besplatno:

Onemogućavanje kontrole negativnih stanja u 1C 8.3

Da biste onemogućili ili omogućili kontrolu ravnoteže u 1C, trebate otići na izbornik "Glavni", a zatim u odjeljku "Postavke" odabrati " ".

U nekim verzijama 1C računovodstva, ove postavke se nalaze u izborniku "Administracija - postavke knjiženja dokumenata".

U "Računovodstvenim parametrima" trebate otići na karticu 1C "Zalihe" i označiti potvrdni okvir "Dozvoli otpis zaliha ako nema stanja prema računovodstvenim podacima":

Zatim sve što treba da uradite je da kliknete na dugme „Sačuvaj i zatvori“. Sada, prilikom otpisa, bilansi se neće kontrolisati.

Ali takav način će neminovno dovesti do pojave negativnih stanja u skladištu (znači, u programu). Pogledajmo kako se nositi s ovim.

Izvještaj “Kontrola negativnih stanja”

U najjednostavnijem slučaju, samo trebate odabrati period i kliknuti na dugme „Generiraj“. I tu me je čekalo prvo iznenađenje.

Posebno sam u testnom programu simulirao situaciju u kojoj sam prodao više robe nego što imam na zalihama. Štaviše, ovu prodaju je obavio 2013. godine. Logično, isti proizvod imam i sada u minusu, 2016. Stoga nisam ni dodirnuo tačku, već sam odmah kliknuo na “Generiraj”. Nije mi išlo. Ispostavilo se da izvještaj može prikazati informacije o negativnim bilansima samo za odabrani period.

U svojim video tutorijalima često govorim o tome da baza podataka 1C mora biti pripremljena za zatvaranje perioda i izvještavanje. A jedna od bitnih tačaka takve pripreme je kontrola negativnih stanja robe, materijala i gotovih proizvoda. Koje izvještaje trebate koristiti za provjeru statusa računa zaliha u 1C: Računovodstvu? Pogledajmo neke od njih.

1. Izvještaj “Bilans računa”

Mnogi računovođe su navikli da rade sa bilansima računa. Ovaj izvještaj se zaista može koristiti za kontrolu stanja zaliha, samo trebate biti sigurni da su postavke podešene za prikaz kvantitativnih pokazatelja.
Kliknite na dugme "Prikaži postavke" i idite na karticu "Indikatori".

Zatim pažljivo pregledamo izvještaj i analiziramo otkrivene greške

Bilans stanja je zgodan jer vam omogućava da procijenite ne samo prisustvo negativnih kvantitativnih bilansa, već i da otkrijete druge problematične situacije:
- kvantitativno stanje zaliha bez iznosa;
- ukupan saldo bez količine;
- negativan saldo.
Međutim, ako je u računovodstvu uključen veliki broj stavki, tada takva provjera može biti prilično radno intenzivna. Osim toga, SALT će se morati generirati posebno za svaki računski račun (10, 41, 43), što također donekle otežava proces rada.

2. Izvještaj "Kontrola negativnih stanja"

Konfiguracija 1C: Enterprise Accounting 8 izdanje 3.0 pruža izvještaj koji je idealan za praćenje negativnih kvantitativnih stanja zaliha. Izvještaj se nalazi na kartici “Skladište”.

Navodimo period, organizaciju i pravimo izvještaj.

Izvještaj uključuje samo one stavke za koje je utvrđeno negativno kvantitativno stanje. Velika prednost je što se analiziraju podaci o svim računima zaliha. Po mom mišljenju, zgodnije je raditi sa izveštajem nego sa OSV-om.
Ali postoji i minus - izvještaj vam omogućava da pratite samo negativne kvantitativne bilance, ostavljajući iza kulisa druge probleme koje SALT omogućava da otkrijete.

3. Izvještaj “Analiza podkonto”

O ovom izvještaju sam govorio više puta. Subconto analiza je jedan od mojih omiljenih izvještaja, koji vam omogućava ne samo da otkrijete greške, već i, u mnogim situacijama, da shvatite njihove uzroke.
Idite na odjeljak “Izvještaji” - “Subkonto analiza”.

Odaberite podkonto „Nomenklatura“ i provjerite da li je u postavkama izvještaja omogućen prikaz kvantitativnih indikatora.

Subconto analiza je dobra jer vam omogućava da dobijete informacije o kretanju stavki zaliha na svim računovodstvenim računima. Na primjer, za praćenje situacija u kojima je proizvod stigao na jedan računovodstveni račun, ali je prodan s drugog.

Međutim, sa velikim brojem stavki, može biti teško analizirati podatke.
Više o radu sa ovim izvještajem govorio sam u video tutorijalu Kako raditi sa izvještajem „Subconto Analysis“ u 1C - VIDEO.
Dakle, svaki od pregledanih izvještaja ima svoje prednosti i nedostatke. U svom radu bih preporučio njihovo kombinovanje:
- pronaći grube greške koristeći izvještaj „Kontrola negativnih bilansa“;
- zatim pogledajte SALT za sve račune zaliha;
- da biste identifikovali razloge za netačan bilans, koristite izveštaj „Subconto Analysis“.
Također sam raspravljao o zanimljivim primjerima vezanim za pronalaženje i ispravljanje grešaka prilikom obračuna stavki inventara u dva korisna videa:

Kontrola stanja u skladištu je obavezan računovodstveni postupak u svakom preduzeću koje radi sa robom. Često se možete susresti sa situacijom da u programu nema proizvoda, a on se zapravo nalazi u skladištu. U takvoj situaciji postoje dvije opcije:

Pošaljite ga na prodaju;
Ostavite u skladištu dok se ne razjasne okolnosti ove situacije.

Izbor zavisi od nekoliko faktora, kao što su organizaciona politika ili specifična situacija. Ukoliko se proizvod nalazi na tezgi i kupac je za njega zainteresovan (drži ga u rukama), nije preporučljivo odbiti prodaju.

Neka preduzeća praktikuju generisanje prodajnog dokumenta bez knjiženja, ali ne koriste sva ovu praksu. U slučaju ovakvih situacija, program 1C u svojim najnovijim verzijama nudi mogućnost onemogućavanja kontrole negativnih stanja.

Kada je kontrola aktivirana, prodaja robe koja nije na zalihama prema programu će korisniku dati upozorenje: „Kolona „Količina“ u redu 1 liste „Proizvodi“ je pogrešno popunjena. “Naznačena količina premašuje stanje. Preostalo: 18. Nedostaje 111.093.”

Onemogućavanje kontrole negativnih stanja u 1C

Operacija uključivanja/isključivanja kontrole stanja u 1C vrši se kroz meni “Glavno” - “Postavke” - “Računovodstveni parametri” - “Zalihe”. Ovdje morate označiti kvadratić „Dozvoliti otpis zaliha ako nema zaliha prema računovodstvenim podacima“.

Nakon toga, akcija se potvrđuje tipkom „Sačuvaj i zatvori“. Zauzvrat, takve radnje zajamčeno će postati osnova za formiranje negativnih bilansa u računovodstvu. Trebaće ih eliminisati.

Izvještaj “Kontrola negativnih stanja”

Ovaj izvještaj se generiše preko menija “Skladište” - “Izvještaji”, gdje se dokument prikazuje. Od korisnika se traži da odredi interval zahtjeva i klikne na dugme “Generiraj”. Odsustvo određenog perioda neće vam omogućiti da prikažete negativna stanja, što je karakteristika sistema koja zahtijeva obavezno popunjavanje kolone „Period“.

Gotov izvještaj ima sljedeći izgled.

Za sam izvještaj dostupan je standardni set filtera, uključujući grupisanje, sortiranje i druge transformacije podataka u skladu sa zahtjevima i potrebama korisnika. Pomoću dugmeta “Prikaži postavke” možete ručno uključiti dodatne redove u izvještaj.

Ovaj izvještaj pomaže da se u svakom trenutku dobiju sažeti ili detaljni podaci o negativnim saldama na 41 računu. Rezultat izvještaja se prikazuje sa zadanim detaljima (vidi sliku 1)

Jer Budući da je izvještaj u potpunosti napisan pomoću šeme rasporeda podataka, korisniku neće biti teško promijeniti dijelove izvještaja iz korisničkog načina (vidi sliku 2)

Eksterni izvještaj je namijenjen za konfiguraciju "1C: Enterprise Accounting 8, izdanje 3.0" i "izdanje 3.0 (KORP)", koji radi na verziji platforme 8.2 u režimu „UPRAVLJENA APLIKACIJA“.

Besplatni period podrške: 1 mjesec.

Razlozi za kupovinu

Negativni bilansi su uvijek glavobolja za svakog računovođu. Negativna stanja na 41 računu dvostruko pogoršavaju ovu situaciju. Ovaj izvještaj brzo i jasno pokazuje sve "crvenilo" u 41 broj u zgodnom i vizuelnom obliku. Štaviše, lSvako negativno stanje na 41 računu može se dešifrirati korištenjem izvještaja „Subconto Analysis“ i „Kartica računa“. Istovremeno, kombinovanjem korišćenja ovih izveštaja, moguće je spustiti se direktno na nivo evidencijskih dokumenata koji su prouzrokovali kretanje robe. Da biste to učinili, samo kliknite na traženi broj u izvještaju i odaberite izvještaj za dekodiranje.

Prema brojnim zahtjevima korisnika, kreirana je posebna verzija izvještaja „Kontrola negativnih stanja na računima zaliha“ u kojoj je dodata mogućnost kontrole negativnih stanja, ne samo za 41 račun, već i druge glavne račune za kretanje zaliha. stavke:

Račun 07 Oprema za ugradnju
- Konto 08.04 Nabavka osnovnih sredstava
- Račun 10 svi, osim 10.07 (Materijali prebačeni na obradu trećim licima)
- Konto 21 Poluproizvodi sopstvene proizvodnje
- Račun 41 sve osim 41.12 (Roba u trgovini na malo (u NTT po prodajnoj vrijednosti))
- Konto 42.01 Trgovačka marža u automatizovanim maloprodajnim objektima
- Konto 43 Gotovi proizvodi

Takođe, zapamtite da negativna stanja mogu nastati ne samo na računima zaliha, već i na računu carinske deklaracije. Ako trebate kontrolirati i ovaj račun, preporučujemo da se upoznate sa vanjskim izvještajem

Prednosti

Povezivanje putem mehanizma eksterne obrade i izvještavanja. Ovo vam omogućava da koristite izvještaj bez ikakvih promjena u standardnoj konfiguraciji. Također je moguće otvoriti standardni izvještaj preko “File” -> “Open”.
Mogućnost prilagođavanja izvještaja „za sebe“ iz korisničkog moda.

Garancija povrata novca

Infostart LLC Vam garantuje 100% povrat novca ukoliko program ne odgovara deklariranoj funkcionalnosti iz opisa. Novac se može vratiti u cijelosti ako to zatražite u roku od 14 dana od dana prijema novca na naš račun.

Program je toliko dokazano funkcionira da možemo dati takvu garanciju s potpunim povjerenjem. Želimo da svi naši kupci budu zadovoljni kupovinom.