1s revizija poduzeća

Trebate li proširiti funkcionalnost 1C? Trebate li program za rješavanje ne samo tipičnih, već i specifičnih zadataka vašeg poduzeća? Usluga poboljšanja 1C tvrtke Active-IT pomoći će vam da brzo riješite ove probleme.

Vršimo poboljšanja tipičnih 1C konfiguracija bilo koje razine složenosti: od izrade individualnih tiskani obrasci prije uvođenja algoritma za obračun bonusa za sate rada i sl.

Vrijeme obrade- do 5 dana. U slučaju kašnjenja do 10 dana, izvršit ćemo reviziju za vas besplatno.

Još jedna prednost rada s nama je ta što svoj posao uvijek radimo u dobroj vjeri. Ne radimo po shemi “primio projektni zadatak ==> obavio posao ==> predao i zaboravio”. Dobivamo tehnički zadatak, kvalitetno obavljamo svoj posao, puštamo Vas da ocijenite rezultat i po potrebi ispravite reviziju bez dodatnih troškova.

Trošak programera 1C

Cijena konfiguracije: 1500 rub. po satu programera.

Kao rezultat dobivate:

• Suradnja s iskusnim programerima.
• Izrada i implementacija poboljšanja apsolutno bilo koje razine složenosti.
• Obavljanje posla u čim prije- do 5 dana.
• Garancija povrata novca u slučaju kašnjenja.
• Osiguranje kvalitete.

Naručite poboljšanja 1C računovodstva od Active-IT-a!
S nama prilagodite rad 1C specifičnostima Vaše tvrtke.

Razvijen od strane cijelih odjela visokokvalificiranih stručnjaka tvrtke "1C" standardnih i industrijskih konfiguracija dizajniranih za poslovno računovodstvo, kao i podnošenje računovodstvenih i poreznih izvješća. Izradili programeri nastavna sredstva a ispada tehnološko i konzultantska podrška svoje programe već više od desetak godina, temeljene na normama i preporukama zakonodavstva Ruske Federacije.

Čini se da je sve već predviđeno u programima: sve vrste dokumenata, imenika, registara, mehanizama za rad s njima, prikladnih korisničkih sučelja, demo konfiguracija s ispunjenim podacima kao stvarni primjeri vođenje evidencije.

Tipične konfiguracije su napisane za tipične račune i usmjerene su na neku prosječnu i gotovo idealnu organizaciju.

U stvarnom životu poslovno računovodstvo može imati prilično složene i nestandardne situacije. Računovođe i stručnjaci žele vidjeti ovo ili ono izvješće u malo izmijenjenom obliku, a redovita mogućnost prijenosa informacijskih podataka iz jednog programa u drugi (na primjer, od računovodstva do trgovine ili od plaće do računovodstva) ne uzima u obzir sve specifičnosti organizacije.

U takvim slučajevima će u pomoć priskočiti oni koji razumiju strukturu konfiguracije, mogućnosti sustava, njegove specifične mehanizme i znaju kako učinkovito primijeniti te informacije u praksi. Oni će moći ne samo odabrati i, već i finalizirati 1C konfiguraciju, proširujući njezinu standardnu ​​funkcionalnost.

Prednosti modificirane konfiguracije

Kako bismo mogli napraviti i manje promjene (tiskani oblici dokumenata, izgled dokumenata i imenika) u standardnim aplikacijskim rješenjima baziranim na platformi 1C:Enterprise 7.7, bilo je potrebno ukloniti konfiguraciju iz podrške. Za platformu počevši od 8.0, ovaj problem je djelomično riješen: eksterni obrasci za ispis, izvješća i obrasci mogu se mijenjati ili ponovno kreirati bez promjene strukture konfiguracije, a upravljani obrasci platforme 8.3 pružaju još više mogućnosti.

Moduli aplikacijskih rješenja 1C:Enterprise otvoreni za promjene omogućuju vam da modificirate i prilagodite bilo koje aplikacijsko rješenje "za sebe". Finalizacija 1C programa pruža niz prednosti:

1. Prva i najvažnija stvar je da se softversko rješenje prilagođava zahtjevima određenog računovodstva u organizaciji.
2. Uz pomoć novorazvijenih prava i korisničkih uloga uvedenih u konfiguracijsku strukturu, moguće je fleksibilnije opisati dopuštene i zabranjene radnje pri radu s dokumentima i imenicima jednog ili grupe zaposlenika.
3. Postavljanje i promjena korisničkih sučelja (kod upravljanih aplikacija mnogo toga se implementira na standardni način).
4. Mogućnost promjene tiskanih oblika dokumenata, obrazaca i izvještaja.
5. Promjena mehanizama internih softverskih proračuna, postavljanje složenih proračuna, proizvodne formule, složena obračunska polja dokumenata itd.
6. Mogućnost promjene izgled dokumenti, dnevnici dokumenata, registri korisnika, elementi imenika.
7. Sposobnost dodavanja vizualnog prikaza objekata.

Za modificiranje primijenjenih rješenja nije potrebno koristiti posebne softverske proizvode - svi razvojni alati uključeni su u tehnološku platformu.

Nedostaci prilagodbe konfiguracija

Uz sve očite prednosti, usavršavanje tipičnih 1C konfiguracija za sobom povlači neke neugodne posljedice:

1. Uklonjeno iz tehničke podrške 1C radi mogućnosti dorade standardnog rješenja gubi mogućnost automatskog ažuriranja. Ako se nadogradnja ipak izvrši, tada će se sve promjene napravljene u arhitekturi konfiguracije izgubiti. Samo će kvalificirani stručnjak moći ažurirati program, koji će sva ručna poboljšanja prenijeti na ažuriranu verziju programa.
2. Vrlo često se događa da modificirane samopisne konfiguracijske mehanizme dalje implementiraju 1C programeri na redovit način i da su uključeni kao dio jednog od ažuriranja. Dakle, prethodno napravljene izmjene više nisu potrebne.
3. Svaki 1C programer, poput umjetnika, ima svoj stil: netko iskusniji piše kompetentnije i vještije, netko originalniji. Razumijevanje koda druge osobe, ako je potrebno, može biti vrlo teško, do te mjere da je brže napisati modul od nule nego mijenjati tuđi kod. Dakle, postoji određena veza za programera koji unosi promjene u program.
4. Kupac nema uvijek dovoljno kvalifikacija da izradi kompetentan tehnički zadatak za programera i jasno objasni kakav krajnji rezultat želi vidjeti. Kao rezultat toga, može doći do nesporazuma između dviju strana i potrebe za daljnjom prilagodbom narudžbe.

Često se događa da nesigurni korisnici softverskih rješenja 1C:Enterprise koji nisu proučili sve postavke, računovodstvene metode, mehanizme namire, koji nisu razumjeli postavke obrazaca za ispis i izvješća traže dovršetak konfiguracije. U takvim slučajevima, zadatak programera je identificirati moguće redovite načine rješavanja nastalih problematičnih problema, osposobiti korisnika za njihovu uporabu i izvršiti promjene u konfiguraciji samo u slučaju stvarno hitne potrebe.

Glavni konkurentska prednost softverskih proizvoda 1C 8.2 i 8.3 - mogućnost izmjene standardnih konfiguracija programa i razvoj najoptimalnijih rješenja za zahtjeve krajnjeg korisnika na glavnoj bazi 1C platforme.
Široka funkcionalnost implementira vlastiti programski jezik, kao i ugrađeno razvojno okruženje koje pruža fleksibilnost u postavkama.

Tvrtka 1C u interesu korisnika softver stvara rješenja po principu ključ u ruke, jednako sposoban zadovoljiti potrebe svake organizacije, uzimajući u obzir jedinstvenost i specifičnosti svakog poduzeća. Širok raspon dodataka osnovnoj konfiguraciji čini rad u 1C što ugodnijim.

Imate pitanje, trebate li pomoć konzultanta?

Koja su najčešća poboljšanja 1C?

Najčešća vrsta dorade je izmjena korisničkog sučelja. Dublje promjene u izradi i implementaciji posebnih algoritama u sustav su manje uobičajene, ali su također dostupne za implementaciju.

Primjeri izmjena 1C

1. Fleksibilna konfiguracija pristupa i korisničkih prava je možda najrelevantnija za svaki višekorisnički sustav. Također u 1C postoji mogućnost postavljanja zadanih vrijednosti, što značajno ubrzava radni proces.
2. Izrada i ispravljanje raznih tiskanih obrazaca, koji su u 1C analogni papirnatom dokumentu, kao i izvještaji, koji su konačni proizvod analize unesenih podataka u 1C programu. Ove izmjene ne zahtijevaju ozbiljne intervencije u konfiguraciji programa.
3. Izrada i prezentacija jasna i razumljiva projektni zadatak za 1C programera, što olakšava daljnje izmjene i omogućuje vam da uspješno uključite izvođače trećih strana u njegovu implementaciju.
4. 1C sustav je prilično svestran i u izvornoj verziji ne ispunjava uvijek sve zahtjeve krajnjeg korisnika, stoga često zahtijeva razvoj i implementaciju jedinstvene funkcionalnosti, prema željama klijenta.
5. Postavljanje performansi i brzine kako bi se osigurala maksimalna učinkovitost u obavljanju operacija namire

Trošak usluga stručnjaka za rad s 1C

Tvrtka 1C čvrsto je ukorijenjena u niši programa za automatizaciju aktivnosti poduzeća. " Računovodstvo poduzeća», « Upravljanje trgovinom», « platni spisak upravljanja osobljem" itd. – postali su zaštitni znakovi tvrtke i uspješno se koriste u malim i velikim poduzećima.

1C poboljšava svoj razvoj, ali uvijek će postojati klijent sa zadacima koji nisu pokriveni standardnom funkcionalnošću. Ovdje u igru ​​dolaze programeri trećih strana s dobrom idejom modificiranja tipičnog rješenja u skladu sa željama klijenta. Nažalost, ne donose sva poboljšanja dugoročnu radost. Konfiguracije prebačene do neprepoznatljivosti siguran su način da ostanete bez ažuriranja od dobavljača.

Zašto se ovo događa? Problem s profesionalnošću programera trećih strana ili nesavršenošću arhitekture standardnih rješenja? Po mom skromnom mišljenju, problemi postoje s obje strane: 1C ne promiče uvelike ispravne pristupe finaliziranju standardnih rješenja, a mnogi programeri radije rade na starinski način, bez gubljenja vremena na učenje novih značajki i čitanje "zamorne" dokumentacije.

Problem

Prije nego počnemo govoriti o rješenjima, izjasnimo se o problemu. Tipična rješenja ne mogu ispuniti sve "popis želja" tvrtke i jedini način da ih implementirate je da kontaktirate treće strane / interne programere. Ako Popis želja utječe na tipične mehanizme (objekte, obrasce, algoritme), tada konfiguracija postaje neprikladna za automatsko ažuriranje.

Možete ga ažurirati, ali ćete to morati učiniti ručno i sva je prilika da nešto pokvarite. Kao rezultat toga, klijent dobiva: željenu funkcionalnost, probleme s ažuriranjem i ovisnost o programerima trećih strana (u nedostatku vlastitog razvojnog odjela). Mogućnost i cijena naknadnih ažuriranja ovisit će o tome koliko je ispravno osmislio rješenje problema.

Dokumentacija, alati

Nije važno koju konfiguraciju pokušavate podesiti, prva stvar koju treba svladati je proces dokumentacije. Bez toga, svi naknadni savjeti neće donijeti željeni učinak.

Sve promjene napravljene na bez greške treba zabilježiti u tracker/wiki/bazu podataka, itd. Dokumentacija napravljenih promjena trebala bi dopuniti informacije iz konfiguracijskog spremišta ili drugog sustava kontrole verzija. Dokumentaciju ne treba pisati radi dokumentacije, dokumente treba pravovremeno ažurirati.

Ako se ovaj zadatak izvrši i programeri/menadžeri rade s takvim dokumentima, tada se broj pogrešaka koje se javljaju u procesu ažuriranja verzija konfiguracija kod dobavljača značajno smanjuje.

U stvarnosti, razvoj rješenja za 1C platformu još nije razvio punopravnu razvojnu kulturu. Ne koriste svi programeri specijalizirane alate koji pojednostavljuju pregled koda, dokumentaciju itd. Želite li stvoriti rješenja koja su lakša za podršku i održavanje? Počnite se upoznavati s razvojnim praksama koje ciljaju na druge platforme. Mnogi od njih su sasvim realni za uvlačenje u 1C.

Konfiguracija

Tvrtka 1C i programeri industrijskih rješenja svjesni su da je ili nerealno ili teško stvoriti univerzalno rješenje u kutiji koje je potpuno spremno za rad. Dovođenje poslovnih procesa tvrtki do nekog zajedničkog nazivnika nemoguć je zadatak, a najfleksibilnije rješenje je pružiti mogućnost samokonfiguracije.

Nažalost, dokumentacija o mogućim postavkama nema uvijek vremena za sazrijevanje zajedno sa softverskim rješenjem. Kao rezultat toga, počinje izum bicikala: zadaci u nekoliko klikova često se provode u obliku štake, obilno impregnirane ne najkvalitetnijim kodom.

Trebate primjere štaka? Nema na čemu! Kupcu uvijek nedostaju polja u standardnim dokumentima/imenicima i želi dodati svoja. Lakše je ispuniti ovu želju bez otvaranja konfiguratora. Aktivirajte korištenje dodatnih (vidi sliku 1) u postavkama i zatim brzo kreirajte sva potrebna polja. Ovako stvoreni atributi ne utječu na konfiguraciju i prikladni su za korištenje u izvješćima, stoga praktički ni na koji način nisu inferiorni od izvornih.

Drugi čest primjer je stvaranje dodatnih tiskarskih obrazaca. Niti jedna standardna konfiguracija ne može klijentu osigurati sve potrebne tiskarske forme, pa se izrada nedostajućih prepušta vanjskim izvršiteljima.

Može se izraditi ista tiskarska forma različiti putevi: koristite mehanizam koji pruža BSP (biblioteka standardnih podsustava) ili upišite kod izravno u obrazac/upravljački modul određenog objekta. Rezultat će biti isti - klijent će dobiti ono što želi, ali podrška rješenja će se zakomplicirati.

Mnogo je loših primjera poboljšanja, jedan zaključak se nameće - proučite radni alat što detaljnije. Potražite zaobilazna rješenja i uđite u tipične mehanizme u slučajevima kada stvarno ne možete bez toga.

Moderna standardna rješenja savršeno su konfigurirana, a mnogi zadaci se učinkovito rješavaju bez otvaranja konfiguratora. Nemojte biti lijeni pratiti tehnološke inovacije na stranicama poput "Kroz ogledalo" i primjenjivati ​​ih, a ne rješenja "na čelo".

Vanjske tiskarske ploče

Tehnologija nije bazirana na platformi, već je implementirana korištenjem mogućnosti BSP-a (Knjižnica standardnih podsustava). Budući da su sva standardna rješenja izgrađena na temelju BSP-a, ne bi trebalo biti problema s podrškom.

Princip rada takve obrade je jednostavan. Programer kreira obradu u skladu s određenim predloškom. U njemu implementira niz metoda izvoza koji vam omogućuju da se registrirate u sustavu i aktivirate iz određenih objekata. Kao rezultat toga, uobičajena obrada postaje dio standardnog rješenja i dostupna je za pozivanje iz raznih objekata.

Pripremljeni primjer takve obrade možete preuzeti na web stranici časopisa. Obrada obrazaca sadrži priličnu količinu pozadinskog koda, tako da ćemo ovdje pokriti najzanimljivije stvari, a ostalo ćete naučiti iz izvornog koda. Primjer koji sam pripremio možete koristiti kao osnovu za izradu vlastitih tiskarskih obrazaca. Servisni kod je opisan u modulu za obradu.

Za izradu vanjskog tiskarskog obrasca potrebno je opisati tri uslužne funkcije: Pojedinosti o vanjskoj obradi», « Pečat», « OutputInformationOnDocument". Moraju biti u modulu za obradu, jer. kontaktirat će ih mehanizmi BSP-a.

Funkcija " Pojedinosti o vanjskoj obradi» opisuje strukturu s osnovnim informacijama za obradu. Navedeni podaci nužni su za uspješnu registraciju u mehanizmu eksternih tiskarskih obrazaca. Izravna registracija se događa dodavanjem elementa u imenik "Dodatna izvješća i obrada" (vidi sliku 2).

Posebnu pozornost treba obratiti na sljedeća svojstva:

• Niz zadataka. Sadrži naziv metapodataka za koje će se ispisati registrirati. Dopušteno je nekoliko opcija za određivanje objekata: “Document.IncomingCashOrder”, “Document.*”. Zadnji unos podrazumijeva sve dokumente dostupne u sustavu.
• Pogled. Definira vrstu vanjske obrade. Tretmani različitih vrsta bilježe se različito. Za tiskane obrasce navedite "Obrazac za ispis", ostale dostupne vrste navedene su u komentarima.
• Ime. Naziv obrade u sustavu.
• Identifikator. Koristi se na nekoliko mjesta, preporučuje se smisleno ime. Najčešće se ovdje navodi naziv obrade, na primjer: "HornsIExperience_Formation of the Layout of the Cash Order".
• Modifikator. Ako je raspored dokument proračunske tablice, zatim navodimo "Ispis XML-a".

postupak" Pečat» obavlja uslužnu ulogu i poziva ga ugrađeni mehanizmi sustava. U većini slučajeva njegov sadržaj ostaje nepromijenjen, osim parametara poziva "OutputSpreadsheetDocumentToCollection" (pogledajte tijelo procedure).

Obavezno je navesti ID naredbe (mora odgovarati vrijednosti " Identifikator"navedeno u proceduri" Pojedinosti o vanjskoj obradi”) i postavite sinonim (koristit će se u naslovu prozora za prikaz generiranog dokumenta proračunske tablice).

Sljedeća na redu za razmatranje je funkcija “GeneratePrintForm”. Može se činiti da se upravo u njemu vrši formiranje tiskanog oblika, ali to je samo na prvi pogled. Zapravo, ovo je još jedna uslužna funkcija koja od programera zahtijeva:

• Naziv za spremanje postavki ispisa. Češće koriste predložak: “PRINT_PARAMETERS_PrintFormName”.
• Izgled. U metodi "Get Layout" morate navesti naziv izgleda.

Tada na scenu stupa "magija". Započinje nabrajanje objekata, ispis obrazaca za koje je potrebno generirati. Za svakog od njih, postupak " OutputInformationOnDocument“, koja je zaslužna za formiranje tiskarske forme, radi koje se pristupilo izradi obrade.

Navedeni algoritam pokazao se prilično samodostatnim i prikladan je za formiranje tiskanog obrasca i za jedan i za nekoliko objekata. Uostalom, ništa ne sprječava korisnika da odabere nekoliko dokumenata u obrascu popisa i klikne gumb "Ispis".

Tretmani za punjenje

Potrebno je stalno automatizirati popunjavanje standardnih dokumenata. Važno je razumjeti kako to učiniti što fleksibilnije i ne komplicirati postupak za daljnje održavanje tipičnog rješenja.

Opći princip razvoja sličan je stvaranju vanjskih tiskarskih formi. Istina, postoji nekoliko "ali". Prvo, malo je lakše napraviti obradu popunjavanja (po mom mišljenju), a drugo, na primjeru ćemo vidjeti kako je moguće pojednostaviti popunjavanje uslužnih funkcija (pristup je primjenjiv pri razvoju eksternih tiskarskih obrazaca).

Početak procesa razvoja obrade punjenja je standardan: kreiramo novu obradu i opisujemo uslužnu funkciju u modulu - “Detalji eksterne obrade” (vidi listing 1).

Listing 1. Prazan prostor za obradu ispune

Na popisu je prikazan kod za popunjavanje servisne funkcije, samo što se ovaj put, umjesto zamjene niza identifikatora, napuštaju funkcije iz odgovarajućih BSP modula. Zašto je ova metoda bolja od prethodne? Svestraniji je i sigurniji. Ako programeri BSP-a refaktoriraju identifikatore, tada će stvorena obrada prestati raditi (orijentirani, tvrdo kodirani identifikatori), a to se neće dogoditi pri korištenju API-ja.

Razmatrana funkcija dovoljna je za stvaranje okvira za obradu-ispunjavanje. Tada sve ovisi o zadatku. Ako želite stvoriti obrazac za obradu i uspostaviti vezu s objektom za popunjavanje, u obrascu ćete morati opisati nekoliko parametara:

• Odredišni objekti (proizvoljni) – niz referenci na objekte za popunjavanje.
• Identifikator (String) – identifikator naredbe.
• AdditionalProcessingReference (ReferenceReference.AdditionalReportsAndProcessings).

Za ispravan rad potrebno je definirati sve navedene parametre. U većini slučajeva morat ćete raditi s "Destination Objects". Ako je obrada punjenja usmjerena na rad s jednim objektom za popunjavanje, tada je dovoljno provjeriti ispunjava li kolekciju i, ako je uspješna, izvući null element.

Modernizacija standardnih oblika

Razmotrimo jedan od tipičnih zadataka koji se javljaju prilikom pročišćavanja standardnih rješenja. Zamislite da smo za određeni dokument morali dodati: tabelarni dio i nekoliko detalja. Ovi entiteti su nam bili potrebni za rješavanje zadatka koji je nemoguće ili iznimno problematično izvesti korištenjem funkcionalnosti BSP konfiguracije.

Nakon proširenja tipičnih objekata, morate urediti glavni obrazac. U najjednostavnijem slučaju, prikažite stvorene elemente i za njih napišite logiku. Banalno uređivanje oblika je kao smrt, jer odmah nailazimo na problem opisan na početku članka. Za elegantno rješenje takvih problema na razini platforme stvoren je mehanizam proširenja.

Proširenja su dodaci koji vam omogućuju izmjenu konfiguracije bez izravnog mijenjanja. Za jednu konfiguraciju može se stvoriti nekoliko proširenja koja obavljaju potpuno različite zadatke.

Nova proširenja se kreiraju u konfiguratoru pomoću upravitelja proširenja ("Konfiguracija" -> "Proširenja konfiguracije"). Prozor upravitelja prikazuje sva instalirana proširenja (vidi sliku 3) i sučelje za stvaranje novih.

Da biste stvorili novo proširenje, kliknite gumb "Dodaj" i popunite polja u prozoru koji se pojavi (slika 4):

• Ime. Standardna pravila za imenovanje objekata metapodataka 1C.
• Sinonim.
• Prefiks. Dodatna vrijednost koja će se automatski dodati za sve stvorene entitete u proširenju.

Kliknite "U redu" i pred vama će se pojaviti dodatno stablo konfiguracije (slika 5).

Princip rada sa stablom konfiguracije proširenja ne razlikuje se puno od rada sa standardnim konfiguracijskim stablom informacijska baza. Razlika je u ograničenjima (http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513).

Rezimirajući dokumentaciju, glavna ograničenja nameću se mogućnosti proširenja konfiguracije dodatnim objektima metapodataka. Na primjer, proširenja ne mogu stvoriti nove dokumente, imenike i bilo koje druge entitete za pohranu podataka u bazi podataka.

S jedne strane, ovo je ozbiljno ograničenje, ali s druge strane, pouzdana je zaštita od situacija kada se podaci mogu izgubiti zbog sljedećeg ažuriranja ili nemogućnosti proširenja da radi s novom verzijom konfiguracije.

Slijedom navedenog zaključujemo: kreiramo nove entitete za pohranu podataka kao i obično, ali vršimo modifikaciju i integraciju s ostalim dijelovima proširenja.

Pokušajte staviti bilo koji objekt metapodataka u generirani stub. Svoje eksperimente provodim na konfiguraciji „Obračun nekredita financijska organizacija CORP", ali sve navedeno bit će relevantno za većinu rješenja temeljenih na BSP-u.

Proširio sam dokument " ContInsurancePolicy” (dodan tabelarni dio i nove pojedinosti), a zatim je u kreiranu ekstenziju dodao glavni oblik dokumenta (kontekstualni izbornik “Dodaj u ekstenziju”).

Uz obrazac će se prenijeti povezani detalji, kao i niz drugih objekata (slika 6.).

Obrazac proširenja možete mijenjati po vlastitom nahođenju: dodati nove kontrole, kreirati atribute, dodati logiku itd. To je nemoguće (ne preporuča se) osim brisanja postojećih kontrola. Mogu se vezati uz logiku forme, pa je bolje sakriti nepotrebne elemente.

Ovako stvorena ekstenzija bit će odmah spremna za korištenje. Iz upravitelja proširenja možete je izvesti u datoteku i dostaviti za druge konfiguracije. Važno je napomenuti da je instalacija proširenja dostupna u načinu "Enterprise".

Ideje za ekstenzije

Ne biste trebali razmišljati o ekstenzijama kao o vrsti štaka za modificiranje objekata. Ovo je cjeloviti sustav dodataka s velikim razvojnim potencijalom. Već danas proširenja omogućuju stvaranje: podsustava, zajedničkih modula, uloga, uobičajenih obrazaca, obrade, izvješća, HTTP usluga, WS veza, XDTO paketa. Navedeni objekti bit će dovoljni za rješavanje mnogih stvarnih problema.

Primjerice, u našoj tvrtki, uz pomoć ekstenzija, uspjeli smo riješiti ciklus zadataka vezanih uz integraciju CRM-a i korporativnog portala. Mehanizmi razmjene premješteni su u proširenja, a integracija zahtijeva nekoliko klikova mišem. Svi potrebni objekti metapodataka isporučuju se kao ekstenzije (HTTP usluge, obrada, itd.).

Slična je situacija i s integracijom CIS-a i CMS-a. Standardni mehanizmi razmjene u obliku glomaznog CommerceML-a nisu najprikladniji i najbrži način za učitavanje stavki na stranicu. Proširenja programera CMS-a mogu jednostavno riješiti ovaj problem i ne stvaraju tipična rješenja za korisnika s naknadnim ažuriranjem.

Mogućnost korištenja HTTP usluga u proširenjima - povećava moguće obrasce korištenja. Integracija s vanjskim uslugama, razmjene - sve se to jednostavno implementira funkcionalnostima HTTP usluga. Zanimljive primjere možete vidjeti u istoimenom članku objavljenom u prošlom broju našeg časopisa.

Što još mogu učiniti ekstenzije?

Možete dugo razgovarati o mehanizmu konfiguracijskih proširenja i napisati poseban članak. Tehnologija se neprestano razvija i dodaje nove značajke. Najzanimljivije novosti dogodile su se izdavanjem platforme 8.3.9. Prvi koncept presretanja / zamjene funkcija u modulima (modul extension) ugledao je svjetlo.

Bit ideje: pružiti programeru aplikacije mogućnost promjene logike modula bez izravnog unošenja promjena. Na primjer, postoji modul "SuperModule" u standardnoj konfiguraciji koji sadrži mnoge funkcije izračuna. Programer mora promijeniti logiku rada nekoliko funkcija iz ovog modula, a proširenje modula idealno je za ovaj zadatak.

Uz pomoć novih opcija proširenja takve probleme možemo riješiti presretanjem poziva. Mehanizam produžetka omogućuje dodatne upute za predprocesor (napomene) koji vam omogućuju presretanje generičkih metoda.

Programer ima priliku izvršiti svoj kod prije koda tipa, nakon koda tipa ili umjesto njega. Dovoljno je opisati odgovarajuće postupke i postaviti odgovarajuću napomenu ispred njih:

&Prije, &umjesto, &poslije. Na primjer: &Umjesto ("CalculateInsurancePremium") Funkcija CalculateInsurancePremiumWithAdditionalRisks(Parameter) // Some Code EndFunction

Ažurirani mehanizam proširenja omogućuje vam dodavanje vlastitih rukovatelja događaja tipične konfiguracije, kao i opskrbu vlastitim zajedničkim modulima s ekstenzijom.Sve gore navedeno bit će relevantno za sve vrste modula, osim za obične module obrasca.

Mehanizam proširenja modula omogućuje vam puno toga, ali ga trebate koristiti vrlo pažljivo. Uz njegovu pomoć lakše je nego ikad oštetiti i razbiti tipične mehanizme i neće se odmah moći pogoditi odakle noge rastu. Ne zaboravite, može postojati nekoliko proširenja i svako od njih može imati svoju implementaciju.

Pretplate na događaje

Proširenja donose pravu čaroliju, ali postoji tona konfiguracija koje rade na starijim platformama do kojih novije tehnologije još nisu stigle. Kako biti u takvim slučajevima? Što ako želite dodati svoja kretanja u dodatne registre prilikom knjiženja standardnog dokumenta?

Pretplate na događaje provjerena su opcija za rješavanje takvih problema. Programer je dovoljno izraditi vlastiti zajednički modul za opis postupaka/funkcija koje se pozivaju kao odgovor na određeni događaj i dodati potrebne pretplate u konfiguraciju. U tom slučaju, održavanje konfiguracije neće patiti, a programer dobiva priliku izvršiti svoj kod nakon rukovatelja tipičnim konfiguracijskim objektima.

Softversko popunjavanje obrazaca

Kako precizirati standardne obrasce bez korištenja mogućnosti mehanizma proširenja? Vrlo jednostavno - programski stvoriti elemente. Metoda se ne može nazvati univerzalnom, jer. još uvijek morate unijeti kod u standardni obrazac. Istina, u ovom slučaju morat ćete napraviti jednu liniju koja će izvući proceduru iz zajedničkog modula s algoritmom za kreiranje kontrola obrasca.

Izmjena običnih oblika na predloženi način je problematična (utječe na pozicioniranje piksela elemenata), ali s kontroliranim, naprotiv, nema poteškoća. Ako iz nekog razloga nije moguće koristiti proširenja, tada je programsko usavršavanje obrazaca jedini ispravan i manje težak za održavanje način za modificiranje standardnih obrazaca.

Promjena uloge

Često sam viđao kako programeri pokušavaju modernizirati standardne uloge. Ovo je najgora ideja koja se može zamisliti. Recimo samo – nikad ne mijenjajte tipične uloge. Ako trebate proširiti prava za rad s novim konfiguracijskim objektima, dodajte zasebne uloge i dodijelite ih korisniku zajedno sa standardnim.

U idealnom slučaju, pokušajte podijeliti uloge što je više moguće. Dodijelite uloge za čitanje i pisanje dokumenata / imenika, nemojte kombinirati prava u jednu ulogu. Naravno, to ne biste trebali činiti za svaki konfiguracijski dokument/referencu, ali biste to trebali učiniti barem za grupe objekata. Razmotrimo primjer - " Gotovinski dokumenti". To uključuje barem "PKO" i "RKO". Stoga je lako formirati fleksibilne sigurnosne profile (FSP).

Zašto ne možete promijeniti zadane uloge? Prvi razlog je taj što se generičke uloge često mijenjaju. Svako ažuriranje zadane konfiguracije uvodi nove objekte, a standardne uloge se mijenjaju u skladu s tim. Stoga ćete morati stalno uspoređivati ​​uloge kako ne biste slučajno prepisali prava pristupa svojim objektima. Drugi razlog: nedostatak razumnog mehanizma za usporedbu uloga.

Ne budi lijen

Ovom frazom želio bih završiti ovaj članak: "Ne budi lijen." Ne pokušavam nikoga uvrijediti, ali ću samo pokušati naglasiti da ništa ne stoji. Tehnologija napreduje, ali programeri imaju dobro pamćenje za loše događaje. Rafiniranje tipičnih konfiguracija oduvijek je bilo praćeno bolom, no danas se situacija ispravlja.

Važno je ne sjediti, već pratiti razvoj industrije i početi primjenjivati ​​nove mehanizme u rješavanju svakodnevnih problema. Promovirajte korištenje novih obrazaca, donesite informacije kolegama koji su malo "zapeli" u prošlosti. Što će više programera pokupiti nove stavke, brže će se otkriti nedostaci i sva je prilika da će 1C nastaviti aktivno raditi na poboljšanjima.

Pa svima ostalima, dobrodošli pod kat.

Pravila i tehnike za finaliziranje standardnih 1C konfiguracija kako bi se olakšala njihova daljnja podrška i ažuriranje

Dakle, kada radimo određeni projekt (pod riječju "mi" mislim na sve ljude koji su uključeni u automatizaciju poslovnih procesa), nadamo se da će se kasnije to nesmetano pretočiti u podršku. U pravilu, ako je sve dobro napravljeno i kupac zadovoljan, to se i dogodi.

Podršku karakterizira vrlo specifičan skup zadataka - to mogu biti zadaci za savjetovanje iz kategorije "odakle takvi brojevi" ili za ispravljanje nekih neshvatljivih pogrešaka itd. No, budući da se gotovo svi projekti sastoje od prilagođavanja nekog standardnog rješenja potrebama korisnika, konfiguraciju s podrškom potrebno je povremeno ažurirati za nova izdanja:

• Ako slijedite neka pravila razvoja, nakon što ste potrošili vrlo malo truda u fazi projekta, u budućnosti će biti moguće uštedjeti na održavanju i ažuriranju konfiguracija.
• I obrnuto, ako je u fazi projekta bilo nekih pogrešaka, žurbe, netočnog dizajna koda, kasnije se to može pretvoriti u pravi pakao podrške i ažuriranja.

Je li netko morao ažurirati konfiguraciju koja je prepisana bez ikakvih identifikacijskih oznaka? Vidite li koliko je teško usporediti staru konfiguraciju dobavljača s novom konfiguracijom, ručno raščlaniti svaku instancu "dvostruko promijenjene" u usporedbi s trenutnom konfiguracijom, i tako dalje. Sve je to prilično problematično.

9 jednostavnih pravila za projektiranje izmjena u standardnim konfiguracijama

1. Koncept minimiziranja "uništavanja" tipične konfiguracije

Prvo čak i nije pravilo, to je određeni koncept minimiziranja "uništavanja" tipične konfiguracije.

Njegova je bit da uvijek treba birati one načine rješavanja problema koji će omogućiti lakše ažuriranje konfiguracije u budućnosti, čak i ako je takvo rješenje nešto teže implementirati. Jasno je da to treba učiniti bez fanatizma, u razumnim granicama, ali programer bi uvijek trebao imati na umu da konfiguracija ostaje na podršci i analizirati koliko će njegov kod u budućnosti komplicirati ažuriranje konfiguracije, birajući najprikladnije rješenje.

2. Komentiranje promjena koda

Drugo pravilo je da Svaka promjena koda mora biti komentirana.

U našoj tvrtki koristimo sljedeću shemu:

• Na početku promjene je uvodni komentar(počinje likovima //++ )
• Na kraju - završni komentar(počinje likovima //-- )
• A one promjene koje je programer napravio su u sredini.

Ovo je obavezno pravilo za sve promjene.

Komentari otvaranja i zatvaranja imaju oznaku promjene. Sadrži sljedeće sastavnice:

• Prefiks projekta- prema zadanim postavkama koristimo FTO
• Naziv domene programera. Formira se vrlo povoljno: tvrtka je velika, distribuirana, a ako ne poznajete programera, ali trebate nešto pitati o njemu, možete uzeti njegov nadimak iz ove oznake, stavite @fto.com.ru na desno i pošalji mu pismo kako bi ga na taj način kontaktirao.
• Sljedeće dolazi datum promjene. Kada se promjene dogode unutar nekoliko zadataka, ti se snopovi komentara mogu ugniježditi jedan u drugi, a nije uvijek jasno kojem početnom bloku pripada ovaj završni komentar, pa se fokusiramo na datum. Uz to, datum odmah pokazuje kada je izmjena napravljena: prije tri godine, prije šest mjeseci ili jučer.
• Onda dolazi broj zadatka, što je postavljeno samo u uvodnom komentaru. Zašto samo tamo? Tako da tijekom globalnog pretraživanja po broju zadatka, samo početak promjena koda ulazi u odabir, s kojeg već možete gledati dolje, inače će se udvostručiti. Na primjer, kada predate zadatak na pregled koda, vrlo je zgodno pretraživati ​​po oznaci.

Primjeri

Ovako to izgleda umetnuti kod:

Ovako to izgleda uklanjanje koda- kod ne uklanjamo u potpunosti, već ga komentiramo. Zbog toga uvijek možete vidjeti što je komentirano, a u tom slučaju možete se brzo vratiti.

Ovako to izgleda promjena koda: prvo se komentira sav kod dobavljača, a zatim se dodaje vaš vlastiti kod.

Djeluje zasebno pravilo za dodavanje procedura, funkcija i globalnih varijabli modula. U ovom slučaju završni komentar nalazi se u istom retku kao i ključna riječ EndProcedure. Zašto se to radi? Kako bi bilo zgodno prenositi izmjene pomoću "proceduralne usporedbe".

Ovdje slika to pokazuje pomoću "proceduralne usporedbe" možete jednostavno istaknuti ovaj postupak prilikom spajanja, i bit će u potpunosti (zajedno s naljepnicama) prenesen. Ili obrnuto, možete poništiti okvir pored nje kako ne biste prenijeli.

A ako je završni komentar na sljedećem redu, onda će biti dodijeljen sljedećoj proceduri i neće ga se moći tek tako prenijeti bez dodatnih troškova.

3. Dodavanje objekata najviše razine

Sljedeće pravilo je dodavanje objekata najviše razine (direktorije, dokumenti, registri, itd.) u konfiguraciju.

Ovo pravilo je to nazivi objekata moraju početi s prefiksom. Za što?

• Prvo, vizualno ističe dodani element u konfiguraciji i kodu. odmah je jasno da je to naš dodani objekt.
• Drugo, postiže se jedinstvenost imena, jer davatelj može dodati vlastiti objekt s istim imenom. A ako koristimo vlastiti prefiks, onda to jamči da će naše ime biti jedinstveno.

Sinonimi objekta moraju početi s prefiksom u zagradama. To nam omogućuje da istaknemo naš dodani objekt u sučelju.

Naravno, ovo je vrlo kontroverzno pravilo, i njegova uporaba mora biti dogovorena s kupcem. Ova shema je odgovarala našim klijentima, pa se kod nas ukorijenila i ušla u pravila. Ali ovdje je na vama i klijentu da odlučite hoćete li to učiniti ili ne.

Pa, zadnje pravilo: komentari na sve dodane objekte moraju sadržavati posebnu oznaku s imenom programera i brojem izdanja. Ova oznaka je slična uvodnom komentaru iz modula, samo bez posebnih znakova - uz nju uvijek mogu razumjeti tko je dodao ovaj objekt, kada i za koji zadatak.

Pa da rezimiramo:

• Imena se daju s prefiksom,
• Sinonimi - s prefiksom u zagradi
• A komentar mora sadržavati posebnu oznaku.

4. Dodavanje podređenih objekata

Pod dodavanjem pod-objekata, mislim na dodavanje rekvizita, izgleda, obrazaca i tako dalje. na konfiguracijske objekte.

Ovdje moramo odmah istaknuti dvije situacije u kojima dodajemo podređeni objekt:

• Na tipičan konfiguracijski objekt
• Ili nekom objektu koji je ranije dodan unutar projekta.

Razmotrimo svaku od ovih situacija zasebno.

Za dodavanje podređenih objekata tipičnim konfiguracijskim objektima vrijede sljedeća pravila.

• Imena moraju početi potpuno isto s prefiksom. Time postižemo jedinstvenost imena i vizualno je također uvijek jasno da je to naš objekt.

• Sinonim se popunjava bez prefiksa, jer više nema potrebe za odabirom naših objekata, naših detalja.

• I konačno, komentar također sadrži posebnu oznaku tako da je jasno tko, kada i zašto.

Dakle, sumirajmo kako se događa dodavanje podređenih objekata tipičnim konfiguracijskim objektima:

• Imena se daju s prefiksom,
• Sinonimi prema općim pravilima
• A komentari sadrže posebnu oznaku.

A ako onim objektima koji su prethodno dodani unutar projekta dodamo podređene objekte i već sadrže prefiks u svom nazivu, tada:

• Njihova imena ne smiju sadržavati prefiks, jer je već jasno da je objekt već jedinstven i nema potrebe da ga nekako posebno selektirate.

• Sinonimi za takve podređene objekte također su navedeni bez prefiksa, jer nije potrebna posebna selekcija.

• A komentar sadrži posebnu oznaku samo kada je ovaj podređeni objekt dodan unutar drugog zadatka. Jer ako moj zadatak kaže da moram dodati dokument koji ima te i takve detalje, ne trebam stavljati takvu oznaku za svaki atribut. Ali ako je zadatak potpuno drugačiji, svakako ću staviti oznaku da bude jasno zašto sam to napravio.

A sada sumirajmo kako se podređeni objekti dodaju objektima dodanim unutar projekta:

• Imena bez prefiksa.
• Sinonimi bez prefiksa.
• A komentari bi trebali sadržavati posebnu oznaku samo kada se dodaju unutar drugog zadatka.

Ako se ovo pravilo spoji za oba slučaja i "složi", onda će se dobiti sljedeća ploča:

• Novi objekti:
  • Ime počinje prefiksom.
  • Sinonimi - s prefiksom u zagradi.
  • Komentar sadrži oznaku.
• Podobjekti koje dodajemo objektima tipa:
  • Imena počinju prefiksom,
  • Sinonim prema općim pravilima
  • Dodajte oznaku komentaru.
• A ako dodamo podređene objekte objektima dodanim unutar projekta, onda
  • Za njih ne postoje posebna pravila.
  • Ali ako je zadatak drugačiji, na isti način stavljamo oznaku u komentar.

5. Dodavanje unaprijed definiranih elemenata

Sljedeće pravilo je dodavanje unaprijed definiranih elemenata.

Ovdje postoje točno dvije situacije:

• Kada dodamo unaprijed definirani element tipičnom konfiguracijskom objektu (priručniku, planu tipova karakteristika)
• A kada dodamo unaprijed definirani element objektu koji je dodan unutar projekta.

Ako generičkom konfiguracijskom objektu dodamo unaprijed definirani element,

• Njegovo Ime sličan mora početi s prefiksom. Tako jamčimo jedinstvenost njegovog imena i možemo odmah vizualno identificirati naš dodani element.
• Šifra i imeće se formirati prema općim pravilima,
• Ali označiti evo, nažalost nigdje staviti. Stoga neće biti moguće pronaći ovaj dodani unaprijed definirani element globalnom pretragom zadatka.

A ako dodamo unaprijed definirane elemente objektima dodanim unutar projekta, onda

• Njegovo naziv neće sadržavati prefiks, budući da to ne treba nekako odvajati.

Dakle, ako povučemo analogiju s prethodnom tablicom, onda:

• Unaprijed definirani elementi za generičke objekte dodaju se s prefiksom,
• A sve ostalo - prema općim pravilima, ne treba dodavati posebne prefikse.

6. Korištenje zajedničkih modula i njihova stroga struktura

Sljedeće pravilo odnosi se na korištenje zajedničkih modula i organizaciju stroge strukture za njih.

Prvo, za različite postupke, funkcije, rukovatelje pretplatom i zakazane poslove, trebali biste dodati svoje vlastite module, ostavljajući tipične module nepromijenjenima. A ako programer želi postaviti neku vrstu postupka izvoza u standardni modul, onda to ne morate učiniti, morate stvoriti vlastiti modul.

Drugo, imajte na umu da zajednički moduli se dodaju prema pravilima za dodavanje objekata najviše razine(ime i sinonim s prefiksom, oznakom u komentaru itd.)

Treće, nazivi modula moraju biti slični modulima odgovarajućeg tipa.

Nema potrebe ponovno izmišljati kotač: zovemo ga na isti način kao što je uobičajeno u tipičnim konfiguracijama - za svaku funkcionalnost postoji modul koji odgovara općeprihvaćenim oznakama u 1C. Na primjer:

• FTO_Kupac opće namjene,
• PTO_Poslužitelj opće namjene,
• PTO_Global opće namjene,
• PTO_Regulatory TasksServer
• itd.

I još veliki pojedinačni zadaci može (i vjerojatno bi trebao) staviti u zasebne zajedničke module.

7. Korištenje pretplata i njihova stroga struktura

Sljedeće pravilo je korištenje pretplata i njihova stroga struktura. Koja je njegova bit?

Pretplate bi se trebale koristiti za rukovanje raznim događajima povezanim s generičkim objektima, kao što su:

• Prije snimanja
• Prilikom snimanja
• itd.

• Naravno možete uzeti uredite modul tipa objekta, umetanje vašeg koda u odgovarajuću proceduru. Ali ovo - loš način.
• Bolje je umjesto ovoga dodajte pretplatu za rukovanje ovim događajem.

Pretplata se dodaje prema sljedećim dogovorenim pravilima:

1. Za sve događaje iste vrste u sustavu dodaje se samo jedna pretplata. Na primjer, ako trebam koristiti vlastiti algoritam za različite imenike u događaju “Prije snimanja rječnika”, tada za sve te direktorije koristim samo jednu dodanu pretplatu “Prije snimanja rječnika”.
2. Svi objekti unutar ove klase odabrani su u izvoru(na primjer, svi imenici)
3. Za dodanu pretplatu kreira se poseban modul koji se zove potpuno isto(samo radi praktičnosti).
4. U glavnom rukovatelju događaja definira se uvjet koji analizira tip objekta(vrsta vodiča).
5. I već određene radnje izvode se ovisno o vrsti objekta.

Mogu vam pokazati na primjeru. Pretpostavimo da postoji takav zadatak: prilikom knjiženja dokumenta "Napredno izvješće" unesite unose u registar akumulacije koji je ranije dodan.

Prvo dodajemo opći modul PTO_DocumentsProcessingConductance u skladu sa svim pravilima.

• Kao izvor navedite DocumentObject (svi dokumenti);
• Kao rukovalac - naš modul je dodan gore.

I već u modulu, u samom rukovatelju, određujemo kakav nam je dokument došao i, ovisno o njegovoj vrsti, pozivamo jednu ili drugu proceduru.

Pretplata je jedna, ali radnje mogu biti različite. T Također možete kontrolirati redoslijed pozivanja procedura.

Kao rezultat toga, postupak kreiranja pretplate je sljedeći:

• Jedna pretplata
• Jedan zajednički modul
• I ništa drugo više nije potrebno: modul dokumenta ostaje nepromijenjen - više se neće pojavljivati ​​u odjeljku "dvaput promijenjeno".

8. Uređivanje obrazaca

Sljedeće pravilo je uređivanje obrazaca.

Ovdje na isti način izdvajamo dvije točke, dvije situacije:

• Kada uređujemo forme tipa;
• A kada uređujemo obrasce dodane unutar projekta.

Prva situacija je uređivanje e standardni obrasci, oblici tipičnih predmeta. Ovo je najkontroverzniji dio pravila. Svojedobno, još u doba konvencionalnih formi, kada su se projekti uglavnom radili na SCP-u, vodili smo mnogo rasprava o tome što učiniti s formama. Koje su bile opcije?

• Izravno uređivanje pravilnih oblika je da samo ručno mijenjam obrazac. Uz ovu opciju, svaki put kada dobavljač unese izmjene u ovaj obrazac, moram ponovno prenijeti sve svoje izmjene. loš način.
• Drugi način je izradite kopiju obrasca. Tada napravim kopiju standardnog obrasca, dodijelim ga kao glavni i izvršim svoje izmjene u njemu. Ali opet, ako dobavljač promijeni ovaj obrazac, moram ručno prenijeti njegove promjene u svoju verziju. Nije najbolji način.
• Druga opcija je stvaranje zasebne kartice. Na obrascu stvaramo zasebnu karticu i na nju postavljamo svoje elemente. Jasno je da ova metoda nije fleksibilna, jer ponekad trebate umetnuti svoj element negdje točno na određeno mjesto na obrascu. Ili trebate promijeniti svojstva tipičnih elemenata, dodijeliti im novi rukovatelj itd. Stoga je nije fleksibilan način Ni on ne radi baš dobro.
• Kao rezultat odabrali smo način potpunog programskog uređivanja obrazaca. Za nove programere koji nisu iskusili ovu metodu, isprva se čini da je programsko uređivanje obrasca vrlo teško. Ali u stvarnosti, ne. Iz svog iskustva reći ću da samo trebate napuniti ruku. Osim toga, već duže vrijeme imamo napisane module s izvoznim procedurama za programski mijenjanje obrazaca, a sve se to radi prilično jednostavno. Kada su se pojavili upravljani oblici, u potpunosti smo prenijeli i ovu praksu programske promjene obrazaca na upravljane forme. Štoviše, programsko uređivanje upravljanog obrasca postalo je općenito jednostavno – ne može se usporediti s običnim obrascima.

Pokažimo primjer. U rukovatelju OnCreateOnServer, dodajem poziv svojoj proceduri ModifyFormProgrammatically, gdje programski dodajem elemente obrascu.

U konfiguracijama temeljenim na BSP 2(kao što su ERP, računovodstvo, itd.) dodano Obrasci za obradu događaja.OnCreationOnServer(), koji, između ostalog, ulazi također u nadjačani modul.

I tako u nadjačanom modulu možete dodati svoj kod- na primjer, u proceduri OnCreateAtServer(). Ovdje definiram naziv obrasca, a ovisno o njemu pozivam jednu ili drugu proceduru, gdje elemente dodajem programski.

Čini se da je teško, da je ova shema glomazna, ali zapravo, ako se svi projekti rade prema takvim pravilima, tada programer, primajući zadatak, već odmah zna gdje tražiti, gdje nešto dodati. Tako da mislim da je vrlo zgodno.

Osim toga, konfiguracije temeljene na BSP 2 također redefiniraju druge rukovaoce obrascima - kao što su OnReadOnServer(), BeforeWriteOnServer(), itd. A u ovim rukovateljima također možete aktivno koristiti redefiniranje pozvanih procedura. Štoviše, redefinirani modul teoretski se ne mijenja od strane dobavljača, a tamo možete napisati vlastiti kod bez straha od sukoba.

Ako uređujemo obrazac koji je dodan kao dio projekta, onda ovdje ne treba ništa posebno raditi, uređujemo ga na uobičajen način, ručno.

9. Principi rada s ulogama

I posljednje pravilo su principi rada s ulogama.

Načela rada s ulogama su sljedeća:

1. Ako je moguće, onda generičke uloge uvijek treba ostaviti neimenovanim. Morate dobro razmisliti je li doista potrebno promijeniti tipičnu ulogu ili možete učiniti nešto drugačije.
2. Dodanim konfiguracijskim objektima dodjeljujemo prava u novim, posebno kreiranim ulogama. Stoga, kada u konfiguraciju dodam izvješće, a za njega ne postoji odgovarajuća uloga koju smo unaprijed dodali, kreiram zasebnu ulogu. A onda se ova uloga dodaje željenim profilima. A tipične uloge se ne mijenjaju.
3. I ako dođe do promjena uRLS, zatim se sastavljaju prema pravilima za uređivanje modula.

Na primjer, ako trebam promijeniti RLS, onda stavljam uvodni komentar, komentiram stari kod, zatim dodajem svoj i stavljam završni komentar. Uvijek je jasno: tko, zašto (u okviru kojeg zadatka) i kada sam se promijenio.

Dakle, naveo sam svih devet jednostavnih pravila za dizajniranje modifikacija.

Dodatni predmeti i trikovi za lakši život

U zaključku ću govoriti o nekim objektima i trikovima koji programeru mogu olakšati život.

1. Samoidentifikacija testnih baza podataka

Prva tehnika je samoidentifikacija testnih baza.

Zaključak je:

• postoji neka konstanta koja pohranjuje adresu radne baze proizvodnje.
• Kada se sustav pokrene, ova adresa se provjerava.: odgovara adresi radne baze ili ne odgovara.
• I ako se ne poklapa(baza ne radi), dakle zamjenjuje se zaglavlje sustava.

Snimka zaslona pokazuje kako to izgleda. Ovo je posebno korisno kada programeri (ili konzultanti) imaju otvorene mnoge baze podataka (radne, testirane, razvojne, itd.) i mogu slučajno pogriješiti i promijeniti podatke u radnoj bazi podataka. A ako se promijeni naslov, onda je već "na stroju" - oči u gornjem lijevom kutu, pogledate kakva je baza - da, testirajte, možete je promijeniti.

Time mijenjamo podatke u infobazama činimo sigurnijim.

Štoviše, provjera vrijednosti ove konstante također je korisna pri obavljanju nekih rutinskih zadataka. Naime:

• razmjena podataka,
• korisničke obavijesti,
• neke pošiljke,
• teške regulatorne zadatke.
• itd.

Kada programer kreira takav zakazani zadatak, mora provjeriti radi li se baza podataka ili ne. Jasno je da bi, teoretski, na svim testnim bazama, zakazani zadaci trebali biti onemogućeni u konzoli klastera. Ali uvijek postoji ljudski faktor, kada je netko napravio novu bazu podataka, u nju učitao svježe podatke, nešto promijenio i kao rezultat toga došlo je do neke vrste kritične razmjene s bazama koje rade. A onda rastavljanje - zašto se to dogodilo? Zato smo mi prije kritičnih zakazanih zadataka uvijek provjeravamo je li to radna baza ili ne.

Konfiguracije temeljene na BSP 2 imaju sličan mehanizam: ako se promijeni mjesto infobaze, postavlja se pitanje - je li to kopija baze podataka ili je baza premještena. U principu, ovaj mehanizam može biti dovoljan, ali opet može intervenirati ljudski faktor, netko neće razumjeti što se događa i pritisnut će krivi gumb. Tako, po mom mišljenju, konstanta je pouzdanija.

2. Rukovanje inicijalizacijom

Sljedeći trik je obrada inicijalizacije.

• Ovo je obrada dodana konfiguraciji koja sadrži svoju trenutnu verziju u svom kodu.
• Istodobno se konfiguraciji koja pohranjuje trenutnu verziju inicijalizacijske obrade također dodaje neka konstanta.
• Prilikom pokretanja sustava vrši se provjera
• A, ako se verzija promijenila, izvode se potrebni rukovaoci i postavlja se nova vrijednost konstante.

Zašto je ovo potrebno? Često je prilikom dodavanja nove funkcionalnosti u konfiguraciju potrebno izvršiti neke radnje u samoj bazi podataka: na primjer, dodali ste unaprijed definirani element direktorija, a sada trebate ispuniti njegove detalje. Na projektu može biti puno baza, a ručno popunjavanje ovih podataka je, naravno, loše. točnije:

• Povećana verzija obrada inicijalizacije;
• Opišite u kodu kako programski ispuniti podatke;
• I nakon toga nova verzija obrade automatski će kroz pohranu doći do svih potrebnih baza podataka, tamo će započeti i poduzet će sve potrebne korake.

Na dijagramu ovo operativni postupak prikazano ovako:

• Pokretanje sustava
• Usporedba konstantne verzije s verzijom za obradu.
• Ako se ne poklapa, izvedena redom sve potrebno rukovaoci,
• Postavlja se nova vrijednost konstante.

Kao rezultat, posvuda, u svim bazama podataka, podaci se ažuriraju.

3. Imenik unaprijed definiranih vrijednosti

Sljedeći trik je imenik unaprijed definiranih vrijednosti.

Često postoji potreba da se iz koda uputi na postojeće elemente direktorija koji nisu unaprijed definirani. Jasno je da je bolje napraviti unaprijed definirani element, ali dogodilo se da se element ne može unaprijed definirati, ali se ipak odnosi na njega.

Koje mogućnosti implementacije postoje?

• Pristup elementu po imenu. Jasno je da se naziv promijenio - kod je prestao raditi. Loše.
• Kontakt putem koda. Malo bolje, ali se i kod može promijeniti. Ne baš dobro.
• Kontakt putem internog ID-a. Tada, prilikom prijenosa, ni ovaj kod neće raditi. Općenito, sva ova tri slučaja neće funkcionirati ako prenesemo modifikaciju s jedne baze na drugu. Ne baš dobro.
• Ponuđeno stvoriti direktorij unaprijed definiranih vrijednosti.

Ovaj imenik sadrži samo jedan atribut s tipom DirectoryLink(link na sve vodiče).

Ako se trebam pozvati na neki element unutar zadatka, ovom direktoriju dodajem unaprijed definirani element (na primjer, Contractor_Agroimpulse)

I tada već u kodu za obradu inicijalizacije, bilo ručno, popunjavam vrijednost ovog imenika s drugom stranom koja mi je potrebna.

Sukladno tome, nakon ovoga Moći ću pristupiti ovoj drugoj stranci putem imenika unaprijed definiranih vrijednosti. Time se postiže:

• Prilikom prijenosa izmjena između različitih baza podataka, sve moje kod radi bez ikakvih dodatnih izmjena.
• Uz to, moguće je da je danas ta suradnik Agroimpuls, a sutra neka druga organizacija, ali ne trebam ništa mijenjati u konfiguraciji, samo uzimam i mijenjam njegovu vrijednost u imeniku predefiniranih vrijednosti.

4. Pregledajte privremene tablice u programu za ispravljanje pogrešaka

Pa, posljednji trik je pregled privremenih tablica u programu za ispravljanje pogrešaka.

• Prilikom otklanjanja pogrešaka složenih upita s privremenim tablicama Potrebno je pogledati sadržaj ove privremeni stolovi.
• Za ove svrhe limenka koristiti posebnu funkciju za pregled privremenih tablica.
• Ova funkcija zgodno mjesto u globalnom modulu.

• I Ime nekako kratko, na primjer BT()

U ovom slučaju:

• JA SAM staviti prijelomnu točku na mjestu gdje imam zahtjev.
• U prozoru "Izračunaj izraz" upisujem BT (Zahtjev);
• Kliknite "Izračunaj" i Dobivam strukturu privremenih tablica upita da vidite koji su podaci.

Ovo je vrlo zgodna značajka, koristimo je cijelo vrijeme. Pogotovo pri izračunu cijene koštanja, odnosno u konfiguracijama kao što je ZUP. Iskreno, ne razumijem kako drugi žive bez toga.

V Najnovija verzija pojavila se platforma ugrađeni alat koji vam omogućuje pregled privremenih tablica, ali mislim da je tako nije baš ugodno. Iskoristite svoju funkciju puno bolje.

Zaključak

Hvala svima. Imam malu stranicu, na ovoj stranici su sva ova pravila detaljno izložena i ne samo ona - uđite, pročitajte, pišite mi poštom ili skypeom.

Zanima me ova tema, spreman sam razgovarati o tome. Zaista mi je važno da i ti uspiješ.