Ena od glavnih prednosti programov 1C Enterprise je ogromna možnost prilagajanja individualnim zahtevam vsakega uporabnika. To zahteva spreminjanje in urejanje obstoječih konfiguracij ali razvoj lastnih iz nič.
Revizija 1C Gre za spremembo standardnih konfiguracij, kot so računovodstvo, obračun plač in kadrov, upravljanje trgovine, kompleksna avtomatizacija, vodenje proizvodnih obratov itd., na željo naročnika. V vseh standardnih programih 1C je konfiguracijska koda odprta, razen osnovnih različic, in lastnik programa 1C lahko prosto dokončaj 1C da ustreza vašim potrebam. Prav to je najpomembnejša prednost programov 1C. Pomanjkljivost posodobitve programa 1C je, da če spremenite standardno konfiguracijo, bo posodabljanje težje. Toda tudi to težavo je mogoče rešiti.

Običajno 1C revizija vključuje: modifikacijo natisnjenih obrazcev, modifikacijo poročil ali razvoj novih poročil, razvoj procesiranja za analizo za prihranek časa, obdelavo informacij ali izpolnjevanje informacij, modifikacijo konfiguracije z ustvarjanjem novih konfiguracijskih objektov (imenikov, dokumentov, registrov, njihovih podrobnosti) Če želite spremeniti 1C, morate uporabiti storitve izkušenega programerja.

Program 1C Enterprise uporablja vgrajen programski jezik, v katerem so brez izjeme napisane vse konfiguracije 1C, standardne in nestandardne. Strokovnjak, ki ima veščine za delo s programom 1C Enterprise v načinu - Konfigurator, lahko poljubno spremeni en ali drug algoritem konfiguracije 1C, spremeni videz elementov programa, ustvari nove konfiguracijske objekte itd.

Zato je programski sistem 1C Enterprise univerzalen. Če za osnovo vzame standardno konfiguracijo, na primer 1C Trade Management, jo lahko programer prilagodi posebnostim podjetja na katerem koli področju dejavnosti tako, da Izboljšave 1C mehanizmi in konfiguracijski objekti.

Ta proces se imenuje - revizija 1s- Z uporabo istega vgrajenega jezika lahko programer ustvari popolnoma novo konfiguracijo, ko gre za avtomatizacijo zelo specifičnih področij trgovine, proizvodnje ali drugih področij človeške dejavnosti. V ta namen se izdela podrobna tehnična specifikacija, ki do najmanjših podrobnosti opisuje vse ključne točke izdelane konfiguracije. Oblikovanje takšne konfiguracije zahteva veliko časa.

Prednosti konfiguracije, ustvarjene iz nič, so očitne, vendar obstaja ena velika pomanjkljivost - dolg razvojni čas in visoki stroški. Veliko lažje je ustvariti dodaten podsistem na podlagi obstoječe konfiguracije. Vgrajeni jezik se lahko uporablja tudi za ustvarjanje novih zdravljenj.

Z uporabo vgrajenega jezika 1C je mogoče uporabiti mehanizem za nalaganje podatkov v 1C iz programa, s katerim ste delali. Če je količina podatkov zelo velika, jih ročni prenos ni ekonomsko izvedljiv. Za specialista je to le nekaj ur dela. Vsekakor pa ne podcenjujte vsestranskosti sistema 1C Enterprise in zmogljivosti vgrajenega jezika.

Vsaka organizacija, tudi majhna, ima svoj niz poslovnih procesov. Za učinkovito delo in največji dobiček je treba velike poslovne procese avtomatizirati. Programi 1C odlično opravljajo to funkcijo. Toda na žalost idealnih programov ni, tako kot ima vsak človek svoje predstave o popolnosti. Programer 1C vam lahko pomaga izboljšati vaš program. Po spremembi standardnega 1C boste prejeli program, ki v celoti ustreza vašim idejam in potrebam.

Revizija 1C- nabor ukrepov za konfiguracijo in posodobitev programov 1C, da ustrezajo potrebam vašega podjetja.

Kako posodabljamo programe 1C

Da bi dosegli idealen rezultat, ko stranka prejme točno tisto, kar je nameravala pri dokončanju programov 1C, ponujamo naslednjo shemo dela:

1. odjemalec poroča informacije o nameščenih ;
2. naročnik našega strokovnjaka seznani z osnovnimi načeli dela njegove organizacije, sporoči bistvo problema, opiše, kaj točno bi rad izboljšal;
3. Stranki dodelimo programerja 1C, ki bo ves čas sodelovanja z njo sodeloval z našim podjetjem in bo poznal vse značilnosti računovodstva pri poslovanju stranke. Osebni programer 1C bo v celoti odgovoren za izvedbo izboljšav, ki jih je implementiral;
4. tehnične specifikacije so sestavljene. Na podlagi prejetih informacij bodo naši programerji 1C naredili potrebne zaključke in ponudili možnosti za rešitev problema bodisi s spremembami bodisi s prilagoditvami v 1C;
5. dogovorjeni so stroški časa in denarja za dokončanje 1C;
6. izvajajo se dela, dogovorjena z naročnikom;
7. Rezultate dela testiramo in predamo naročniku.

Najpogostejše spremembe 1C

Spodaj navajamo posebej priljubljene izboljšave v programih 1C:

• Izdelava imenikov in podrobnosti. Ustvarjanje dodatnih mest za shranjevanje informacij, kot so na primer avtomobilske številke
• Izpopolnjevanje ali razvoj novih tiskovnih form. Spreminjanje videza računov, faktur in drugih tiskanih oblik dokumentov glede na zahteve vaše organizacije.
• Ustvarite nova ali spremenite obstoječa poročila. Izdelava dodatnih ali urejanje obstoječih poročil za računovodje, vodje ali direktorje podjetij.
• Nastavitev pravic dostopa. Omejitev ali razširitev uporabniškega dostopa do informacij v bazi podatkov.
• Razvoj zdravljenja. Izdelava obdelave za poenostavitev sistemov za vnos informacij, analiza dejavnosti podjetja, avtomatsko izvedene funkcije, na primer tiskanje paketa dokumentov ali prenos informacij iz datoteke Excel (*.xls).
• Nastavitev izmenjave 1C. Uvoz/izvoz podatkov iz enega programa 1C v drugega.
• Svetovanje uporabnikom 1C. Pojasnilo oziroma usposabljanje uporabnikov za delo z implementiranimi izboljšavami.
• Posodabljanje spremenjenih konfiguracij. Posodabljamo konfiguracije, ki so jih spremenili naši in tretji programerji 1C.

Prednosti zaupanja izboljšav v 1C nam

Obstaja več razlogov, zakaj je naročanje modifikacij pri našem podjetju donosno:

• Visoka kvaliteta. Naši programerji 1C so visoko usposobljeni strokovnjaki, kar potrjujejo ustrezni certifikati 1C.
• Poceni. Naše podjetje je majhno, a hitro rastoče, odpravljamo posrednike med stranko in programerjem, zaradi tega nam uspeva ohraniti nizke stroške storitev 1C, od 1000 rubljev. na uro specialističnega dela.
• Hiter zaključek dela. Za naše podjetje se ne splača odlašati z dokončanjem vaše naloge. Zato je zagotovljeno, da boste rezultat svojega dela prejeli najkasneje v treh delovnih dneh. Če je naloga majhna, je verjetno, da boste lahko dobili spremembo, ki jo potrebujete, v 1C na dan, ko se obrnete nanjo.
• 100% garancija za izvedbo predelave. Naše podjetje jamči za funkcionalnost izboljšav naših zaposlenih v vašem programu. V enem letu po uvedbi nam lahko sporočite, če odkrijete skrite napake, in v najkrajšem možnem času jih bomo popolnoma brezplačno odpravili.
• Kljub temu, da se geografsko nahajamo v St. Petersburg, Za vas lahko na daljavo opravimo katerokoli delo, ne glede na to, kje na svetu se nahajate.

Standardne in panožne konfiguracije, ki so jih razvili celi oddelki visokokvalificiranih strokovnjakov podjetja 1C, so namenjene vodenju poslovnih evidenc ter oddaji računovodskih in davčnih poročil. Razvijalci so ustvarili metodološke priročnike in že desetletja zagotavljajo tehnološko in svetovalno podporo svojim programom na podlagi norm in priporočil zakonodaje Ruske federacije.

Zdi se, da programi že ponujajo vse: vse vrste dokumentov, imenikov, registrov, mehanizme za delo z njimi, priročne uporabniške vmesnike, demo konfiguracije z izpolnjenimi podatki kot resnične primere računovodstva.

Tipične konfiguracije so napisane za standardno računovodstvo in ciljajo na neko povprečno in skoraj idealno organizacijo.

V resničnem življenju ima lahko poslovno računovodstvo precej zapletene in nestandardne situacije. Računovodje in strokovnjaki želijo videti to ali ono poročilo v nekoliko spremenjeni obliki, standardna možnost nalaganja informacijskih podatkov iz enega programa v drugega (na primer iz računovodstva v trgovino ali iz plač v računovodstvo) ne upošteva vseh posebnosti organizacije.

V takih primerih bodo na pomoč priskočili tisti, ki razumejo strukturo konfiguracije, zmožnosti sistema, njegove specifične mehanizme in znajo te informacije učinkovito uporabiti v praksi. Ne bodo lahko samo izbrali in, ampak tudi spremenili konfiguracijo 1C in razširili njeno standardno funkcionalnost.

Prednosti spremenjene konfiguracije

Da bi lahko naredili tudi manjše spremembe (tiskane oblike dokumentov, izgled dokumentov in referenčnih knjig) standardnih aplikacijskih rešitev, ki temeljijo na platformi 1C:Enterprise 7.7, je bilo potrebno odstraniti konfiguracijo iz podpore. Za platformo, od 8.0 naprej, je ta problem delno rešen: zunanje tiskane obrazce, poročila in obrazce je mogoče spremeniti ali ponovno ustvariti brez spreminjanja konfiguracijske strukture, upravljani obrazci platforme 8.3 pa ponujajo še več možnosti.

Moduli aplikacijskih rešitev 1C:Enterprise, ki so odprti za spremembe, vam omogočajo, da spremenite in prilagodite katero koli aplikacijsko rešitev, »da ustreza vašim potrebam«. Izpopolnitev programa 1C zagotavlja številne prednosti:

1. Prva in najbolj osnovna stvar je, da se programska rešitev prilagodi specifičnim računovodskim zahtevam organizacije.
2. S pomočjo na novo razvitih in vnesenih v strukturo konfiguracije uporabniških pravic in vlog je možno bolj fleksibilno opisati dovoljena in prepovedana dejanja pri delu z dokumenti in imeniki enega ali skupine zaposlenih.
3. Nastavitev in spreminjanje uporabniških vmesnikov (pri upravljanih aplikacijah je veliko implementirano na standarden način).
4. Možnost spreminjanja tiskanih oblik dokumentov, obrazcev in poročil.
5. Spreminjanje mehanizmov internih programskih izračunov, nastavitev kompleksnih izračunov, proizvodnih formul, kompleksnih dokumentnih polj itd.
6. Možnost spreminjanja videza dokumentov, dnevnikov dokumentov, registrov uporabnikov, elementov imenika.
7. Možnost dodajanja vizualne predstavitve predmetov.

Za spreminjanje aplikacijskih rešitev vam ni treba uporabljati ločenih programskih izdelkov – vsa razvojna orodja so vključena v tehnološko platformo.

Slabosti sprememb konfiguracije

Z vsemi očitnimi prednostmi ima sprememba standardnih konfiguracij 1C tudi nekaj neprijetnih posledic:

1. Standardna rešitev je bila odstranjena iz tehnične podpore 1C zaradi možnosti spreminjanja izgubi možnost samodejnega posodabljanja. Če je posodobitev kljub temu izvedena, bodo vse spremembe konfiguracijske arhitekture izgubljene. Posodabljanje programa lahko izvaja samo usposobljen strokovnjak, ki bo vse ročno napisane izboljšave prenesel v posodobljeno različico programa.
2. Pogosto se zgodi, da razvijalci 1C naknadno implementirajo spremenjene samonapisane konfiguracijske mehanizme na standarden način in jih vključijo kot del ene od posodobitev. Tako predhodno izvedene spremembe niso več potrebne.
3. Vsak programer 1C ima tako kot umetnik svoj slog: nekateri izkušeni pišejo bolj kompetentno in spretno, drugi bolj izvirno. Razumevanje kode druge osebe, kadar je to potrebno, je lahko zelo težko, do te mere, da je hitreje napisati modul iz nič, kot spremeniti kodo nekoga drugega. Tako obstaja neka povezava s programerjem, ki spreminja program.
4. Stranka nima vedno dovolj kvalifikacij, da bi sestavila kompetentno tehnično specifikacijo za programerja in jasno pojasnila, kakšen končni rezultat želi videti. Posledično lahko pride do nesporazumov med obema stranema in potrebe po nadaljnjih prilagoditvah naročila.

Pogosto se zgodi, da negotovi uporabniki programskih rešitev 1C:Enterprise, ki niso preučili vseh nastavitev, računovodskih metod, mehanizmov obračunavanja in ne razumejo nastavitev tiskanih obrazcev in poročil, zahtevajo spremembe konfiguracije. V takih primerih je naloga razvijalca identificirati možne standardne načine za reševanje nastalih problematičnih vprašanj, usposobiti uporabnika za njihovo uporabo in spremeniti konfiguracijo le v primerih res nujne potrebe.

Podjetje 1C se je trdno uveljavilo v niši programov za avtomatizacijo dejavnosti podjetij. " Računovodstvo podjetja», « Upravljanje trgovine», « Plača Kadrovsko upravljanje" itd. – so postale vizitke podjetja in se uspešno uporabljajo tako v malih kot velikih podjetjih.

1C izboljšuje svoj razvoj, vendar bo vedno obstajala stranka z nalogami, ki jih standardna funkcionalnost ne pokriva. Tukaj pridejo v igro zunanji razvijalci z dobro idejo, da standardno rešitev spremenijo v skladu z željami naročnika. Na žalost vse izboljšave ne prinesejo trajnega veselja. Konfiguracije, izlopane do neprepoznavnosti, so zanesljiv način, da ostanete brez posodobitev dobavitelja.

Zakaj se to dogaja? Ali gre za težavo v strokovnosti zunanjih razvijalcev ali v nepopolnosti rešitvene arhitekture standardnih rešitev? Po mojem skromnem mnenju obstajajo težave na obeh straneh: 1C ne popularizira zelo pravilnih pristopov k dokončanju standardnih rešitev in mnogi razvijalci raje delajo na staromoden način, ne da bi izgubljali čas z učenjem novih funkcij in branjem "dolgočasne" dokumentacije.

Težava

Preden začnemo govoriti o rešitvah, izrazimo problem. Standardne rešitve ne morejo izpolniti vseh "želj" podjetja in edini način za njihovo implementacijo je, da se obrnete na zunanje/lastne razvijalce. Če »seznam želja« vpliva na standardne mehanizme (predmete, obrazce, algoritme), postane konfiguracija neprimerna za samodejno posodabljanje.

Lahko ga posodobite, vendar boste morali to narediti ročno in obstaja velika verjetnost, da se kaj pokvari. Kot rezultat, stranka prejme: želeno funkcionalnost, težave pri posodabljanju in odvisnost od razvijalcev tretjih oseb (če ni lastnega razvojnega oddelka). Možnost in stroški poznejših posodobitev bodo odvisni od tega, kako pravilno je formaliziral rešitev problema.

Dokumentacija, orodja

Ne glede na to, katero konfiguracijo poskušate spremeniti, je prva stvar, ki jo morate obvladati, postopek dokumentacije. Brez tega vsi nadaljnji nasveti ne bodo prinesli želenega učinka.

Vse izvedene spremembe je treba zabeležiti v sledilnik/wiki/zbirko podatkov itd. Dokumentacija o izvedenih spremembah mora dopolnjevati informacije iz konfiguracijskega repozitorija ali drugega sistema za nadzor različic. Dokumentacije ne bi smeli pisati zaradi dokumentacije; dokumente je treba pravočasno posodobiti.

Če je ta naloga opravljena in razvijalci/upravljavci delajo s takimi dokumenti, se število napak, ki nastanejo med postopkom posodabljanja konfiguracijskih različic pri dobavitelju, bistveno zmanjša.

V resnici razvoj rešitev za platformo 1C še ni ustvaril polne razvojne kulture. Vsi razvijalci ne uporabljajo specializiranih orodij, ki poenostavijo pregled kode, dokumentacijo itd. Ali želite ustvariti rešitve, ki jih je lažje podpirati in vzdrževati? Začnite se učiti o razvojnih praksah, ki ciljajo na druge platforme. Veliko jih je povsem mogoče povleči v 1C.

Konfiguracija

Podjetje 1C in razvijalci industrijskih rešitev se dobro zavedajo, da je ustvarjanje univerzalne škatlaste rešitve, ki je popolnoma pripravljena za delo, nerealno ali težko. Spraviti poslovne procese podjetij na nek skupni imenovalec je nemogoča naloga, najbolj prilagodljiva rešitev pa ostaja možnost samostojnega konfiguriranja.

Dokumentacija o možnih nastavitvah žal nima vedno časa dozoreti skupaj s programsko rešitvijo. Kot rezultat, se kolesa začnejo na novo izumljati: naloge v nekaj klikih se pogosto izvajajo v obliki bergle, močno prepojene z ne najbolj kakovostno kodo.

Potrebujete primere bergel? Prosim! Stranki vedno manjkajo polja v standardnih dokumentih/imenikih in želi dodati svoja. To željo je lažje uresničiti brez odpiranja konfiguratorja. V nastavitvah aktivirajte uporabo dodatnih (glej sliko 1) podrobnosti in nato hitro ustvarite vsa potrebna polja. Tako ustvarjene podrobnosti ne vplivajo na konfiguracijo in so primerne za uporabo v poročilih, zato praktično v ničemer niso slabše od domačih.

Drug pogost primer je ustvarjanje dodatnih tiskanih obrazcev. Nobena standardna konfiguracija ne more naročniku zagotoviti vseh potrebnih tiskanih obrazcev, zato je razvoj manjkajočih oddan zunanjim izvajalcem.

Isti natisnjeni obrazec je mogoče izdelati na različne načine: uporabiti mehanizem, ki ga nudi BSP (knjižnica standardnih podsistemov) ali zapisati kodo neposredno v obrazec/upravljalni modul določenega objekta. Rezultat bo enak - stranka bo dobila, kar želi, le podpora rešitvi bo postala bolj zapletena.

Obstaja veliko slabih primerov modifikacij, vendar se nakazuje en zaključek - preučite delovno orodje čim bolj podrobno. Poiščite rešitve in se lotite standardnih mehanizmov v primerih, ko brez tega res ne morete.

Sodobne standardne rešitve so odlično konfigurabilne, veliko nalog pa je učinkovito rešenih brez odpiranja konfiguratorja. Ne bodite leni, da bi spremljali tehnološke novosti na spletnih mestih, kot je "Skozi zrcalo", in jih uporabljali, ne pa "direktnih" rešitev.

Zunanje tiskarske plošče

Tehnologija ne temelji na platformi, ampak je implementirana z uporabo zmogljivosti BSP (Standardna podsistemska knjižnica). Ker so vse standardne rešitve zgrajene na osnovi BSP, ne bi smelo biti težav s podporo.

Načelo delovanja takšnih zdravil je preprosto. Razvijalec ustvari obdelavo v skladu z določeno predlogo. Izvaja številne metode izvoza, ki vam omogočajo registracijo v sistemu in aktiviranje iz določenih predmetov. Posledično normalna obdelava postane del standardne rešitve in je na voljo za klicanje iz različnih objektov.

Na spletni strani revije si lahko prenesete pripravljen primer takšne obdelave. Obdelava za ustvarjanje tiskanih obrazcev vsebuje dostojno količino storitvene kode, zato si bomo tukaj ogledali najbolj zanimive stvari, ostalo pa boste izvedeli iz izvorne kode. Primer, ki sem ga pripravil, lahko uporabite kot osnovo za razvoj lastnih tiskanih obrazcev. Servisna koda je opisana v modulu za obdelavo.

Če želite ustvariti zunanji tiskani obrazec, morate opisati tri storitvene funkcije: “ Informacije O zunanji obdelavi», « Pečat», « Zaključek Informacije po dokumentu" Morajo biti v modulu za obdelavo, saj do njih bodo dostopali mehanizmi BSP.

Funkcija " Informacije O zunanji obdelavi» opisuje strukturo z osnovnimi informacijami o obdelavi. Našteti podatki so potrebni za uspešno prijavo v mehanizem zunanjih tiskanih obrazcev. Neposredna registracija se izvede z dodajanjem elementa v imenik »Dodatna poročila in obdelava« (glej sliko 2).

Posebno pozornost je treba nameniti naslednjim lastnostim:

• ArrayDestinations. Vsebuje ime metapodatkovnih objektov, za katere se bo registriral tisk. Dovoljenih je več možnosti za določanje predmetov: “Dokument.ReceiptCashOrder”, “Dokument.*”. Zadnji vnos pomeni vse dokumente, ki so na voljo v sistemu.
• Pogled. Določa vrsto zunanje obdelave. Zdravljenja različnih vrst se evidentirajo različno. Za tiskane obrazce navajamo "PrintedForm"; druge razpoložljive vrste so navedene v komentarjih.
• Ime. Ime obdelave v sistemu.
• Identifikator. Uporablja se na več mestih, zato je priporočljivo, da mu date smiselno ime. Najpogosteje je tukaj navedeno ime obdelave, na primer: "HornsICOTravel_Cash Order Layout Formation".
• Modifikator. Če je kot postavitev uporabljen dokument s preglednico, podajte »PrintXML«.

Postopek " Pečat" opravlja servisno vlogo in ga kličejo vgrajeni mehanizmi sistema. V večini primerov njegova vsebina ostane nespremenjena z izjemo parametrov klica »Output TabularDocumentInCollection« (glejte telo postopka).

Obvezno morate navesti identifikator ukaza (ustrezati mora vrednosti " Identifikator", določeno v postopku " Informacije O zunanji obdelavi«) in nastavite sinonim (uporabljen bo v naslovu okna za prikaz ustvarjenega dokumenta preglednice).

Naslednja v vrsti za obravnavo je funkcija »GeneratePrintForm«. Morda se zdi, da se tu oblikuje tiskovna forma, vendar je to le na prvi pogled. Pravzaprav je to še ena storitvena funkcija, ki od razvijalca zahteva:

• Ime za shranjevanje nastavitev tiskanja. Najpogosteje uporabljena predloga je: “PRINT_PARAMETERS_PrintFormName”.
• Postavitev. Metoda GetLayout zahteva, da določite ime postavitve.

Potem pride na vrsto "čarovnija". Zažene se popis objektov, za katere je potrebno izdelati tiskane obrazce. Za vsakega od njih je postopek " Zaključek Informacije po dokumentu«, odgovoren za oblikovanje tiskovne forme, zaradi katere se je začela izdelava obdelave.

Dani algoritem se je izkazal za precej samozadostnega in je primeren za generiranje tiskane oblike tako za en predmet kot za več. Navsezadnje uporabniku nič ne preprečuje, da bi v obrazcu s seznamom izbral več dokumentov in kliknil gumb »Natisni«.

Obdelave za polnjenje

Obstaja stalna potreba po avtomatizaciji izpolnjevanja standardnih dokumentov. Pomembno je razumeti, kako to narediti čim bolj prilagodljivo in ne zapletati postopka za nadaljnjo podporo standardne rešitve.

Splošni princip oblikovanja je podoben izdelavi zunanjih tiskovin. Res je, obstaja več "ampak". Prvič, nekoliko lažje je narediti obdelavo polnjenja (po mojem mnenju), in drugič, na primeru bomo videli, kako je mogoče poenostaviti izpolnjevanje servisnih funkcij (pristop je uporaben pri razvoju zunanjih tiskanih obrazcev).

Začetek procesa razvoja polnilne obdelave je standarden: ustvarimo novo obdelavo in opišemo servisno funkcijo v modulu - "Informacije O zunanji obdelavi" (glej listing 1).

Listing 1. Prazen za obdelavo polnjenja

Parametri registracije = AdditionalReportsAndProcessing.InformationOnExternalProcessing("2.1.2.1"); Registration Parameters.View = AdditionalReportsAndProcessingClientServer.ProcessingTypeFillingObject(); Parametri registracije.Purpose.Add("Document.ContactInsurance Policy"); Registration Parameters.Name = NStr("ru="Izpolnjevanje metod za poravnavo izgub""); RegistrationParameters.SafeMode = False; Registration Parameters.Information = "Demonstrira mehanizem za ustvarjanje obdelave polnil"; Registration Parameters.Version = "1.0.1"; NewCommand = Parametri registracije.Commands.Add(); NewTeam.Presentation = NStr("ru = "Izpolnite metode za poravnavo izgub""); NewTeam.Identifier = "Izpolnite metode poravnave izgube"; NewCommand.Use = AdditionalReportsAndProcessingClientServer.CommandTypeOpenForm(); ReturnRegistrationParameters;

Seznam prikazuje kodo za polnjenje storitvene funkcije, le da so tokrat namesto zamenjave identifikatorjev nizov funkcije izhodne iz ustreznih modulov BSP. V čem je ta metoda boljša od prej prikazane? Je bolj vsestranski in varnejši. Če razvijalci BSP refaktorirajo identifikatorje, bo ustvarjena obdelava prenehala delovati (orientirani, trdo kodirani identifikatorji), vendar se to ne bo zgodilo pri uporabi programskega vmesnika.

Obravnavana funkcija zadostuje za ustvarjanje ogrodja za polnjenje obdelave. Potem je vse odvisno od problema, ki ga rešujemo. Če želite ustvariti obrazec za obdelavo in vzpostaviti povezavo s polnilnim objektom, boste morali v obrazcu opisati več parametrov:

• Ciljni objekti (po meri) – niz sklicev na predmete za polnjenje.
• Identifikator (niz) – identifikator ukaza.
• Dodatna povezava za obdelavo (Povezava do imenika. Dodatna poročila in obdelava).

Za pravilno delovanje je potrebno določiti vse navedene parametre. V večini primerov boste morali delati z "Ciljni objekti". Če je obdelava polnjenja osredotočena na delo z enim samim objektom, ki ga je treba zapolniti, je dovolj, da preverite, ali je zbirka zapolnjena, in, če je uspešno, izvlečete ničelni element.

Posodobitev tipskih obrazcev

Razmislimo o eni od tipičnih nalog, ki se pojavijo pri dokončanju standardnih rešitev. Predstavljajmo si, da smo za določen dokument morali dodati: tabelarični del in več podrobnosti. Te entitete smo potrebovali za rešitev naloge, ki jo je nemogoče ali izjemno problematično izvesti z uporabo konfiguracijske funkcionalnosti BSP.

Po razširitvi standardnih predmetov morate urediti glavni obrazec. V najpreprostejšem primeru prikažite ustvarjene elemente in jim napišite nekaj logike. Trivialno urejanje obrazca je kot smrt, ker ... takoj naletimo na težavo, opisano na začetku članka. Za elegantno reševanje tovrstnih težav na ravni platforme je bil ustvarjen razširitveni mehanizem.

Razširitve so vtičniki, ki vam omogočajo spreminjanje konfiguracije, ne da bi jo neposredno spremenili. Za eno konfiguracijo je mogoče ustvariti več razširitev, ki opravljajo popolnoma različne naloge.

Nove razširitve se ustvarijo v konfiguratorju z uporabo upravitelja razširitev (“Konfiguracija” -> “Konfiguracijske razširitve”). Okno upravitelja prikazuje vse nameščene razširitve (glejte sliko 3) in vmesnik za ustvarjanje novih.

Če želite ustvariti novo razširitev, kliknite gumb »Dodaj« in izpolnite polja v oknu, ki se prikaže (slika 4):

• Ime. Standardna pravila za poimenovanje metapodatkovnih objektov 1C.
• Sinonim.
• Predpona. Dodatna vrednost, ki bo samodejno dodana za vse ustvarjene entitete v razširitvi.

Kliknite »V redu« in pred vami se bo prikazalo dodatno konfiguracijsko drevo (slika 5).

Načelo dela s konfiguracijskim drevesom razširitve se ne razlikuje veliko od dela s standardnim konfiguracijskim drevesom informacijske baze. Razlika je v omejitvah (http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513).

Če povzamemo dokumentacijo, so glavne omejitve postavljene na možnost razširitve konfiguracije z dodatnimi objekti metapodatkov. Na primer, v razširitvah ne morete ustvariti novih dokumentov, imenikov ali drugih entitet za shranjevanje podatkov v bazi podatkov.

Po eni strani je to resna omejitev, po drugi strani pa zanesljiva zaščita pred situacijami, ko se podatki lahko izgubijo zaradi naslednje posodobitve ali nezmožnosti razširitve za delo z novo različico konfiguracije.

Glede na zgoraj povedano sklepamo: ustvarjamo nove entitete za shranjevanje podatkov kot običajno, vendar izvajamo modifikacije in integracije z drugimi deli v razširitvi.

Poskusite v ustvarjeno predlogo vstaviti kateri koli predmet metapodatkov. Svoje poskuse izvajam na konfiguraciji »Računovodski oddelek nekreditne finančne organizacije CORP«, vendar bo vse povedano relevantno za večino rešitev, zgrajenih na podlagi BSP.

Razširil sem dokument " ContInsurance Policy"(dodan tabelarični del in nove podrobnosti), nato pa ustvarjeni razširitvi dodal glavno obliko dokumenta (kontekstni meni "Dodaj razširitvi").

Skupaj z obrazcem bodo preneseni povezani podatki in številni drugi objekti (slika 6).

Razširitveni obrazec lahko spremenite po lastni presoji: dodajte nove kontrole, ustvarite podrobnosti, dodajte logiko itd. Ni mogoče (ni priporočljivo), razen brisanja obstoječih kontrolnikov. Logika obrazca je lahko odvisna od njih, zato je bolje skriti nepotrebne elemente.

Tako ustvarjena razširitev bo takoj pripravljena za uporabo iz upravitelja razširitev jo lahko izvozite v datoteko in jo ponudite za druge konfiguracije. Pomembno je omeniti, da je namestitev razširitev na voljo v načinu Enterprise.

Ideje za podaljške

O razširitvah ne bi smeli razmišljati kot o berglah za spreminjanje predmetov. To je popoln sistem vtičnikov z velikim potencialom za razvoj. Že danes razširitve omogočajo ustvarjanje: podsistemov, skupnih modulov, vlog, skupnih obrazcev, procesiranja, poročil, HTTP storitev, WS povezav, XDTO paketov. Naštetih objektov je dovolj za rešitev številnih realnih problemov.

Na primer, v našem podjetju smo s pomočjo razširitev uspeli rešiti vrsto težav, povezanih z integracijo CRM in korporativnega portala. Mehanizmi izmenjave so bili premaknjeni v razširitve, integracija pa zahteva nekaj klikov miške. Vsi potrebni metapodatkovni objekti so dobavljeni kot razširitev (storitve HTTP, obdelava itd.).

Podobno je z integracijo CIS in CMS. Standardni menjalni mehanizmi v obliki okornega CommerceML niso najbolj priročen in najhitrejši način za nalaganje artiklov na spletno mesto. Razširitve razvijalcev CMS lahko enostavno rešijo to težavo in uporabniku ne nudijo standardnih rešitev za težave z naknadnimi posodobitvami.

Možnost uporabe v razširitvah storitve HTTP močno razširi možne vzorce aplikacij. Integracija z zunanjimi storitvami, izmenjave - vse to je preprosto implementirano s funkcionalnostjo storitev HTTP. Nekaj ​​zanimivih primerov si lahko ogledate v istoimenskem članku, objavljenem v zadnji številki naše revije.

Kaj še lahko naredijo razširitve?

O mehanizmu razširitev konfiguracije lahko govorimo dolgo časa in napišemo ločen članek. Tehnologija se nenehno razvija in dodaja nove zmogljivosti. Najbolj zanimive novosti so se pojavile z izdajo platforme 8.3.9. Prvi koncept prestrezanja/nadomeščanja funkcij v modulih (module extension) je ugledal luč sveta.

Bistvo ideje: omogočiti razvijalcu aplikacije, da spremeni logiko modulov brez neposrednih sprememb. Na primer, obstaja modul "SuperModule" v standardni konfiguraciji, ki vsebuje številne računske funkcije. Razvijalec mora spremeniti logiko več funkcij iz tega modula in razširitev modula je idealna za to nalogo.

S pomočjo novih zmogljivosti razširitve lahko tovrstne težave rešujemo s prestrezanjem klicev. Razširitveni mehanizem zagotavlja dodatna navodila za predprocesor (opombe), ki omogočajo prestrezanje standardnih metod.

Razvijalec ima možnost, da izvede svojo kodo pred standardno, za standardno ali namesto nje. Dovolj je, da opišete ustrezne postopke in pred njimi postavite ustrezno opombo:

&Pred, &Namesto, &Potem. Na primer: &Namesto ("Izračun zavarovalne premije") Funkcija Izračun zavarovalne premije z dodatnimi tveganji (parameter) // Neka koda Konec funkcije

Posodobljeni razširitveni mehanizem vam omogoča dodajanje lastnih obdelovalcev dogodkov za standardne konfiguracije, kot tudi dobavo lastnih skupnih modulov z razširitvijo. Vse zgoraj navedeno bo relevantno za vse vrste modulov, z izjemo modulov navadnih oblik.

Mehanizem za razširitev modula vam omogoča veliko, vendar ga morate uporabljati zelo previdno. Z njegovo pomočjo je lažje kot kdaj koli prej poškodovati in zlomiti standardne mehanizme in ne boste mogli takoj uganiti, od kod prihajajo noge. Ne pozabite, razširitev je lahko več in vsaka ima lahko svojo izvedbo.

Naročnine na dogodke

Razširitve prinašajo pravo čarovnijo, vendar obstaja veliko konfiguracij, ki delujejo na starejših platformah, ki jih nove tehnologije še niso dosegle. Kaj storiti v takih primerih? Kaj pa, če morate pri knjiženju standardnega dokumenta svoje premike dodati v dodatne registre?

Naročnine na dogodke so časovno preizkušena možnost za reševanje tovrstnih težav. Razvijalec mora samo ustvariti svoj skupni modul za opis postopkov/funkcij, ki se kličejo kot odziv na določen dogodek, in konfiguraciji dodati potrebne naročnine. V tem primeru to ne bo vplivalo na vzdrževanje konfiguracije in razvijalec bo lahko izvedel svojo kodo po obdelovalcih za standardne konfiguracijske objekte.

Programsko spreminjanje obrazcev

Kako spremeniti standardne obrazce brez uporabe zmožnosti razširitvenega mehanizma? Programsko ustvarjanje elementov je zelo preprosto. Metode ni mogoče imenovati univerzalne, ker še vedno morate vnesti kodo v obrazec predloge. Res je, v tem primeru boste morali dodati eno vrstico, ki bo potegnila postopek iz splošnega modula z algoritmom za ustvarjanje kontrol obrazca.

Spreminjanje običajnih obrazcev s predlagano metodo je problematično (vpliva na položaj pikslov elementov), ​​pri nadzorovanih pa, nasprotno, ni težav. Če iz nekega razloga uporaba razširitev ni mogoča, je programsko spreminjanje obrazcev edini pravilen in manj zahteven za podporo način spreminjanja standardnih obrazcev.

Sprememba vloge

Pogosto sem videl, kako razvijalci poskušajo posodobiti standardne vloge. To je najslabša ideja, ki si jo lahko zamislite. Recimo samo – nikoli ne menjajte tipičnih vlog. Če morate razširiti pravice za delo z novimi konfiguracijskimi objekti, dodajte ločene vloge in jih dodelite uporabniku skupaj s standardnimi.

V idealnem primeru poskušajte čim bolj razdeliti vloge. Dodelite vloge za branje in pisanje dokumentov/imenikov, ne združujte pravic v eno vlogo. Seveda tega ne bi smeli narediti za vsak dokument/konfiguracijski imenik, vendar morate to storiti vsaj za skupine predmetov. Razmislimo o primeru - "Dokumenti o gotovini". Ti vključujejo vsaj "PKO" in "RKO". To olajša ustvarjanje prilagodljivih varnostnih profilov (FSP).

Zakaj ne morete spremeniti standardnih vlog? Prvi razlog: tipične vloge se pogosto menjajo. Vsaka posodobitev standardne konfiguracije uvaja nove objekte, standardne vloge pa so ustrezno spremenjene. Posledično boste morali nenehno primerjati vloge, da ne bi pomotoma prepisali pravic dostopa do svojih objektov. Drugi razlog: pomanjkanje razumnega mehanizma za primerjavo vlog.

Ne bodi len

To je ravno stavek, s katerim bi rad zaključil ta članek: "Ne bodi len." Nikogar ne želim užaliti, ampak želim samo poudariti, da nič ne miruje. Tehnologije se razvijajo, vendar imajo razvijalci dober spomin na slabe dogodke. Izpopolnjevanje standardnih konfiguracij je vedno spremljalo bolečino, danes pa se stanje popravlja.

Pomembno je ne sedeti, ampak slediti razvoju industrije in začeti uporabljati nove mehanizme pri reševanju vsakdanjih težav. Spodbujajte uporabo novih vzorcev, posredujte informacije sodelavcem, ki so malo »zataknjeni« v preteklosti. Bolj kot razvijalci izberejo nove izdelke, hitreje bodo odkrite napake in obstaja velika verjetnost, da bo 1C še naprej aktivno delal na izboljšavah.