Și din nou, o surpriză din partea Consiliului de Securitate - toate documentele privind activitățile de comerț exterior ne-au forțat acum să furnizăm numai în formă electronică, iar acest lucru se poate face numai prin SPED. Despre implementarea și configurarea acestuia și vor fi discutate.
Mi-a plăcut produsul personal. Este mult mai bine adaptată pentru utilizarea în mediile corporatiste decât banca client "nativă" a SB RF și majoritatea sistemelor client ale altor bănci. Prin urmare, în parte, eu chiar mulțumesc Consiliului de Securitate pentru ceea ce ei încă mai au forțat să utilizeze SPED (pana acum am evitat trecerea la SPED pentru simplul motiv că sprijinul întregului va fi în Sankt Petersburg, și suntem în orașul poate obține cu greu sfaturile Consiliului de Securitate și ce să spunem despre consultarea de la Sankt Petersburg).
Canal la FPSU
Deoarece vom folosi SPED ca bancă client a Consiliului de Securitate al Federației Ruse, avem nevoie de un canal securizat (cu ajutorul Amicon FPSU IP / Client) la bancă. Cu această ocazie, a scris mai multe articole. Vă recomandăm opțiunea cea mai flexibilă din punctul meu de vedere, cu routerele dedicate FPSU.
distribuire
Avem distribuția de la bancă. Voi cita descrierea lui de pe disc:
În cazul nostru, dosarul 1-53-03 conține distribuția SPED versiunea 1.53.03 în rădăcina discului (va fi discutată mai departe). Pentru a verifica versiunea sistemului, utilizați instrumentul Orca din MSI SDK (care este inclus în seria SDK Platform). Să ne uităm la tabelul Proprietăți (imaginea din stânga).
Da, vestea bună este că distroul este deja sub forma unui fișier .msi, este aproape gata de distribuție prin GPO. Să începem.
Pregătirea punctului de instalare administrativă
Totul este ca de obicei. Realizăm resursele de rețea (în cazul în care acestea vor fi disponibile prin DFS) și pregătim de fapt punctul de instalare:
În timpul pregătirii punctului administrativ, este posibil să primiți o eroare (imaginea din stânga). Eroarea citește: Eroare la citirea din fișierul "... \ Prg \ src \ system32 \ SBX \ sbsgn32.dll". Deci, totul este că nu există nici un fișier în distribuție. Aparent, completitudinea distribuției este determinată de lista tranzacțiilor cu banca, furnizată de acordul dvs. cu banca.
Componenta SBX, care solicită acest fișier, nu poate fi realmente setată (uitați-vă la starea instalării sale în imagine spre dreapta, este întotdeauna falsă). Prin urmare, atunci când desfășurarea unor astfel de probleme nu va fi.
Avem opțiuni: fie să editați originalul Msi prin Orca (eliminați componenta problematică a SBX), fie pur și simplu să faceți clic pe "Omiteți". În forma sa pură, este necesară o instalare administrativă pentru a salva distribuția în volum maxim pe stațiile de lucru atunci când se implementează (dacă .cab este inclus în msi cu fișierele de distribuție). Dacă fișierul .cab nu există și distribuția nu este împachetată - puteți folosi fișierul .msi original, dar îmi place să urmez procedurile la ultima literă, dacă este posibil.
Deci, punctul de instalare administrativă este gata. Creați un obiect de politică (GPO).
Pregătirea GPO
Crearea unui obiect GPO și a grupului de securitate pentru acesta. Dreptul de a aplica politica a fost acordat (ca de obicei) numai grupului de instalatori de software (figură din dreapta).
Și acum publicăm cftbc.msi de la punctul de instalare administrativă la GPO (crearea scriptului .aas pentru instalarea în partea SysVol a GPO-ului nostru).
Probleme cu publicarea nu au apărut, totul este pregătit pentru desfășurarea testului clientului. Încercăm.
Verificați distribuția
Nu uitați să activați dispozitivul de testare din grupul Clienți de instalare software. gpupdate pe el - și reporniți-l.
Conectați-vă și vedeți comenzi rapide noi pe desktop. Deja 3 bucăți deodată. Nu-mi place când desktop-ul se înfunda. Și, prin urmare, creați o transformare pentru pachetul Msi, care va ucide înregistrările acestor comenzi rapide (numai cele care au venit pe desktop).
Acordarea pachetului MSI - dezactivarea comenzilor rapide de pe desktop
Să începem. Deschideți cu Orca cftbc.msi din punctul de instalare administrativă. Și să creați o nouă transformare. Acum du-te la tabelul Shortcut. Și ștergeți intrările despre etichetele "inutile".
Și salvați transformarea rezultată (Transform / Generate Transform, numele fișierului pe care l-am specificat [itg] .mst)
Și după repornirea comenzilor rapide de pe desktop nu există, ceea ce am vrut.
"Importarea configurației" utilizând GPO (sau publicarea bazelor de date SPED prin GPO + GPP)
Până în prezent, am decis să doar jumătate din problema și a lansat aplicația în sine. Acum este necesar ca utilizatorii noștri să "importe configurația" (aceasta este în termeni de SPED). Ce este frumos, configurația SPED poate fi stocată ca în HKLM. și în HKCU. Alegerea este a ta. În cazul meu (roaming profiluri de utilizator) este corect atașat la utilizator, așa că am de gând să importe configurația în HKCU, dacă utilizați SPED pe un server terminal, este posibil să aveți o experiență mai bună HKLM, dar esența rămâne aceeași.
Voi importa configurația în registry utilizând GPP. Voi cita din registru pentru o "configurație":
După cum puteți vedea, fiecare cheie ("configuration") este creată cu o cheie în registry (HKCU \ SOFTWARE \ FTC \ RC NWSBRF \ 1. ... \ 2 și așa mai departe). iar valorile sunt mult mai mari decât cele pe care le-am adus. Dar orice altceva (ceea ce a rămas off-screen) - setările de interfață de utilizator salvate (dimensiunile ferestrei, poziția lor și așa mai departe).
parametrii UID, BID, SID, iar KID ar trebui să fie generate pe baza conținutului fișierelor K-0XX-AAAA \ cvtnam1.dbp cvtnam.ldif și de pe disc dat de către bancă. Îl deschidem cu un notebook și vedem:
Dacă ultimele foldere nu au fost - creați-le. Directorul specificat trebuie să conțină fișierul registry.xml. În exemplul nostru, fișierul va fi după cum urmează:
Pentru fiecare "bază" nouă va trebui să creați chei cu un nume digital (1, 2, 3 și așa mai departe). În exemplul nostru - 1. Exemplul rezultat din crearea unui GPP prin fișier xml dintr-un singur motiv - este mai ușor de editat atunci când creați o configurație pentru o altă bază de date (căutarea cu înlocuirea ne va ajuta). Pentru o altă bază de date (configurație) trebuie să înlocuim:
- cheie în registru (de exemplu - pe Software \ FTC \ RC NWSBRF \ 2)
- calea către resursa de fișiere a bazei de date (DB_PATH și DATABASE)
- pentru fișierele temporare TMPDIR
- KID și UID
- calea către fișierul ldif cu utilizatorii bazei de date CVTFILE
- bine, și parametrul CAD. dacă stocați cheile nu pe suporturi amovibile (da, SPED funcționează bine și în această versiune)
Fiți atenți la primul registru de parametri. Pentru el, am arătat acțiunea „Schimbarea“ și a stabilit pavilion removePolicy cu un singur scop - la excluderea utilizatorului din aplicarea secțiunii GPO în registru trebuie să fie eliminate (astfel încât utilizatorul nu a putut vedea bazele, care a pierdut accesul).
Încercați - gpupdate. Și - totul sa dovedit. În registru avem secțiunea necesară. Și SPED la lansare vede baza noastră ("configurația"), comunicarea din baza de date este destul de reușită.
TMPDIR: selectați directorul temporar pentru modulul de comunicare
Iată câteva cuvinte pe care le voi spune. Variabilele de mediu nu sunt acceptate. Și tot drumul, până la cel mai adânc indicat de tine, nu ar trebui să fie ascuns. și nu sistemice. Din acest motiv,% temp% (chiar dacă ne-am implementat în c: \ documents and settings \ user \ local settings \ temp) nu funcționează din păcate - setările locale și directoarele ascunse temporar. P.S. Poate că neajunsul indicat (imposibilitatea specificării directoarelor ascunse pentru TMPDIR și utilizarea unei variabile de mediu în cale, în particular -% temp%) este singurul deficit de SPED în comparație cu alte bănci client.
Cu toate acestea, versiunea cu reflexia% temp% din disc funcționează bine:
Și pentru TMPDIR, specificați Y: \. Această opțiune funcționează foarte bine, dar subst trebuie să fie introdus în scriptul de conectare ... (o soluție similară, valabilă și pentru clienții mobili, a fost deja descrisă).
Importul ordinelor de plată de la 1C
În primul rând, avem nevoie de SPED ca bancă client. Prin urmare, procedura de import a ordinelor de plată trimise de la 1C este necesară.
Trebuie să configurați importul o singură dată pentru o bază de date, nu este nevoie să distribuiți setarea pentru fiecare utilizator - toți parametrii și scripturile sunt stocate în "baza de date".
Scripturile sunt editabile, limba de scripting este Visual Basic. Încă o dată, dezvoltatorii deliciul SPED'a - o abordare de sunet. Datorită o astfel de abordare, puteți repara script-ul sub el (sub formatul său de descărcare de gestiune, cum ar fi în teorie, puteți iniția și descărcarea direct din Sped prin OLE, puteți adăuga operațiile de import jurnalizarea -. Libertatea creativă). Din păcate, script-ul nu ajunge la interfața prin SPED'a nu a putut - nu a găsit. Dacă îmi spui - voi fi recunoscător.
Scriptul pe care l-am importat:
Este mult mai ușor să te uiți la script dacă exportați din 1C în format .dbf, scriptul de mai sus este pentru încărcarea textului.
Odată cu depanarea pot apărea complicații, sunt ajutat de inserții în punctele "de control" de tipul următor:
Procedura de import în sine pare a fi simplă, dar nu a putut fi inițiată de la prima dată. Linia de jos este că funcția Import în meniul Operații va fi disponibilă numai dacă. Dacă aveți documentele de ieșire \ Jurnalul de ordine de plată deschis.
Etichetarea automată: lansarea unui SPED fără a solicita o parolă pentru cheie și fără a alege o configurație, cu importul automat al ordinelor de plată la pornire
Ne întoarcem la Documentația \ Documentație de la dezvoltatorii \ Application Command line.doc de pe discul emis de bancă. Vom crea o linie de comandă pe care SPDED va fi lansată în configurația necesară, fără cereri inutile pentru codurile PIN și altele, precum și cu importul automat al ordinelor de plată la pornire.
Trimiteți-le prietenilor: