1c tok dokumenata, osoba koja odobrava nije navedena. Automatizacija poslovnih procesa. Praćenje poslovnih procesa i njihova optimizacija pomoću 1C: Tok dokumenata

U vezi sa izdavanjem/ažuriranjem ovih proizvoda, kao i razvojem tehnologije web servisa, stručnjaci 1C implementirali su besprijekornu integraciju, 1C ERP i 1C upravljanje dokumentima (u daljem tekstu “DO”).

Ovaj članak će opisati ne samo šemu i konfiguraciju integracije, iako će to biti u potpunosti pokriveno, već će se razmotriti i nekoliko mogućih tipova integracije.

Za implementaciju ove interakcije između dva programa trebat će nam:

• 1C "DO" 2.0 (CORP verzije)

  Web server Apache.

Nema potrebe opisivati ​​instalaciju i konfiguraciju ovih softverskih proizvoda, prijeđimo direktno na konfiguraciju.

Dakle. Poslovni proces je sljedeći: potrebno je da se dogovorimo o kupoprodajnim ugovorima. Šema koordinacije će biti sljedeća:

Da bismo implementirali takvu šemu, dodaćemo korisnike u 1C ERP i 1C DO.

- Sigurnost

- Advokat

- Ekonomista

- Službenik

Sada idemo na podešavanje

Idemo na 1C DO u modu "Konfigurator" i objavimo našu bazu podataka na web serveru.

Naziv - adresa resursa, tj. http://localhost/DocCorp/

Imenik - Lokacija web usluge.

Provjeravamo rad.

Sada izvršimo podešavanja u 1C DO.

1) Kreirajte novu vrstu dokumenta: “Ugovor o prodaji”

Idite na “NSI i administracija” - “Vrste dokumenata”

Kreirajmo grupu dokumenata "Sporazumi"

Kreiranje novog pogleda

Idemo na karticu "Šabloni dokumenata" - "Detalji o dokumentu".

Kreirajmo folder za pohranjivanje svih kupoprodajnih ugovora na jednom mjestu.

Idite na “Proces Templates” i kreirajte novi predložak.

Otvorit će se obrazac za odabir predloška "Odobrenje", kreirajte mapu "Nestandardni procesi", a zatim kreirajte proces "Odobrenje prodajnog ugovora"

Snimimo proces.

Pređimo na subjekte procesa, jer Imamo uslovno rutiranje, koje zavisi od iznosa ugovora, potreban nam je objekat analize, napravimo ga.

Vratimo se na karticu "Postavke procesa" i dodajmo odobravaoce.

Zatim mijenjamo smjer rutiranja i postavljamo redoslijed koordinacije:

Sada postavimo catch adresiranje, kliknite na dugme „Uslovi korišćenja“. *(Samo u CORP verziji).

Kreirajmo novi uvjet usmjeravanja: iznos ugovora > 100.000 rub.

Dodijelimo ga "Tip dokumenta" - "Ugovor o prodaji".

Postavljanje 1C "TO" je završeno. Pređimo na postavljanje 1C: ERP-a.

Dodajmo korisnike, isto kao u 1C "DO"

U polje URL unesite web adresu servisa, označite potrebne okvire i nastavite sa podešavanjem integracije.

Naznačimo u postavkama s kojim dokumentom želimo povezati proces.

Ovo će biti "sporazum sa drugom stranom", objekat iz 1C "DO" - "Interni dokument"

Nakon odabira relacija, izvršit će se osnovno podešavanje povezanih objekata.

Potrebno je konfigurirati brojna polja.

Vrsta dokumenta u 1 “PRIJE” - “Ugovor o prodaji”

Kada se unese tip dokumenta, 1C ERP ga traži u 1C “DO”.

“Folder” - “Ugovori o prodaji” (mesto skladištenja dokumenata)

"Matični broj"

Podrazumevani sistem kaže da je ovo "Kod", ovo je netačno, hajde da promenimo vrednost.

Ovo je naš broj ugovora.

Konfigurirajmo preostala polja

To je sve - Sačuvajte postavku.

Kreirajmo kupoprodajni ugovor u 1C ERP, kreirat ćemo ga pod korisnikom "Službenik"

Sada kreirajmo 1C "DO" proces na osnovu ovog sporazuma. Kliknite na „Više“ u obrascu liste

U 1C DO kreira se interni dokument „Ugovor o prodaji“.

"Naziv" koji odgovara podacima iz 1C ERP-a. Sistem nas odmah traži da odaberemo predložak procesa. Odaberite “Ugovor o kupoprodajnom ugovoru” i kliknite “Kreiraj proces”. Za sada nećemo instalirati potvrdni okvir “Pokreni odmah”.

Iznos našeg ugovora je > 100.000 rubalja, stoga je naše pravilo rutiranja funkcioniralo, dodat je “Ekonomist”.

Započnimo proces.

Sada se prijavimo u 1C ERP pod različitim korisnicima i vidimo rezultat. Kada se korisnik prvi put prijavi u 1C ERP, ako je konfigurirana integracija sa 1C “DO”, od korisnika će biti zatraženo da unese prijavu i lozinku za povezivanje na “DO”.

Onda idemo u The Economist

On nema zadataka, jer... njegovo odobrenje dolazi nakon “Advoka”, mi ćemo se dogovoriti o dogovoru od “Advokata” i ažurirati zadatke “Ekonomista”

Naš ugovor je prešao u status “Važeći”.

Mala digresija. Ovo je primjer integracije od 1C ERP u 1C DO. Ali, po mom mišljenju, postoji niz nedostataka ne u samoj integraciji, već u organizaciji poslovnog procesa. Recimo da imamo veliki protok dokumenata o kupoprodajnim ugovorima sa ugovornim stranama, svi ugovori prolaze kroz proceduru odobravanja. Stoga svaki put ugovor mora biti upisan u 1C: ERP. Ali ugovor možda neće biti odobren, tada će „smeće“ ostati u bazi podataka, da ne kažem da će to uvelike uticati na rad sistema, ali ipak.

Ali postoji prilika za proširenje odnosa. “Službenik službenika” kreira interni dokument “Ugovor o prodaji” u 1C “DO”, dokument prolazi kroz faze odobravanja, zatim, kada bude odobren, “Službenik službenika” unosi već odobrene podatke u 1C ERP i postavlja odnos između objekta u 1C ERP i 1C “DO”.

U 1C DO napravićemo interni dokument „Ugovor o prodaji“

Registriramo ugovor i šaljemo ga koristeći obrazac odobrenja koji smo kreirali.

Mala nepreciznost na snimku ekrana je kasnije naveden kao 1.500 rubalja.

Odredio sam iznos ugovora na 1.500 rubalja, tako da Economist ne treba da daje odobrenja.

Pređimo na 1C ERP.

Kao što vidite, čak i bez kreiranja dokumenta u 1C ERP sa besprekornom integracijom, svi korisnički procesi u 1C „PRIJE” se prikazuju u 1C ERP.

Nakon što su završene sve procedure odobravanja i dogovoren ugovor, potrebno je samo da ga unesete u 1C ERP bazu podataka i uspostavite vezu.

Unosimo naš ugovor u 1C ERP i uspostavljamo vezu sa dogovorenim objektom od 1C “DO”

Idite na "Tok dokumenata" ovog dokumenta i odaberite "interni dokument" 1C DO.

Pretraživanje se odvija prema odabranim kriterijima na strani 1C "DO".

Sada smo konfigurisali vezu između dva objekta.

U isto vrijeme, nismo kreirali nepotrebne dokumente u 1C ERP-u, cijeli proces odobravanja odvijao se na strani ERP-a (pomoću 1C DO alata). I primljena je veza između 2 objekta iz različitih baza.

To je sve za ovo. Koje metode odabrati ovisi o vašim potrebama, odlučite sami.

PS. Prilikom integracije sa 1C ERP-om, preporučio bih postavljanje planova za razmjenu strukture poduzeća, partnera, korisnika i DDS artikala. Ovo će smanjiti smetnje u 1C DO sistemu i imati ažurne informacije za ugovorno računovodstvo.

3 Operativno planiranje i činjenice. DS pokret.

3.1 Rezervacija budžeta

Kao što je ranije spomenuto, DDS ograničenja po budžetu (DDS poslovni planovi)se često može specificirati (na primjer, iznos za stavku može biti detaljan od strane druge strane, od strane dodatnih analitičara, na primjer, događaja, itd.).

Postavljanje DS limita u operativnoj konturi vršiće se dokumentom „Rezervacija budžeta“.Takve dokumente je pogodno unositi na osnovu DDS poslovnih planova. Istovremeno, postavljanje i kontrola limita će se vršiti u kontekstu unaprijed definisanog scenarija – „rezerva“.

I dalje, tokom operativnog planiranja rashoda DS (u trenutku podnošenja zahteva za isplatu), program će proveriti trenutna operativna stanja prema limitima. A ako je granica prekoračena, program neće dozvoliti takvu aplikaciju i biće izdato odgovarajuće upozorenje.

Da biste omogućili zabranu knjiženja dokumenata kada je ograničenje prekoračeno, idite na odjeljak „Opšti imenici i postavke/Podešavanje parametara/Trezor”.

Postavićemo i zastavicu „Zabraniti direktno kreiranje naloga za plaćanje na osnovu aplikacija, zaobilazeći registar plaćanja“.Ova funkcionalnost će biti potrebna, jer će naš zadatak nužno uključivati ​​registar plaćanja (registar će nužno formirati i odobriti glavni računovođa).

Dakle, ulazimo u dokumente Rezervacije budžeta za period - septembar 2017.

Obratimo pažnju na sljedeće tačke:

• 
  Nećemo kreirati rutu odobrenja za dokument „Rezervacija budžeta“. Postavite znak "Izvan rute" i status "Odobreno"

• 
  Organizaciju ćemo označiti kao “MSK UK (Funkcije upravljanja)”, dok će CFO ostaviti vrijednost koja je naznačena u poslovnom planu.

3.2 Putevi za odobravanje zahtjeva za plaćanje dobavljaču

U sklopu zadatka koji rješavamo osigurat ćemo odobrenje zahtjeva za plaćanje dobavljaču duž rute odobrenja.Dakle, zahtjev za plaćanje će automatski biti poslat “kroz lanac sporazuma”, od kojih će svaki morati da odobri (ili odbije u svojoj fazi) prijavu.

Svaki sagovornik će „sa svoje strane“ provjeriti potrebu za odobrenjem aplikacije. Na primjer, osoba odgovorna za kupovinu -će provjeriti ispravnost uslova ugovora, blagajnik će se pobrinuti da nema gotovinskog jaza (i po potrebi izvršiti balansiranje u kalendaru plaćanja), finansijski. direktor će dati konačnu saglasnost na prijavu itd.

Istovremeno, sistem će automatski odrediti potrebu slanja aplikacije određenim sagovornicima (u našem primjeru uslovi će biti konfigurisani u zavisnosti od DDS članka u aplikaciji). također, Postavljanje uslova se može obaviti vrlo fleksibilno i svi ostali podaci iz aplikacije se mogu provjeriti.

Idemo na odjeljak "Procesi i odobrenja/Šabloni procesa".

Kreirajmo novi šablon - “Proces odobravanja zahtjeva za plaćanje”. Naznačit ćemo „Put odobrenja“ kao svrhu procesa. Tippredmet odobrenja – “Zahtjev za rad”.

Kreirajmo sljedeću rutu odobrenja:

Uslovi odabira rute se konfigurišu u posebnom konstruktoru.One. Uvijek možete konfigurirati - kada su uvjeti (ili grupe uvjeta) ispunjeni, koje radnje treba izvršiti i na koje faze odobravanja program treba nastaviti.

Da biste provjerili kako će uvjeti rutiranja funkcionirati ovisno o parametrima zahtjeva, funkcija „Prikaži“ je osigurana u provjeri rute.

Faza „Obaveštenje“ može delovati kao posebna faza (mrežni dijagram procesa).

Odnosno, kada se pređe u ovu fazu, sistem će moći da generiše zasebno upozorenje za korisnika.

Shodno tome, faza „Obaveštenje“ može biti uključena u dijagram procesne mreže.

Da biste konfigurirali sadržaj upozorenja, trebate konfigurirati predložak upozorenja:

Pored toga, sistem obezbeđuje automatski generiranje upozorenja u vezi s pojavom raznih događaja. Evo liste ponuđenih kategorija događaja:

Na taj način, na primjer, možete konfigurirati generiranje upozorenja kada će se prilikom prelaska na svaku od faza odobrenja automatski generirati upozorenja o tome.

One. davalac odobrenja će uvijek primati obavještenja, vidjeti o kojim fazama trenutno treba da se dogovori i moći će dovršiti odobrenje direktno iz dnevnika „Moji zadaci i upozorenja“.

Da biste omogućili generiranje upozorenja o događajima,trebate otići na odjeljak “Procesi i odobrenja/Postavke upozorenja” i dodajte ovaj unos:

I na kraju Nakon što je predložak procesa odobravanja u potpunosti konfigurisan, potrebno je da navedete ovaj predložak u propisima o izvještavanju. U našem primjeru, U uredbi „Utvrđivanje i kontrola DDS limita“ se zahtijeva da se uspostavi matrica nadležnih za odobravanje kopija izvještaja – da se u njoj navede obrazac za proces odobravanja.

Za dokument Zahtjev za rad navedite obrazac procesa „Proces odobravanja zahtjeva za plaćanje“.

3.3 Koordinacija zahtjeva za rutu

U sklopu zadatka koji rješavamo, generirat ćemo zahtjev za plaćanje i poslati ga na odobrenje.

Popunimo dokument Prijava za rad tipa „BDDS (Rashodna) poravnanja sa drugim ugovornim stranama“.

Da bismo provjerili kontrolu limita, u prijavi ćemo navesti iznos veći od predviđenog limitima.

Kada pokušamo da objavimo dokument, dobićemo poruku o prekoračenju ograničenja.

Ispravimo ovu situaciju pravilnim formiranjem aplikacije.Naznačićemo izvor ograničenja (dokument budžetske rezervacije) i naznačiti raspoloživi iznos.

Popunimo drugu stranu i ugovor;Idemo na karticu "Kontrola ograničenja".

Vidjet ćemo kakav je trenutni limit salda (uzimajući u obzir tekući rad) i koji je planirani limit.

Pogledajmo dokument i vidimo da li dokument dobija status "U toku odobrenja"

Kliknite na dugme "Napredak odobrenja" da otvorite rutu i vidite fazu u kojoj se aplikacija trenutno nalazi.

Trenutna faza je označena plavom bojom.

Sada da vidimo kako program implementira mehanizam za generiranje upozorenja i koje mogućnosti pruža saglasniku.

Idemo na odjeljak "Procesi i odobrenja/Moji zadaci i upozorenja".

Vidimo da se u sistemu generišu upozorenja.Upozorenja se generišu i po kategorijama događaja i prelaskom na pojedinačne faze procesa.

Bez napuštanja dnevnika obavještenja, odobravatelj može odobriti fazu, prenijeti fazu na zamjenika i dodijeliti dodatne odobravaoce.

Za dodatnu kontrolu nad aplikacijama, program pruža mogućnost konfigurisanja zabrane/dozvole plaćanja za posebno određene analitičare.

U rubrici “Planiranje i kontrola/Dozvole i zabrane plaćanja” napravićemo (na primjer) sljedeći unos.

Kada pokušamo da podnesemo takav zahtjev na odobrenje, dobijamo sljedeću poruku

To znači da iako aplikacija prolazi kontrolu limita, ona ne prolazi direktivu kontrole plaćanja.

Deaktivirajmo prethodno unesenu direktivu i pošaljemo aplikaciju na odobrenje.

Kliknite na dugme „Odobri dokument“ da biste nastavili sa odobrenjem u trenutnoj fazi.

Unećemo vizu (objašnjenje) i kliknuti na „Slažem se“.

Pretpostavimo da je u sljedećoj fazi odobravanja blagajnik vidio da u prijavi nije popunjena svrha plaćanja i smatrao je potrebnim da vrati zahtjev izvođaču (kako bi on popunio sva polja, kako treba). Za ove svrhe, predviđeno je dugme „Odbij“.

Program također pruža sljedeće korisne karakteristike u vezi prolaska putanje odobrenja:

• 
  Odbiti zahtjev za prethodni korak odobrenja;
• 
  Pošaljite aplikaciju na odobrenje dodatnim odobravaocima (tj., ako je potrebno, možete dodati odobravače na trenutnu rutu i preusmjeriti aplikaciju na njih).

3.4 Rad sa kalendarom plaćanja.

Dakle, trenutno su 2 zahtjeva za isplatu u fazi “koordinacije” sa blagajnikom.

Glavni zadatak blagajnika je kontrola mogućnosti plaćanja.Odnosno da, na primjer, ne nastane cash gap (treba procijeniti koliki je iznos planiran na tekućim računima u trenutku plaćanja). Takođe u U ove 2 aplikacije nisu definisani tekući računi (sa kojih će se vršiti uplata).

Sveukupno, blagajnik mora balansirati poziciju plaćanja (odrediti račun za plaćanje i pratiti datum plaćanja za gotovinske praznine).A ako se pokaže da nema dovoljno gotovine za planirani trenutak, onda blagajnik mora ili pomjeriti datum planirane uplate ili uzeti u obzir (dodatno planirati) gotovinu c za prijem, ili odgoditi prijavu zbog nemogućnosti plaćanja (premjestiti na stop listu). Sve ove funkcije, kao i funkcija razdvajanja jedna aplikacija na više (kako bi se jedan iznos podijelio na nekoliko) i funkcija premještanja gotovine između računa - sve će to biti uzeto u obzir pri kasnijem radu s kalendarom plaćanja.

Također je važno spomenuti još jednu funkcionalnost za rad sa kalendarom plaćanja, a to je mogućnost spremanja različitih „opcija za razvoj događaja“.

Odnosno, blagajnik može modelirati, na primjer, situaciju br. 1 „dodatnog planiranja“ očekivanog prijema gotovineod klijenta i analizirati i sačuvati ovaj „scenarij“ događaja (ovu verziju kalendara plaćanja). Zatim simulirati situaciju br. 2, kada se nije desio očekivani prijem d/s, ali je potrebno zatvoriti manjak d/s. c kroz kretanje d/ c sa drugog tekućeg računa i djelimično pomjeriti datume plaćanja. Ukupno će biti moguće uporediti oba scenarija i odabrati najpovoljniji.

Funkcionalnost kalendara plaćanja u UH pruža bogate mogućnosti za blagajnika, pogledajmo sve ovo na primjerima.

Međutim, prije nego počnete raditi s kalendarom plaćanja, morate izvršiti sljedeće korake.

Konfigurirajte niz parametara za kalendar plaćanja:

• 
  Horizonti formiranja kalendara (broj dana);
• 
  Uzimati u obzir ili ne (1 ili 0, ili na primjer - 0,5 - onda "uzimamo pola u obzir") dokumente za prijavu (uključujući one koji nisu odobreni, one koji su u procesu odobravanja) prilikom formiranja kalendara plaćanja .
  • 
    One. Ako postavite "1" svuda za neodobrene aplikacije, tada će sve neodobrene (ali u procesu odobravanja) aplikacije biti u potpunosti uzete u obzir od strane programa prilikom generiranja kalendara plaćanja.

    Drugim riječima, to znači da će program sagledati planirane datume plaćanja i iznose za ove aplikacije, te u skladu s tim ove podatke uključiti u kalendar i izračunati planirana stanja gotovine na tekućim računima, uzimajući u obzir očekivana plaćanja po takvim aplikacijama.

Registrirajte setrenutna početna stanja:

Da biste izračunali kalendar plaćanja u programu, morate registrirati početna stanja d/c. Obavezno tako da se početna stanja registruju u akumulacionom registru „Gotovina“. Istovremeno, stvarno kretanje (dolazak/odlazak) d/ c takođe treba da se odrazi u ovom registru.

Registracija početnih stanjavrši se izradom dokumenta „Kreiranje početnih stanja”. pri čemu, Ovaj dokument se, naravno, može popuniti automatski, prema računovodstvenim podacima. računovodstvo ( m .e prema tekućem računu 51).

Dakle, registrujemo početna stanja 2 pravna lica. fizičkih lica i njihovih bankovnih računa.

Stvarna primanja/otpušavanja d/s će se odraziti u programu kroz dokumente „Odraz stvarnih budžetskih podataka“.Takvi dokumenti će se automatski generisati u programu u trenutku kada se ta činjenica prikaže. kretanje knjigovodstvenih dokumenata d/c (priznanice/otpisi d/ c po računu). Ovo ponašanje sistema je određeno ovim postavkama:

Idemo na odjeljak "Planiranje i kontrola/Kalendar plaćanja".

Postavimo sljedeće ključne parametre:

• Uspostavićemo grupisanje: po organizaciji i bankovnom računu;
• Postavljamo period: od tekućeg datuma do kraja tekućeg mjeseca;

Izbor po organizaciji: uspostavićemo konsolidacijom grupe MSC Energy +

Mi ćemo generisati kalendar plaćanja (kalendar će biti generisan od trenutnog datuma do kraja meseca).

Videćemo da kalendar uključuje početna stanja za dva tekuća računa,planirana kretanja troškova d/c (isplata dva zahtjeva za isplatu, dospijeće sutra).

Crvena boja znači da imamo gotovinski jaz na računu „Nije definisan bankovni račun“. Ovo se dogodilo jer račun za plaćanje nije definiran u aplikacijama.

• Promijenimo broj odabranih narudžbi. Postavimo račun – VTB 24.

• 
  Kao rezultat, dobijamo da je „bankovni račun nije definisan“ isključen iz kalendara, međutim od 05.09. postoji gotovinski jaz u iznosu od 4000. Poenta je da su planirani troškovi (34 hiljade rubalja u ukupno za 2 prijave) premašuje stanje d/c na računu.

• Koristeći funkciju „odloženo/odloženo“, možete odgoditi aplikaciju na neko vrijeme (premjestiti je na stop listu). Zatim ga vratite iz odgode.

• Rezultirajuća verzija kalendara se može sačuvati. A onda otvorite, uporedite i izaberite povoljnije scenarije za razvoj situacije u vezi kretanja d/s.

• Možete pomjeriti datum plaćanja za prijave na određeni rok

Također možete zatvoriti gotovinske praznine, na primjer, putem gotovinskih transfera unutar grupe(sa računa jedne organizacije na račun druge organizacije). U ove svrhe je obezbeđena aplikacija za unutrašnje kretanje.

Možete brzo planirati i troškove i očekivane prihode. To mogu biti transakcije kao što su primanja od klijenata i očekivana primanja iz drugih transakcija.

3.5 Formiranje registra plaćanja.

Nakon što je odobrenje prijava završeno, one se mogu uključiti u registar plaćanja.

U našem primjeru, glavni računovođa kreira i održava registar u statusu „Odobreno“.

Nalozi za plaćanje se generišu pomoću dugmeta „Generiraj naloge za plaćanje“.

3.6 Odraz činjenica, distribucija izjava analitičarima budžeta.

Nakon preuzimanja od banke klijenta po zaduženju sa tekućeg računa, dokumenti će se učitati u program"Zaduženja sa tekućeg računa."

Napominjemo da će program nakon zaduženja sa tekućeg računa automatski generirati dokumente „Odraz stvarnih podataka“.

Svrha dokumenata “Odraz činjeničnih podataka” je da odraze činjenicu troška u budžetu i registrima tokova gotovine. Stvarna potrošnja d/c se također uzima u obzir u kalendaru plaćanja za određivanje tekućih stanja c.

Nakon učitavanja bankovnog izvoda, program se može koristiti za njegovu distribuciju među analitičarima planiranja.

Takav algoritam se može konfigurirati u obradi „Distribucija bankovnih izvoda među analitičarima planiranja“.Popunjavanje će se vršiti na osnovu predložaka za analizu. Program može kreirati mnogo šablona za punjenje.

Evo primjera predloška koji postavlja analitičku vrijednost “Projekt”. Šablon (pravilo) radi za sve organizacije i izvođače. Istovremeno se provjerava sadržaj svrhe plaćanja.Odnosno, ako polje „Svrha plaćanja“ sadrži kombinaciju riječi „Glavni ugovor“, tada se u ovom slučaju analitika „Glavni projekat“ instalira u polje projekta.

Na taj način možete organizirati druge algoritme za prepoznavanje svrhe plaćanja i, shodno tome, popunjavanje polja tsfo , DDS članak, analitičar itd.

Podsistem je pogodan za one koji

• Umoran sam od ljudi koji s vremena na vrijeme trče po kancelarijama samo zbog potpisa;
• potrebno je vidjeti: ko, kada i kako je odobrio ovaj ili onaj objekt u bazi podataka 1C;
• potrebno je smanjiti vrijeme odobravanja (ugovora, zahtjeva za trošenje sredstava ili bilo čega drugog).

Program vam omogućava koordinaciju svih dokumenata i referentnih knjiga u bazi podataka 1C. Koordinacija se odvija sekvencijalno, tj. Prvo se slaže prvi recenzent, ako se slaže, onda sljedeći, i tako dalje.

Postoje sljedeći statusi:

• "Nije odobreno"
• “U procesu odobravanja”,
• "Odobreno"
• "Otkazano"
• “Vraćeno na reviziju.”

Prilikom kreiranja zadataka za recenzente ne precizira se određeni korisnik, već se popunjava samo Addressing Role + Addressing Department. Pretpostavimo da se moramo složiti

Tada će biti kreiran zadatak za računovođu iz računovodstva. I određeni korisnici moraju biti navedeni u registru „Registar adresa“.

Tako će zadatak za odobrenje vidjeti dva korisnika odjednom i svaki od njih može izvršiti zadatak. Ovo je posebno korisno kada jedan zaposlenik ide na godišnji odmor i trebate navesti korisnika koji ga zamjenjuje. U tom slučaju dovoljno je dodati novi unos u registar adresa i svi stari i svi novi zadaci će odmah biti vidljivi novom korisniku.

Prednosti

• potpuno otvoreni izvor;
• nezavisna konfiguracija;
• nezavisno od BSP-a (za nestandardne konfiguracije ovo je važno);
• može se ugraditi u bilo koju konfiguraciju (pogledajte listu testiranih konfiguracija ispod);
• radi u tankom klijentu (takođe radi u redovnoj aplikaciji);
• Za postavljanje nove koordinacije nije potrebno programiranje, sve se radi u runtime modu;
• vrlo jednostavno postavljanje novog ugovora, potrebno je samo proći kroz 4 koraka i ugovor se može koristiti;
• možete postaviti odobrenja za bilo koji direktorij i bilo koji dokument u bazi podataka 1c;
• slanje obavještenja putem e-pošte;
• značajno smanjenje vremena odobrenja, a često se vrijeme odobrenja značajno smanjuje;
• uvek je jasno ko mora da odobri, kao i ko je to odobrio i kada;
• mogućnost zabrane izvršenja dokumenta dok se ne dogovori;
• mogućnost zabrane upotrebe objekta baze podataka dok se ne dogovori;
• lako se integrirati u druge poslovne procese u 1C;
• nema potrebe za posebnom bazom podataka u kojoj se odvija koordinacija, sve se dešava u jednoj bazi podataka.

Video

• Postavljanje novog sporazuma

• pregled odgovarajućeg podsistema

• kako integrirati podsistem u standardnu ​​konfiguraciju

• Kako postaviti račun za slanje obavještenja:

Podsistem je u potpunosti implementiran u upravljanim oblicima i radi u tankom klijentu.

Primjeri korištenja podsistema

Primjer 1

Neophodno je da se odobri zahtjev za utroškom sredstava prije nego što se može izvršiti. U tom slučaju potrebna je sljedeća ruta koordinacije:

• uvijek koordinirati sa “menadžerom nabavke”;
• ako je iznos prijave veći od 10.000, dogovorite se sa komercijalnim direktorom;
• ako je iznos prijave veći od 50.000, dogovorite se sa finansijskim direktorom;
• ako je iznos prijave veći od 100.000, onda se dogovorite sa generalnim direktorom.

Primjer 2

Svi korisnici mogu kreirati ugovore u sistemu potrebno je podesiti odobrenje ugovora koristeći sljedeću rutu:

• ako druga strana/partner pripada grupi dobavljača, potrebno je da se dogovorite sa „računovođom dobavljača“;
• ako druga strana/partner spada u grupu kupaca, potrebno je da se dogovorite sa „Računovođom kupaca“;
• uvijek provjerite sa advokatom;
• ako je ugovor u konvencionalnim jedinicama, onda se dogovorite sa komercijalnim direktorom;

Često postavljana pitanja (FAQ)

Pitanje: Da li je moguće integrirati podsistem u nestandardnu ​​konfiguraciju?

odgovor: Da, možete, za to je potrebno da konačna konfiguracija sadrži sljedeće:

• Directory.Users;
• Parametar sesije "CurrentUser";
• Konfiguracija mora imati svojstvo “Upravljana aplikacija” ili svojstvo “Upravljane i obične aplikacije”, jer svi oblici su kontrolisani.

Pitanje: Da li je moguće pozvati obrazac “Statusi odobrenja” direktno iz elementa direktorija ili dokumenta?

odgovor: da, možeš. Ako koristite upravljane forme onda morate:

• idite na konfigurator;
• pronađite opštu naredbu “bpsStatusConcordance”;
• kliknite desnim tasterom miša i izaberite svojstvo;
• u svojstvu “Command Parameter Type” navedite kompozitni tip podataka i odaberite željeni objekt.

Ako koristite regularne forme i standardnu ​​konfiguraciju, tada trebate:

• preuzeti iz isporuke obradu “bpsStatusCoordination.epf”;
• Kliknite na "Usluga - Dodatne forme za štampanje i obrada - Štampanje formulara"
• kliknite na dodaj, a zatim navedite obradu;
• dodati u sekciju tabele one objekte za koje treba pozvati ovu obradu;
• Sada će dugme za štampanje moći da pozove ovu obradu.

Ako koristite obične forme i konfiguracija nije standardna, tada morate ručno umetnuti kod u svaki oblik direktorija/dokumenta, primjer koda se može naći u obradi “Primjer koda za dodavanje gumba u normalu Form.epf” (iz ponude).

Pitanje: Da li je moguće odrediti status, recimo "Plaćeno" za dokument?

odgovor: Da, možete, za ovo vam je potrebno:

• idite u direktorij “Statusi objekata” i dodajte element s imenom “Paid”, zapišite ga i zatvorite;
• zatim otvorite obradu “Statusi odobrenja”, kliknite na dugme “Postavi status” i odaberite status “Plaćeno”.

Uloge

• (BPS) Korisnik- mora biti specificirano za sve korisnike;
• (BPS) Uređivanje registra adresiranja- potrebno je pravo na uređivanje registra „Registar adresa“;
• (BPS) Uređivanje dokumenata, registracija statusa objekta- pravo je neophodno kako biste ručno mogli odrediti status za 1c objekt;
• (BPS) Puna prava- pristup svim objektima koordinacionog podsistema, a neophodan je i za uspostavljanje koordinacije.

Šta se dešava automatski

• obavijesti se šalju prema rasporedu (jednom u minuti);

Šta se planira dodati u budućnosti ako podsistem bude uspješan

• mogućnost preusmjeravanja zadatka odobrenja drugom recenzentu;
• mogućnost prilagođavanja šablona za generisanje teksta objašnjenja, koji je naznačen pri pokretanju odobrenja i slanju obavještenja putem e-pošte (na primjer: u obrazloženje uključiti valutu dokumenta, menadžera, iznos itd.);
• mogućnost pristanka putem pisma odgovora, bez prijave u 1C;
• tako da se jedinica adresiranja automatski bira iz zaglavlja dokumenta/imenika, a ne „rigidno“ naznačena u predmetu odobrenja;
• mogućnost korištenja podsistema „Koordinacija“ u konfiguracijama gdje je omogućeno ograničenje pristupa na nivou zapisa;
• zabrana korištenja elementa imenika dok se ne dogovori.

Razvoj se vrši na Bitbucket-u (za sada zatvoreno spremište), glavna funkcionalnost podsistema je pokrivena testovima pomoću xUnitFor1c().

Testiranje prijenosa na standardne konfiguracije

Testiranje je obavljeno na platformi: 8.3.8.1652

Konfiguracija

Rezultati testa

Poslovni proces je stabilan slijed radnji zaposlenih u organizaciji. Automatizacija takvih sekvenci pojednostavljuje rad i značajno ubrzava završetak završnog zadatka.

U programu 1C: Document Flow 8 implementiraju se sljedeće vrste poslovnih procesa:

• Razmatranje: dokument se dostavlja rukovodiocu na razmatranje i njegovim rješenjem se vraća autoru dokumenta.
• Izvođenje: dokument se prenosi na izvršenje svim korisnicima na listi i kontroloru radi održavanja discipline izvršenja. Za odgovornog izvršioca može se imenovati jedan od korisnika.
• koordinacija: dokumenti priloženi takvom poslovnom procesu dostavljaju se na odobrenje navedenim ispitanicima, a zatim se vraćaju autoru poslovnog procesa na pregled rezultata odobrenja ili slanje na ponovno odobrenje.
• izjava: dokument ide odgovornom licu na odobrenje i vraća se autoru dokumenta na pregled rezultata odobrenja.
• Registracija: dokument ide sekretaru da mu se dodijeli registarski broj, ovjeri pečatom organizacije i pošalje dopisniku.
• Uvod: Koristeći ovaj poslovni proces, potreban dokument se šalje svim korisnicima na listi na pregled.
• Narudžba: Koristeći ovaj poslovni proces, možete izdati instrukcije zaposlenima i provjeriti njihovo izvršenje.

Svaki poslovni proces, kako napreduje kroz faze, kreira zadatke upućene određenim korisnicima. Na primjer, poslovni proces Red prvo će kreirati zadatak Dovršite zadatak za izvršioca, a nakon što izvršilac evidentira završetak ovog zadatka, zadatak Provjerite napredak za pokretača poslovnog procesa.

Zadatke možete dodijeliti ne samo određenim izvođačima, već i ulogama. Tako, na primjer, dokument se može poslati na odobrenje uloge Direktor, a program će automatski prenijeti odgovarajući zadatak na onoga koji trenutno obavlja ovu ulogu - samog direktora ili njegovog zamjenika. Zadatak se također može adresirati na korisnike identificirane sljedećim automatskim zamjenama:

• Svi rukovodioci autora poslovnog procesa,
• Svi podređeni autora poslovnog procesa,
• Neposredni rukovodilac autora dokumenta,
• Svi rukovodioci autora dokumenta.

Sastav uloga je jedinstven za svako preduzeće ili instituciju i može se menjati i konfigurisati bez zaustavljanja sistema. Kada se uloga izvršioca promijeni, zadaci se automatski prenose na radnu površinu novog izvršitelja.

Korisnik može u svakom trenutku pogledati listu zadataka koji su mu dodijeljeni na listi Moji zadaci. Lista se automatski učitava kada se program pokrene.

Dodatno, korisnik može primiti obavijest da završi zadatak putem e-pošte.

Za svaki poslovni proces program kreira karticu sa koje korisnik može pozvati vizualni dijagram toka poslovnog procesa. Izvršenje faza poslovnog procesa će se odraziti na dijagramu toka. Uz njegovu pomoć kreator poslovnog procesa može u svakom trenutku saznati u kojoj je fazi njegova implementacija i koji zaposleni su već obavili svoj zadatak, a ko nisu. Ispod je kartica i tipičan dijagram toka poslovnog procesa Koordinacija.

Na osnovu ovog dokumenta može se kreirati novi poslovni proces povezan sa određenim dokumentom. Za svaku vrstu poslovnog procesa, program daje posebnu listu, na primjer, listu odobrenja:

Za svaki tip poslovnog procesa možete konfigurirati predložak koji će se koristiti prilikom kreiranja novih poslovnih procesa. Predložak poslovnog procesa sadrži informacije kao što su:

• usmjeravanje,
• rokovi,
• važnost,
• ime,
• opis i drugo.

Na primjer, predložak poslovnog procesa Usklađivanje ugovora može izgledati ovako:

U kartici tipa dokumenta možete navesti listu predložaka poslovnih procesa povezanih s njom. Ova lista će se automatski koristiti prilikom kreiranja novih poslovnih procesa na osnovu dokumenata ove vrste. U datom primjeru, tip dolaznog dokumenta je Sporazum vezano za gornji šablon Usklađivanje ugovora i još dva šablona - Odobrenje ugovora (jednostavno) I Registracija ugovora:

Prilikom kreiranja poslovnog procesa na osnovu bilo kojeg dolaznog dokumenta tog tipa Sporazum korisnik će moći da izabere odgovarajući šablon sa ove liste.

Pozivamo vas da razmotrite primjer. Marketinški stručnjak ili stručnjak iz odjela za planiranje postavlja cijene za robu. U ovoj kompaniji politiku cijena odobrava menadžment, a proces usvajanja cijene uključuje niz međusobno povezanih radnji. Kako uspostaviti proces određivanja cijena u standardnom programu?

Već smo govorili o poslovnim procesima u standardnom rješenju 1C: Upravljanje trgovinom 8, kao funkcionalnosti koja pomaže kombiniranju niza operacija u strogo definiran slijed radnji. Kao rezultat toga, rad zaposlenih u kompaniji zasniva se na jasno definisanom algoritmu.

Prethodno konfigurisanje procesa pregovaranja o cijeni

• Uspostavljanje procesa dogovaranja cijena u programu 1C: Upravljanje trgovinom 8 počinje omogućavanjem odgovarajuće opcije.
• Zatim morate provjeriti “Profili pristupa” svih korisnika koji su uključeni u određivanje cijena. U našem primjeru cijene postavlja marketer, nakon čega ih odobrava menadžment, pa provjeravamo: uloga „Postavljanje cijena artikala bez odobrenja“ mora biti onemogućena u njegovom profilu.
• Na kraju, potrebno je dodati korisnike koji odobravaju konačne cijene. Da biste to učinili, potrebno je otići u imenik „Uloge i izvršioci poslovnih procesa“ i dodijeliti odgovornom rukovodiocu ulogu „Koordinator određivanja cijena artikala“.

Kako funkcionira poslovni proces pregovaranja o cijeni?

Princip rada mehanizma pregovaranja o cijeni korištenjem poslovnih procesa je sljedeći. Naš marketer, proučivši situaciju na prodajnom tržištu, dolazi do zaključka da se za neke artikle iz asortimana mogu povećati cijene. U standardnom rešenju 1C: Upravljanje trgovinom 8 cijene se utvrđuju pomoću dokumenta „Postavljanje cijena artikala“. Međutim, da bi promjene cijene stupile na snagu, ovaj dokument mora imati status „Odobreno“. Naš marketer nema pravo da menja status dokumenta, pa će za promenu cena morati da koristi poslovni proces „Odobravanje cene“.

Pretpostavimo da menadžer vjeruje da se cijene mogu još više podići.

• U tom slučaju treba da popuni polje „Rezultat izvršenja zadatka“, dajući svoje predloge i klikne na dugme „Nije dogovoreno“.
• U tom slučaju marketer dobiva obavijest o donesenoj odluci u kojoj se može upoznati sa željama menadžera.
• Zatim marketer klikne na dugme „Upoznati“ i završava poslovni proces. Sada marketer mora revidirati cijene u skladu sa prijedlozima menadžera i kreirati novi poslovni proces.
• Menadžer se još jednom upoznaje sa promijenjenim cijenama i dogovara ih. U tom slučaju, dokument „Određivanje cijena artikala“ koji je kreirao marketinški stručnjak dobiva status „Dogovoren“ i objavljuje se u programu.

Menadžer ima sve pod kontrolom

Na kartici „Odobrenje“ menadžer može pratiti cijeli proces odobravanja određenog dokumenta o promjenama cijena.

Sav rad na svakom takvom dokumentu pohranjen je u programu na jednom mjestu, što omogućava procjenu efikasnosti rada marketera.

U zaključku, želio bih napomenuti da korištenje poslovnog procesa „Ugovor o cijenama“ omogućava vam da pojednostavite proces određivanja cijena, poboljšavajući kvalitetu upravljanja osobljem i kontrolu nad njima.