Koliko često vaša kompanija treba pogledajte ko je promenio 1C dokument?

Ili kako saznati ko je od zaposlenih promenio ovaj ili onaj atribut dokument 1s 8?

Kako gledati povijest promjena dokumenata 1C?

Modul "Istorija promjena" baziran na 1C 8

Pogodno i efikasno alat analiza i kontrolu radnje korisnika 1C.

Probleme rješava modul "Historija promjena" 1C 8:

• Otklanjanje mogućnosti prevara korisnici sa dokumentima sa zadnjim datumom;
• Utvrđivanje ko je kriv za uvođenje pogrešni podaci u dokumentima;
• Mogućnost detekcije neispravan rad programa u smislu automatskih izmjena ili ponovnog postavljanja dokumenata;
• Otkrivanje namjerno izobličenje (promjena) podataka, na primjer, unošenje pogrešnih podataka za kontakt klijenta od strane beskrupuloznih menadžera;
• Prilika vidi šta se desilo sa dokumentom ili referentnom knjigom prije promjene i, ako je potrebno, vratite sve nazad.

Prednosti mehanizma "Historija promjena" 1C 8:

• Svi podaci se pohranjuju unutar 1C baze podataka, što osigurava velika brzina pretraživanja potrebne informacije i izradu potrebnih izvještaja.
• Modul 1C 8 "Historija promjena" ima minimalan uticaj na performanse. Teško da ćete osjetiti razliku kada radite sa i bez našeg podsistema.
• Modul univerzalni I lako se integriše u bilo koju, čak i standardnu, sistemsku konfiguraciju « 1C:Enterprise" verzije 8.2 i verzije 8.3 , uključujući verziju.

Mogućnosti modula:

Modul vam omogućava da fleksibilno konfigurišete objekte koji će biti nadgledani.

Pregled historije promjena podataka moguć je direktno iz forme dokumenta ili imenika i dostupan je korisnicima koji imaju odgovarajuća prava.

Kontrolni mehanizam uključuje promjene detalja direktorija i dokumenata. Istovremeno se čuvaju i stare i nove vrijednosti atributa.

Dostupan je mehanizam za kontrolu promjena u redovima 1C dokumenta. Na primjer, prikazuju se promjene cijena, količina i drugi podaci u određenom redu.

Moguće je vidjeti izbrisane i dodane redove u tabelarnim dijelovima dokumenata. U tom slučaju, program će zanemariti promjene u sortiranju redova unutar dokumenta, što zapravo nije promjena podataka. Radi jasnoće, u izvještaju o promijenjenim podacima dodani redovi su obojeni plavom bojom, a izbrisani rozo.

Dnevnik 1C 8.

Kako saznati ko je promijenio 1C dokument?

Čini se da je sve jednostavno - možete vidjeti ko je promijenio 1C dokument "Dnevnik registracije". Na kraju krajeva, on bilježi događaje koji se odnose na promjene objekata baze podataka, kao i događaje koji se javljaju pri radu sa bazom podataka (prijava i odjava korisnika, greške, generiranje izvještaja). Tako da časopis postaje veoma dobar puno dodatnih unosa, zbog čega obim časopisa naglo raste i nastaju problemi kako pohranjivanjem časopisa tako i traženjem zaista korisnih i potrebnih informacija u njemu.

Ali najveći nedostatak standardnog magazinaregistracija— nemogućnost da saznate šta je tačno promenjeno u objektu: svojstvo ili linija u tabelarnom delu — nećete naći odgovor. I sigurno nećete ni na koji način znati koji su podaci bili prije promjene, a šta poslije.

Također je nemoguće konfigurirati ugrađeni dnevnik tako da iz otvorenog dokumenta ili referentne knjige možete vidjeti cijelu povijest promjena 1C 8 klikom na jedno dugme. Takve manipulacije zahtijevaju prilično složenu, za neobučenog korisnika, podešavanje izbora u dnevniku.

Modul "Historija promjena" je zgodan i operativan alat za analizu i praćenje radnji korisnika 1C.

To Modul "Istorija promjena" 1C 8 počeo da radi svoj posao, potrebno ga je jednom konfigurisati. Postavljanje ne zahtijeva puno vremena i uključuje odabir dokumenata, direktorija, kao i njihovih detalja, koji će se koristiti za praćenje i pohranjivanje historije promjena.

Cijena modula ovisi o potrebi za uslugama za njegovu instalaciju i konfiguraciju. WITH Kontaktirajte nas na bilo koji pogodan način i saznajte cijenu.

Ovaj članak je najava nove funkcionalnosti.
Ne preporučuje se korištenje sadržaja ovog članka za učenje novih funkcionalnosti.
Potpuni opis nove funkcionalnosti će biti dat u dokumentaciji za odgovarajuću verziju.
Kompletna lista izmjena u novoj verziji nalazi se u datoteci v8Update.htm.

Implementirano u verziji 8.3.11.2867.

Implementirali smo novi mehanizam, historija podataka, koji kompaktno pohranjuje povijest promjena podataka aplikacije od strane korisnika. Koristeći gotova rješenja interfejsa ili korištenjem ugrađenog jezika, sada možete fleksibilno analizirati promjene podataka, upoređivati ​​različite verzije i vratiti podatke u stanje koje su imali u odabranoj verziji.

U kojim scenarijima je potrebno raditi sa historijom podataka?

Najčešće je potreban pristup istoriji podataka kako bi se utvrdio korisnik koji je izvršio neku promjenu. Na primjer, proizvod je prodan drugoj strani uz preveliki popust, a sada želim razumjeti tko je postavio takav popust. Ili druga situacija u kojoj se čini da je cijena artikla tačna, ali je predmet prodavan po nižoj cijeni u prošlosti. Moramo saznati ko je promijenio cijenu, a zatim je vratio na prethodnu vrijednost.

Druga situacija u kojoj je potrebna historija podataka je da je u trenutnom trenutku vrijednost nekog atributa u računovodstvenom sistemu postavljena na način da to dovodi do negativnih posljedica. Potrebno je saznati kada je tačno postavljena ova vrijednost i koji korisnik ju je postavio.

Da biste dalje analizirali situaciju, možda ćete morati saznati sve promjene koje je napravio određeni korisnik koji je jednom učinio nešto pogrešno. Jer u drugim slučajevima mogao je napraviti sličnu grešku.

Konačno, nakon što se pronađu sve neprikladne promjene, može postojati prirodna želja za vraćanjem prethodnog, ispravnog stanja podataka, ili čak vraćanjem podataka koji su direktno izbrisani.

Istovremeno, u svim gore navedenim scenarijima, želite da se ove mogućnosti ostvare uz minimalan gubitak performansi i prostora na disku.

Kako se ne bi pokazalo da povijest promjena objekata zauzima više prostora od samih korisnih objekata s kojima radite. Ili kako bi se osiguralo da pružanje ove funkcionalnosti ne rezultira značajnim usporavanjem za korisnike.

Jasno je da je nemoguće potpuno eliminisati gubitke performansi, jer je umjesto jedne radnje potrebno izvršiti dvije: čuvanje objekta i isto tako čuvanje njegove historije. Ali u isto vrijeme, želim da ti gubici budu nevidljivi.

Postoji još jedna karakteristika koja se ne odnosi na funkcionalnost ili tehničke zahtjeve, već na specifičnosti tržišta 1C:Enterprise. Možete smisliti vrlo dobar mehanizam koji će raditi brzo i imati odličnu funkcionalnost. Ali ako zahtijeva značajnu tehničku stručnost da bi se postavio, uključio i održavao, to bi moglo poništiti bilo koju od njegovih prednosti.

Stoga, administriranje takvog mehanizma ne bi trebalo biti teško i za programera i za administratora baze podataka. Zaista, u malim implementacijama datoteka, administrator je često jedan od korisnika, a ponekad i jedini korisnik ovog aplikativnog rješenja.

Koje mogućnosti za analizu istorije već postoje na platformi?

Glavni alat koji možete koristiti za analizu "šta se dešava u sistemu" je datoteka evidencije. Između ostalog, bilježi promjene podataka. Odnosno, možete saznati ko je i kada promijenio podatke određenog objekta. Ali njegove mogućnosti u oblasti o kojoj se raspravlja tu se završavaju, jer je iz dnevnika nemoguće shvatiti koji su pojedini detalji promijenjeni, u kakvom je prethodnom stanju. Štaviše, nemoguće je vratiti prethodno stanje svojstva ili cijelog objekta pomoću dnevnika.

Još jedan alat koji postoji već duže vrijeme i koji je uključen u sva rješenja za cirkulaciju je BSP - biblioteka standardnih podsistema. Uključuje podsistem za verzioniranje objekata. Ovaj podsistem sadrži sve navedene funkcije, ali ima neka praktična ograničenja.

Prvo, dio je biblioteke, tako da njegova implementacija u aplikativno rješenje zahtijeva učešće kvalifikovanog programera. Dobro je ako je BSP inicijalno prisutan u aplikacijskom rješenju. Ali ako ga nema, administrator, ili, posebno, kvalifikovani korisnik, neće moći samostalno da ga implementira.

Drugo, zadatak održavanja istorije podataka je sam po sebi zadatak niskog nivoa i efikasnije se rešava u tehnološkom sloju platforme.

Prednosti rješenja ugrađenog u platformu

Kada smo analizirali trenutnu situaciju, postojeće iskustvo u korišćenju BSP-a i odmerili sve prednosti i nedostatke, došli smo do zaključka da bi najefikasnije rešenje bilo implementiranje istorije podataka kao dela same tehnološke platforme. Time ćete postići sljedeće prednosti:

• Da bi koristio ovaj mehanizam, administrator ili korisnik ne moraju mijenjati konfiguraciju, sve što je potrebno je već na platformi. Samo ga trebaš uključiti.
• Ovaj mehanizam će raditi brže od analoga implementiranih kao dio konfiguracije, jer koristit će funkcije koje nisu dostupne na ugrađenom jeziku.
• Sama historija podataka će zauzeti manje prostora, jer neće biti pohranjena kopija podataka, već samo njihova razlika u odnosu na prethodnu verziju. Osim toga, sama verzija verzija se ne može primijeniti na sve detalje, već samo na one koji su od interesa. Ovo će takođe omogućiti dodatne uštede.
• Biće moguće podržati verzionisanje ne samo onih objekata koji imaju jedinstvenu vezu (direktorije, dokumenti, itd.), već i entiteta koji nisu objekti, kao što su, na primer, unosi u registar informacija.

Osnovne informacije o mehanizmu

Mehanizam historije podataka je u potpunosti implementiran unutar platforme, ne zahtijeva nikakvu instalaciju dodatnog softvera i spreman je za korištenje u bilo koje vrijeme, ali nije uključen po defaultu.

Možete ga omogućiti i u konfiguratoru i u načinu 1C: Enterprise. To može učiniti programer u konfiguratoru, u načinu 1C:Enterprise korisnik, koristeći obradu napisanu na ugrađenom jeziku.

“Omogućavanje” mehanizma je da naznači za koje konfiguracijske objekte će se održavati povijest promjena. Štaviše, održavanje istorije može se omogućiti ne samo za ceo objekat, već i za njegove pojedinačne komponente: detalje, dimenzije, resurse. Uključujući detalje za tabelarne dijelove. Dakle, možete birati: pohraniti kompletne informacije ili uštedjeti prostor.

Implementirali smo pohranu historije za imenike, dokumente, zadatke, poslovne procese i registre informacija. Možda ćemo u budućnosti proširiti ovu listu.

Podatke istorije pohranjujemo u zasebne tabele u bazi podataka. Da bismo poboljšali efikasnost, pohranjujemo samo razliku između verzija podataka. Ako imate „težak“ dokument sa velikim brojem redova u tabelarnom delu, a promenite samo jedan atribut u samom dokumentu, tada će samo ova promena biti sačuvana u istoriji podataka. To jest, nećete pohraniti mnogo kopija ovog objekta i zauzeti prostor na disku.

Osim promjena podataka, pohranjujemo i metapodatke objekta u vrijeme kada je verzija snimljena. Ovo je neophodno kako bi se pravilno izgradili izvještaji o objektima koji su snimljeni u drugom stanju konfiguracije. Na primjer, kada su neki detalji nazvani drugačije, drugi detalji nisu bili prisutni, a drugi su bili prisutni, ali su naknadno izbrisani.

Rukovanje promjenama podataka

Proces upravljanja verzijama podataka sastoji se od dvije faze. Prvo, kada pišete objekat (na primjer, dokument), generira se posebna poruka koja se stavlja u red čekanja. Ovu fazu izvodi platforma, programer ne učestvuje u njoj.

Ali drugu fazu pokreće programer. Druga faza je da se prilikom obrade reda ovi podaci preuzimaju, stavljaju u skladište verzija i postaju dostupni za rad s njima.

Da bi se red obradio na ovaj način, upravitelj historije podataka ( Data History Manager) postoji metoda UpdateHistory(). Pretpostavljamo da ćete ga koristiti na isti način kao i sličan metod za ažuriranje indeksa pretraživanja punog teksta. To jest, ažurirat ćete historiju u nekom rutinskom zadatku, koji se izvodi s određenom učestalošću.

Vjerujemo da će ova asinhrona operacija rezultirati i efikasnim snimanjem objekata i minimalnim troškovima performansi.

Korisnički interfejs

U korisničkom sučelju 1C: Enterprise poziva se novi mehanizam Istorija promjena. Uključuje nekoliko obrazaca koji vam omogućavaju da izvršite radnje koje su navedene na početku ovog članka.

Lista verzija za određeni objekat

Ako je za objekt omogućeno snimanje povijesti, nova naredba se pojavljuje među standardnim naredbama objekta Istorija promjena.

Omogućava vam da vidite listu svih promjena (verzija) objekta.

U koloni Izvor promjeneČvor plana razmjene se također može specificirati ako je promjena napravljena u čvoru i „stigla“ u ovu bazu podataka kao rezultat razmjene podataka.

Na ovoj listi, u koloni

U toku rada preduzeća često postoji potreba da se sazna ko je, kada i šta tačno promenio dokument ili programski priručnik.

Vrlo često mi se postavljaju pitanja:

• Kako vidjeti ko je promijenio dokument u 1C 8.2?
• Kako vidjeti ko je promijenio dokument u 1C?
• Kako saznati u 1C ko je promijenio dokumente i kada?
• Kako saznati u 1C ko je promijenio objavljivanje u dokumentu?
• Kako vidjeti ko je promijenio dokument u 1C?

Dnevnik

Sadrži informacije o tome koji su se događaji dogodili u infobazi u određenom trenutku ili koje su radnje izvršene od strane određenog korisnika. Za svaki unos u dnevniku koji odražava promjenu podataka, prikazuje se status završetka transakcije (transakcija je uspješno završena ili je transakcija otkazana).

Dnevnik je dostupan u načinu rada 1C:Enterprise iu načinu konfiguratora.

Pristup dnevniku je moguć i iz moda konfiguratora (preko menija Administracija - Dnevnik), i iz Enterprise moda (meni Servis - Dnevnik). U taksi modu ( Glavni meni - Sve funkcije - Standardno - Dnevnik)

Vrsta dnevnika(Redovni obrasci i taksi):

Odabir u dnevniku(Redovni obrasci i taksi):

Koristeći alate za rad sa listama, moguće je učitavanje evidencije registracije u tabelarni ili po potrebi tekstualni dokument (preko Akcije - Izlazna lista), koji se kasnije može sačuvati, na primjer, u Excel, TXT ili HTML formatu. U ovom slučaju moguće je konfigurirati nivo događaja koji će se bilježiti u dnevnik, kao i učestalost podjele dnevnika u zasebne datoteke (u modu konfiguratora menija Administracija - Postavljanje dnevnika).

I tu je takođe moguće smanjiti broj unosa u ovaj log do određenog datuma, što se radi kako bi se ubrzao rad sa mehanizmom za analizu i evidentiranje događaja u sistemu ili da bi nebitne informacije bile nepotrebne.

Gdje se vodi dnevnik?

U bazi podataka datoteka: folder u direktoriju baze podataka 1Cv8Log - ovo je direktorij koji sadrži dnevnik.

Ako planirate da prenesete datoteku baze podataka i želite da sačuvate istoriju dnevnika i svakako morate da kopirate fasciklu 1Cv8Log u kategoriju nove 1C baze podataka. Ako trebate izbrisati evidenciju registracije 1C u bazi podataka, jednostavno izbrišite mapu 1Cv8Log.

INKlijent-server baza podataka: C:\Program Files\1cv8\srvinfo\<Имя кластера сервера>\<Идентификатор базы на сервере>\1Cv8Log

Od verzije 8.3.5.1068. Dnevnik je značajno prerađen kako bi se povećala brzina izvršavanja zahtjeva prema logu i povećala pouzdanost pohranjivanja podataka.

Ovo je, između ostalog, zahtijevalo promjenu formata pohrane dnevnika. Sada je pohranjen u jednoj datoteci SQLite baze podataka. Ovaj fajl ima ekstenziju lgd.

Versioniranje objekata

U nekim 1C konfiguracijama uveden je poseban mehanizam "Objektno verzioniranje".

Podrazumevano, upravljanje verzijama je onemogućeno; da biste ga omogućili, otvorite Servis - Postavke računovodstva - Podešavanje računovodstvenih parametara

Kliknite na dugme “Podešavanje verzionisanja objekata” da odaberete koji direktorijumi i dokumenti trebaju biti verzionisani (pratiti ko je šta promenio i kada).

Prema zadanim postavkama, objekti baze podataka se ne nadziru, zbog čega se pored svake vrste dokumenta postavlja zastavica “Ne verziju”. Ako je potrebno da se izvrši nadzor, potrebno je da postavite „Verziju“ nasuprot evidenciji dokumenata od interesa.

To je to, kada zatvorite prozor i kliknete na dugme "Ok", objekti će biti praćeni.

Da biste vidjeli sve promjene koje je neko napravio u dokumentu ili referentnoj knjizi, potrebno je ući u meni: Usluga - Istorija promjena objekata

Versioniranje u 1C:Enterprise ➾ Istorija promjena objekata ➾ Kako podesiti verzioniranje objekata u 1C:Enterprise? ➾ Šta je verzija? Postavljanje opcija, uloga, mehanizma za snimanje verzija, itd.

Zamislite situaciju: vi ste menadžer prodaje. Kreirali ste narudžbu za koju morate poslati robu. Generirali smo prodajni dokument i otkrili da podaci u njemu ne odgovaraju narudžbini kupca. Da biste saznali ko je, kada i koje promjene izvršio dokument, postoji mehanizam za verzioniranje u konfiguracijama 1C: Enterprise 8.

Versioniranje je pohranjivanje historije promjena objekata. Za razliku od dnevnika, pored pohranjivanja historije ko je promijenio koji objekt, kada i šta, mehanizam verzioniranja omogućava administratoru sistema da vidi specifične promjene koje su korisnici napravili.

Sistem vam omogućava da vidite bilo koju verziju objekta ili da uporedite bilo koju verziju objekta jednu s drugom. Da biste radili s historijom promjena objekata, prvo morate konfigurirati njihovu verziju. Administrator sistema konfiguriše i pregleda istoriju verzija.

Kako konfigurirati verzioniranje objekata?

Trenutno je mehanizam verzioniranja dostupan u mnogim standardnim, najčešćim konfiguracijama, na primjer:

Versioniranje konfiguriše administrator sistema sa punim pravima.

Otvorite karticu "Versioning" i potvrdite izbor u polju za potvrdu "Koristi verzioniranje objekata":

Kliknite na "Podešavanje verzije objekata..."

Prilikom postavljanja verzije za svaku vrstu dokumenta i direktorija, možete odrediti:

• Ne verziju - vrijednost je postavljena na sve objekte prema zadanim postavkama;
• Verzija - vrijednost se koristi za konfiguriranje direktorija i dokumenata;
• Verzija prilikom knjiženja - vrijednost se koristi samo za dokumente.

Ako je odabrana opcija Verzija, svaki put kada se objekt promijeni, sljedeća verzija objekta će biti upisana u njegovu povijest verzija.

Ako dokument ima postavljen način Verzija na knjiženje, tada će prva verzija dokumenta biti zabilježena u historiji tek nakon prvog objavljivanja dokumenta. Nakon toga, verzije dokumenta će se snimati svaki put kada se objavljeni dokument snimi. Režim vam omogućava da ne kreirate verzije novih dokumenata koje korisnik nije dovršio, kako se ne bi povećala veličina sigurnosti informacija. Preporučujemo da ovu postavku primijenite na sve dokumente.

Versioniranje velikog broja objekata može dovesti do povećanja baze podataka zbog skladištenja njihovih verzija. Stoga se preporučuje selektivno korištenje ove funkcije.

Za pregled historije promjena objekata, otvorite Alati/Historija promjena objekata. Naredba je dostupna samo administratoru sistema i samo za one objekte koji imaju konfigurirano upravljanje verzijama. U obrascu koji se otvori odaberite objekt (u primjeru, ovo je narudžba kupca), odaberite verzije ovog objekta koje želite usporediti i kliknite na dugme „Uporedi verzije“.

Ova naredba će generirati Izvještaj o promjenama verzije objekta (kliknite na sliku za povećanje):

Zamislimo situaciju. Odgovorno lice za blagajnu upisalo je blagajnički dokument u dnevnik, popunilo parametre i obrađivalo ga. Vrijeme je prolazilo, a jednog dana glavni računovođa je iznenada pronašao nesklad između podataka kreiranog dokumenta i stvarne transakcije. Blagajnik kaže da je sve podatke uneo apsolutno tačno, a ostali računovodstveni radnici ili nemaju pristup dokumentu ili ubedljivo tvrde da nisu uključeni u promene. Ali činjenica je očigledna!..

Dakle, hajde da odgovorimo na pitanja "Kako pogledati nekoga ko je promenio dokument u 1C 8.2?", "Kako to pogledati u 1C?", "Kako saznati u 1C ko je promenio dokumente i kada?", "Kako saznati u 1C ko je promijenio knjiženje u dokumentu?" , "Kako vidjeti ko je promijenio dokument u 1C?"

Zapravo je prilično jednostavno. Program 1C: Računovodstvo ima ugrađen alat za evidentiranje radnji korisnika u bazi podataka.

Provjerimo njegov učinak na primjeru neovlaštenog obračuna plata za jednog od zaposlenih u organizaciji. Hajde da otvorimo dnevnik plata.

Dodajmo još jednog zaposlenog na posljednji obračunski dokument. Izračunat ćemo i obraditi dokument.

Čini se da je to to. Namjerno dodavanje na uplatu je neprimjetno uračunato, ostaje samo čekati da odgovorni računovođa generira dokument o uplati, primi „doplatu“ i možete u radnju po novu odjeću... Međutim, napadač ne treba žuriti.

Odgovoran računovođa ili GB, osjetivši da nešto nije u redu, vrlo lako može pogledati ko je šta i kada promijenio u dokumentu.

Da biste to učinili, otvorite stavku glavnog izbornika "Usluga", a zatim odaberite "Dnevnik registracije". Imajte na umu da je po defaultu opcija dnevnika omogućena. Međutim, ponekad, pogrešno vjerujući da će evidentiranje dovesti do loših performansi, neki administratori ga onemogućuju. Tako se gubi korisna funkcionalnost.

Pa hajde da otvorimo časopis.

Instaliranjem filtera na dokument, vidimo sve radnje koje se na njemu izvode.

One. koji korisnik, sa kog računara, u kom dokumentu i, najvažnije, šta je i kada urađeno.

Dakle, nema bijega od svevidećeg oka 1C kada se dokumenti mijenjaju.

Međutim, pošteno rečeno, vrijedno je napomenuti da je, unatoč svim mogućnostima dnevnika registracije, iskreno slabo informativan i pretrpan. Ako su vašoj kompaniji potrebni određeni detalji o promijenjenim vrijednostima detalja, možete koristiti razvoj () Ovaj razvoj ima skup najneophodnijih funkcija praćenja i izvještavanja za računovođu, ugrađenih u dnevnike dokumenata.

Kao primjer, prikazaćemo dnevnik gotovinskih dokumenata za konfiguraciju jednog od preduzeća koja su koristila ovaj razvoj. U polju "Odgovorni" vidimo nepromijenjenu vrijednost osobe koja je kreirala dokument, au polju "Promijenjeno" - nadimak korisnika 1C koji je napravio posljednje izmjene.

Osim toga, dostupne su informacije o određenim promjenama u detaljima dokumenta. Ko, kada, u kom dokumentu, sa čega na šta, sa kog kompjutera. Sve, sve do znaka.

Koristeći jednu od metoda koje smo razmotrili, računovođa koji ima pristup uvijek će moći ispravno identificirati korisnika 1C koji je izvršio najnovije izmjene u dokumentu baze podataka.

Ako imate bilo kakvih poteškoća, mi ćemo svakako pomoći.

Možete razgovarati o operaciji i postavljati pitanja o njoj na.

Ako imate pitanja o članku ili još uvijek postoje neriješeni problemi, o njima možete razgovarati na