U konfiguraciji za 1C: "Upravljanje trgovinom" u izdanju 11, umjesto uobičajenog batch računovodstva, pojavio se takozvani RAUZ, ili, tačnije, u smislu UT: vođenje evidencije nabavne vrijednosti robe po vrsti zaliha.

Za početak, vrijedi reći šta je to ROUSE i odakle je došao.

RAUZ - napredna analitika troškovnog računovodstva. Ovaj mehanizam se prvi put pojavio u SCP i integrisanim konfiguracijama 2008. godine. Predviđeno je pohranjivanje informacija o robi (proizvodima) i troškovima u jednom registru (ili bolje rečeno, u tri umjesto 32 za UPP - preuzeto odavde) i to ne u kontekstu serija, već u kontekstu računovodstvenog analitičara, koji ubrzava do obračuna i utvrđivanja ukupne cijene robe (gotovih proizvoda). Ova kalkulacija se ne dešava u trenutku prodaje (otpisa) robe (proizvoda), već kao posebna obrada (dokument) samo da bi se uzeli u obzir svi troškovi i ubrzao ovaj proces.

U konfiguraciji UT11 ovaj termin (RAUZ) se ne koristi, jer kao takvo nije predviđeno „računovodstvo troškova“ (tačnije, obezbeđeno je, ali ne u istim količinama i u tom smislu), ali osnova ostaje:

1. Broj registara je smanjen u odnosu na UT10.3

Bilo 18: Troškovi, PDVLots of Goods, PDV Presented, VATPresentedRealization0, PDVacrued, = PDV neizravni izdaci, PDVSales0, Lots of GoodsInWarehouses, LotsofGoodsTransferred, Sales, SalesOnDiscountCards, SalesCost, GoodsVRetailsIn Goods sInSkladišta, Robne Organizacije.

Sada 4: prihod i trošak prodaje, slobodni ostaci, trošak robe, roba u skladištima;

2. Cena koštanja se obračunava ne u trenutku otpisa robe, već u posebnom dokumentu, regulatornom zadatku;

Sve je to, naravno, dobro, ali vrijedi reći da je za Integrated ili SCP, gdje se koriste različiti troškovi, proizvodnja i složene kalkulacije troškova, RAUZ neosporna prednost, ali za Trade Management, gdje je u principu sve prilično jednostavno - kupljeno, prodano, vođeno računovodstvo po vrsti zaliha postaje priličan problem. Kada menadžeri ne mogu pratiti bruto dobit prodatih proizvoda u realnom vremenu, to nije baš dobro, pogotovo jer je vrijedno reći da je u UT10.3, da bi se ubrzao proces obrade dokumenata, bila moguća obrada dokumenata po serijama u realnom vremenu, ali odvojenom obradom!

komentar: Omogućite mogućnost korištenja grupnog obračuna samo u UPP-u. U postavkama Integriranog računovodstva postoji i opcija obračuna robe, po partijama, ALI cijena koštanja u ovom slučaju se uopće neće formirati. Ne postoji takva opcija u UT11.

Pređimo na postavljanje računovodstva u UT11.

Možete omogućiti zasebno računovodstvo u podsistemu Administracija na kartici Financije.

Ako je " Po odjelu ili menadžeru“, za svaki odsjek (Referentne informacije o propisima – Struktura poduzeća), potrebno je navesti koja će se točno evidencija voditi za ovaj odjel.

Bitan: Ovo su vrlo interesantni parametri, ako ih postavite od strane menadžera odjela, onda će samo menadžer koji ih je kupio moći prodati proizvod; ako ga postavite po odjelima, onda možete prodati robu samo iz odjela za koji je kupljena (ne postoji standardni mehanizam za kretanje robe između odjeljenja).

potpiši " Po finansijskim računovodstvenim grupama" vam omogućava da navedete dodatnu analitiku za finansijsko računovodstvo obračuna sa dobavljačima u dokumentima prijema, tada ćete također morati navesti ovu analitiku u prodajnim dokumentima.

osobina" Dogovoreno“, omogućava označavanje transakcija prilikom prijema robe i njene prodaje.

Najpotrebniji i neobavezujući znak je " Od strane dobavljača“, partner (dobavljač) je naveden u dokumentu prijema, a utvrđuje se automatski pri prodaji.

Bitan: dopuna vrsta inventara u dokumentu se dešava samo u trenutku knjiženja ako:

• dokument nije izvršen;
• ključni detalji u zaglavlju ili u PM-u su promijenjeni;

Takođe, vrste evidencije se automatski ponovo popunjavaju u svim dokumentima prilikom postavljanja ili uklanjanja znaka vođenja odvojenog računovodstva u postavkama .

zaključak: jednostavno ponovno objavljivanje dokumenata neće ponovo popuniti tipove inventara u dokumentima!

Nakon postavljanja potrebnih karakteristika, u trenutku prijema robe, kreiraće se odgovarajući elementi imenika Vrste zaliha, koji će delovati kao serije, a prilikom otpisa (prodaje) robe, ove vrste zaliha, u zavisnosti od navedenog detalji, biće automatski određeni i zamijenjeni u dokumentu. Odabrane vrste inventara možete pogledati klikom na dugme "Otvori vrste inventara" na traci sa alatkama PM dokumenta.

Nakon što je roba kapitalizirana i prodana, vrijedi odrediti našu dobit od prodaje. U tu svrhu postoji dokument “Obračun troškova” (Finansijski podsistem – Regulatorni dokumenti). Ovaj dokument ima 2 opcije za njegovo formiranje: preliminarnu i stvarnu.

At preliminarni proračun operativni trošak se formira (ne puni): dodatni troškovi se ne uzimaju u obzir. rashodi, trošak prodaje se ne usklađuje u zavisnosti od usklađivanja iz prethodnog perioda, prihod se ne raspoređuje na aktivnosti organizacije, a greške zaokruživanja se ne otpisuju.

Plaćanje unaprijed potrebno posebno za menadžere koji trebaju vidjeti cijenu prodatih proizvoda u realnom vremenu. Ali ne postoji način da se dobije u realnom vremenu, a moguće je izvršiti ovaj dokument automatski kroz rutinski zadatak. Da bi to funkcionisalo, morate: u postavkama metoda za procjenu cijene robe (koje se nalaze na organizacijskoj kartici s lijeve strane u navigacijskom panelu "Metode za procjenu troškova robe"), postaviti atribut " Ažurirajte s rutinskim zadatkom". Zatim u postavkama rutinskih zadataka (Administracija - Podrška i održavanje - Rutinski i pozadinski zadaci) pronađite "Obračun troškova", provjerite da li se koristi i postavite raspored za to.

Stvarno proračun mora se obaviti ručno na kraju mjeseca. Da biste to učinili, morate postaviti odgovarajući atribut u dokumentu „Obračun troškova“ i izvršiti ga.

Sada možete generirati izvještaj o bruto dobiti.

Izvana izgleda da je sve prelepo, ali ako pokušate da dobijete trošak u smislu prodajnih dokumenata, dobićete sliku:

Ovo navodi na zaključak da nije moguće dobiti cijenu koštanja u kontekstu prodajnih dokumenata u UT11.0.8.11 standardnim sredstvima.

P.S. Kolona „Dodatni troškovi” u izveštaju o bruto dobiti i dokumenti „Raspodela troškova za nabavnu vrednost robe” i „Raspodela troškova i prihoda” zaslužuju posebnu pažnju, ali to je u posebnom članku, kao i trikovi izračunavanje troškova i zamke u troškovima UT11.

Trošak otpisa može se izračunati i za mjesec i za određeni vremenski period putem dokumenta „Obračun cijene robe“. Možete izračunati i preko mjesečnog asistenta za zatvaranje.

Bilješka. Trošak se obračunava za svako skladište posebno.

• Prosječni mjesečni trošak se obračunava na kraju mjeseca. Svaki proizvod dobiva istu cijenu mjesečno. Formula izračuna je sljedeća:

(bilans (troškova) na početku mjeseca + prijem (troška) u toku mjeseca) / (bilans količine na početku mjeseca + prijem količine u toku mjeseca) = trošak

• FIFO ponderisana procena se izračunava da bi se odredila vrednost bilansa koristeći sledeću formulu.

(stanje (trošak) na početku mjeseca + primici (po vrijednosti) u toku mjeseca) / (stanje na početku mjeseca (količina) + primici u toku mjeseca (količina)) = cijena koštanja apsolutno bilo koje serije za odabranog mjeseca

• FIFO rolling procjena izračunava potrošnju robe po redoslijedu prijema, tj. ako je jedna stavka nomenklature stigla ranije od druge stavke koja je stigla kasnije, tada će prva biti ranije otpisana.

Praksa obračuna troškova u 1C:UT 11.1:

Prvi metod. Najjednostavniji je da se na kraju svakog mjeseca kreira dokument "Prodaja - Dokumenti za obračun cijene robe".

Metod dva. Kroz "Administracija - Podrška i održavanje - Rutinski i pozadinski zadaci - Obračun troškova - Pokreni sada." Također možete konfigurirati zakazani zadatak da se pokreće automatski jednom mjesečno.

Rice. 1

Rice. 2

Kako izvršiti proceduru obračuna troškova:

1. Desni klik na ćeliju sa crvenim brojem (u koloni “Bruto profit”), zatim “Dešifriraj”. Tamo trebate odabrati "Magistar" - možete vidjeti s kojim dokumentima su napravljena kretanja.

2. Registar akumulacije gledamo kroz meni:

“Meni” - “Servis” - “Opcije” - “Prikaži meni “Sve funkcije””;

Idite na meni “Sve funkcije” - “Registri akumulacije” - “Roba u skladištima (ili roba organizacije) ili “Troškovi robe”.

Ako izvršite selekciju po nomenklaturi i karakteristikama, vidjet ćete po kojoj cijeni je kupljen (dokument „Prijem robe i usluga” ili unošenje početnih stanja), te po kojoj cijeni je prodat;

Rice. 3

Rice. 4

Rice. 5

Bilješka. Valute su u 1C:UT podijeljene na valutu upravljanja i regulatornog računovodstva uglavnom za formiranje računovodstvenih dokumenata u programu: knjiga kupovine i prodaje, itd., Ali ako su iste (rublja), onda neće biti razlika u izvještajima, ovisno o izboru valute.

Nazad Gore

Mehanizam za vanmrežni (neoperativni) obračun troškova, kretanje kroz registre troškova, opšte informacije.

Počevši od ERP verzije 2.1.3 (i odgovarajućih verzija KA i UT), razlikuju se dva tipa kretanja:

• “primarni” - formiran u skladu sa logikom dokumenata tokom njihove implementacije;
• “izračunato” - generisano ovim mehanizmom (identifikator tipa kretanja je novi atribut “Obračun troškova” akumulacionih registara).

Za listu registara koje održava mehanizam obračuna troškova, pogledajte Podaci o izlaznom mehanizmu()

Rekorder kretanja poravnanja je sada primarni dokument (iz atributa Dokument o kretanju), a ne dokument Obračun cijene robe. Dokument Obračun troškova robe više ne vrši kretanja u sljedećim registrima: Prihodi i Troškovi prodaje, Nabavke, Ostali troškovi rada u procesu (dostupno samo u ERP i KA) (dokument ostaje registrator za ove registre radi kompatibilnosti unatrag ).

Prilikom ponovnog knjiženja dokumenata, pohranjuju se kretanja poravnanja, bez obzira na promjene u dokumentu (U tu svrhu se u modul postavlja posebna šifra za skup evidencije vođenih registara. Za primjer pogledajte modul registra akumulacije Troškovi robe - pozivi na procedure ovog modula.). Promjene u dokumentu će biti uzete u obzir pri kretanju obračuna prilikom ponovnog obračuna troška.

Počevši od verzije ERP 2.1.3, algoritam za generisanje i snimanje kretanja je promenjen.
Sada, za svaki mehanizam koji opslužuje mehanizam, registri kretanja se formiraju na sljedeći način:

• prije početka obračuna, stara kretanja poravnanja se ne brišu - ostaju u IS-u do kraja obračuna;
• nova izračunata kretanja generisana mehanizmom se stavljaju u tabelu vrednosti;
• kada se dostigne određena veličina tablice vrijednosti ili kada se završi sljedeća faza izračunavanja;
• nova kretanja iz tabele vrednosti se prenose u privremenu tabelu;
• na kraju obračuna upoređuju se nova (iz privremene tabele) i stara (iz podataka o sigurnosti informacija) kretanja:
  • kretanja se prepisuju samo za one dokumente koji imaju razlike između kretanja starih i novih naselja;
  • samo dokumenti sa prepisanim kretanjima se registruju za obračun u računovodstvu.

Ove promjene vam omogućavaju da:

• vidjeti cijenu koštanja dokumenta iz samog dokumenta - sa izvještajem „Kretanje dokumenata“;
• pri ponovnom obračunu troškova prepisati samo stvarno promijenjena kretanja poravnanja;
• registrovati za odraz u računovodstvu samo dokumente sa prepisanim kretanjima (u ERP i CA).

Prelazak na ERP verziju 2.1.3 (i odgovarajuće verzije KA2 i UT11)

Prilikom prelaska na novu verziju, prethodno generirana kretanja poravnanja se ne mijenjaju automatski,
jer Za to nije potreban jednostavan prijenos kretanja između snimača, već "emulacija" preračunavanja troškova, što je bremenito...
Ako započnete ponovno izračunavanje starog perioda, tada će se u njemu generirati ispravni pokreti prema novoj shemi.

Započnite obračun troškova.

Ulazna tačka u algoritam proračuna je procedura Izračunaj sve() u koji se prosleđuju parametri:

• obračunski period - mjesec;
• moguć je „laki“ preliminarni obračun troškova - omogućava vam generiranje nekih izvještaja (ako je stvarni obračun već napravljen za navedeni period, tada se preliminarni obračun neće izvršiti);
• obračun se vrši ili za navedeni niz organizacija, ili za sve organizacije povezane sa navedenom organizacijom prema međukompanijskoj šemi (pogledajte Odnosi organizacija prema međukompanijskoj šemi()):
  • ako organizacija za obračun nije navedena, onda će se obračun izvršiti za sve organizacije koje imaju kretanja u registrima troškova u navedenom periodu;
  • sve organizacije za koje se vrši stvarni obračun moraju imati isti metod za vrednovanje zaliha (pogledajte DefineValueValuationMethod());
• Pokretanje obračuna troškova moguće je i interaktivno (iz mehanizma zatvaranja na kraju mjeseca) i iz rutinskog zadatka.

Originalni opis

// Početak obračuna troškova.
// (prethodno - Izvrši RegularTaskCostCostCalculation() modula upravitelja dokumenata obračuna troškova)
// Opcije:
// Datum - Datum - period obračuna troškova
// PreliminaryCalculation - Boolean - izvršiti stvarni ili preliminarni izračun;
// može se izvršiti preliminarni proračun
// = rutinski zadatak
// = kao pripremna faza za raspodjelu troškova za proizvode
// Organizacija - DirectoryLink.Organizations - izračunati samo za navedenu organizaciju;
// trošak organizacija povezanih u okviru interkompanijske šeme sa navedenom će također biti ponovo izračunati
// - Niz - niz organizacija za koje treba izračunati trošak, ostale organizacije se ne obračunavaju
// RoutineTask - Boolean - ako je istinito, to znači da je pozvan iz rutinskog zadatka za izračunavanje preliminarnog troška
// Parametri za otklanjanje grešaka - Struktura - ima za cilj da poništi svojstva strukture istog imena. Parametri izračunavanja
// (za više detalja, pogledajte objašnjenja u kodu InitializeCalculationParameters() za parametar DebugParameters)

Prije obračuna, za svaku organizaciju (ako već nije postojala) biće generiran dokument Obračun cijene robe sa sljedećim popunjavanjem:

• u atributu Organizacija zaglavlja dokumenta biće naznačena organizacija kojoj ovaj dokument pripada;
• u tabelarnom delu Organizacije sve organizacije povezane sa njom u okviru interkompanijske šeme biće naznačene, uklj. i sama:
  • Prije ERP verzije 2.1.3 (i odgovarajućih verzija KA i UT) nije postojao takav atribut zaglavlja, a dokument kalkulacije troškova kreiran je sam za cijelu grupu organizacija povezanih po Intercampany šemi (informacije o dokumentima za obračun troškova po organizaciji se pohranjuje u općim parametrima proračuna - u privremenoj tabeli VTCountingCostCalculationDocuments i svojstvu CalculationDocumentsByOrganizations).

Za izvođenje izračuna bez pada u slučaju greške, postoji funkcija omotača CalculateAllAtTryException() parametri su slični proceduri CalculateAll(), ali funkcija vraća vrijednost - Boolean - znak uspješnog izvršenja proračuna.

Izvođenje kalkulacija troškova.

Direktan obračun se vrši u funkciji Izračunaj trošak po grupi organizacija()
Šematski, proračun izgleda ovako:

• inicijaliziraju se opći parametri za cijeli algoritam (pogledajte InitializeCalculationParameters());
• faze-proračuni se pozivaju sekvencijalno (više detalja u nastavku)
  • neki koraci mogu biti preskočeni zbog postavki sistema i/ili parametara pokretanja proračuna;
  • rezultat faze su generirana izračunata kretanja i/ili “globalne” privremene tabele (koriste se u sljedećim fazama);
• snimaju se modifikovani izračunati pokreti;
  • snimanje se može izvesti u nekoliko niti koristeći pozadinske poslove (pogledajte svojstvo "Maksimalni broj datoteka");
• Promijenjena dokumenta se odražavaju u računovodstvu.

Struktura faze proračuna.

Šematski, postupak izračuna izgleda ovako:

• kreira se zahtjev za odabir izvornih podataka za pozornicu; njegova svojstva su popunjena; zahtjev je ispunjen;
  • ako je svrha faze samo formiranje “globalnih” privremenih tabela, sljedeće se ne odnosi na nju;
• Na osnovu podataka zahteva, kretanja namirenja se generišu pomoću registara obračuna troškova;
  • neke faze kretanja se ne formiraju - formiraju se samo "globalne" privremene tablice;
  • kod za generisanje kretanja je uključen u procedure oblika GenerateMovements<Имя регистра><Уточнение операции>();
  • unutar ovih procedura, za dodavanje kretanja, obavezno se koristi procedura AddRecordToMotionTable();
• "lokalne" privremene tabele koje se koriste samo unutar faze se brišu (pogledajte DestroyTemporaryTables());
• generisani pokreti se prenose iz tabela vrednosti u privremene tabele (pogledajte CacheFormedMoves());
  • istovremeno se ažuriraju i servisni keševi okretaja i stanja (više detalja u nastavku);
  • To. U intervalu između uzorkovanja izvornih podataka i kraja faze, ne možete pristupiti keš memoriji - oni se ne ažuriraju.

Pristup podacima o sigurnosti informacija u upitima.

Budući da se nova kretanja namirenja u registrima troškova evidentiraju u IS tek na kraju obračuna,
onda se tokom izračunavanja, prilikom pristupa tabelama ovih registara (stvarnim ili virtuelnim), moraju poštovati neka pravila (važi samo za registre navedene u InitializeRegisters()).
1. Promete (kretanja) registra za period potrebno je dobiti kombinovanjem:

• tabela glavnog registra sa izborom "T.Cost Cost Calculation = False" (primarna kretanja);
• VTKash privremena tabela<Имя регистра>(kretanja novih naselja);

Radi praktičnosti, za neke registre ovi podaci se automatski keširaju u privremenu tablicu VTKashRecords<Имя регистра>.
Lista registara je navedena u svojstvu "RegistersWithCalculationRecords" općih parametara proračuna.

2. Stanje registra (za bilansne registre) na kraju perioda treba dobiti kombinovanjem:

• registrovati stanja na početku perioda;
• tabela glavnog registra sa izborom "T.Cost Cost Calculation = False" (primarna kretanja za period);
• VTKash privremena tabela<Имя регистра>(nova naselja za period).

Radi praktičnosti, za neke registre ovi podaci se automatski keširaju u privremenu tablicu VTKashCalculatedBalances<Имя регистра>.
Lista registara je navedena u svojstvu "RegistersWithCalculatedBalances" općih parametara proračuna.

3. Nova kretanja generirana u prethodnim fazama obračuna pohranjuju se u privremenu tablicu VTKash<Имя регистра>.
Ova privremena tabela je kreirana za sve registre koje opslužuje mehanizam obračuna troškova.

Postoji i niz dodatnih mogućnosti rada sa upitima (razlozi: optimizacija, platforma, itd.).

1. Podaci koji se koriste za odabire u svim zahtjevima mehanizma proračuna se pohranjuju

• opći parametri proračuna (organizacije, period, vrijednosti funkcionalnih opcija itd.);
• u “globalnim” privremenim tabelama (na primjer, VTOSelectionAnalyticsByPartners - pogledajte InitializeTemporaryTablesForSelections()).

Za postavljanje ovih parametara koristite univerzalnu proceduru InitializeRequestProperties()
Kao rezultat toga, zajamčeno je da će svi upiti rješavača koristiti iste odabire.
Ista procedura postavlja opći privremeni upravitelj tablice za upit, koji pohranjuje sve gore navedene tablice keša.

2. Postoji greška platforme 30025997, koja uzrokuje probleme sa poljem Tip kretanja u privremenim tabelama.
Da biste zaobišli grešku u svim privremenim tabelama tipa VTKash, VTKashRecords, VTKashCalculatedRemains
Umjesto standardnog polja Movement Type, pohranjuje se tehnogeno polje ServiceMovement TypeIncoming sa tipom „Boolean“ algoritam za rad s njim:

• u upitima prema ovim privremenim tabelama, trebali biste pristupiti samo polju ServiceType of MovementReceipt;
• u tabelama vrednosti u kojima su prethodno akumulirani novi zapisi poravnanja, postoji samo standardno polje Tip kretanja;
• Konvertovanje polja između tabele vrednosti i privremene tabele se vrši automatski, nisu potrebni dodatni koraci.

Otklanjanje grešaka i rješavanje problema.

Kako bi se olakšao razvoj, testiranje i rješavanje problema, implementiran je mehanizam za evidentiranje proračuna (pogledajte procedure tipa Calculation Protocol_...) koji se obrađuje u sljedećim koracima:

• na početku sljedeće faze obračuna, vrši unos u evidenciju registracije - radi praćenja toka obračuna;
• Na kraju proračuna, detaljan protokol proračuna se prikazuje u dnevniku registracije.

Također je moguće poništiti neke parametre proračuna (pogledajte CalculateAll(), parametar parametara za otklanjanje grešaka).

P.S. Ovaj članak će biti najkorisniji za programere. Zasnovan je na komentarima 1C programera u rješenju 1C: Enterprise: „Upravljanje trgovinom“, izdanje 11.2.3.

Članak je napisan u obliku FAQ i idealan je za korisnike koji ne žele ulaziti u višestranične opise različitih metoda obračuna troškova.

U ovom članku ćemo pogledati koje metode vrednovanja postoje i koje su njihove karakteristike, koja je računovodstvena analitika moguća i gdje se konfiguriše, koje dokumente treba sastaviti u sistemu i kako utiču na obračun troškova. Dodatno ćemo razmotriti opcije obračuna materijala i opreme, raspodjelu troškova i moguće greške u obračunu troškova.

Za osnovu je uzet kurs „UT 11 – Brzi početak“, a korišteni su i materijali sa webinara i priručnika za obuku.

Primjenjivost

Članak je napisan za urednike 1C: Upravljanje trgovinom 11.0 . Ako koristite ovo izdanje, odlično - pročitajte članak i implementirajte funkcionalnost o kojoj se raspravlja.

Ako planirate započeti implementaciju UT 11, tada će se, najvjerovatnije, koristiti novije izdanje - imajte na umu da su greške u obračunu troškova već ispravljene, a funkcionalnost će se malo razlikovati.

Stoga preporučujemo pohađanje kursa Praktični zadaci nivoa 1C: Specijalista za UT 11, KA 2 i 1C: ERP 2, ovo će vam pomoći da izbjegnete greške i gubitak vremena/ugleda.

Obračun troškova u "1C: Upravljanje trgovinom 11"

Koje metode procjene vrijednosti robe pri otuđenju se mogu koristiti u UT 11?

Možete odabrati jednu od dvije metode za procjenu troška robe pri odlasku - prosjek za mjesec, FIFO.

Gdje navesti metodu koja se koristi za vrednovanje robe prilikom otuđenja?

Financije -> Postavljanje metoda procjene troškova. Postavka se postavlja za svaku organizaciju od određenog datuma.

Gdje se koristi uvedeni način vrednovanja robe pri otuđenju?

U dokumentu “Obračun cijene robe” (Finansije -> Regulatorni dokumenti). Može se mijenjati direktno u dokumentu.

Koje su karakteristike “FIFO” metode u UT11?

• Ne postoji uobičajeni koncept serije (dokument o prijemu). Serija je određena vrijednostima dimenzije registra troškova robe, gdje ne postoji dokument o prijemu.
• Sve serije sa istim dimenzijama u registru troškova robe na kraju mjeseca se spajaju u jednu seriju, koja se smatra početnim stanjem za naredni period.
• Svi prijemi u toku dana sa istim merama u registru troškova robe smatraju se jednom serijom. Količina i trošak ove serije se sastoji od svih računa po danu.

Za koje se objekte analitičkog računovodstva trošak stavke može posebno uzeti u obzir?

Trošak stavke može se posebno uzeti u obzir za sljedeće objekte analitičkog računovodstva: skladište, financijsko računovodstvena grupa, odjel ili menadžer, transakcija.

Gdje definirati analitičke računovodstvene objekte za koje se trošak stavke može posebno uzeti u obzir?

Administracija -> Finansije -> Zasebno računovodstvo. U kontekstu skladišta uvijek se vrši kalkulacija troškova. Zasebno računovodstvo se sprovodi i metodom FIFO i metodom proseka.

Zašto iznos otpisanog troška nije naveden prilikom knjiženja dokumenata za prodaju?

Implementacijski dokumenti čine kretanja samo po količini.

Trošak će se izračunati pomoću dokumenta „Obračun troška robe“; Ispada da je količina otpisana jednim dokumentom, a troškovi drugim.

Koje regulatorne dokumente morate unijeti da biste izračunali trošak i dobili finansijski rezultat, kakav je redoslijed dokumenata?

Da biste ispravno izračunali trošak, morate unijeti dokumente sljedećim redoslijedom:

1. Distribucija odgođenih troškova (Finansije -> Distribucija RBP-a)
2. Raspodjela troškova nabavne vrijednosti robe (Finansije -> Regulatorni dokumenti -> Raspodjela troškova nabavne vrijednosti robe). Za svaku organizaciju može se uneti samo jedan dokument mesečno. Dokument nije potreban. Ako se ne unese, tada će se raspodjela troškova za trošak robe izvršiti dokumentom „Obračun cijene robe“. Ali preporučuje se da unesete ovaj dokument da biste identifikovali greške u proračunu.
3. Obračun cijene robe (Finansije -> Regulatorni dokumenti -> Obračun cijene robe).
4. Raspodjela troškova i prihoda (Finansije -> Regulatorni dokumenti -> Raspodjela rashoda i prihoda).

Koliko često trebam unositi dokument Obračun troškova?

U roku od mjesec dana unosimo dokumente “Obračun troškova” sa “preliminarnom” opcijom.

Na kraju mjeseca unosimo dokument “Obračun troškova” sa opcijom “stvarno”.

Dokumenti se mogu unositi za svaku organizaciju. Ako postoji preprodaja robe između organizacija, tada se takve organizacije moraju unijeti u jedan dokument.

Da li je moguće automatski izračunati troškove prema rasporedu?

Možete, za to trebate postaviti rutinski zadatak (Financije -> Postavljanje metoda za procjenu cijene robe -> Ažuriraj trošak rutinskim zadatkom); Administracija -> Planirani i pozadinski zadaci, dodajte zadatak “Obračun troškova” na listu aktivnih zadataka, postavite raspored.

Zašto je „preliminarni“ metod obračuna troškova uveden u dokument „Obračun koštanja robe“?

“Preliminarni” način izračunavanja je uveden kako bi se povećale performanse upisivanja u neke registre. Izračunava se „preliminarni“ trošak, koji će na kraju mjeseca biti izračunat tačno u „stvarnom“ načinu.

Koja je razlika između „prethodne“ kalkulacije troškova i „stvarne“ kalkulacije u dokumentu „Obračun koštanja robe“?

Trošak se uvijek obračunava prema „prosjeku“, bez obzira na metodu specificiranu za organizaciju.

Proračun se vrši pojednostavljenom metodom (TZR se ne distribuiraju).

Kretanje se dešava samo u registru troškova robe, evidentira se referentna vrednost troška obračunata metodom prosečnih troškova, detaljizacija troška se vrši prema merenjima registra troškova robe. Period čuvanja podataka je mjesec dana.

Kretanja u ovom registru formiraju se prema preliminarnim i stvarnim opcijama obračuna troškova. Kretanja u registrima Troškovi robe, Prihodi i troškovi prodaje, Ostali rashodi se ne formiraju.

U kojim izvještajima možete analizirati preliminarne troškove?

1. U izvještaju Analiza prihoda i rashoda (Finansije -> Finansijski izvještaji -> Prihodi i rashodi).
2. U izvještaju Prihodi i troškovi prodaje (Finansije -> Finansijski izvještaji
   -> Bruto profit za….).

Moguće greške UT11 pri obračunu troškova i metode za njihovo ispravljanje

Razlog je taj što sistem „pamti“ prethodno otpisanu „Vrstu inventara“ kada se dokument prvi put knjiži i upisuje je u tabelarnu sekciju „Vrste zaliha“ (tabelarni deo „Vrste zaliha“ se ne briše tokom bilo kakvih radnji sa dokument).

Metoda eliminacije: prije pokretanja dokumenta „Obračun troškova“, obrišite tabelarni dio „Vrste zaliha“ dokumenta „Prodaja robe i usluga“.

Kada se ulazni dokumenti mijenjaju „retrospektivno“ (promjena datuma dokumenta) u prodajnom dokumentu, partija robe se otpisuje ne u skladu sa FIFO metodom (ako je to postavljeno u dokumentu „Obračun troškova“).

Razlog - sistem određuje koju seriju treba otpisati prema registru informacija Datum prijema robe Organizacije. Prilikom promene datuma knjiženog dokumenta prijema, Datum prijema u registru podataka o Datumu prijema robe organizacija menja se samo kada je novi datum veći od prethodnog.

Dakle, ako je dokument imao datum 03.01 - u registru Datum prijema = 03.01, promeniti u 04.01 - u registru Datum prijema = 04.01, promeniti u 02.01 - u registru Datum prijema = 04.01. Ispravka - brisanje evidencije o zalihama iz registra podataka o Datumu prijema robe organizacija i ponovno knjiženje dokumenata.

Kada se ulazni dokumenti mijenjaju „retrospektivno“ (promjena datuma dokumenta) u prodajnom dokumentu, partija robe se otpisuje ne u skladu sa FIFO metodom (ako je to postavljeno u dokumentu „Obračun troškova“).

Razlog je u tome što ako je tokom perioda bilo više prijema sa istim mjerenjima u registru „Troškovi robe“, tada sistem smatra da je zadnji datum prijema datum serije. Dakle, ako je 1. i 10. došlo do dolaska 10 komada i 20 komada. roba sa merama po registru Trošak robe SbTv1, a 3. je došlo do dolaska iste robe 10 kom. sa merama po registru Troškovi robe SbTV2, onda kada se ovaj proizvod proda 15. u količini od 10 kom. Grupa 3. datuma će biti otpisana, jer MAX(1,3)=3 na SatTV1.

Kada promijenite postavku vezanja računovodstva troškova, već postoje uneseni dokumenti prijema.

Na šta treba obratiti pažnju prilikom promjene zasebnih računovodstvenih postavki

Kada promijenite postavke vezanog računovodstva, mijenja se analitika vrste inventara. U mnogim dokumentima ova analitika se popunjava kada se dokument knjiži, bilježi se u detaljima dokumenta i ne mijenja se kada se dokument ponovo knjiži.

Da li je moguće uključiti troškove tehničke opreme u cijenu robe?

Da, moguće je, ali iznos TZR se čuva u posebnom atributu registra troškova robe – Iznos dodatnih troškova.

Da li je moguća raspodjela robe i materijala na trošak zaliha i materijala tekućeg perioda ako je dokumentacija za njih stigla u narednom periodu (roba je primljena 25.01.13., a isporučni dokumenti od transportne kompanije su izdati dana 02/05/13)?

Ne možeš. Dokumenti o prijemu robe i materijala i robe i materijala moraju biti u istom periodu.

Da li je moguće automatski rasporediti isporuku robe na više dokumenata o prijemu ili na listu artikala?

Ne, ne možete, takva distribucija se mora obaviti ručno. Za svaki račun ili artikl unesite poseban red i ručno izračunajte iznos.

Da li je moguće alocirati dodatne troškove na određeni dokument Montaža (demontaža) robe?

Ne možeš. Moguće je samo za nomenklaturu. Ako smo ovaj artikal kupili od dobavljača, onda dodatno. troškovi će biti raspoređeni i na nju. Ali možete krenuti manje očiglednim putem. Uđite u posebno montažno skladište, premestite sve komponente tamo, unesite dokument o montaži (demontaži), premestite komplet iz skladišta komponenti. Zatim možete unijeti dodatne. troškovi za konkretan potez.

Koji dokumenti se koriste za dokumentovanje troškova obračuna plaća?

Dokument Potvrdni nalog sa vrstom transakcije Ostali troškovi.

Da li je moguće vremenski razdvojiti odraz troškova za isplatu zarada i samu isplatu zarada?

Da li je moguće automatski rasporediti dodatne troškove na više dimenzija?

Ne, ne možete, takva distribucija se mora obaviti ručno. Za svaku analitiku unesite poseban red i ručno izračunajte iznos.

Na kraju izvještajnog perioda, sistem izračunava trošak. Da biste to učinili, koristite dokument Obračun cijene robe, s instaliranom opcijom Stvarno:

U tom slučaju možete odrediti način obračuna troškova - Mjesečni prosjek, FIFO (ponderisano vrednovanje), FIFO (rotirajuća procjena).

Trošak se također može izračunati unaprijed; dostupne su iste metode:

Obračun troškova se može izvršiti uz izolaciju finansijskog rezultata prema određenim analitičarima. Moraju biti postavljeni u sistemu unaprijed, prije upotrebe. Ako je omogućena funkcionalna opcija, finansijski rezultat se odvaja po nalozima; ali možete odrediti i dodatne opcije distribucije:

1. U prosjeku
2. FIFO (ponderisano vrednovanje)
3. FIFO (rotirajuća procjena)
4. Opcije 1 ili 2
5. Opcije 1 ili 3
6. Opcije 1 ili 2 ili 3

Verified. Tačan odgovor je prvi. Generalno, sve opcije su dostupne, ali prema odgovorima na testu, preliminarni trošak se izračunava samo po prosjeku.

Pitanje 13.34 ispita 1C: ERP Professional Enterprise Management 2.0. Prilikom postavljanja računovodstvene politike organizacije, kao metod obračuna troškova može se odabrati sljedeće:

1. U prosjeku
2. FIFO (ponderisano vrednovanje)
3. FIFO (rotirajuća procjena)
4. Opcije 1 ili 2
5. Opcije 1 ili 3
6. Opcije 1 ili 2 ili 3

1. Po nalogu
2. Po dogovoru
3. Od strane menadžera
4. Opcije 1 i 2
5. Opcije 1 i 3
6. Opcije 1 i 2 i 3

Pitanje 13.37 ispita 1C: ERP Professional Enterprise Management 2.0. Finansijski rezultat se može izolovati:

1. Po nalogu
2. Pod ugovorom
3. Po odjelu
4. Opcije 1 i 2
5. Opcije 1 i 3
6. Opcije 1 i 2 i 3

Pitanje 13.35 ispita 1C: ERP Professional Enterprise Management 2.0. Ako postoji prodaja među kompanijama, metoda obračuna troškova bi trebala biti:

1. Isto za sve organizacije koje se bave registracijom interkompanijske prodaje
2. Može se razlikovati za svaku organizaciju
3. Opcije 1 ili 2 u zavisnosti od podešavanja sistema

Pitanje 13.38 ispita 1C: ERP Professional Enterprise Management 2.0. Finansijski rezultat možete pogledati uzimajući u obzir segregaciju u izvještajima:

1. Analiza troškova proizvoda
2. Bruto dobit preduzeća
3. Prihodi i rashodi
4. Opcije 1 i 2
5. Opcije 2 i 3
6. Opcije 1 i 2 i 3