Întreprindere de rafinare 1c. Conceptul de a minimiza „distrugerea” unei configurații tipice

Ei bine, toți ceilalți, bine ai venit la pisică.

Reguli și tehnici pentru finalizarea configurațiilor tipice 1C pentru a le facilita suportul și actualizarea

Deci, atunci când realizăm un anumit proiect (prin cuvântul „Noi” mă refer la toți oamenii care sunt implicați în automatizarea proceselor de afaceri), sperăm că atunci acesta va curge ușor în suport. De regulă, dacă totul este făcut bine și clientul este mulțumit, așa se întâmplă.

Asistența se caracterizează printr-un set foarte specific de sarcini - acestea pot fi sarcini pentru o consultare din categoria „de unde au venit astfel de numere” sau pentru corectarea unor erori de neînțeles etc. Dar, deoarece aproape toate proiectele constau în adaptarea unor soluții tipice la nevoile clientului, configurația cu suport trebuie actualizată periodic pentru noile versiuni:

• Dacă urmați câteva reguli de dezvoltare, atunci, cheltuind foarte puțin efort în etapa de proiect, în viitor puteți economisi asistență și actualizarea configurațiilor.
• Și invers, dacă la etapa proiectului au existat unele greșeli, graba, proiectarea incorectă a codului, atunci mai târziu acest lucru poate duce la un adevărat infern de suport și actualizări.

A trebuit cineva să actualizeze vreodată o configurație care a fost rescrisă fără marcaje? Vedeți cât de dureros este să comparați configurația veche a furnizorului cu noua configurație, să analizați manual fiecare caz de „dublu-schimbare” în comparație cu configurația curentă și așa mai departe. Toate acestea sunt destul de problematice.

9 reguli simple pentru proiectarea modificărilor în configurații tipice

1. Conceptul de minimizare a „distrugerii” unei configurații tipice

Prima nu este nici măcar o regulă, este un anumit concept de minimizare a „distrugerii” unei configurații tipice.

Esența sa este că trebuie să alegeți întotdeauna acele metode de rezolvare a problemelor care să ofere o actualizare mai ușoară a configurației în viitor, chiar dacă o astfel de soluție este ceva mai dificil de implementat. Este clar că acest lucru ar trebui făcut fără fanatism, într-un cadru rezonabil, dar dezvoltatorul ar trebui să-și amintească întotdeauna că configurația rămâne pe suport și să analizeze cât de mult codul său va complica actualizarea configurației în viitor, alegând cea mai potrivită soluție.

2. Comentarea modificărilor de cod

A doua regulă este că l orice modificare a codului trebuie comentată.

În compania noastră, folosim următoarea schemă:

• La începutul schimbării este comentariu de deschidere (începe cu semne //++ )
• La sfarsit - comentariu de închidere (începe cu semne //-- )
• ȘI acele modificări făcute de dezvoltator sunt la mijloc.

Aceasta este o regulă obligatorie pentru orice modificare.

Comentariile de deschidere și de închidere au un semn de modificare... Conține următoarele constituenți:

• Prefixul proiectului - implicit folosim FTO
• Numele domeniului dezvoltatorului... Se formează foarte convenabil: compania este mare, distribuită și, dacă nu cunoașteți dezvoltatorul, dar trebuie să-l întrebați despre el, îi puteți lua porecla de pe această etichetă, puneți-l pe @ fto.com.ru dreapta și trimiteți-i o scrisoare, astfel încât să îl contactați.
• Mai departe merge schimba data... Când apar modificări în cadrul mai multor sarcini, aceste pachete de comentarii pot fi imbricate unul în celălalt și nu este întotdeauna clar cărui bloc de deschidere îi aparține acest comentariu de închidere, așa că ne concentrăm asupra datei. În plus, data arată imediat când a fost făcută modificarea: acum trei ani, acum șase luni sau ieri.
• Apoi vine numărul sarcinii, pe care plasat doar în comentariul de deschidere... De ce doar acolo? Astfel, în timpul unei căutări globale după numărul de sarcini, numai începutul modificărilor codului va fi inclus în selecție, din care puteți privi mai jos, altfel se va dubla. De exemplu, atunci când trimiteți o sarcină la revizuirea codului, este foarte convenabil să căutați după etichetă.

Exemple de

Așa arată cod de lipire:

Așa arată eliminați codul - nu ștergem complet codul, comentăm codul. Datorită acestui fapt, puteți vedea întotdeauna ce a fost comentat și, în acest caz, puteți reveni rapid.

Așa arată schimbarea codului: Mai întâi, se comentează întregul cod al furnizorului, apoi se adaugă codul dvs.

O regulă separată funcționează pentru a adăuga proceduri, funcții și variabile globale la module... În acest caz comentariul de închidere este plasat pe aceeași linie cu cuvântul cheie EndProcedure... De ce se face asta? Pentru a facilita transferul modificărilor folosind „comparația procedurală”.

Aici în imagine puteți vedea asta folosind „comparația procedurală” puteți evidenția pur și simplu această procedură când combinați, și va fi transferat complet (împreună cu etichetele). Sau invers, puteți debifa caseta din fața ei pentru a nu o transporta.

Și dacă comentariul de închidere este pe linia următoare, atunci va fi trimis la următoarea procedură și nu va fi posibil să-l transferați așa fără costuri suplimentare.

3. Adăugarea de obiecte de nivel superior

Următoarea regulă este adăugarea obiectelor de nivel superior (directoare, documente, registre etc.) la configurație.

Această regulă este aceea numele obiectelor trebuie să înceapă cu un prefix. Pentru ce?

• În primul rând, evidențiază vizual elementul adăugat în configurație și în cod. puteți vedea imediat că acesta este obiectul nostru adăugat.
• În al doilea rând, se realizează unicitatea numeluideoarece furnizorul își poate adăuga propriul obiect cu același nume. Și dacă folosim propriul nostru prefix, acesta va garanta că numele nostru va fi unic.

Sinonimele de obiect trebuie să înceapă cu un prefix între paranteze... Acest lucru permite ca obiectul nostru adăugat să fie evidențiat în interfață.

Desigur, aceasta este o regulă foarte controversată și aplicarea acestuia trebuie convenită cu clientul... Clienții noștri au fost mulțumiți de o astfel de schemă, așa că a rămas cu noi și a intrat în reguli. Dar aici depinde de dvs. și de client să decideți dacă să faceți acest lucru sau nu.

Ei bine, ultima regulă: comentariile la toate obiectele adăugate trebuie să conțină o etichetă specială cu numele dezvoltatorului și numărul sarcinii. Această etichetă este similară cu comentariul de deschidere din modul, doar fără caractere speciale - cu ajutorul său pot înțelege întotdeauna cine, când și pentru ce sarcină a adăugat acest obiect.

Deci, pentru a rezuma:

• Numele sunt prefixate cu,
• Sinonime - prefixate între paranteze
• Iar comentariul trebuie să conțină o etichetă specială.

4. Adăugarea de obiecte subordonate

Prin adăugarea de obiecte subordonate mă refer la adăugarea de recuzită, machete, forme etc. în obiecte de configurare.

Aici trebuie să evidențiem imediat două situații în care adăugăm un obiect subordonat:

• Intr-un obiect tipic de configurare
• Sau într-un obiect care a fost adăugat mai devreme în cadrul proiectului.

Să luăm în considerare fiecare dintre aceste situații separat.

Pentru a adăuga obiecte subordonate obiectelor de configurare tipice se aplică următoarele reguli.

• Numele trebuie să înceapă exact la fel cu un prefix... Datorită acestui fapt, obținem unicitatea numelui și este, de asemenea, întotdeauna clar din punct de vedere vizual că acesta este obiectul nostru.

• Sinonimul este completat fără prefix, deoarece nu mai este nevoie să ne selectăm obiectele, cerințele.

• Și, în sfârșit, comentariul conține și o etichetă specialăpentru a clarifica cine, când și de ce.

Deci, să rezumăm modul în care obiectele subordonate sunt adăugate la obiectele tipice de configurare:

• Numele sunt prefixate cu,
• Sinonime generale
• Și comentariile conțin o etichetă specială.

ȘI dacă adăugăm obiecte subordonate acelor obiecte care au fost adăugate anterior în cadrul proiectului și conțin deja un prefix în numele lor, apoi:

• Al lor numele nu trebuie să conțină un prefix, deoarece este deja clar că obiectul este deja unic și nu este nevoie să-l evidențiezi în alt mod.

• Sinonimele pentru astfel de obiecte subordonate sunt de asemenea specificate fără prefix.deoarece nu este necesară o selecție specială.

• Și comentariul conține o etichetă specială numai atunci când acest obiect subordonat este adăugat ca parte a unei alte sarcini. Pentru că dacă în sarcina mea este scris că trebuie să adaug un document care să aibă astfel de detalii, nu trebuie să pun un astfel de semn pentru fiecare atribut. Dar dacă sarcina este complet diferită, am pus cu siguranță o etichetă, astfel încât să fie clar de ce am făcut-o.

Acum să rezumăm modul în care obiectele subordonate sunt adăugate la obiectele adăugate în cadrul proiectului:

• Nume fără prefix.
• Sinonime fără prefix.
• Și comentariile ar trebui să conțină o etichetă specială numai atunci când sunt adăugate ca parte a unei alte sarcini.

Dacă această regulă este combinată pentru ambele cazuri și „puneți pe rafturi”, veți obține următorul tabel:

• Obiecte noi:
  • Numele începe cu un prefix.
  • Sinonimele sunt prefixate între paranteze.
  • Comentariul conține o etichetă.
• Obiectele subordonate pe care le adăugăm la obiectele generice:
  • Numele încep cu un prefix,
  • Sinonim pentru reguli generale
  • Punem o notă în comentariu.
• Și dacă adăugăm obiecte subordonate obiectelor adăugate în cadrul proiectului, atunci
  • Nu există reguli speciale pentru ei,
  • Dar dacă sarcina este diferită, atunci punem un semn în comentariu în același mod.

5. Adăugarea de elemente predefinite

Următoarea regulă este să adăugați elemente predefinite.

Două situații se pot distinge aici în același mod:

• Când adăugăm un element predefinit unui obiect de configurație tipic (la o referință, la o diagramă a tipurilor de caracteristici)
• Și când adăugăm un element predefinit la obiectul adăugat în cadrul proiectului.

Dacă adăugăm un element predefinit unui obiect de configurare generic,

• A lui nume similar trebuie să înceapă cu un prefix... Astfel, garantăm unicitatea numelui său și putem identifica imediat vizual elementul nostru adăugat.
• Cod și numese va forma conform regulilor generale,
• Dar eticheta aici, din păcate, nicăieri de pus... Prin urmare, nu va fi posibil să găsiți acest element predefinit adăugat printr-o căutare globală de sarcini.

ȘI dacă adăugăm elemente predefinite obiectelor adăugate în cadrul proiectuluiatunci

• A lui numele nu va conține un prefix, deoarece nu este nevoie să o evidențiem cumva.

Deci, dacă facem o analogie cu tabelul anterior, atunci:

• Elementele predefinite pentru obiectele generice sunt adăugate cu prefixul,
• Și toate celelalte - în conformitate cu regulile generale, nu trebuie adăugate prefixe speciale.

6. Utilizarea modulelor comune și a structurii lor stricte

Următoarea regulă se referă la utilizarea modulelor comune și organizarea unei structuri stricte pentru acestea.

În primul rând, ar trebui să adăugați propriile module pentru diferite proceduri, funcții, gestionare a abonamentelor și lucrări programate utilizate în mod repetat, lăsând modulele standard neschimbate. Și dacă un dezvoltator dorește să plaseze un fel de procedură de export într-un modul tipic, atunci nu trebuie să facă asta, trebuie să își creeze propriul modul.

În al doilea rând, vă rugăm să rețineți că modulele comune sunt adăugate conform regulilor pentru adăugarea obiectelor de nivel superior (nume și sinonim cu prefix, etichetă în comentariu etc.)

În al treilea rând, numele modulelor trebuie să fie similare cu modulele standard corespunzătoare.

Nu este nevoie să reinventăm roata: o numim la fel cum este obișnuit în configurațiile tipice - pentru fiecare funcționalitate există un modul corespunzător notației general acceptate în 1C. De exemplu:

• FTO_GeneralAppointmentClient,
• FTO_GeneralPurposeServer,
• FTO_General PurposeGlobal,
• FTO_RegularJobsServer
• Etc.

Si ceva sarcini individuale mari este posibil (și, probabil, este necesar) mutați în module comune separate.

7. Utilizarea abonamentelor și structura strictă a acestora

Următoarea regulă este utilizarea abonamentelor și structura strictă a acestora. Care este esența sa?

Abonamentele ar trebui utilizate pentru a gestiona diferite evenimente legate de obiecte generice, ca:

• Înainte de a înregistra
• La înregistrare
• Etc.

• Desigur, puteți lua și editați modulul unui obiect tipic, prin introducerea codului dvs. în procedura corespunzătoare. Dar asta - cale greșită.
• E mai bine in loc de asta adăugați un abonament pentru a gestiona acest eveniment.

Abonamentul este adăugat în conformitate cu următoarele reguli convenite:

1. Se adaugă un singur abonament pentru toate evenimentele de același tip din sistem... De exemplu, dacă trebuie să-mi folosesc algoritmul pentru diverse referințe în cazul „Înainte de a înregistra o referință”, atunci pentru toate aceste referințe folosesc un singur abonament adăugat „Înainte de a înregistra o referință”.
2. Toate obiectele din această clasă sunt selectate în sursă(de exemplu, toate directoarele)
3. Pentru abonamentul adăugat, se creează un modul separat, numit exact la fel (doar pentru comoditate).
4. În gestionatorul principal de evenimente, este definită o condiție care analizează tipul de obiect (fel de carte de referință).
5. Și deja anumite acțiuni sunt efectuate în funcție de tipul de obiect.

Vă pot arăta cu un exemplu. Să presupunem că există o astfel de sarcină: atunci când postați documentul „Raport avansat”, faceți intrări în registrul de acumulare adăugat mai devreme.

Mai întâi, adăugăm un modul general FTO_DocumentsProcessingWith toate regulile.

• Specificați DocumentObject (toate documentele) ca sursă;
• Ca manipulator - modulul nostru a fost adăugat mai sus.

Și deja în modul, în gestionarul în sine, determinăm ce fel de document a venit la noi și, în funcție de tipul său, numim această sau acea procedură.

Abonamentul este unul, dar acțiunile pot fi diferite. Tde asemenea, puteți controla ordinea în care sunt apelate procedurile.

Ca urmare, procedura de creare a unui abonament este după cum urmează:

• Un abonament,
• Un modul comun
• Și nu este nevoie de nimic altceva: modulul de document rămâne neschimbat - în „de două ori modificat” nu va mai apărea.

8. Editarea formularelor

Următoarea regulă este editarea formularelor.

Aici, în același mod, evidențiem două puncte, două situații:

• Când edităm exemple de formulare;
• Și când edităm formularele adăugate în cadrul proiectului.

Prima situație este editareaformulare standard, forme de obiecte tipice... Acesta este cel mai controversat punct al regulilor. La un moment dat, în vremea formularelor convenționale, când proiectele se făceau în principal pe SCP, am avut multe discuții despre ce să facem cu formularele. Care au fost opțiunile?

• Editarea directă a formelor obișnuite este că doar schimb forma manual. Cu această opțiune, de fiecare dată când furnizorul își modifică acest formular, trebuie să transfer din nou toate modificările mele. Cale greșită.
• O altă modalitate este făcând o copie a formularului... Acesta este momentul în care fac o copie a formularului eșantion, îl atribuiesc celui principal și le fac modificările. Dar, din nou, dacă un furnizor modifică acest formular, trebuie să transfer manual modificările în varianta mea. Nu este cel mai bun mod.
• O altă opțiune este crearea unei file separate... Creați o filă separată pe formular și plasați elementele noastre pe el. Este clar că această metodă nu este flexibilă, deoarece uneori trebuie să introduceți elementul undeva într-un anumit loc al formularului. Sau trebuie să modificați proprietățile elementelor standard, să le atribuiți un nou handler etc. Prin urmare aceasta mod nu flexibil - nici nu merge foarte bine.
• Ca rezultat am ales o metodă de editare a formularelor complet programatică... Noilor dezvoltatori care nu au întâlnit această metodă le este inițial foarte dificil să editeze un formular prin programare. Dar, în realitate - nu. Din practica mea, voi spune că trebuie doar să vă puneți mâna în mână. În plus, avem module scrise de mult timp cu proceduri de export pentru schimbarea programelor a formularelor și toate acestea se fac destul de ușor. Când s-au introdus formulare gestionate, am migrat, de asemenea, pe deplin această practică de schimbare programată a formularelor în formulare gestionate. Mai mult decât atât, a devenit în general ușor să editați programatic un formular gestionat - cu formele uzuale nu compara.

Să vă arătăm cu un exemplu. În handler OnCreateAtServer, adaug un apel la procedura mea ModifyFormProgrammatically, unde am adăugarea de software elemente pe formă.

În configurații bazate pe BSP 2 (cum ar fi ERP, contabilitate etc.) adăugat handlerForm.OnCreateAtServer de evenimente ()care, printre altele, intră de asemenea în modulul suprascris.

Așadar în modulul suprascris puteți adăuga codul - de exemplu, la procedura OnCreateAtServer (). Aici definesc numele formularului și, în funcție de acesta, numesc aceasta sau acea procedură, unde adaug elemente programatic.

Se pare că este dificil, că această schemă este greoaie, dar de fapt, dacă toate proiectele sunt realizate conform unor astfel de reguli, atunci dezvoltatorul, care primește sarcina, știe deja imediat unde să caute, unde să adauge ce. Prin urmare, mi se pare că este foarte convenabil.

În plus, în configurațiile bazate pe BSP 2, sunt redefinite și alte gestionare de formulare - precum ReadOnServer (), BeforeWriteOnServer () etc. Și în aceste gestionare, puteți utiliza, de asemenea, activ suprascrierea procedurilor numite. Mai mult, modulul suprascris al vânzătorului nu se modifică teoretic și puteți scrie codul acolo fără teama de conflicte.

Dacă edităm un formular adăugat în cadrul proiectului, atunci nu este nevoie să facem nimic special, îl edităm în mod obișnuit, manual.

9. Principii de lucru cu roluri

Și ultima regulă este principiile de lucru cu roluri.

Principiile de lucru cu rolurile sunt după cum urmează:

1. Dacă este posibil atunci rolurile tipice trebuie lăsate întotdeauna fără nume... Trebuie să vă gândiți cu atenție dacă este cu adevărat necesar să schimbați rolul tipic sau dacă puteți face ceva diferit.
2. Atribuim drepturi obiectelor de configurare adăugate în roluri noi, create special. Prin urmare, când adaug un raport la configurație și nu există un rol adecvat pe care l-am adăugat anterior pentru acesta, creez un rol separat. Și apoi acest rol este adăugat la profilurile necesare. Iar rolurile tipice nu se schimbă.
3. ȘI dacă există modificări înRLS, apoi sunt întocmite conform regulilor de editare a modulelor.

De exemplu, dacă trebuie să schimb RLS, atunci pun un comentariu de deschidere, comentez vechiul cod, apoi adaug propriul meu și pun un comentariu de închidere. Este întotdeauna clar: cine, de ce (în ce sarcină) și când m-am schimbat.

Deci, am enumerat toate cele nouă reguli simple pentru modding.

Obiecte și tehnici suplimentare pentru a face viața mai ușoară

În concluzie, voi vorbi despre unele dintre obiectele și tehnicile care pot ușura viața unui dezvoltator.

1. Autoidentificarea bazelor de testare

Prima tehnică este autoidentificarea bazelor de testare.

Concluzia este că:

• există o constantă care stochează adresa bazei productive active.
• Când sistemul pornește, această adresă este verificată: dacă se potrivește cu adresa bazei de lucru sau nu.
• ȘI dacă nu se potrivește (baza nu funcționează), atunci antetul sistemului este înlocuit.

Captura de ecran arată cum arată. Acest lucru este util mai ales atunci când dezvoltatorii (sau consultanții) au multe baze de date deschise (de lucru, testare, dezvoltare etc.) și pot greși din greșeală și pot schimba datele din baza de date de lucru. Și dacă titlul este schimbat, atunci „pe mașină” - ochii din colțul din stânga sus, vedeți ce fel de bază este - da, testați, îl puteți schimba.

Astfel, modificăm datele din bazele de date mai sigure.

În afară de, verificarea valorii acestei constante este, de asemenea, utilă atunci când efectuați unele sarcini de rutină... Și anume:

• schimb de date,
• notificări utilizator,
• unele corespondențe,
• sarcini grele de rutină.
• Etc.

Când un dezvoltator creează o astfel de sarcină programată, trebuie să verifice dacă este sau nu o bază de lucru. Este clar că, în teorie, sarcinile programate pe toate bazele de testare ar trebui să fie dezactivate în consola cluster. Dar există întotdeauna un factor uman, când cineva a creat o nouă bază de date, a încărcat date noi în ea, a schimbat ceva și, ca rezultat, a existat un fel de schimb critic cu baze de date funcționale. Și apoi confruntarea - de ce s-a întâmplat? De aceea noi înainte de sarcini de rutină critice, verificăm întotdeauna dacă este o bază de lucru sau nu.

Configurările bazate pe BSP 2 au un mecanism similar: dacă se modifică locația bazei de date, se pune întrebarea - este o copie a bazei de date sau a fost mutată baza de date. În principiu, acest mecanism poate fi suficient, dar din nou, factorul uman poate interveni, cineva nu va înțelege ce se întâmplă și va apăsa butonul greșit. Prin urmare, după părerea mea, constanta este mai fiabilă.

2. Manipularea inițializării

Următorul truc este tratarea inițializării.

• Aceasta este o procesare de completare de configurare care conține versiunea sa curentă în codul său.
• În același timp, o anumită constantă este adăugată și la configurație, care stochează versiunea curentă a procesării de inițializare.
• La pornirea sistemului, se efectuează o verificare
• Și, dacă versiunea s-a schimbat, sunt executate gestionarele necesare și se setează o nouă valoare constantă.

De ce este nevoie de asta? Adesea, atunci când adăugați noi funcționalități la configurație, este necesar să efectuați unele acțiuni în baza de date în sine: de exemplu, am adăugat un element de catalog predefinit, iar acum trebuie să completăm detaliile acestuia. Pot exista o mulțime de baze pe proiect, iar completarea manuală a acestor date este, desigur, rea. Mai corect:

• Măriți versiunea procesare inițializare;
• Descrieți în cod cum să completați datele prin program;
• Si dupa aceea o nouă versiune prelucrare automat prin stocare va intra în toate bazele de date necesare, începe de acolo și va efectua toate acțiunile necesare.

În diagramă, aceasta procedura de operare afișat astfel:

• Pornirea sistemului
• Compararea versiunii constante cu versiunea de procesare.
• Dacă nu se potrivește, sunt efectuate consecvent toate necesare manipulatori,
• Noua valoare a constantei este setată.

Ca urmare, datele sunt actualizate peste tot, în toate bazele de date.

3. Directorul valorilor predefinite

Următorul truc este un director cu valori predefinite.

Este adesea necesar să se facă referire din cod la elementele de catalog existente care nu sunt predefinite. Este clar că este mai bine să creați un element predefinit, dar s-a întâmplat ca un element să nu poată fi predefinit, dar va fi totuși abordat.

Care sunt opțiunile de implementare?

• Consultați articolul după nume... Este clar că numele s-a schimbat - codul a încetat să funcționeze. slab.
• Consultați după cod... Puțin mai bine, dar și codul se poate schimba. Nu prea bine.
• Contact prin identificator intern. Apoi, la portare, nici acest cod nu va funcționa. În general, toate aceste trei cazuri nu vor funcționa dacă transferăm o modificare de la o bază la alta. Nu prea bine.
• A oferit creați un director cu valori predefinite.

Acest director conține un singur atribut cu tipul Director. (link către toate cărțile de referință).

Dacă în cadrul unei sarcini trebuie să mă refer la un element, adaug un element predefinit la această referință (de exemplu, Contractor_Agroimpulse)

Și apoi, în codul de procesare a inițializării sau manual, completez valoarea acestui director cu contrapartea de care am nevoie.

În consecință, după aceea voi putea face referire la această contrapartidă prin directorul valorilor predefinite... Datorită acestui fapt, se realizează că:

• Când transferați modificări între diferite baze, toate datele mele codul funcționează fără nicio lucrare suplimentară.
• În plus, este posibil ca astăzi această contrapartidă să fie Agroimpulse și mâine să fie o altă organizație, dar nu trebuie să modific nimic în configurație, pur și simplu iau și îi schimb valoarea în directorul valorilor predefinite.

4. Vizualizarea tabelelor temporare în depanator

Ei bine, ultimul truc este să vizualizați tabele temporare în depanator.

• Când depanați interogări complexe cu tabele temporare trebuie să poată vizualiza conținutaceste mese temporare.
• În aceste scopuri poate sa folosiți o funcție specială pentru a vizualiza tabele temporare.
• Această funcție convenabil loc în modulul global.

• ȘI a numi oarecum scurt, de exemplu BT ()

În acest caz:

• Eu pune un punct de întrerupere la locația în care am cererea.
• În fereastra „Calculați expresia” scriu VT (Cerere);
• Fac clic pe „Calculare” și obținerea structurii tabelelor de interogare temporarăpentru a vedea ce date există.

Aceasta este o caracteristică foarte utilă și o folosim tot timpul. Mai ales la calcularea costurilor sau în configurații precum ZUP. Sincer, nu înțeleg cum trăiesc alții fără ea.

Cea mai recentă versiune a platformei are instrument încorporat,ceea ce vă permite să vizualizați tabele temporare, dar mi se pare nu foarte confortabil. Folosirea funcției dvs. este mult mai bună.

Concluzie

Mulțumiri tuturor. Am un site mic, pe acest site toate aceste reguli sunt prezentate în detaliu și nu numai ele - intrați, citiți, scrieți-mi prin poștă sau skype.

Acest subiect este interesant pentru mine, sunt gata să comunic despre el. Este foarte important pentru mine să reușești și tu.

Lăsați-vă numele și numărul de telefon, operatorul vă va contacta la timp de muncă în termen de 2 ore.

Moscova Saint Petersburg Samara

Oferiți un set de instrumente puternic și versatil pentru diferite companii și companii. Cu toate acestea, merită menționat faptul că universalitatea are un dezavantaj: programele îndeplinesc doar funcții generale. pentru nevoile fiecărei companii specifice este destul de simplu - îmbunătățirile 1C vă vor ajuta în acest sens.

Avantajele de a lucra cu noi

• Toate serviciile pentru revizuirea 1C 8.2 sunt efectuate în conformitate cu tehnologia bine stabilită, certificată conform sistemului internațional de management al calității ISO 9001: 2001.
• Vă garantăm termeni minimi executarea muncii, sub rezerva cooperării active a Clientului cu experții companiei noastre.
• Am stabilit preturi minimeastfel încât atât începătorii cât și companii mari ar putea aduce îmbunătățirile necesare la 1C.
• noi controlăm calitatea performanța muncii. Fiecare angajat este desemnat un expert 1C care controlează munca.
• noi dăm garanții pentru munca prestată. Dacă în termen de două luni Clientul descoperă erori și defecțiuni în funcționarea programelor 1C, le vom remedia absolut gratuit.

Ce sunt îmbunătățirile 1C?

Rafinarea 1C este un fel de „reglare” a programelor 1C pe care le folosiți cel mai des în munca dvs.

Pe bază, există diverse modificări care acoperă maxim întreprinderile, companiile și organizațiile reprezentate pe piața internațională. Dar nu poți mulțumi pe toată lumea, deoarece fiecare companie este unică. Aceste îmbunătățiri „locale” sunt aduse de specialiștii 1C: franciza Victoria.

Când ar trebui să actualizați 1C?

Înainte de a aduce îmbunătățiri la 1C, trebuie să răspundeți la câteva întrebări:

• Specificul organizației este implementat în funcționalitatea tipică? Experiența noastră ne permite să afirmăm că majoritatea deciziilor privind revizuirea se iau în grabă. Ca urmare, companiile investesc o mulțime de bani în îmbunătățiri și modificări, dar nu obțin rezultatul scontat. Dar au trebuit doar să consulte un specialist.
• Procesele care urmăresc automatizarea organizației sunt cu adevărat importante exact în forma în care s-au dezvoltat în companie? Când dezvoltă configurații pentru 1C, specialiștii 1C: Franchisee Victoria folosesc metode de contabilitate care au fost testate în timp și experiența multor companii. Astfel de tehnici sunt cele mai eficiente, deci este mai bine să ne încredem în experiența noastră și să restructurăm ușor unele dintre procesele de afaceri din companie.

Experții recomandă îmbunătățiri numai cu condiția ca toate posibilitățile funcționalității încorporate să se fi epuizat deja. Vrem să menționăm că funcționalitatea tipică a programelor 1C este destul de largă și, dacă este configurată corect, poate fi utilizată pentru a rezolva majoritatea sarcinilor standard.

Dacă este imposibil să se facă fără modificări, experții analizează dacă modificările introduse vor afecta alte secțiuni contabile.

Scopul nostru este să aducem îmbunătățiri cu modificări minime ale configurației, astfel încât întreținerea suplimentară a software-ului să nu se transforme într-o „gaură neagră” și o durere de cap pentru companie.

În compania noastră, îmbunătățirile la configurațiile 1C sunt efectuate în conformitate cu cerințele sistemului internațional de calitate ISO 9001: 2001.

Cum este rafinat 1C?

Principalul avantaj competitiv al produselor software 1C 8.2 și 8.3 este capacitatea de a modifica configurațiile standard ale programului și de a dezvolta cele mai optime soluții pentru cerințele utilizatorului final pe baza platformei 1C.
Funcționalitatea largă implementează propriul limbaj de programare, precum și un mediu de dezvoltare încorporat care oferă flexibilitate în setări.

Compania 1C în interesul utilizatorilor software creează soluții gata făcute, capabile în egală măsură să satisfacă nevoile fiecărei organizații, luând în considerare unicitatea și specificul oricărei întreprinderi. O selecție largă de programe de completare la configurația de bază face ca lucrul în 1C să fie cât mai confortabil posibil.

Aveți o întrebare, aveți nevoie de ajutorul unui consultant?

Care sunt cele mai frecvente îmbunătățiri la 1C?

Cel mai comun tip de prelucrare este modificarea interfeței cu utilizatorul. Modificările mai profunde legate de crearea și implementarea algoritmilor speciali în sistem sunt mai puțin frecvente, dar sunt disponibile și pentru implementare.

Exemple de modificări 1C

1. Configurarea flexibilă a drepturilor de acces și de utilizator este probabil cea mai relevantă pentru orice sistem multi-utilizator. De asemenea, în 1C este posibilă configurarea valorilor implicite, ceea ce accelerează semnificativ procesul de lucru.
2. Dezvoltarea și corectarea diferitelor formulare tipărite, în 1C, care sunt analogi unui document pe hârtie, precum și rapoarte, care sunt produsul final al analizei datelor introduse în programul 1C. Aceste modificări nu necesită intervenții serioase în configurația programului.
3. Dezvoltarea și executarea de specificații tehnice clare și ușor de înțeles pentru programatorul 1C, facilitând modificările ulterioare și permițând implicarea cu succes a contractanților terți în implementarea acestuia.
4. Sistemul 1C este destul de versatil și în versiunea inițială nu îndeplinește întotdeauna toate cerințele utilizatorului final, prin urmare necesită adesea dezvoltarea și implementarea unei funcționalități unice, conform dorințelor clientului.
5. Reglarea și performanța performanței, pentru a asigura o eficiență maximă în efectuarea operațiunilor de decontare

Costul serviciilor de specialitate pentru lucrul cu 1C

Aproape toate proiectele din aproape orice companie mare de integratori 1C constau în finalizarea configurațiilor tipice și vizează în principal optimizarea contabilității activitatea economică organizarea și livrarea raportării reglementate relevante. Iar acest lucru, la rândul său, înseamnă că, în viitor, soluțiile implementate vor trebui rafinate în conformitate cu legislația care se schimbă frecvent. În practică, acest lucru înseamnă aproape întotdeauna actualizarea versiunilor configurațiilor tipice, pe baza cărora a fost luată decizia și adaptarea modificărilor deja făcute în conformitate cu modificările din următoarea versiune.

Adesea, un proiect nu poate fi numit complet de succes dacă clientul nu a rămas în organizația integratoare pentru asistență. Și dacă respectați regulile stricte pentru schimbarea configurațiilor tipice, atunci cheltuiți foarte puțin timp în etapa de dezvoltare, puteți economisiți multe, multe ore și nervi în viitor la actualizarea constantă a configurației modificate. Dimpotrivă, o atitudine nepoliticoasă, „diavol-poate-îngriji” față de proiectarea codului, alegerea mai rapidă și mai simplă, dar nu modalitățile corecte de implementare a sarcinilor poate transforma actualizarea configurației rezultate într-un adevărat infern pentru asistență. În viitor, acest lucru va avea ca rezultat ore de actualizare uriașe, o încărcătură accentuată de dezvoltatori în perioada de raportare, un număr mare de erori după actualizare, nemulțumirea clienților etc.

Mai jos este un set de reguli de dezvoltare în configurații tipice, care vor facilita mult actualizările ulterioare ale configurației. Acest cod a luat naștere treptat din mulți ani de experiență a unui număr mare de dezvoltatori ai unei companii minunate și, în profunda mea convingere, ar trebui să fie obligatoriu pentru toți dezvoltatorii, indiferent în ce departament / proiect / direcție lucrează.

1. Conceptul de minimizare a „distrugerii” unei configurații tipice

Dacă se presupune că configurația tipică modificată va fi actualizată odată cu lansarea noilor versiuni, atunci dezvoltatorii ar trebui să o facă amintiți-vă întotdeauna acest lucru și luați măsuri pentru a facilita actualizarea. Ar trebui să alegeți întotdeauna acele metode de rezolvare a problemelor care vă vor oferi actualizare mai ușoară a configurației în viitor, chiar dacă sunt ceva mai dificil de implementat. Desigur, numai cu condiția ca metoda mai ușor de actualizat să nu prezinte neajunsuri grave în ceea ce privește performanța, înțelegerea codului etc.

2. Comentarea modificărilor de cod:

Absolut toate modificările aduse codului de program al modulelor ar trebui comentate. Un bloc de linii care a suferit o modificare trebuie să fie înconjurat de linii de comentarii cu un format special. Principiul formării acestor linii este prezentat printr-un exemplu:

// ++ VION 20.07.2016 0001234 Îmbunătățire la început // - VION 20.07.2016

• // ++ - începutul blocului
• // - - sfârșitul blocului
• VION - numele (sau porecla) dezvoltatorului
• 0001234 - numărul activității de către tracker, introdus numai în comentariul de deschidere, astfel încât fiecare modificare a codului să intre în rezultatele căutării globale după numărul activității o singură dată
• Rafinare la început - un comentariu arbitrar, folosit dacă este necesar, dar dacă numărul sarcinii lipsește, atunci este necesar un scurt text explicativ

Comentariile sunt menite să evidențieze modificările față de funcționalitatea tipică. Dacă un dezvoltator modifică textul propriei modificări după o perioadă de timp în cadrul aceleiași sarcini, atunci aceste modificări nu sunt comentate separat (și nici comentariul extern existent nu se modifică). Dacă un dezvoltator modifică textul său, dar pentru o altă sarcină sau modifică codul scris de un alt dezvoltator, atunci ar trebui să se utilizeze comentariile.

Comentariile de încadrare sunt aliniate la stânga blocului de cod modificabil. Exemplele de mai jos demonstrează modul de utilizare a comentariilor de schimbare:

2.1 Introducerea codului

Exemplu:

Procedură OnOpening () Dacă acest lucru este nou (), atunci FillFieldsDefault (); EndIf; ConfigureFormElements (); // ++ VION 20.07.2016 0001234 ConfigureAdditionalElements (); // - VION 20.07.2016 SetFields Visibility (); Sfârșitul procedurii

2.2 Eliminarea codului

Exemplu:

Procedură deschisă () // ++ VION 20.07.2016 0001234 // Dacă acest lucru este nou () Atunci // FillFieldsDefault (); // EndIf;ConfigureAdditionalElements (); // - VION 20.07.2016 SetFields Visibility (); Sfârșitul procedurii

2.3 Modificarea codului existent

La schimbarea codului existent, mai întâi se comentează vechiul bloc, apoi se scrie o nouă versiune.

Exemplu:

Procedură Activată Deschideți () Dacă acest lucru este nou () Atunci // ++ VION 20.07.2016 000123 // FillFieldsDefault ();FieldFillSettings \u003d GetFieldsFillSettings (); FillFieldsDefault Advanced (CustomizeFillFields); // - VION 20.07.2016 EndIf; ConfigureFormElements (); SetVisibilityFields (); Sfârșitul procedurii

2.4 Adăugarea de proceduri și funcții într-un modul

Pentru proceduri și funcții adăugate, precum și pentru declararea variabilelor modulului obiectelor standard, reguli suplimentare comentând:

• Nu blocul de proceduri adăugate este comentat în ansamblu, ci fiecare procedură sau funcție adăugată în separat.
• Comentariul de deschidere merge pe linia dinaintea șefului procedurii sau funcției, iar comentariul de închidere merge pe aceeași linie, unde scrie „Sfârșitul procedurii” sau „Sfârșitul procedurii”, separat printr-un spațiu.
• Comentariile asupra modificărilor în cadrul procedurilor existente se efectuează în conformitate cu regulile generale.

Exemplu:

// ++ VION 20.07.2016 000123 Var mSettingsFillFields; Procedură Modificați formularul programatic () ... ... EndProcedure// - VION 20.07.2016 // ++ VION 20.07.2016 000123Procedură Data livrării ProcesareSelecție () ... ... EndProcedure// - VION 20.07.2016

Această regulă facilitează transferul modificărilor într-un modul într-o „comparație procedurală” a configurațiilor.

Dacă puneți comentariul de închidere pe următoarea linie:

Apoi, într-o „comparație procedurală”, acest comentariu va fi recunoscut ca o descriere a următoarei proceduri din text, care va fi considerată modificată.

3. Adăugarea de obiecte de nivel superior

Numele obiecte de nivel superior, creat în configurație, neapărat trebuie să înceapă cu prefixul companiei dvs. sau cu un prefix de proiect separat. De regulă, este format din două sau trei litere majuscule și un subliniat, de exemplu AB_... În consecință, obiectele create vor fi denumite AB_NewReference, AB_NewDataRegister, AB_NewDocument etc.

Sinonimele (nume vizibile de utilizator) ale obiectelor de nivel superior adăugate trebuie să înceapă cu un prefix inclus între paranteze: (AB)... Ca urmare, aceste obiecte vor fi evidențiate vizual în liste și sunt grupate la începutul acestora (ceea ce face atât testarea, cât și utilizarea mai ușoară).

În comentariul obiectului creat, ar trebui să indicați numele dezvoltatorului, data și numărul sarcinii, prin analogie cu codul adăugat, dar fără semnele „++”. Acest lucru va asigura faptul că obiectul de configurare este legat de sarcina pe care o caută căutarea globală.

Exemplu: Creați un director „Proiecte”.

Acțiunile dezvoltatorului: următoarea referință este creată în configurație:

• Nume: AB_Projects
• Sinonim: Proiecte (AB)

4. Adăugarea de obiecte subordonate

Modul de adăugare a atributelor obiectelor de configurare depinde de obiectul de configurare la care se adaugă atributul: la obiectul de configurare creat de furnizorul unei soluții tipice (adică, un obiect sub suport) sau unui obiect adăugat în cadrul proiectului curent ( adică având deja un prefix) ...

4.1 Adăugarea de obiecte subordonate la obiecte de configurare tipice

Obiectele subordonate adăugate obiectelor de configurare (tipice) existente trebuie prefixat: AB_AdditionalProps, AB_New TabularPart, AB_UserSettingsForm, AB_LayoutSpecial Invoice... Dar, în același timp, sunt create sinonime ale unor astfel de obiecte subordonate fără prefix.

În comentariul obiectului creat, ar trebui să specificați numele dezvoltatorului, data și numărul sarcinii, prin analogie cu. Acest lucru va asigura faptul că obiectul de configurare este legat de sarcina pe care o caută căutarea globală.

Exemplu: Creați atributul „Proiect” al documentului „Plată în avans”.

Acțiunile dezvoltatorului: în configurație sunt create următoarele elemente de recuzită:

• Nume: AB_Project
• Sinonim: Proiect
• Comentariu: // VION 20.07.2016 000123

4.2 Adăugarea de obiecte subordonate la obiectele adăugate în cadrul proiectului

Se adaugă obiecte subordonate adăugate la obiectele de nivel superior adăugate la configurația din cadrul proiectului, adică care conțin deja un prefix în nume. fără prefix... Sunt create și sinonime pentru astfel de obiecte subordonate fără prefix.

În comentariul obiectului creat, ar trebui să indicați numele dezvoltatorului, data și numărul sarcinii, prin analogie cu. Acest lucru va asigura faptul că obiectul de configurare este legat de sarcina pe care o caută căutarea globală. Comentariul poate fi omis dacă cerințele sunt create în cadrul aceleiași sarcini ca și obiectul de nivel superior.

Exemplu: Creați atributul „Responsabil” pentru directorul „(AB) Projects”.

Acțiunile dezvoltatorului: Dacă sarcina este diferită de cea în care a fost creat directorul „(AB) Projects”, atunci în configurație se creează următorul atribut:

• Nume: Responsabil
• Sinonim: Responsabil
• Comentariu: // VION 20.07.2016 000456

5. Adăugarea de elemente predefinite

Când adăugați elemente de catalog predefinite, diagrame de tipuri caracteristice și diagrame de conturi, ar trebui să utilizați aceleași reguli ca și când adăugați obiecte subordonate (secțiuni tabulare, atribute) la obiectele de nivel superior.

5.1 Adăugarea de elemente predefinite obiectelor de configurare tipice

Elementele predefinite pentru obiecte de configurare tipice sunt în mod necesar adăugate cu prefixul... Numele este setat fără prefix.

Exemplu: Adăugați contul predefinit 10.15 - Formulare de raportare stricte în planul de conturi „Autosustenabil”.

Acțiunile dezvoltatorului: Adăugați următorul cont predefinit:

• Nume: AB_Statement Forms
• Cod: 10.15
• Nume: Forme de raportare strictă

Dacă trebuie să redenumiți un element predefinit al unui obiect de configurare tipic (de exemplu, un cont), ar trebui să lăsați obiectul în sine neschimbat și să îl redenumiți programatic într-unul special.

5.2 Adăugarea de elemente predefinite la obiectele adăugate în cadrul proiectului

Elementele predefinite sunt adăugate la obiectele de configurare adăugate în cadrul proiectului, adică conținând deja un prefix în numele lor fără prefix în nume și titlu.

6. Utilizarea modulelor comune și structura strictă a acestora

Procedurile și funcțiile care sunt utilizate în mod repetat în configurație, abonamente și gestionări de lucrări programate sunt plasate în module comune. În aceste scopuri, adăugați module propriiadăugate de obiecte de nivel superior, lăsând module standard neschimbat... Următoarele module comune ("AB_" - prefix) vor fi utile în timpul dezvoltării:

• AB_General (client, server, conexiune externă) - pentru a găzdui proceduri și funcții normale.
• AB_Server (numai server) - Pentru proceduri și funcții care trebuie executate într-un mediu server.
• AB_Global - pentru proceduri și funcții, care sunt incomode de apelat într-un mod standard (printr-un nume de modul și o perioadă).
• AB_Privilegiat - pentru proceduri și funcții care trebuie să fie îndeplinite întotdeauna în deplinătate.
• AB_Reuse - pentru a memora în cache valorile returnate ale unor funcții.

Codurile blocului funcțional pot fi transferate în module comune separate volum mare, acest lucru face mai ușoară depanarea unui astfel de cod atunci când se utilizează magazinul de configurații. În caz contrar, dezvoltatorul ar trebui să se asigure că este disponibil un modul comun adecvat înainte de a adăuga un nou modul la configurație.

7. Utilizarea abonamentelor și structura strictă a acestora

Pentru a gestiona diferite evenimente asociate cu obiecte de configurare standard, ar trebui să utilizați mecanismul de abonare în loc să modificați modulele obiectelor în sine, dacă este posibil.

Pentru fiecare eveniment pot exista nu mai mult de un abonament (ca obiect de metadate), al cărui handler și codul asociat ar trebui să fie plasate în un modul general separat (pentru a spori paralelismul dezvoltatorilor cu depozitul). Numele abonamentului și numele modulului partajat trebuie să fie sunt la fel și potrivi evenimentul fiind procesat. Este indicată sursa abonamentului toate obiecte potențial posibile pentru procesare (toate directoarele, toate documentele etc.).

Procedura de gestionare a abonamentului trebuie să conțină apeluri de subrutină care efectuează acțiunile necesare. Acestea sunt menționate în funcție de tipul sursei, precum și în secvența dorită. Se efectuează comentarii în modulul de abonament atunci când se adaugă cod pentru sarcini noi.

Exemplu: La postarea documentului „Plată în avans”, faceți înregistrări în registrul de acumulare „(AB) Costurile proiectului”.

Acțiunile dezvoltatorului:

1. Creați un abonament „AB_DocumentsProcessingProcessing” (dacă un astfel de abonament nu a fost creat anterior), specificați toate documentele ca sursă, evenimentul - „PostingProcessing”.

2. Creați un modul de server comun "AB_DocumentsProcessingProcessing".

3. În modul, creați o procedură de export „Procesarea înregistrării”. Selectați această procedură ca gestionar pentru abonamentul creat anterior. În procedură, în funcție de tipul de document, sunt apelați gestionarii necesari.

4. Modulul documentului „Plata în avans” trebuie să rămână neschimbat.

8. Editarea formularelor

8.1 Editarea formelor obiectelor tipice

Dacă modificarea formularului standard (atât normal, cât și gestionat) este mică (de exemplu, pentru a pune mai multe detalii noi pe formular), atunci o astfel de modificare ar trebui efectuată complet programatic. Adică, modificările se fac doar la modulul formular, iar formularul în sine din configurator rămâne neschimbat... Pentru unii dezvoltatori, această metodă de editare a formularelor poate părea destul de consumatoare de timp la început. Cu toate acestea, având suficientă experiență în schimbarea programelor de forme, nu va dura mai mult de 3-5 minute pentru a adăuga un element. Timpul petrecut se plătește de multe ori cu actualizările ulterioare ale configurației tipice.

Exemplu: În formularul principal al documentului „Plata în avans”, adăugați variabila „(AB) Project”.

Acțiunile dezvoltatorului: În handlerul formularului „OnCreateAtServer” adăugați procedura „ModifyFormProgrammatically ()”. În această procedură, adăugați elementul dorit pentru a forma elemente.

Este posibil să creați un modul separat, care va conține toate procedurile și funcțiile necesare pentru schimbarea formularelor standard.

În configurațiile tipice bazate pe BSP 2, există deja o funcționalitate specială în aceste scopuri:

În procedura „OnCreateAtServer” a modulului general „ModifyConfigurationRedefinable”, vă puteți apela gestionarul.

Unde, prin numele formularului, puteți apela procedura necesară cu modificarea programatică a formularului.

Dacă intenționați să adăugați la formular număr mare de elemente sau secțiuni tabulare, este de asemenea posibil să modificați manual formularul. În acest caz, se recomandă să creați o filă separată pe formular și să plasați toate elementele necesare pe acesta. Acest lucru va face mult mai ușor să actualizați formularul în continuare.

8.2 Editarea formelor obiectelor adăugate în cadrul proiectului

Formele obiectelor adăugate în cadrul proiectului (adică cele cu un prefix în numele lor) sunt editate în mod obișnuit.

9. Principii de lucru cu roluri

Rolurile generice trebuie lăsate întotdeauna neschimbate (dacă este posibil). Acest lucru este pentru a face mai ușoară actualizarea configurației modificate de la noile versiuni, deoarece compararea și restabilirea rolurilor este un proces complicat și minuțios.

Drepturile asupra obiectelor adăugate la configurație ar trebui atribuite în nouroluri create în acest scop.

Ar trebui implementate restricțiile de acces la date permise de rolurile generice programaticcât mai mult posibil. Și numai atunci când o astfel de interdicție va fi foarte dificil de implementat programatic (sau o astfel de soluție va fi nesigură), este permisă modificarea rolurilor tipice. Modificările aduse rolurilor tipice ar trebui să fie minim necesare și documentate. De exemplu, dacă trebuie să modificați textul restricțiilor de acces într-un rol (RLS), atunci, conform, ar trebui să comentați întregul eșantion de cod și apoi să adăugați codul cu modificările necesare.

10. Rapoarte externe și procesare

Majoritatea îmbunătățirilor din sistem pot fi realizate utilizând rapoartele suplimentare și mecanismul de procesare.

În configurațiile bazate pe BSP 2 (ERP, UT 11, BP 3.0, ZUP 3.0 etc.), acest mecanism este semnificativ extins. Cu ajutorul acestuia, fără a modifica configurația, este posibil să creați rapoarte externe și procesare (cu plasarea comenzii de lansare în interfața de comandă și posibilitatea de a configura accesul la diferiți utilizatori), procesarea completării unui document, prelucrarea creării unui document pe bază, formulare suplimentare de imprimare etc.

Te-a ajutat acest articol?

Dezvoltat de departamente întregi de specialiști înalt calificați ai companiei "1C" configurații tipice și industriale, concepute pentru contabilitatea afacerilor, precum și pentru livrarea contabilității și raportare fiscală... Dezvoltatorii au creat mijloace didactice și oferă asistență tehnologică și de consultanță pentru programele lor de câteva decenii, pe baza normelor și recomandărilor legislației Federației Ruse.

S-ar părea că programele oferă deja orice: tot felul de documente, cărți de referință, registre, mecanisme de lucru cu ele, interfețe de utilizator convenabile, configurații demo cu date completate ca exemple reale de contabilitate.

Configurațiile tipice sunt scrise pentru contabilitate tipică și sunt axate pe o organizație medie și aproape ideală.

În viața reală, contabilitatea afacerilor poate avea situații destul de complexe și nestandardizate. Contabilii și specialiștii doresc să vadă acest raport sau altul într-o formă ușor modificată, iar capacitatea regulată de a încărca date de informații dintr-un program în altul (de exemplu, de la contabilitate la comerț sau de la salariu la contabilitate) nu ia în considerare toate specificul organizației.

În astfel de cazuri, vor veni în ajutor cei care înțeleg structura de configurare, capacitățile sistemului, mecanismele sale specifice și știu cum să aplice în mod eficient aceste informații în practică. Aceștia vor putea nu numai să selecteze și, ci și să rafineze configurația 1C, extinzând funcționalitatea sa standard.

Avantajele configurației modificate

Pentru a putea face chiar modificări minore (forme tipărite ale documentelor, apariția documentelor și cărților de referință) în soluțiile tipice de aplicații bazate pe 1C: Enterprise platform 7.7, a fost necesar să eliminați configurația din suport. Pentru platformă, începând cu 8.0, această problemă este parțial rezolvată: formularele, rapoartele și formularele externe tipărite pot fi modificate sau recreate fără a modifica structura de configurare, iar formularele gestionate ale platformei 8.3 oferă și mai multe opțiuni.

Module de 1C: Soluțiile aplicate pentru întreprinderi care sunt deschise pentru modificări vă permit să modificați și să personalizați orice soluție de aplicație „pentru dvs.”. Rafinarea programului 1C oferă o serie de avantaje:

1. În primul rând, soluția software se adaptează la cerințele contabilității specifice din organizație.
2. Cu ajutorul noului dezvoltat și introdus în structura de configurare a drepturilor și rolurilor utilizatorilor, este posibil să se descrie mai flexibil acțiunile permise și interzise atunci când se lucrează cu documente și directoare ale unuia sau unui grup de angajați.
3. Configurarea și schimbarea interfețelor utilizator (pentru aplicațiile gestionate, multe sunt implementate în mod regulat).
4. Capacitatea de a schimba formularele tipărite ale documentelor, formularelor și rapoartelor.
5. Schimbarea mecanismelor calculelor software interne, setarea calculelor complexe, a formulelor de producție, a câmpurilor complexe de documente etc.
6. Modificabilitate aspect documente, jurnale de documente, registre de utilizatori, articole din director.
7. Capacitatea de a adăuga o reprezentare vizuală a obiectelor.

Pentru a modifica soluțiile de aplicații, nu este nevoie să utilizați produse software separate - toate instrumentele de dezvoltare fac parte din platforma tehnologică.

Dezavantaje ale personalizării configurațiilor

Cu toate avantajele evidente, rafinarea configurațiilor tipice 1C implică unele consecințe neplăcute:

1. Soluția tipică eliminată din suportul tehnic 1C pentru posibilitatea revizuirii pierde capacitatea de actualizare automată... Dacă, cu toate acestea, actualizarea este efectuată, atunci toate modificările aduse arhitecturii de configurare vor fi pierdute. Numai un tehnician calificat va putea actualiza software-ul și va migra orice îmbunătățiri scrise manual către software-ul actualizat.
2. Destul de des se întâmplă ca mecanismele de configurare rafinate auto-scrise să fie implementate ulterior de dezvoltatorii 1C în mod regulat și să fie incluse ca parte a actualizărilor. Astfel, modificările făcute anterior nu mai sunt necesare.
3. Fiecare programator 1C, ca artist, are propriul său stil: cineva cu experiență scrie mai competent și mai profesional, cineva este mai original. Poate fi foarte dificil să înțelegeți codul altei persoane, dacă este necesar, până la punctul în care este mai rapid să scrieți un modul de la zero decât să faceți modificări în codul altcuiva. Astfel, există un anumit atașament la programator care face modificări programului.
4. Clientul nu are întotdeauna suficiente calificări pentru a compune un competent sarcină tehnică și explică clar ce rezultat final vrea să vadă. Ca urmare, pot exista neînțelegeri între cele două părți și necesitatea unei ajustări ulterioare a comenzii.

Se întâmplă adesea ca utilizatorii nesiguri ai soluțiilor software 1C: Enterprise care nu au studiat toate setările, metodele contabile, mecanismele de decontare, care nu au înțeles setările formularelor tipărite și rapoartelor, care cer revizuirea configurației. În astfel de cazuri, sarcina dezvoltatorului este de a identifica posibile soluții standard la problemele problematice care au apărut, de a învăța utilizatorul să le folosească și de a face modificări la configurație numai în cazul unei nevoi cu adevărat urgente.