Paano magbukas 

Pagpino ng mga karaniwang 1c na configuration. Pagdaragdag ng Mga Paunang Natukoy na Elemento

Kailangan mo bang palawakin ang functionality ng 1C? Kailangan mo ba ang programa upang malutas hindi lamang ang pamantayan, kundi pati na rin ang mga partikular na problema ng iyong negosyo? Ang serbisyo sa pagbabago ng 1C mula sa Active-IT ay makakatulong sa iyong mabilis na malutas ang mga isyung ito.

Nagsasagawa kami ng mga pagbabago sa mga karaniwang 1C na pagsasaayos ng anumang antas ng pagiging kumplikado: mula sa paglikha ng indibidwal nakalimbag na mga form bago magpakilala ng algorithm para sa pagkalkula ng mga bonus para sa mga oras ng trabaho, atbp.

Oras ng turnaround- hanggang 5 araw. Sa kaso ng pagkaantala ng hanggang 10 araw, gagawa kami ng mga pagbabago para sa iyo nang walang bayad.

Ang isa pang bentahe ng pakikipagtulungan sa amin ay palagi naming ginagawa ang aming trabaho nang may mabuting pananampalataya. Hindi kami nagtatrabaho ayon sa "nakuha" na pamamaraan teknikal na gawain==> tapos na ang trabaho ==> inabot ito at nakalimutan." Natanggap namin ang teknikal na gawain, isagawa ang aming trabaho nang mahusay, hayaan kang suriin ang resulta at, kung kinakailangan, ayusin ang rebisyon nang walang karagdagang bayad.

Ang halaga ng isang 1C programmer

Gastos ng pagbabago ng configuration: 1500 kuskusin. bawat oras ng gawain ng programmer.

Bilang resulta makakakuha ka ng:

  • Pakikipagtulungan sa mga makaranasang programmer.
  • Paglikha at pagpapatupad ng mga pagpapabuti ng ganap na anumang antas ng pagiging kumplikado.
  • Pagkumpleto ng trabaho sa pinakamaikling posibleng panahon - hanggang 5 araw.
  • Garantiyang ibabalik ang pera sa kaso ng pagkaantala ng oras.
  • Pagtitiyak ng kalidad.

Mag-order ng mga pagbabago sa 1C Accounting mula sa Active-IT!
I-customize ang 1C na trabaho sa mga detalye ng iyong negosyo sa amin.

Halos lahat ng mga proyekto sa halos anumang malaking kumpanya ng 1C integrator ay binubuo ng pagpino ng mga karaniwang pagsasaayos at pangunahing naglalayong i-optimize ang accounting aktibidad sa ekonomiya pag-aayos at pagsusumite ng naaangkop na kinokontrol na pag-uulat. At ito naman, ay nangangahulugan na sa hinaharap ang mga ipinatupad na solusyon ay kailangang baguhin alinsunod sa madalas na pagbabago ng batas. Sa pagsasagawa, halos palaging nangangahulugan ito ng pag-update sa mga inilabas ng mga karaniwang pagsasaayos kung saan nakabatay ang solusyon, at pag-angkop sa mga pagbabagong nagawa na alinsunod sa mga pagbabago sa susunod na paglabas.

Kadalasan ang isang proyekto ay hindi matatawag na ganap na matagumpay kung ang kliyente ay hindi mananatili sa organisasyon ng integrator para sa suporta. At kung sumunod ka sa mahigpit na mga patakaran para sa pagbabago ng mga karaniwang pagsasaayos, pagkatapos ay pagkatapos ng paggastos napakaliit na oras sa yugto ng pag-unlad, magagawa mo makatipid ng marami, maraming oras at nerbiyos sa hinaharap sa patuloy na pag-update ng binagong configuration. Sa kabaligtaran, ang isang bastos, "walang pakialam" na saloobin sa disenyo ng code, ang pagpili ng mas mabilis at mas simple sa halip na mga tamang paraan upang ipatupad ang mga gawain ay maaaring gawing isang tunay na impiyerno upang suportahan ang pag-update ng resultang configuration. Sa hinaharap, magreresulta ito sa malalaking oras ng pag-update, isang matalim na workload ng mga developer sa panahon ng pag-uulat, malaking bilang ng mga error pagkatapos ng pag-update, hindi kasiyahan ng customer, atbp.

Nasa ibaba ang isang hanay ng mga panuntunan sa pag-develop sa mga karaniwang configuration, na lubos na magpapadali sa karagdagang mga update sa configuration. Ang code na ito ay unti-unting ipinanganak mula sa maraming taon ng karanasan ng isang malaking bilang ng mga developer ng isang kahanga-hangang kumpanya, at, sa aking opinyon pinakamalalim na paniniwala, ay dapat na mandatory para sa lahat ng mga developer, kahit saang departamento/proyekto/direksyon sila nagtatrabaho.

1. Ang konsepto ng pagliit ng "pagkasira" ng isang karaniwang pagsasaayos

Kung ang binagong karaniwang configuration ay nilayon na ma-update habang inilalabas ang mga bagong release, dapat ang mga developer laging tandaan ito at gumawa ng mga hakbang upang mapadali ang pag-update. Dapat mong palaging piliin ang mga paraan ng paglutas ng mga problema na magbibigay mas madaling pag-update ng configuration sa hinaharap, kahit na medyo mas mahirap ipatupad ang mga ito. Siyempre, sa kondisyon lamang na ang pamamaraan na mas maginhawa para sa pag-update ay walang malubhang mga disbentaha sa lugar ng pagganap, pagkakaunawaan ng code, atbp.

2. Mga pagbabago sa code sa pagkomento:

Ganap na lahat ng mga pagbabago sa program code ng mga module ay dapat magkomento. Ang isang bloke ng mga linya na sumailalim sa pagbabago ay dapat na napapalibutan ng mga linya ng komento na may espesyal na format. Ang prinsipyo ng pagbuo ng mga linyang ito ay ipinapakita sa sumusunod na halimbawa:

//++ VION 07/20/2016 0001234 Pagtatapos sa simula //-- VION 07/20/2016
  • //++ - simula ng block
  • //— — dulo ng block
  • VION - pangalan (o palayaw) ng developer
  • 0001234 - numero ng gawain ayon sa tracker, inilagay lamang sa pambungad na komento, upang ang bawat pagbabago ng code ay lilitaw sa mga resulta ng isang pandaigdigang paghahanap ayon sa numero ng gawain nang isang beses lamang
  • Mga pagpapabuti sa simula— isang di-makatwirang komento, ginagamit kung kinakailangan, ngunit kung walang numero ng gawain, kung gayon ang isang maikling paliwanag na teksto ay kinakailangan

Ang mga komento ay inilaan upang i-highlight ang mga pagbabago kumpara sa karaniwang pag-andar. Kung binago ng isang developer ang teksto ng kanyang sariling pagbabago pagkalipas ng ilang panahon bilang bahagi ng parehong gawain, kung gayon ang mga naturang pagbabago ay hindi ikokomento nang hiwalay (at ang umiiral na panlabas na komento ay hindi rin binago). Kung ang isang developer ay gumawa ng mga pagbabago sa kanyang teksto, ngunit para sa ibang gawain, o ang code na isinulat ng isa pang developer ay binago, pagkatapos ay ang pagkomento ay dapat gamitin.

Ang mga blangkong komento ay nakahanay sa kaliwang gilid ng na-edit na bloke ng code. Ang mga halimbawa sa ibaba ay nagpapakita kung paano gamitin ang pagbabago ng pagkomento:

2.1 Paglalagay ng code

Halimbawa:

Pamamaraan Sa Pagbubukas() Kung Ito ay Bago() Pagkatapos Punan ang Mga Patlang Sa pamamagitan ng Default(); tapusin kung; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 07/20/2016 SetFieldVisibility (); Katapusan ng Pamamaraan

2.2 Pag-alis ng code

Halimbawa:

Procedure OnOpen() //++ VION 07/20/2016 0001234 //If This is New() Then // Fill in the Default Fields(); //Tapusin kung; ConfigureAdditionalItems(); //-- VION 07/20/2016 SetFieldVisibility (); Katapusan ng Pamamaraan

2.3 Pagbabago ng umiiral na code

Kapag binabago ang umiiral na code, ang lumang bloke ay dapat munang magkomento, pagkatapos ay isang bagong bersyon ang isusulat.

Halimbawa:

Procedure OnOpen() If This Is New() Then //++ VION 07/20/2016 000123 //Fill Fields By Default(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 07.20.2016 EndIf; SetFormElements(); SetFieldVisibility (); Katapusan ng Pamamaraan

2.4 Pagdaragdag ng mga pamamaraan at function sa isang module

Para sa mga karagdagang pamamaraan at pag-andar, pati na rin para sa pagdedeklara ng mga variable ng module ng mga karaniwang bagay, ang mga sumusunod ay nalalapat: karagdagang mga patakaran pag-format ng mga komento:

  • Hindi ang bloke ng mga idinagdag na pamamaraan sa kabuuan ang binibigyang komento, ngunit bawat isa idinagdag na pamamaraan o function sa magkahiwalay.
  • Ang pambungad na komento ay napupunta sa linya bago ang procedure o function header, at ang pangwakas na komento ay napupunta sa parehong linya, kung saan nakalagay ang "End of procedure" o "End of procedure", na pinaghihiwalay ng space.
  • Ang pagkomento sa mga pagbabago sa loob ng mga kasalukuyang pamamaraan ay isinasagawa gamit pangkalahatang tuntunin.

Halimbawa:

//++ VION 07/20/2016 000123 Variable mSettingField Filling; Pamamaraan ModifyFormProgrammatically () ... ... EndProcedure//-- VION 07/20/2016 //++ VION 07/20/2016 000123 Pamamaraan PetsaShipmentProcessingSelection () ... ... EndProcedure//-- VION 07.20.2016

Binibigyang-daan ka ng panuntunang ito na madaling ilipat ang mga pagbabago sa isang module sa isang "procedural na paghahambing" ng mga configuration.

Kung ilalagay mo ang pangwakas na komento sa susunod na linya:

Pagkatapos, sa panahon ng "paghahambing sa pamamaraan", ang komentong ito ay makikilala bilang isang paglalarawan ng susunod na pamamaraan sa teksto, na ituturing na nagbago.

3. Pagdaragdag ng mga top-level na bagay

Mga pangalan mga bagay sa pinakamataas na antas, nilikha sa pagsasaayos, Kailangan dapat magsimula sa prefix ng iyong kumpanya o isang partikular na prefix ng proyekto. Bilang isang tuntunin, ito ay binubuo ng dalawa o tatlo malaking titik at salungguhit, halimbawa AB_. Alinsunod dito, ang mga nilikha na bagay ay tatawagin AB_Bagong Direktoryo, AB_NewInformationRegister, AB_NewDocument atbp.

Ang mga kasingkahulugan (mga pangalan na nakikita ng user) ng mga idinagdag na bagay sa pinakamataas na antas ay dapat magsimula sa isang prefix na nakapaloob sa mga panaklong: (AB). Bilang resulta, ang mga bagay na ito ay makikitang mai-highlight sa mga listahan at ipapangkat sa simula ng mga ito (na nagpapadali sa pagsubok at paggamit).

Sa komento ng nilikhang bagay, dapat mong ipahiwatig ang pangalan ng developer, petsa at numero ng gawain, katulad ng idinagdag na code, ngunit walang mga palatandaang "++". Titiyakin nito na ang object ng pagsasaayos ay nauugnay sa gawain, na natagpuan ng pandaigdigang paghahanap.

Halimbawa: Gumawa ng direktoryo ng "Mga Proyekto".

Mga Pagkilos ng Developer: ang sumusunod na direktoryo ay nilikha sa pagsasaayos:

  • Pangalan: AB_Projects
  • Synonym: (AB) Projects

4. Pagdaragdag ng mga subordinate na bagay

Ang paraan para sa pagdaragdag ng mga detalye ng configuration object ay depende sa kung aling configuration object idinaragdag ang property: sa isang configuration object na ginawa ng supplier karaniwang solusyon(ibig sabihin, isang bagay sa ilalim ng suporta) o isang bagay na idinagdag bilang bahagi ng kasalukuyang proyekto (ibig sabihin, mayroon nang prefix).

4.1 Pagdaragdag ng mga subordinate na bagay sa karaniwang mga bagay sa pagsasaayos

Ang mga subordinate na bagay na idinagdag sa mga umiiral na (karaniwang) configuration object ay dapat maging prefix: AB_Mga Karagdagang Props, AB_NewTabularPart, AB_FormUserSettings, AB_LayoutSpecialInvoice. Ngunit sa parehong oras, ang mga kasingkahulugan ng naturang mga subordinate na bagay ay nilikha walang prefix.

Sa komento ng nilikhang bagay, dapat mong ipahiwatig ang pangalan ng developer, petsa at numero ng gawain, katulad ng . Titiyakin nito na ang object ng pagsasaayos ay nauugnay sa gawain, na natagpuan ng pandaigdigang paghahanap.

Halimbawa: Lumikha ng katangiang "Proyekto" ng dokumentong "Paunang pagbabayad".

Mga Pagkilos ng Developer: ang sumusunod na katangian ay nilikha sa pagsasaayos:

  • Pangalan: AB_Project
  • Kasingkahulugan: Proyekto
  • Komento: // VION 07/20/2016 000123

4.2 Pagdaragdag ng mga subordinate na bagay sa mga bagay na idinagdag sa loob ng isang proyekto

Ang mga subordinate na bagay na idinagdag sa mga top-level na bagay na idinagdag sa pagsasaayos sa loob ng proyekto, ibig sabihin, naglalaman na ng prefix sa pangalan, ay idinagdag. walang prefix. Ang mga kasingkahulugan para sa mga subordinate na bagay ay nilikha din walang prefix.

Sa komento ng nilikhang bagay, dapat mong ipahiwatig ang pangalan ng developer, petsa at numero ng gawain, katulad ng . Titiyakin nito na ang object ng pagsasaayos ay nauugnay sa gawain, na natagpuan ng pandaigdigang paghahanap. Ang komento ay maaaring tanggalin kung ang mga detalye ay ginawa bilang bahagi ng parehong gawain bilang ang pinakamataas na antas na bagay mismo.

Halimbawa: Gumawa ng attribute na “Responsible” sa direktoryo ng “(AB) Projects”.

Mga Pagkilos ng Developer: Kung ang gawain ay iba sa isa kung saan ginawa ang direktoryo ng "(AB) Projects", ang mga sumusunod na detalye ay ginawa sa configuration:

  • Pangalan: Responsable
  • Kasingkahulugan: Responsable
  • Komento: // VION 07/20/2016 000456

5. Pagdaragdag ng mga paunang natukoy na elemento

Kapag nagdaragdag ng mga paunang natukoy na elemento ng direktoryo, mga chart ng mga uri ng katangian at mga chart ng mga account, dapat mong gamitin ang parehong mga panuntunan tulad ng kapag nagdaragdag ng mga subordinate na bagay ( tabular na bahagi, mga detalye) sa mga top-level na bagay.

5.1 Pagdaragdag ng mga paunang natukoy na elemento sa karaniwang mga bagay sa pagsasaayos

Ang mga paunang natukoy na elemento para sa karaniwang mga bagay sa pagsasaayos ay kinakailangang idagdag may unlapi. Ang pangalan ay ibinigay walang prefix.

Halimbawa: Magdagdag ng paunang-natukoy na account 10.15 sa "Cost Accounting" na chart ng mga account – Mahigpit na mga form sa pag-uulat.

Mga Pagkilos ng Developer: Idagdag ang sumusunod na paunang natukoy na account:

  • Pangalan: AB_FormsStrictReporting
  • Code: 10.15
  • Pangalan: Mahigpit na mga form sa pag-uulat

Kung kailangan mong palitan ang pangalan ng isang paunang natukoy na elemento ng isang tipikal na configuration object (halimbawa, isang invoice), dapat mong iwanan ang object mismo na hindi nagbabago, at isagawa ang pagpapalit ng pangalan sa programmatically sa isang espesyal na .

5.2 Pagdaragdag ng mga paunang natukoy na elemento sa mga bagay na idinagdag sa loob ng isang proyekto

Ang mga paunang natukoy na elemento ay idinaragdag sa mga bagay sa pagsasaayos na idinagdag sa loob ng proyekto, ibig sabihin, naglalaman na ng prefix sa kanilang pangalan walang prefix sa pangalan at titulo.

6. Paggamit ng mga karaniwang module at ang kanilang mahigpit na istraktura

Ang mga pamamaraan at pag-andar na paulit-ulit na ginagamit sa pagsasaayos, mga processor para sa mga subscription at nakagawiang gawain ay matatagpuan sa mga karaniwang module. Para sa mga layuning ito dapat kang magdagdag sariling mga module, idinagdag ng mga top-level na bagay, na nag-iiwan ng mga karaniwang module hindi nagbabago. Ang mga sumusunod na karaniwang module ("AB_" ay ang prefix) ay magiging kapaki-pakinabang sa panahon ng pagbuo:

  • AB_Pangkalahatang Layunin (kliyente, server, panlabas na koneksyon) - upang mapaunlakan ang mga karaniwang pamamaraan at function.
  • AB_Server (server lang) - para sa mga pamamaraan at function na dapat isagawa sa kapaligiran ng server.
  • AB_Global - para sa mga pamamaraan at pag-andar na hindi maginhawang tumawag sa karaniwang paraan (sa pamamagitan ng pangalan ng module at panahon).
  • AB_Privileged - para sa mga pamamaraan at function na palaging kailangang isagawa nang may ganap na karapatan.
  • AB_Muling gamitin - upang i-cache ang mga return value ng ilang function.

Maaari mong ilagay ang code ng mga functional block sa magkahiwalay na karaniwang mga module malaking volume, sa kasong ito, ang pag-debug ng naturang code ay pinasimple kapag gumagamit ng configuration store. Sa ibang mga kaso, dapat tiyakin ng developer na may available na angkop na karaniwang module bago magdagdag ng bagong module sa configuration.

7. Paggamit ng mga subscription at ang kanilang mahigpit na istraktura

Upang iproseso ang iba't ibang mga kaganapan na nauugnay sa karaniwang mga bagay sa pagsasaayos, dapat mong gamitin ang mekanismo ng subscription sa halip na gumawa ng mga pagbabago sa mga module ng mga bagay mismo, kung maaari.

Para sa bawat kaganapan ay maaaring magkaroon hindi hihigit sa isang subscription(bilang isang metadata object), dapat ilagay ang handler nito at ang nauugnay na code hiwalay na karaniwang module(upang pataasin ang parallelism ng trabaho ng mga developer sa storage). Ang pangalan ng subscription at ang karaniwang pangalan ng module ay dapat na ay pareho At tumutugma ang kaganapang pinoproseso. Ang pinagmulan ng subscription ay ipinahiwatig Lahat mga bagay na posibleng posible para sa pagproseso (lahat ng mga direktoryo, lahat ng mga dokumento, atbp.).

Ang pamamaraan ng tagapangasiwa ng subscription ay dapat maglaman ng mga tawag sa mga subprocedure na nagsasagawa ng mga kinakailangang pagkilos. Naa-access ang mga ito depende sa uri ng pinagmulan, pati na rin sa kinakailangang pagkakasunud-sunod. Ang pagkomento sa module ng subscription kapag nagdadagdag ng code para sa mga bagong gawain ay isinasagawa.

Halimbawa: Kapag nagpo-post ng dokumentong “Advance Payment,” gumawa ng mga entry sa accumulation register na “(AB) Project Costs”.

Mga Pagkilos ng Developer:

1. Lumikha ng isang subscription na "AB_DocumentsProcessingProcessing" (kung ang naturang subscription ay hindi pa nagawa nang mas maaga), tukuyin ang lahat ng mga dokumento bilang pinagmulan, ang kaganapan ay "ProcessingProcessing".

2. Lumikha ng isang karaniwang module ng server na "AB_DocumentsProcessing".

3. Sa module, gumawa ng export procedure na “ProcessingProcessing”. Piliin ang pamamaraang ito bilang tagapangasiwa para sa naunang ginawang subscription. Sa pamamaraan, depende sa uri ng dokumento, ang mga kinakailangang humahawak ay tinatawag.

4. Ang module ng dokumentong "Paunang Pagbabayad" ay dapat manatiling hindi nagbabago.

8. Pag-edit ng mga form

8.1 Pag-edit ng mga hugis ng mga karaniwang bagay

Kung ang pagbabago sa isang karaniwang form (parehong regular at pinamamahalaan) ay maliit (halimbawa, pagdaragdag ng ilang bagong detalye sa form), kung gayon ang naturang pagbabago ay dapat na ganap na isagawa sa pamamagitan ng programmatically. Ibig sabihin, ang mga pagbabago ay ginagawa lamang sa form na module, at ang form mismo ay nananatili sa configurator hindi nagbabago. Maaaring makita ng ilang developer na medyo mahirap ang paraan ng pag-edit ng form na ito sa simula. Gayunpaman, ang pagkakaroon ng sapat na karanasan sa mga form na nagbabago ng program, ang pagdaragdag ng isang elemento ay tatagal ng hindi hihigit sa 3-5 minuto. Ang oras na ginugol ay nagbabayad nang maraming beses sa mga kasunod na pag-update sa karaniwang pagsasaayos.

Halimbawa: Sa pangunahing anyo ng dokumentong "Paunang pagbabayad", idagdag ang detalyeng "(AB) Project".

Mga Pagkilos ng Developer: Sa form handler "When CreatedOnServer" idagdag ang procedure na "EditFormProgrammatically()". Sa pamamaraang ito, idagdag ang nais na elemento sa mga elemento ng form.

Posibleng lumikha ng isang hiwalay na module na maglalaman ng lahat ng kinakailangang mga pamamaraan at pag-andar para sa pagbabago ng mga karaniwang form.

Sa karaniwang mga pagsasaayos batay sa BSP 2, mayroon nang espesyal na paggana para sa mga layuning ito:

Sa pamamaraang "Kapag CreateOnServer" ng pangkalahatang module na "Modification of Configuration Overridden" maaari mong tawagan ang iyong sariling handler.

Kung saan, sa pamamagitan ng pangalan ng form, maaari mong tawagan ang kinakailangang pamamaraan na may programmatic modification ng form.

Kung plano mong magdagdag sa form isang malaking bilang ng mga elemento o mga bahagi ng tabular, posible rin ang manual reshaping. Sa kasong ito, inirerekumenda na lumikha ng isang hiwalay na tab sa form at ilagay ang lahat ng kinakailangang elemento dito. Gagawin nitong mas madali ang mga pag-update ng form sa hinaharap.

8.2 Pag-edit ng mga hugis ng mga bagay na idinagdag sa loob ng proyekto

Ang mga anyo ng mga bagay na idinagdag sa loob ng proyekto (iyon ay, ang mga may prefix sa kanilang pangalan) ay na-edit sa karaniwang paraan.

9. Mga prinsipyo ng pagtatrabaho sa mga tungkulin

Ang mga generic na tungkulin ay dapat palaging iwanang hindi nagbabago (kung maaari). Ito ay kinakailangan upang mapadali ang pag-update ng binagong configuration mula sa mga bagong release, dahil ang paghahambing at pagpapanumbalik ng mga tungkulin ay isang kumplikado at maingat na proseso.

Ang mga karapatan sa mga bagay na idinagdag sa pagsasaayos ay dapat italaga sa bago mga tungkuling nilikha para sa layuning ito.

Dapat ipatupad ang mga paghihigpit sa pag-access sa data na pinahihintulutan ng mga karaniwang tungkulin sa pamamagitan ng programming, habang posible. At kapag ang naturang pagbabawal ay magiging napakahirap ipatupad sa programmatically (o ang ganitong solusyon ay hindi mapagkakatiwalaan) ay pinahihintulutan na baguhin ang mga karaniwang tungkulin. Ang mga pagbabago sa mga karaniwang tungkulin ay dapat ang pinakamababang kinakailangan at dokumentado. Halimbawa, kung kailangan mong baguhin ang teksto ng mga paghihigpit sa pag-access sa isang tungkulin (RLS), ayon sa , dapat mong ikomento ang lahat ng sample na code, at pagkatapos ay idagdag ang code na may mga kinakailangang pagbabago.

10. Mga panlabas na ulat at pagproseso

Karamihan sa mga pagpapabuti sa system ay maaaring isagawa gamit ang Mga Karagdagang ulat at mekanismo ng pagproseso.

Sa mga pagsasaayos batay sa BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0, atbp.) Ang mekanismong ito ay makabuluhang pinalawak. Sa tulong nito, nang hindi binabago ang pagsasaayos, posible na lumikha ng mga panlabas na ulat at pagproseso (kasama ang paglalagay ng utos ng paglulunsad sa interface ng command at ang kakayahang i-configure ang pag-access para sa iba't ibang mga gumagamit), pagproseso ng pagpuno ng isang dokumento, pagproseso ng paglikha ng isang dokumento batay sa, karagdagang mga naka-print na form, atbp.

Nakatulong ba sa iyo ang artikulong ito?

Ang 1C 8.2 at 8.3 ay may napakakahulugan competitive advantage— ang kakayahang baguhin ang mga karaniwang configuration ng 1C at bumuo ng sarili mong mga solusyon batay sa platform. Nakamit ito salamat sa built-in na kapaligiran sa pag-unlad na ang sistema ay may sariling .

Ang kumpanya ng 1C, na nag-aalala tungkol sa mga customer nito, ay nagsisikap na gumawa ng mga solusyon na pinakaangkop sa lahat ng mga organisasyon sa merkado. Ang bawat kumpanya, tulad ng isang tao, ay natatangi. Ito ay isang uri ng "tuning" ng 1C configuration upang umangkop sa iyong mga pangangailangan.

Anong mga bagong bagay ang karaniwang ginagawa sa 1C?

Bilang isang patakaran, ang mga pagbabago ay may kinalaman sa bahagi ng interface ng programa. Gayunpaman, mayroon ding mga seryosong pagbabago sa mga pagsasaayos - ang pagpapakilala ng mga bagong subsystem, mga bagong algorithm.

Mga halimbawa ng mga pagbabago sa 1C 8.3:

  • Pagse-set up ng mga karapatan ng user at mga default na halaga. Flexible na pagsasaayos ng mga karapatan - napaka mahalagang punto. Ang mga user at ang kanilang mga karapatan ay isang bagay na kung wala ito ay imposibleng magtrabaho sa anumang multi-user system.
  • Pagbabago at paglikha ng bago nakalimbag na mga form. Ang naka-print na form ay isang papel na katumbas ng isang dokumento sa 1C. Posible na parehong pinuhin ang mga dati at magdagdag ng mga bago. Ang pag-edit ng mga naka-print na form ay maaaring gawin nang hindi binabago ang configuration.
  • Paglikha ng mga bago at pagbabago ng mga umiiral na mga ulat. Ang ulat ay ang huling produkto ng anumang analytical sistema ng impormasyon, kabilang ang 1C Enterprise. Maaaring baguhin ang mga ulat sa programa nang hindi binabago ang configuration.
  • . Bilang isang patakaran, ang isang hindi teknikal na savvy na kliyente ay hindi palaging makakasulat ng mga karampatang teknikal na detalye para sa mga programmer. Kasabay nito, ang gawain mismo ay maaaring makumpleto alinman sa loob ng bahay o ng mga third-party na kumpanya.
  • Pagdaragdag sa Configuration bagong functionality. Ang 1C ay isang unibersal na sistema at hindi maaaring isaalang-alang ang mga kagustuhan ng bawat kliyente. Ang mga karampatang espesyalista ay magagawang makabuluhang palawakin ang pag-andar ng programa at isama ito nang "walang putol".
  • Pag-optimize ng pagganap ng 1C. Ang 1C Enterprise system ay isa sa mga nangunguna sa segment nito sa mga tuntunin ng pagganap. Gayunpaman, upang makuha pinakamataas na bilis Para gumana ang system, kailangan ang ilang pagbabago, na naka-customize sa IT infrastructure ng kliyente.

Presyo para sa isang oras ng trabaho ng isang 1C specialist

Ang halaga ng trabaho para baguhin ang mga karaniwang configuration ng 1C ay karaniwang tinatantya sa mga oras ng tao.

Well, lahat ng iba pa, maligayang pagdating sa pusa.

Mga panuntunan at diskarte para sa pag-finalize ng mga karaniwang 1C configuration para mapadali ang kanilang karagdagang suporta at pag-update

Kaya, kapag gumawa kami ng isang proyekto (sa salitang "Kami" ang ibig kong sabihin ay ang lahat ng mga taong kasangkot sa pag-automate ng mga proseso ng negosyo), umaasa kami na pagkatapos ay maayos itong dumaloy sa suporta. Bilang isang patakaran, kung ang lahat ay tapos na nang maayos at ang customer ay nasiyahan, ito ang mangyayari.

Ang suporta ay nailalarawan sa pamamagitan ng isang napaka-espesipikong hanay ng mga gawain - ito ay maaaring mga gawain sa konsultasyon tulad ng "saan nagmula ang mga numerong ito" o upang itama ang ilang hindi maintindihan na mga error, atbp. Ngunit, dahil halos lahat ng mga proyekto ay kinabibilangan ng pag-angkop ng ilang karaniwang solusyon sa mga pangangailangan ng customer, ang configuration na may suporta ay kailangang pana-panahong i-update sa mga bagong release:

  • Kung susundin mo ang ilang mga panuntunan sa pag-unlad, kung gayon, na gumastos ng napakakaunting paggawa sa yugto ng proyekto, sa hinaharap ay makakatipid ka sa pagpapanatili at pag-update ng mga pagsasaayos.
  • At kabaligtaran, kung sa yugto ng proyekto mayroong ilang mga error, pagmamadali, o hindi tamang pag-format ng code, pagkatapos ay maaaring magresulta ito sa isang tunay na impiyerno ng suporta at pag-update.

Nagkaroon na ba ng sinuman na mag-update ng pagsasaayos na muling isinulat nang walang anumang mga marka ng pagkakakilanlan? Naiintindihan mo ba kung ano ang sakit na ihambing ang lumang configuration ng vendor sa bagong configuration, manu-manong i-parse ang bawat case ng "dalawang beses na binago" kapag inihambing sa kasalukuyang configuration, atbp. Ang lahat ng ito ay medyo may problema.

9 simpleng panuntunan para sa pagdidisenyo ng mga pagbabago sa karaniwang mga pagsasaayos

1. Ang konsepto ng pagliit ng "pagkasira" ng isang karaniwang pagsasaayos

Ang una ay hindi kahit isang panuntunan, ito ay isang uri ng konsepto para sa pagliit ng "pagkasira" ng isang karaniwang pagsasaayos.

Ang kakanyahan nito ay dapat mong palaging piliin ang mga paraan ng paglutas ng mga problema na magbibigay ng mas madaling pag-update ng pagsasaayos sa hinaharap, kahit na ang gayong solusyon ay medyo mas mahirap ipatupad. Malinaw na dapat itong gawin nang walang panatismo, sa loob ng makatwirang mga limitasyon, ngunit dapat palaging tandaan ng developer na ang pagsasaayos ay nananatiling nasa ilalim ng suporta, at pag-aralan kung gaano magiging kumplikado ang kanyang code sa pag-update ng pagsasaayos sa hinaharap, sa pagpili ng pinakaangkop na solusyon.

2. Mga pagbabago sa code sa pagkomento

Ang pangalawang tuntunin ay ang l anumang pagbabago sa code ay dapat magkomento.

Sa aming kumpanya ginagamit namin ang sumusunod na pamamaraan:

  • Sa simula ng pagbabago ay pambungad na komento(nagsisimula sa mga palatandaan //++ )
  • Sa dulo - pangwakas na komento(nagsisimula sa mga palatandaan //-- )
  • A ang mga pagbabagong ginawa ng developer ay nasa gitna.

Ito ay isang mandatoryong panuntunan para sa anumang mga pagbabago.

Ang pambungad at pagsasara ng mga komento ay may marka ng pagbabago. Ito ay naglalaman ng mga sumusunod mga bahagi:

  • Prefix ng proyekto- bilang default ginagamit namin ang FTO
  • Pangalan ng domain ng developer. Ito ay nabuo nang napakaginhawa: ang kumpanya ay malaki, ipinamamahagi, at kung hindi mo kilala ang developer, ngunit kailangan mong magtanong sa kanya tungkol sa kanya, maaari mong kunin ang kanyang palayaw mula sa tag na ito, ilagay ang @fto.com.ru sa sa kanan at padalhan siya ng liham para makontak siya.
  • Susunod na dumating petsa ng pagbabago. Kapag naganap ang mga pagbabago sa loob ng balangkas ng ilang mga gawain, ang mga bundle na ito ng mga komento ay maaaring ilagay sa loob ng isa't isa, at hindi palaging malinaw kung saang pambungad na bloke kabilang ang pagsasara ng komentong ito, kaya tumuon kami sa petsa. Bilang karagdagan, ang petsa ay agad na nagpapakita kung kailan ginawa ang pagbabago: tatlong taon na ang nakakaraan, anim na buwan na ang nakalipas o kahapon.
  • Pagkatapos ay dumating numero ng gawain, alin inilagay lamang sa pambungad na komento. Bakit doon lang? Upang sa panahon ng isang pandaigdigang paghahanap sa pamamagitan ng numero ng gawain, ang simula lamang ng mga pagbabago sa code ang kasama sa pagpili, kung saan maaari kang tumingin pababa, kung hindi, magkakaroon ng mga doble. Halimbawa, kapag nagsusumite ng gawain sa pagsusuri ng code, napakaginhawang maghanap nang partikular sa pamamagitan ng tag.

Mga halimbawa

Ito ang hitsura nito ipasok ang code:

Ito ang hitsura nito pagtanggal ng code- hindi namin ganap na inaalis ang code, ikokomento namin ang code. Dahil dito, palagi mong makikita kung ano ang ni-comment out, at kung may mangyari mabilis kang makakabalik.

Ito ang hitsura nito pagbabago ng code: Una, ang lahat ng vendor code ay nagkomento, at pagkatapos ay ang iyong sariling code ay idinagdag.

Gumagana ang isang hiwalay na panuntunan para magdagdag ng mga procedure, function at global module variables. Sa kasong ito ang pangwakas na komento ay inilalagay sa parehong linya ng keyword Katapusan ng Pamamaraan. Bakit ito ginawa? Upang gawing maginhawa ang paglipat ng mga pagbabago gamit ang "procedural comparison".

Dito sa larawan makikita mo iyon gamit ang "paghahambing ng pamamaraan" maaari mong i-highlight lamang ang pamamaraang ito kapag pinagsama, at ito ay ganap na ililipat (kasama ang mga marka). O vice versa, maaari mong alisan ng check ang kahon sa tabi nito upang hindi ito ilipat.

At kung ang pagsasara ng komento ay nasa susunod na linya, pagkatapos ay itatalaga ito sa susunod na pamamaraan at hindi posible na ilipat lamang ito nang walang karagdagang gastos.

3. Pagdaragdag ng mga top-level na bagay

Ang susunod na panuntunan ay ang pagdaragdag ng mga top-level na bagay (mga direktoryo, dokumento, rehistro, atbp.) sa pagsasaayos.

Ang panuntunang ito ay iyon ang mga pangalan ng bagay ay dapat magsimula sa isang prefix. Para saan?

  • Una, biswal nitong hina-highlight ang idinagdag na elemento sa pagsasaayos at sa code agad na malinaw na ito ang aming idinagdag na bagay.
  • Pangalawa, ang pagiging natatangi ng pangalan ay nakakamit, dahil maaaring magdagdag ang provider ng sarili nitong object na may parehong pangalan. At kung gagamit tayo ng sarili nating prefix, ginagarantiyahan nito na magiging kakaiba ang ating pangalan.

Ang mga kasingkahulugan ng bagay ay dapat magsimula sa isang prefix sa mga panaklong. Ito ay nagpapahintulot sa amin na i-highlight ang aming idinagdag na bagay sa interface.

Siyempre, ito ay isang napakakontrobersyal na tuntunin, at ang paggamit nito ay dapat na sumang-ayon sa customer. Natuwa ang aming mga kliyente sa pamamaraang ito, kaya nag-ugat ito sa amin at naging bahagi ng mga patakaran. Ngunit narito, ikaw at ang kliyente ang magpasya kung dapat mong gawin ito o hindi.

Well, ang huling panuntunan: ang mga komento para sa lahat ng idinagdag na bagay ay dapat maglaman ng isang espesyal na label na may pangalan ng developer at ang numero ng gawain. Ang label na ito ay katulad ng pambungad na komento mula sa module, walang mga espesyal na character - sa tulong nito palagi kong mauunawaan kung sino, kailan at para sa anong gawain ang idinagdag ang bagay na ito.

Kaya, upang ibuod:

  • Ang mga pangalan ay tinukoy na may prefix,
  • Mga kasingkahulugan - may prefix sa panaklong
  • At ang komento ay dapat maglaman ng isang espesyal na tag.

4. Pagdaragdag ng mga subordinate na bagay

Sa pamamagitan ng pagdaragdag ng mga sub-object ang ibig kong sabihin ay pagdaragdag ng mga props, layout, form, atbp. sa mga bagay sa pagsasaayos.

Dito kailangan nating i-highlight agad ang dalawang sitwasyon kung saan nagdaragdag tayo ng subordinate na bagay:

  • Sa isang tipikal na object ng pagsasaayos
  • O sa ilang bagay na idinagdag kanina sa loob ng proyekto.

Isaalang-alang natin ang bawat isa sa mga sitwasyong ito nang hiwalay.

Upang magdagdag ng mga subordinate na bagay sa karaniwang mga bagay sa pagsasaayos Nalalapat ang mga sumusunod na patakaran.

  • Ang mga pangalan ay dapat magsimula sa parehong prefix. Dahil dito, nakakamit natin ang pagiging natatangi ng pangalan at sa paningin ay laging malinaw na ito ang ating layunin.

  • Ang kasingkahulugan ay pinupunan nang walang prefix, dahil dito hindi na kailangang i-highlight ang aming mga bagay, ang aming mga detalye.

  • At sa wakas, ang komento ay naglalaman din ng isang espesyal na tag, upang maging malinaw kung sino, kailan at bakit.

Kaya, ibubuod natin kung paano gumagana ang pagdaragdag ng mga subordinate na bagay sa karaniwang mga bagay sa pagsasaayos:

  • Ang mga pangalan ay tinukoy na may prefix,
  • Mga kasingkahulugan ayon sa pangkalahatang tuntunin
  • At naglalaman ang mga komento ng isang espesyal na label.

A kung magdaragdag tayo ng mga subordinate na bagay sa mga bagay na iyon na dati nang idinagdag sa loob ng proyekto at naglalaman na ng prefix sa kanilang pangalan, pagkatapos ay:

  • Ang kanilang hindi dapat maglaman ng prefix ang mga pangalan, dahil malinaw na na ang bagay ay natatangi na, at hindi na kailangang espesyal na i-highlight ito sa anumang iba pang paraan.

  • Ang mga kasingkahulugan para sa mga subordinate na bagay ay tinukoy din nang walang prefix, dahil walang espesyal na pagpili ang kailangan.

  • At ang komento ay naglalaman lamang ng isang espesyal na label kung ang subordinate na bagay na ito ay idinagdag bilang bahagi ng isa pang gawain. Dahil kung sasabihin ng aking gawain na kailangan kong magdagdag ng isang dokumento na may ganoon at ganoong mga detalye, hindi ko kailangang maglagay ng ganoong label para sa bawat detalye. Ngunit kung ang gawain ay ganap na naiiba, sinisigurado kong maglagay ng marka upang malinaw kung bakit ko ito ginawa.

Ngayon ay ibubuod natin kung paano idinaragdag ang mga subordinate na bagay sa mga bagay na idinagdag sa loob ng proyekto:

  • Mga pangalan na walang prefix.
  • Mga kasingkahulugan na walang prefix.
  • At ang mga komento ay dapat lamang maglaman ng isang espesyal na label kapag idinagdag ang mga ito bilang bahagi ng isa pang gawain.

Kung pagsasamahin namin ang panuntunang ito para sa parehong mga kaso at "hatiin ito sa mga piraso," makukuha namin ang sumusunod na talahanayan:

  • Mga bagong bagay:
    • Ang pangalan ay nagsisimula sa isang prefix.
    • Mga kasingkahulugan - na may prefix sa panaklong.
    • Naglalaman ng label ang komento.
  • Mga subordinate na bagay na idinaragdag namin sa mga generic na bagay:
    • Nagsisimula ang mga pangalan sa prefix,
    • Kasingkahulugan ayon sa pangkalahatang tuntunin
    • Maglagay ng tag sa komento.
  • At kung magdaragdag tayo ng mga subordinate na bagay sa mga bagay na idinagdag sa loob ng proyekto, kung gayon
    • Walang mga espesyal na patakaran para sa kanila,
    • Ngunit kung iba ang gawain, maglalagay kami ng tag sa komento sa parehong paraan.

5. Pagdaragdag ng mga paunang natukoy na elemento

Ang susunod na panuntunan ay ang pagdaragdag ng mga paunang natukoy na elemento.

Dito, ang dalawang sitwasyon ay maaaring makilala sa eksaktong parehong paraan:

  • Kapag nagdagdag kami ng paunang natukoy na elemento sa isang tipikal na object ng pagsasaayos (sa isang reference na libro, sa isang plano ng mga uri ng katangian)
  • At kapag nagdagdag kami ng paunang natukoy na elemento sa isang bagay na idinagdag sa loob ng proyekto.

Kung magdaragdag kami ng paunang-natukoy na elemento sa isang generic na configuration object,

  • Ang kanyang Pangalan katulad dapat magsimula sa isang prefix. Kaya, ginagarantiyahan namin ang pagiging natatangi ng pangalan nito at magagawang makita agad ang aming idinagdag na elemento.
  • Code at pangalan mabubuo ayon sa pangkalahatang tuntunin,
  • Pero label dito, sa kasamaang palad, walang ilagay ito. Samakatuwid, hindi magiging posible na mahanap ang idinagdag na paunang-natukoy na elemento gamit ang isang pandaigdigang paghahanap ng gawain.

A kung magdaragdag kami ng mga paunang natukoy na elemento sa mga bagay na idinagdag sa loob ng proyekto, Iyon

  • Ang kanyang hindi maglalaman ng prefix ang pangalan, dahil hindi na kailangang i-highlight ito kahit papaano.

Kaya, kung gumuhit kami ng isang pagkakatulad sa nakaraang talahanayan, kung gayon:

  • Ang mga paunang natukoy na elemento para sa mga generic na bagay ay idinaragdag kasama ng prefix,
  • At lahat ng iba pa - ayon sa mga pangkalahatang tuntunin, walang mga espesyal na prefix ang kailangang idagdag.

6. Paggamit ng mga karaniwang module at ang kanilang mahigpit na istraktura

Ang susunod na tuntunin ay may kinalaman sa paggamit ng mga karaniwang module at ang organisasyon ng isang mahigpit na istraktura para sa kanila.

Una, para sa iba't ibang paulit-ulit na ginagamit na mga pamamaraan, mga function, mga tagapangasiwa ng subscription at mga nakagawiang gawain, dapat mong idagdag ang iyong sariling mga module, na iniiwan ang mga karaniwang module na hindi nagbabago. At kung nais ng isang developer na maglagay ng ilang uri ng pamamaraan sa pag-export sa isang karaniwang module, hindi na kailangang gawin iyon, kailangan mong gumawa ng sarili mong module.

Pangalawa, mangyaring tandaan na ang mga karaniwang module ay idinaragdag alinsunod sa mga panuntunan para sa pagdaragdag ng mga bagay sa pinakamataas na antas(pangalan at kasingkahulugan ng prefix, tag sa komento, atbp.)

pangatlo, ang mga pangalan ng module ay dapat na katulad ng kaukulang karaniwang mga module.

Hindi na kailangang muling likhain ang gulong: tinatawag namin ito sa parehong paraan tulad ng nakasanayan sa mga karaniwang pagsasaayos - para sa bawat pag-andar ng sarili nitong module, na naaayon sa pangkalahatang tinatanggap na mga pagtatalaga sa 1C. Halimbawa:

  • FTO_General Purpose Client,
  • FTO_General Purpose Server,
  • FTO_General Purpose Global,
  • FTO_RoutineTasksServer
  • atbp.

At ilan malalaking indibidwal na gawain maaari mo (at marahil ay dapat) ilagay sa magkakahiwalay na karaniwang mga module.


7. Paggamit ng mga subscription at ang kanilang mahigpit na istraktura

Ang susunod na panuntunan ay ang paggamit ng mga subscription at ang kanilang mahigpit na istraktura. Ano ang kakanyahan nito?

Dapat gamitin ang mga subscription upang pangasiwaan ang iba't ibang kaganapan na nauugnay sa mga generic na bagay, tulad ng:

  • Bago mag-record
  • Kapag nagre-record
  • atbp.

  • Syempre pwede mong kunin i-edit ang isang karaniwang module ng object, sa pamamagitan ng pagpasok ng iyong code sa naaangkop na pamamaraan. Pero ito - masamang paraan.
  • Mas mabuti sa halip na ito magdagdag ng subscription upang maproseso ang kaganapang ito.

Ang subscription ay idinagdag ayon sa mga sumusunod na napagkasunduang panuntunan:

  1. Para sa lahat ng kaganapan ng parehong uri sa system, isang subscription lang ang idinagdag. Halimbawa, kung kailangan kong gumamit ng sarili kong algorithm para sa iba't ibang mga direktoryo sa kaganapang "Bago magsulat ng isang direktoryo," para sa lahat ng mga direktoryo na ito ay gumagamit lang ako ng isang idinagdag na subscription na "Bago magsulat ng isang direktoryo".
  2. Pinipili ng pinagmulan ang lahat ng mga bagay sa loob ng klase na ito(halimbawa, lahat ng mga direktoryo)
  3. Para sa idinagdag na subscription, isang hiwalay na module ang nilikha, na tinatawag na eksaktong pareho(para lamang sa kaginhawahan).
  4. Sa pangunahing tagapangasiwa ng kaganapan, tinukoy ang isang kundisyon na sinusuri ang uri ng bagay(uri ng direktoryo).
  5. At na Depende sa uri ng bagay, ang ilang mga aksyon ay isinasagawa.

Maaari kong ipakita sa iyo ang isang halimbawa. Ipagpalagay na mayroong ganoong gawain: kapag nagpo-post ng dokumentong "Advance na ulat", gumawa ng mga entry sa naunang idinagdag na rehistro ng akumulasyon.

Una, idinagdag namin ang pangkalahatang module FTO_DocumentsProcessingProcessing ayon sa lahat ng mga patakaran.

  • Tinukoy namin ang DocumentObject (lahat ng mga dokumento) bilang pinagmulan;
  • Ang aming module na idinagdag sa itaas ay ginagamit bilang isang handler.

At nasa module na, sa handler mismo, tinutukoy namin kung anong uri ng dokumento ang dumating sa amin at, depende sa uri nito, tinatawag namin ang isa o ibang pamamaraan.

May isang subscription, ngunit maaaring iba ang mga pagkilos. T Maaari mo ring kontrolin ang pagkakasunud-sunod kung saan tinatawag ang mga pamamaraan.

Bilang resulta, ang pamamaraan para sa paglikha ng isang subscription ay ang mga sumusunod:

  • Isang subscription,
  • Isang karaniwang module
  • At walang ibang kailangan: ang module ng dokumento ay nananatiling hindi nagbabago - hindi na ito lilitaw sa mga "dalawang beses na binago".


8. Pag-edit ng mga form

Ang susunod na panuntunan ay ang pag-edit ng mga form.

Dito ay i-highlight natin ang dalawang punto, dalawang sitwasyon:

  • Kapag nag-edit kami ng mga karaniwang form;
  • At kapag na-edit namin ang mga form na idinagdag sa loob ng proyekto.

Ang unang sitwasyon ay ang pag-edit e karaniwang mga form, mga anyo ng mga tipikal na bagay. Ito ang pinakakontrobersyal na punto ng mga patakaran. Noong unang panahon, noong mga araw ng mga conventional form, kapag ang mga proyekto ay pangunahing ginagawa sa SCP, marami kaming mga talakayan tungkol sa kung ano ang gagawin sa mga form. Ano ang mga pagpipilian?

  • Direktang pag-edit ng mga regular na form is that I just change the shape manually. Sa opsyong ito, sa tuwing gagawa ang supplier ng mga pagbabago sa form na ito, kailangan kong ilipat muli ang lahat ng aking mga pagbabago. Masamang paraan.
  • Ang isa pang paraan ay paggawa ng kopya ng form. Ito ay kapag gumawa ako ng isang kopya ng isang karaniwang form, italaga ito bilang pangunahing isa at gawin ang aking mga pagbabago dito. Ngunit muli, kung babaguhin ng supplier ang form na ito, kailangan kong manu-manong ilipat ang kanilang mga pagbabago sa aking bersyon. Hindi ang pinakamahusay na paraan.
  • Ang isa pang pagpipilian ay paggawa ng hiwalay na tab. Lumilikha kami ng isang hiwalay na tab sa form at inilalagay ang aming mga elemento dito. Malinaw na ang pamamaraang ito ay hindi nababaluktot, dahil kung minsan ang iyong elemento ay kailangang ipasok sa isang lugar sa isang partikular na lugar sa form. O kailangan mong baguhin ang mga katangian ng mga karaniwang elemento, magtalaga ng bagong handler sa kanila, atbp. Samakatuwid ito hindi flexible na paraan- hindi rin ito gumagana nang maayos.
  • Ang resulta pinili namin ang paraan ng ganap na programmatic na pag-edit ng mga form. Ang mga bagong developer na hindi nakatagpo ng paraang ito sa una ay napakahirap na mag-edit ng isang form gamit ang program. Ngunit sa katotohanan - hindi. Mula sa aking karanasan sasabihin ko na kailangan mo lang pagbutihin ito. Bilang karagdagan, mayroon kaming mahabang nakasulat na mga module na may mga pamamaraan sa pag-export para sa pagpapalit ng mga form sa program, at lahat ng ito ay ginagawa nang madali. Kapag lumitaw ang mga pinamamahalaang form, ganap din naming inilipat ang kasanayang ito ng pagpapalit ng mga form sa pamamagitan ng program sa mga pinamamahalaang form. At saka, editing kinokontrol na anyo Naging madali sa pangkalahatan ang programming - hindi ito maihahambing sa mga kumbensyonal na anyo.

Hayaan akong ipakita sa iyo ang isang halimbawa. Sa handler ng OnCreateOnServer, nagdaragdag ako ng isang tawag sa aking pamamaraan na EditFormProgrammatically, kung saan ako ay nagdaragdag ng mga elemento sa form sa pamamagitan ng program.

Sa mga pagsasaayos batay sa BSP 2(tulad ng ERP, Accounting, atbp.) idinagdag Event handlerForm.WhenCreatedOnServer(), na, bukod sa iba pang mga bagay, pumasok din sa na-override na module.

At kaya maaari kang magdagdag ng iyong sariling code sa na-override na module- halimbawa, sa WhenCreatingOnServer() procedure. Dito ko tinukoy ang pangalan ng form, at depende dito, tinatawagan ko ang isa o ibang pamamaraan, kung saan nagdaragdag ako ng mga elemento sa programmatically.

Tila ito ay mahirap, na ang pamamaraan na ito ay mahirap, ngunit sa katotohanan, kung ang lahat ng mga proyekto ay ginawa ayon sa mga patakarang ito, kung gayon ang developer, kapag tumatanggap ng isang gawain, ay agad na alam kung saan titingnan, kung saan idaragdag kung ano. Kaya sa tingin ko ito ay napaka maginhawa.

Bilang karagdagan, sa mga pagsasaayos batay sa BSP 2, ang ibang mga tagapangasiwa ng form ay muling tinukoy - tulad ng When ReadingOnServer(), BeforeWritingOnServer(), atbp. At sa mga humahawak na ito ay maaari mo ring aktibong gamitin ang redefinition ng tinatawag na mga pamamaraan. Bukod dito, ang module na muling tinukoy ng supplier ay theoretically ay hindi nagbabago, at maaari mong isulat ang iyong sariling code doon nang walang takot sa mga salungatan.

Kung mag-e-edit kami ng isang form na idinagdag bilang bahagi ng isang proyekto, hindi namin kailangang gumawa ng anumang espesyal na i-edit ito sa karaniwang paraan, sa pamamagitan ng kamay.

9. Mga prinsipyo ng pagtatrabaho sa mga tungkulin

At ang huling tuntunin ay ang mga prinsipyo ng pagtatrabaho sa mga tungkulin.

Ang mga prinsipyo ng pagtatrabaho sa mga tungkulin ay ang mga sumusunod:

  1. Kung maaari, kung gayon ang mga karaniwang tungkulin ay dapat palaging iwanang walang pangalan. Kailangan mong pag-isipang mabuti kung kailangan ba talagang baguhin ang karaniwang tungkulin o kung may magagawa ka sa ibang paraan.
  2. Nagtatalaga kami ng mga karapatan sa mga idinagdag na object ng configuration sa mga bago, espesyal na nilikhang tungkulin. Samakatuwid, kapag nagdagdag ako ng ulat sa pagsasaayos, at walang angkop na tungkulin para dito na dati naming idinagdag, gumagawa ako ng hiwalay na tungkulin. At pagkatapos ay idinagdag ang tungkuling ito sa mga kinakailangang profile. Ngunit ang mga karaniwang tungkulin ay hindi nagbabago.
  3. AT kung may mga pagbabago saRLS, pagkatapos ay na-format ang mga ito ayon sa mga patakaran para sa pag-edit ng mga module.

Halimbawa, kung kailangan kong baguhin ang RLS, pagkatapos ay maglagay ako ng pambungad na komento, magkomento sa lumang code, pagkatapos ay magdagdag ng sarili ko at maglagay ng pangwakas na komento. Laging malinaw: sino, bakit (sa loob ng anong gawain) at kailan ako nagbago.

Kaya inilista ko ang lahat ng siyam simpleng tuntunin pagpaparehistro ng mga pagbabago.

Karagdagang mga bagay at pamamaraan upang gawing mas madali ang buhay

Sa wakas, tatalakayin ko ang ilang bagay at diskarte na maaaring gawing mas madali ang buhay ng isang developer.

1. Pagkilala sa sarili ng mga database ng pagsubok

Ang unang pamamaraan ay ang pagkilala sa sarili ng mga database ng pagsubok.

Ang punto ay:

  • mayroong ilang pare-pareho na nag-iimbak ng address ng gumaganang produktibong database.
  • Kapag nagsimula ang system, susuriin ang address na ito: tumutugma ba ito sa working base address o hindi ito tumutugma.
  • AT kung hindi tugma(hindi gumagana ang base), kung gayon Ang header ng system ay pinapalitan.

Ipinapakita ng screenshot kung ano ang hitsura nito. Ito ay lalong kapaki-pakinabang kapag ang mga developer (o consultant) ay may maraming database na bukas (gumagana, pagsubok, pag-develop, atbp.) at maaari silang hindi sinasadyang magkamali at magbago ng data sa gumaganang database. At kung binago ang pamagat, pagkatapos ay "awtomatikong" - tingnan ang kaliwang sulok sa itaas, tingnan kung anong uri ng database ito - oo, subukan, maaari mong baguhin ito.

Sa ganitong paraan, ginagawa naming mas secure ang pagbabago ng data sa mga infobase.

Bukod sa, Kapaki-pakinabang din ang paggamit ng pagsuri sa halaga ng pare-parehong ito kapag nagsasagawa ng ilang karaniwang gawain. Namely:

  • pagpapalitan ng data,
  • mga notification ng user,
  • ilang mailings
  • mabibigat na gawain sa regulasyon.
  • atbp.

Kapag ang isang developer ay lumikha ng ganoong nakagawiang gawain, dapat niyang suriin kung ito ay isang working base o hindi. Malinaw na, sa teorya, sa lahat ng mga database ng pagsubok, ang mga nakagawiang gawain ay dapat na hindi pinagana sa cluster console. Pero laging may human factor kapag may lumikha bagong base, nag-load ng sariwang data dito, nagbago ng isang bagay, at bilang isang resulta ay naganap ang ilang kritikal na palitan sa mga gumaganang database. At pagkatapos ay ang showdown - bakit nangyari ito? Kaya naman tayo bago kritikal mga nakagawiang gawain Palagi naming sinusuri kung ito ay isang gumaganang database o hindi.

Sa mga pagsasaayos batay sa BSP 2 mayroong isang katulad na mekanismo: kung lokasyon base ng impormasyon mga pagbabago, pagkatapos ay itatanong - ito ba ay isang kopya ng database o ang database ay inilipat. Sa prinsipyo, ang mekanismong ito ay maaaring sapat, ngunit muli, ang kadahilanan ng tao ay maaaring makagambala, ang isang tao ay hindi mauunawaan kung ano ang nangyayari at pindutin ang maling pindutan. kaya lang, sa aking opinyon, ang isang pare-pareho ay mas maaasahan.

2. Pagproseso ng pagsisimula

Ang susunod na trick ay ang pagpoproseso ng initialization.

  • Ito ay isang pagproseso na idinagdag sa configuration, na naglalaman ng kasalukuyang bersyon nito sa code nito.
  • Kasabay nito, ang ilang pare-pareho ay idinagdag din sa pagsasaayos, na nag-iimbak ng kasalukuyang bersyon ng pagpoproseso ng pagsisimula.
  • Kapag nagsimula ang system, isinasagawa ang isang pagsusuri,
  • At, kung nagbago ang bersyon, ipapatupad ang mga kinakailangang humahawak at itatakda ang bagong halaga ng pare-pareho.

Bakit kailangan ito? Kadalasan, kapag nagdaragdag ng bagong pag-andar sa pagsasaayos, kinakailangan na magsagawa ng ilang mga aksyon sa database mismo: halimbawa, nagdagdag ka ng isang paunang natukoy na elemento ng direktoryo, at ngayon ay kailangan mong punan ang mga detalye nito. Maaaring magkaroon ng maraming database sa isang proyekto at ang manu-manong pagpuno sa data na ito ay, siyempre, masama. Mas tama:

  • Palakihin ang bersyon pagpoproseso ng pagsisimula;
  • Ilarawan sa code ang pagkakasunud-sunod ng programmatic filling ng data;
  • At pagkatapos noon bagong bersyon ng pagproseso awtomatikong sa pamamagitan ng imbakan ay mapupunta ito sa lahat ng kinakailangang database, ilulunsad doon at gagawa ng lahat ng kinakailangang aksyon.

Sa diagram na ito mga dapat gawain ipinapakita tulad nito:

  • Simula ng system
  • Paghahambing ng pare-parehong bersyon sa pagpoproseso ng bersyon.
  • Kung hindi tugma, ay isinasagawa sunud-sunod lahat ng kailangan mga humahawak,
  • Nagtatakda ng bagong halaga para sa pare-pareho.

Bilang resulta, ang data ay ina-update sa lahat ng dako, sa lahat ng mga database.

3. Direktoryo ng mga paunang natukoy na halaga

Ang susunod na trick ay isang sanggunian ng mga paunang natukoy na halaga.

Kadalasan mayroong pangangailangang i-access ang mga umiiral nang elemento ng direktoryo mula sa code na hindi paunang natukoy. Ito ay malinaw na ito ay mas mahusay na lumikha ng isang paunang natukoy na elemento, ngunit ito ay nagkataon na ang elemento ay hindi maaaring paunang natukoy, ngunit ito ay maa-access pa rin.

Anong mga opsyon sa pagpapatupad ang nariyan?

  • Sumangguni sa elemento ayon sa pangalan. Ito ay malinaw na ang pangalan ay nagbago - ang code ay tumigil sa paggana. masama.
  • Makipag-ugnayan sa pamamagitan ng code. Medyo mas mahusay, ngunit ang code ay maaari ring magbago. Hindi mabuti.
  • Makipag-ugnayan sa pamamagitan ng panloob na pagkakakilanlan. Pagkatapos kapag inilipat ang code na ito ay hindi rin gagana. Sa pangkalahatan, ang lahat ng tatlong kaso na ito ay hindi gagana kung maglilipat kami ng pagbabago mula sa isang database patungo sa isa pang database. Hindi mabuti.
  • Inaalok lumikha ng isang direktoryo ng mga paunang natukoy na halaga.

Ang direktoryo na ito ay naglalaman lamang ng isang katangian na may uri na DirectoryLink(link sa lahat ng reference na libro).

Kung kailangan kong sumangguni sa ilang elemento bilang bahagi ng isang gawain, nagdaragdag ako ng paunang natukoy na elemento sa reference na aklat na ito (halimbawa, Counterparty_Agroimpulse)

At pagkatapos, alinman sa code sa pagpoproseso ng initialization o sa pamamagitan ng kamay, pinupunan ko ang halaga ng direktoryo na ito ng katapat na kailangan ko.

Alinsunod dito, pagkatapos nito Maaari akong makipag-ugnayan sa katapat na ito sa pamamagitan ng isang direktoryo ng mga paunang natukoy na halaga. Dahil dito, nakamit ang mga sumusunod:

  • Kapag naglilipat ng mga pagbabago sa pagitan iba't ibang batayan lahat ng akin gumagana ang code nang walang anumang karagdagang pagbabago.
  • Dagdag pa, posible na ngayon ang katapat na partido na ito ay Agroimpulse, at bukas ito ay ibang organisasyon, ngunit hindi ko kailangang baguhin ang anuman sa pagsasaayos, pumunta lang ako at baguhin ang halaga nito sa direktoryo ng mga paunang natukoy na halaga.

4. Tingnan ang mga pansamantalang talahanayan sa debugger

Well, ang huling trick ay upang tingnan ang mga pansamantalang talahanayan sa debugger.

  • Kapag nagde-debug ng mga kumplikadong query na may mga pansamantalang talahanayan kailangang matingnan ang nilalaman ang mga ito pansamantalang mga talahanayan.
  • Para sa mga layuning ito Pwede gumamit ng isang espesyal na function upang tingnan ang mga pansamantalang talahanayan.
  • Ang function na ito komportable lugar sa global module.

  • AT pangalan kahit papaano maikli, halimbawa VT()

Sa kasong ito:

  • ako Nagtakda ako ng breakpoint sa lugar kung saan may hiling ako.
  • Sa window na "Kalkulahin ang Expression" isinusulat ko ang VT (Query);
  • I-click ko ang "Kalkulahin" at Nakukuha ko ang istraktura ng mga pansamantalang talahanayan ng query upang makita kung anong data ang naroroon.

Ito ay isang napaka-maginhawang tampok, ginagamit namin ito sa lahat ng oras. Lalo na kapag nagkalkula ng mga gastos, o sa mga pagsasaayos tulad ng ZUP. Sa totoo lang, hindi ko maintindihan kung paano nabubuhay ang iba nang wala siya.

Sa pinakabagong bersyon ng platform ay lumitaw built-in na tool na nagpapahintulot sa iyo na tingnan ang mga pansamantalang talahanayan, ngunit sa palagay ko ito hindi masyadong maginhawa. Ang paggamit ng iyong sariling function ay mas mahusay.

Konklusyon

Salamat sa lahat. Mayroon akong isang maliit na website, sa site na ito ang lahat ng mga patakarang ito at higit pa ay inilatag nang detalyado - pumasok, magbasa, sumulat sa akin sa pamamagitan ng email o sa Skype.

Ang paksang ito ay kawili-wili sa akin, handa akong talakayin ito. Ito ay talagang mahalaga sa akin na ang lahat ay gumagana din para sa iyo.

Kahit ano, kahit na maliit na organisasyon ay may sariling hanay ng mga proseso ng negosyo. Upang gumana nang epektibo at makatanggap pinakamataas na tubo kailangang awtomatiko ang malalaking proseso ng negosyo. Ang mga 1C program ay gumagawa ng isang mahusay na trabaho sa function na ito. Ngunit, sa kasamaang-palad, walang perpektong mga programa, tulad ng bawat tao ay may sariling mga ideya tungkol sa pagiging perpekto. Matutulungan ka ng isang 1C programmer na mapabuti ang iyong programa. Ang pagkakaroon ng pagbabago sa karaniwang 1C, makakatanggap ka ng isang programa na ganap na nakakatugon sa iyong mga ideya at pangangailangan.

Rebisyon 1C- isang hanay ng mga aksyon upang i-configure at gawing makabago ang mga programang 1C upang umangkop sa mga pangangailangan ng iyong negosyo.

Paano namin pinapahusay ang mga programang 1C

Upang makamit ang isang perpektong resulta, kapag natanggap ng kliyente ang eksaktong nais niya kapag tinatapos ang mga programang 1C, inaalok namin ang sumusunod na scheme ng trabaho:

  1. ang kliyente ay nag-uulat ng impormasyon tungkol sa naka-install;
  2. ipinakilala ng kliyente ang aming espesyalista sa mga pangunahing prinsipyo ng gawain ng kanyang organisasyon, ipinapaalam ang kakanyahan ng problema, inilalarawan kung ano ang eksaktong nais niyang pagbutihin;
  3. ang isang 1C programmer ay itinalaga sa kliyente, na makikipagtulungan sa kliyente sa buong oras na nagtatrabaho sa aming kumpanya at malalaman ang lahat ng mga tampok ng accounting para sa negosyo ng kliyente. Ang personal na programmer ng 1C ay magiging ganap na responsable para sa pagganap ng mga pagpapahusay na kanyang ipinatupad;
  4. ang mga teknikal na pagtutukoy ay iginuhit. Batay sa impormasyong natanggap, gagawa ang aming mga programmer ng 1C ng mga kinakailangang konklusyon at mag-aalok ng mga opsyon para sa paglutas ng problema sa pamamagitan man ng mga pagbabago o sa pamamagitan ng paggawa ng mga pagsasaayos sa 1C;
  5. napagkasunduan ang mga gastos sa oras at pera para sa pagtatapos ng 1C;
  6. ipinatupad ang gawaing napagkasunduan sa kliyente;
  7. Ang mga resulta ng trabaho ay nasubok at ipinasa sa kliyente.

Ang pinakakaraniwang mga pagbabago sa 1C

Sa ibaba ay inilista namin ang mga partikular na sikat na pagpapabuti sa mga programang 1C:

  • Paglikha ng mga direktoryo at mga detalye. Paglikha karagdagang mga lugar pag-iimbak ng impormasyon tulad ng mga numero ng sasakyan
  • Pagpipino o pagbuo ng mga bagong porma ng pag-imprenta. Baguhin hitsura bill, invoice at iba pang naka-print na anyo ng mga dokumento ayon sa mga kahilingan ng iyong organisasyon.
  • Gumawa ng bago o baguhin ang mga kasalukuyang ulat. Paglikha ng karagdagang o pag-edit ng mga kasalukuyang ulat para sa mga accountant, manager o direktor ng kumpanya.
  • Pagtatakda ng mga karapatan sa pag-access. Paghihigpit o pagpapalawak ng access ng user sa impormasyon sa database.
  • Pag-unlad ng mga paggamot. Paglikha ng pagproseso upang gawing simple ang mga sistema ng pag-input ng impormasyon, pagsusuri ng mga aktibidad ng enterprise, awtomatikong gumanap ng mga function, halimbawa, pag-print ng isang pakete ng mga dokumento o pag-download ng impormasyon mula sa isang Excel file (*.xls).
  • Pagse-set up ng 1C exchange. Mag-import/mag-export ng data mula sa isang 1C program patungo sa isa pa.
  • Pagkonsulta sa mga gumagamit ng 1C. Paliwanag o pagsasanay ng mga gumagamit upang gumana sa mga ipinatupad na pagpapabuti.
  • Ina-update ang mga binagong configuration. Ina-update namin ang mga configuration na binago ng pareho namin at ng mga third-party na 1C programmer.

Mga kalamangan ng pagtitiwala sa amin ng mga pagpapahusay sa 1C

Mayroong ilang mga dahilan kung bakit kumikita ang pag-order ng mga pagbabago mula sa aming kumpanya:

  • Mataas na kalidad. Ang aming mga 1C programmer ay lubos na kwalipikadong mga espesyalista, na kinumpirma ng mga nauugnay na 1C na sertipiko.
  • Mura. Ang aming kumpanya ay maliit, ngunit mabilis na lumalaki, inaalis namin ang mga tagapamagitan sa pagitan ng customer at ng programmer, dahil dito pinamamahalaan naming panatilihin ang halaga ng mga serbisyo ng 1C sa mababang antas, mula sa 1000 rubles. bawat oras ng trabahong espesyalista.
  • Mabilis na pagkumpleto ng trabaho. Hindi kumikita para sa aming kumpanya na antalahin ang pagkumpleto ng iyong gawain. Samakatuwid, ikaw ay garantisadong matatanggap ang resulta ng iyong trabaho nang hindi lalampas sa tatlong araw ng trabaho. Kung maliit ang gawain, malamang na makukuha mo ang pagbabagong kailangan mo sa 1C sa araw na makipag-ugnayan ka dito.
  • 100% na garantiya para sa pagganap ng pagbabago. Ginagarantiyahan ng aming kumpanya ang paggana ng mga pagpapahusay na ginawa ng aming mga empleyado sa iyong programa. Sa loob ng isang taon pagkatapos ng pagpapatupad nito, maaari mong sabihin sa amin kung nakakita ka ng mga nakatagong depekto, at aayusin namin ang mga ito nang walang bayad sa lalong madaling panahon.
  • Sa kabila ng katotohanan na tayo ay matatagpuan sa heograpiya St. Petersburg, Magagawa naming malayuan ang anumang gawain para sa iyo, nasaan ka man sa mundo.