Știm cu toții că compania 1C a avut multe versiuni diferite ale platformei 1C; acum vom fi interesați de una dintre cele mai recente versiuni la momentul scrierii acestui articol, acestea sunt versiunile 1C 8.2 și 1C 8.3. Dacă ați trebuit să lucrați în ambele versiuni, atunci cel mai probabil a observat diferențe în interfețele acestor versiuni, pentru utilizatori diferă doar ca aspect. În esență, o alegere aplicație obișnuită sau gestionată spune sistemului ce formulare să afișeze să ruleze, regulat sau controlat, precum și ce client de aplicație va fi utilizat implicit, gros sau subțire. Pentru informații mai detaliate despre clienți, citiți articolul „Ce sunt clienții grosi și subțiri în 1C, precum și diferențele lor.”
Aplicație obișnuită 1C (forme obișnuite, interfață obișnuită, versiunea 1C 8.2)
În 1C 8.2 este posibil să funcționeze numai cu forme obișnuite, în modul obișnuit de aplicare. Imaginea de mai jos prezintă baza de date în modul de operare „aplicație obișnuită 1C” (formulare obișnuite).
Aplicație gestionată 1C (formulare gestionate, interfață gestionată, versiunea 1C 8.3)
Pe platforma 1C 8.3 putem lucra atât cu forme obișnuite (în modul de compatibilitate), cât și cu cele gestionate. în plus formularele gestionate au două tipuri de afișare, acesta este standard și taxi. Un exemplu de configurare 1C 8.3 cu formulare standard gestionate este prezentat mai jos, iar după acesta este afișată interfața „Taxi”.
Care este diferența dintre o aplicație 1C obișnuită și gestionată?
După cum am aflat deja o aplicație obișnuită și o aplicație gestionată sunt aceste tipuri de lansare a unui program 1C. Mai mult, în funcție de valoarea tipului de lansare 1C ( aplicație obișnuită sau gestionată), o interfață specifică va fi încărcată implicit ( forme regulate sau gestionate), prin urmare, există atât de multe sinonime pentru acest concept. Dorim să remarcăm că diferențele dintre interfețe sunt destul de semnificative; interfața gestionată a fost complet reproiectată. În principiu, acestea sunt toate diferențele pe care le văd utilizatorii obișnuiți ai programului 1C. În ceea ce privește programatorii, interfața gestionată necesită scrierea codului modificat, deoarece dezvoltarea este deja efectuată în 1C 8.3, și nu în 1C 8.2, de aici toate consecințele care decurg. Codul trebuie, de asemenea, împărțit în client și server; acest lucru este indicat folosind directivele corespunzătoare din configurator.
Formeîn 1C:Enterprise sunt destinate pentru afișarea și editarea informațiilor conținute în baza de date. Formularele pot aparține unor obiecte de configurare specifice sau pot exista separat de acestea și sunt utilizate de întreaga soluție de aplicație.
De exemplu, un director Nomenclatură poate avea mai multe forme care vor fi folosite în scopuri specifice - editarea unui element de director, afișarea unei liste etc.:
Alături de aceasta, pot exista forme generale care nu aparțin unor obiecte de configurare specifice - forme generale.
Forme de bază
Fiecare obiect de configurare poate fi folosit pentru a efectua unele acțiuni standard. De exemplu, pentru orice director poate fi necesar să afișați o listă a elementelor acestuia, să afișați elemente individuale ale directorului, să afișați un grup din director, să selectați elemente și grupuri de elemente din director. Pentru orice document, lista acestor acțiuni va fi mult mai mică: vizualizarea unei liste de documente, selectarea dintr-o listă de documente și vizualizarea unui document separat.
Pentru a se asigura că astfel de acțiuni standard sunt efectuate cu datele obiectelor soluției aplicației, pentru fiecare dintre ele există un set de formulare de bază care vor fi utilizate la efectuarea acțiunilor corespunzătoare. Oricare dintre formele subordonate acestui obiect poate fi atribuită ca fiind cea principală. De exemplu, în director Nomenclatură Pot exista următoarele forme de bază:
Și documentul Recepția de bunuri și servicii compoziția principalelor forme va fi diferită:
Astfel, dacă utilizatorul dorește să vizualizeze lista de directoare Nomenclatură sau lista de documente Recepția de bunuri și servicii, sistemul va deschide formularul corespunzător desemnat ca formular de listă pentru aceste obiecte.
Formulare generate automat
O caracteristică importantă a sistemului 1C:Enterprise 8 este mecanismul formularelor autogenerate. Acest mecanism eliberează dezvoltatorul de a crea toate formularele posibile pentru fiecare obiect de configurare. Dezvoltatorul trebuie doar să adauge un nou obiect de configurare, iar sistemul însuși va genera, la momentele potrivite în munca utilizatorului, formularele necesare pentru a afișa informațiile conținute în acest obiect.
Astfel, dezvoltatorul trebuie să-și creeze propriile forme de obiecte soluție de aplicație doar dacă acestea trebuie să aibă diferențe (design diferit sau comportament specific) față de formularele generate automat de sistem.
Conectarea unui formular la date
Dacă un formular aparține unui anumit obiect de configurare nu determină compoziția datelor care sunt afișate în formular. Faptul că formularul aparține, de exemplu, unui director Nomenclatură, vă permite să îl atribuiți ca unul dintre formele principale pentru acest director, dar nu determină în niciun fel ce date va afișa acest formular și care va fi comportamentul său.
Pentru a asocia un formular cu date se folosesc detalii de formular, care indica lista de date afisata de formular. Toate formularele, în sine, au același comportament, indiferent de datele pe care le afișează. Cu toate acestea, unul dintre atributele formularului poate fi desemnat ca atribut principal pentru acesta (este evidențiat cu caractere aldine), caz în care comportamentul standard al formularului și proprietățile sale vor fi suplimentate în funcție de tipul atributului principal al formularului:
De exemplu, dacă un document este atribuit ca atribut principal al formularului Recepția de bunuri și servicii, apoi la închiderea formularului, sistemul va solicita confirmarea înregistrării și postării acestui document. Dacă atribuiți, de exemplu, un director ca atribut principal al formularului Nomenclatură, atunci o astfel de cerere de confirmare nu va apărea la închiderea formularului.
Structura formei
Principala caracteristică a formularelor este că nu sunt desenate de către dezvoltator în detaliu, „pixel cu pixel”. Un formular într-o configurație este o descriere logică a compoziției formularului. Iar plasarea specifică a elementelor este efectuată automat de către sistem atunci când formularul este afișat.
Partea afișată a formularului (vizibilă pentru utilizator) este descrisă ca un arbore care conține elemente de formular.
Elementele pot fi câmpuri de introducere, casete de validare, butoane radio, butoane etc. În plus, un element poate fi un grup care include alte elemente. Un grup poate fi reprezentat ca un panou cu un cadru, un panou cu pagini (marcaje), o pagină în sine sau un panou de comandă. În plus, elementul poate fi un tabel, care include și elemente (coloane). Structura elementului descrie modul în care va arăta formularul.
Toate funcționalitățile formularului sunt descrise sub formă de detalii și comenzi. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate. Astfel, dezvoltatorul în editorul de formulare trebuie să includă detaliile și comenzile necesare în formular, să creeze elemente de formular care să le afișeze și, dacă este necesar, să aranjeze elementele în grupuri.
Pe baza acestei descrieri logice, sistemul generează automat aspectul formularului pentru a fi afișat utilizatorului. În acest caz, sistemul ia în considerare diverse proprietăți ale datelor afișate (de exemplu, tip) pentru a aranja elementele de formular cât mai convenabil pentru utilizator.
Dezvoltatorul poate influența aranjarea elementelor cu diverse setări. Poate determina ordinea elementelor, poate indica lățimea și înălțimea dorite. Totuși, acestea sunt doar câteva informații suplimentare pentru a ajuta sistemul să afișeze formularul.
În formulare, dezvoltatorul poate folosi nu numai comenzile formularului în sine, ci și comenzile globale utilizate în interfața de comandă a întregii configurații. În plus, este posibil să se creeze comenzi parametrizabile care vor deschide alte formulare ținând cont de datele specifice formularului curent. De exemplu, aceasta ar putea fi apelarea unui raport privind soldurile la depozit care este selectat în prezent în formularul de factură.
Problema principală este că peste 10-15 ani a fost deja compilat o mulțime de cod pentru forme obișnuite. Nimeni nu vrea să rescrie toate acestea pe client-server + mulți oameni sunt instruiți să lucreze cu interfața. Tranziția obligatorie la BP 3.0 începând de anul viitor creează panică în mintea dezvoltatorilor și contabililor. Feedback-ul va fi foarte neplăcut. În plus, ștacheta de intrare în profesie crește, programarea este mai dificilă, iar cele standard au devenit și mai dificile. Care este costul noului algoritm în documentele standard? UV arată grozav când ai 2-3 butoane pe documente, UV este grozav pentru a lucra pe dispozitive mobile, dar doar 0,01% dintre companii îl folosesc. Va trebui să schimbați dacă 1C nu vine cu ceva nou, dar va fi lung și dureros pentru toată lumea. Și companiile însele vor trebui să plătească banii.
Și eu, până acum, am experimentat doar lucruri negative din forme controlate, iată mai multe dezavantaje ale inovației:
- Nimic? Ei bine, am dat peste asta de câteva ori, de exemplu, scriind și atașând un formular de imprimare extern la conf. ZUP, procesarea este o întreagă epopee, plină de instrucțiuni pe Internet și pagini de cod ar trebui.
pe un client gros există o procedură cu parametri, adică dezvoltarea este o chestiune de câteva minute.
iar franele sunt subtiri vizibile cu ochiul liber - Cât despre posibilitatea de a pregăti forme gestionabile - aceasta este artă de dragul artei, dar care este punctul practic, mai ales pentru versiunea fișierului?
- Am sculptat în UV timp de 3 ani, dar acum am revenit la forme simple și credeți-mă, această tranziție a fost destul de dificil de făcut din punct de vedere psihologic, dar aceasta este alegerea mea conștientă pentru că ceea ce oferă 1c în UV este complet UG.... poate că peste câțiva ani 1c va face o descoperire, dar acum ea caută doar locul unde să facă acest progres...
- UV-urile din configurator durează mult mai mult să se deschidă.
După aceea, deschiderea formularelor în 8.1 este ca transferul de la un camion la un avion! - Sunt mai multe probleme pentru toată lumea, utilizatorii sunt șocați de noua interfață (nu toată lumea recunoaște, dar sunt mult mai proști în privința lucrurilor mai mici), jumătate dintre programatori au devenit nepotriviți pentru profesionalism, specialistului obișnuit i-a devenit mai greu. găsi un loc de muncă și cum să produci un produs de calitate. Iar cea mai tare temă de marketing a UV este că se ridică peste tot, încât tranziția are loc cu o simplă actualizare, dar toată lumea uită că de la început trebuie să ajungi din urmă cu cele mai recente lansări! Dar in principiu imi place ideea!
- Nu știu, experiența mea arată contrariul. Acolo unde boom-urile în forme stricte se lovesc automat de câțiva ani, în noile standard UV în fiecare lună începe „de ce, unde este 1C acum după actualizarea acestui buton și de ce acum nu funcționează”, ceea ce, vezi tu , nu adaugă viteză.
- - există mai mult cod
- codul a devenit mai complex
— modificarea celor standard este mult mai dificilă
- utilizatorii cărora le-am dat UT11 nu au găsit avantaje față de 10.x
— dar au găsit unele încetiniri și o lipsă a unor funcții, cum ar fi căutarea (din anumite motive au vrut căutare înainte-înapoi și nu selecție)
Părerea mea este că sacrificiile sunt prea mari de dragul clientului web și al tabletelor. În plus, personal, nu am văzut încă deloc lucru real cu un client web, care trebuie să folosească cu succes accesul de la distanță - Bedlam client-server ar trebui să ofere o creștere a performanței și scalabilității, în timp ce, în același timp, costurile includ o creștere a codării.
Cu toate acestea, nu toată lumea a cunoscut o creștere, de unde și dezamăgirea. Și, în același timp, toată lumea era aplecată pe costurile de codare.
P.S. De fapt, îmi plac cele controlate, desenez calm pe ele. Dar cele tipice au devenit pervertite. - Acasă (computer normal) îmi conduc băutura conform întreprinzătorilor individuali.
8.3, BP3, în carouri. Impresia principală este că nu lucrez, dar aștept tot timpul. răspuns hemoroidal. SALT pentru cont este pur și simplu uimitor - pare un card de cont pentru anul într-un mega-holding. - UT11 este o frână sălbatică, groază și, în general, un coșmar.
UT10 zboară în comparație cu UT11.
În ceea ce privește UV - bug-urile sunt infestate de ani de zile, totul este strâmb, coloanele nu încap niciodată pe un ecran, întinderea este groaznică în multe cazuri.
Și încă pot enumera o mulțime de minusuri, dar probabil că nu voi spune nimic despre plusuri. Pur și simplu nu există.
Firmele au ajuns în mod special cu aceste forme, pentru că dezvoltarea costă mai mult, nu existau speciale și nu există normale.
Sunt puține avantaje, dar desigur că există...
pro:
Răspunsul a fost acolo de mult timp, ceea ce a dat UP:
client multiplatform
- lucrând pe linii de comunicare proaste
- capacitatea de a lucra printr-un browser (fără a instala un client)