Šiame straipsnyje didžiąja dalimi pateikiama teorinės informacijos, reikalingos norint suprasti operacijų ir užraktų svarbą 1C:Enterprise ir DBVS, ir tai atsispindi 1C:Enterprise veikime. Straipsnyje populiariai aprašomas sandorių ir užraktų ryšys per izoliacijos lygius ir lygiagretumo problemas.
Šiame straipsnyje nepateikiami praktiniai patarimai, kaip išspręsti konkrečias problemas, bet yra pagrindas suprasti šiuos straipsnius, kuriuose aprašomi veiksmai, skirti optimizuoti ir pagerinti „1C:Enterprise“ našumą, susijusį su operacijomis ir užraktais.

Produktyvumas yra tiesiogiai susijęs su 1C:Enterprise TRANSACTIONS

„Užrakinti konfliktą operacijos metu:
„Microsoft OLE DB Provider“, skirtas SQL serveriui: Viršytas užrakinimo užklausos skirtasis laikas.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, būsena=34, sunkumas=10, gimtoji=1222, eilutė=1"

Jei 1C:Enterprise pateikia klaidą, panašią į šią, tai reiškia, kad susiduriate su našumo problemomis, susijusiomis su blokavimu. Tokio pobūdžio problemų sprendimas ne visada yra trivialus ir reikalauja tam tikrų specialių žinių apie DBVS ir 1C:Enterprise veikimą, kurių dažnai neturi nei 1C:Enterprise programuotojai, nei sistemos administratoriai. Kita straipsnių serija turėtų užpildyti šių žinių spragą.

Sandoriai 1C: įmonė

Sandoris yra nedaloma operacijų su duomenimis seka. Jis veikia „viskas arba nieko“ principu ir verčia duomenų bazę
iš vienos integralios būsenos į kitą integralią būseną. Jei dėl kokių nors priežasčių vienas iš operacijos veiksmų nevykdomas arba įvyksta sistemos sutrikimas, duomenų bazė grįžta į būseną, buvusią prieš pradedant operaciją (operacija atšaukiama).

Sandorių mechanizmui (žinomai santrumpa ACID) keliami keli reikalavimai: Atomiškumas (Atomiškumas), Nuoseklumas (Nuoseklumas), Isolation (Isolation), Tvarumas (Patvarumas)

Atomiškumas (Atomiškumas). Šis reikalavimas yra tai, kad visi duomenys, su kuriais vykdoma operacija, turi būti patvirtinti ( įsipareigoti), arba atšauktas ( atšaukimas). Neturėtų būti situacijos, kai vieni pakeitimai patvirtinami, o kiti atšaukiami.

„1C:Enterprise“ operacijos atomiškumo savybės užtikrina loginį duomenų vientisumą. Pavyzdžiui, įrašant dokumentą, jo antraštės duomenys įrašomi į vieną fizinę DBVS lentelę, o lentelės dalies duomenys – į kitą. Dokumento įrašymas į operaciją garantuoja, kad duomenys abiejose fizinėse lentelėse (antraštėse ir lentelės dalyse) bus nuoseklūs (neįmanoma parašyti lentelės dalies be antraštės arba atvirkščiai).

Isolation (Isolation). Sandoriai turi būti atliekami savarankiškai ir nepriklausomai nuo kitų sandorių. Kai vienu metu vykdoma daug konkuruojančių operacijų, bet koks konkrečios operacijos atnaujinimas bus paslėptas nuo kitų, kol sandoris nebus įvykdytas. Yra keli transakcijų izoliavimo lygiai, leidžiantys pasirinkti optimaliausią sprendimą našumo ir duomenų vientisumo požiūriu. Pagrindinis šių lygių įgyvendinimo būdas yra užrakinimas, kuris bus aptartas šiame straipsnyje.

Operacijų žurnalas (SQL serveris)

Kiekviena SQL serverio duomenų bazė turi operacijų žurnalą, kuriame įrašomi visi duomenų pakeitimai, atlikti atliekant kiekvieną operaciją. Jei operacija dėl kokių nors priežasčių nebuvo baigta (atšaukta arba buvo nutraukta), SQL serveris, naudodamas operacijų žurnalą, atšaukia visas operacijos operacijas iš eilės atvirkštine tvarka. Tai reiškia, kad ilgai trunkanti rašymo operacija užtruks ilgai ir bus atšaukta.

Operacijų žurnalas yra svarbi duomenų bazės sudedamoji dalis ir, jei sistema sugenda, gali prireikti, kad duomenų bazė būtų nuosekli. Operacijų žurnalo negalima ištrinti ar keisti, nebent žinomos galimos pasekmės.

Priklausomai nuo duomenų bazės nustatymų (atkūrimo modelio), operacijų operacijų žurnalas gali būti apkarpytas (senieji operacijų duomenys ištrinami) automatiškai arba rankiniu būdu (atkūrimo modelis = FULL). Kartais sistemos administratorius pamiršta apkarpyti žurnalą ir gali įvykti klaida: Duomenų bazės operacijų žurnalas pilnas"

Fiziškai MS SQL Server DBVS operacijų žurnalas yra .LDF faile (o duomenų failas yra .MDF).

Sandoriai sistemoje 1C:Enterprise

Sistema 1C:Enterprise netiesiogiai iškviečia operacijas, kai atlieka bet kokius veiksmus, susijusius su duomenų bazėje saugomos informacijos keitimu. Pavyzdžiui, visos įvykių tvarkyklės, esančios objektų ir įrašų rinkinio moduliuose, susijusiuose su duomenų bazės duomenų modifikavimu, iškviečiamos atliekant operaciją.

Netiesioginės operacijos pavyzdys: įvykių seka registruojant dokumentą iš formos

Praktiškai galite nustatyti, kad 1C:Enterprise objekto įrašas (pavyzdžiui, dokumentas) yra TV operacija, atlikdami tokį eksperimentą: Pabandykite paskelbti ir uždaryti (dokumento formoje spustelėkite „Gerai“) naują dokumentą, žinodami avansu, kad jis nebus skelbiamas (pvz., nurodant didelį nurašomų prekių kiekį) . Kadangi likučiai tikrinami dokumento registravimo etape, tvarkyklėje "Apdorojamas registravimas()", šiuo metu pats dokumentas jau turėtų būti įrašytas į duomenų bazę, nes dokumentas anksčiau parašytas tarp "Prieš rašant()" ir " OnWriting()" įvykiai. Bet pasirodžius klaidos pranešimui (trūksta reikiamo kiekio), pamatysime, kad dokumentas neįrašytas į duomenų bazę (išliks modifikavimo vėliavėlė „*“ ir dokumentas sąraše neatsiras). Taip nutinka todėl, kad įvykus klaidai operacija atšaukiama (atšaukimas).

Aiškaus sandorio skambučio naudojimas

Metodas Pradėti operaciją () leidžia atidaryti operaciją. Tada visi duomenų bazės informacijos pakeitimai, padaryti vėlesniais pareiškimais, gali būti visiškai priimti arba visiškai atmesti. Norėdami priimti pakeitimus, naudokite metodą Įvykdyti operaciją ().
Norėdami anuliuoti visus atidarytos operacijos pakeitimus, naudokite metodą Atšaukti operaciją ().

Sandorių izoliacijos laipsnį lemia izoliacijos lygiai. Aukščiausias izoliacijos lygis užtikrina visišką operacijos nepriklausomumą nuo kitų tuo pačiu metu vykdomų operacijų, tačiau tuo pačiu metu žymiai sumažėja ir lygiagretumo laipsnis – kitos operacijos turi laukti prieigos prie einamajame sandoryje naudojamų išteklių. Žemiausias izoliacijos lygis yra priešingas: jis užtikrina maksimalų lygiagrečio veikimo laipsnį, dėl kurio kiti sandoriai daro didelę įtaką esamam ir atsiranda lygiagretumo problemų. Kelių vartotojų sistemose turi būti padarytas kompromisas tarp lygiagretumo (vienalaikės prieigos prie išteklių) ir operacijų izoliacijos lygių. SQL kalbos standartas apibrėžia izoliacijos lygius, kuriuos nustačius užkertamas kelias konkrečioms lygiagretumo problemoms.

Lygiagretumo problemos

Vykdant operacijas lygiagrečiai, galimos šios problemos:
- prarastas atnaujinimas(angl. prarastas atnaujinimas) - kai vienas duomenų blokas vienu metu keičiamas skirtingomis operacijomis, vienas iš pakeitimų prarandamas;
- „nešvarus“ skaitymas(angl. dirty read) – nuskaitomi duomenys, pridėti arba pakeisti dėl operacijos, kuri vėliau nepatvirtinta (atšaukiama);
- nesikartojantis skaitymas(angl. non-repeatable read) - skaitant dar kartą per vieną operaciją, anksčiau skaityti duomenys pasirodo pakeisti;
- fantominis skaitymas(angl. phantom reads) – viena operacija, jos vykdymo metu, kelis kartus parenka daug eilučių pagal tuos pačius kriterijus. Kita operacija tarp šių pasirinkimų prideda arba ištrina eilutes, kurios patenka į pirmosios operacijos atrankos kriterijus, ir baigiasi sėkmingai. Dėl to paaiškėja, kad tie patys pasirinkimai pirmoje operacijoje sukuria skirtingus eilučių rinkinius.

Panagrinėkime situacijas, kuriose gali kilti šios problemos:

Prarastas atnaujinimas

Purvinas skaitymas

Jei rašant duomenis iškyla ankstesnė problema, galimas nešvarus skaitymas, kai viena operacija bando nuskaityti duomenis, su kuriais dirba kita tuo pat metu vykdoma operacija.
Tarkime, kad yra dvi operacijos, kurias atidaro skirtingos programos, kuriose vykdomi šie SQL sakiniai:

Nesikartojantis skaitymas

Tarkime, kad yra dvi operacijos, kurias atidaro skirtingos programos, kuriose vykdomi šie SQL sakiniai:

Operacijoje2 pasirenkama lauko f2 reikšmė, tada Transaction1 keičiama lauko f2 reikšmė. Jei 1 operacijos metu dar kartą bandysite pasirinkti reikšmę iš lauko f2, gausite kitokį rezultatą. Tokia situacija ypač nepriimtina, kai duomenys nuskaitomi su tikslu juos iš dalies pakeisti ir įrašyti atgal į duomenų bazę.

Fantominis skaitymas

Tarkime, kad yra dvi operacijos, kurias atidaro skirtingos programos, kuriose vykdomi šie SQL sakiniai:

Transaction2 vykdo SQL sakinį, kuriame naudojamos visos f2 lauko reikšmės. Tada į 1 operaciją įterpiama nauja eilutė, todėl SQL sakinys turi būti iš naujo vykdomas atliekant 2 operaciją, kad būtų gautas kitoks rezultatas. Ši situacija vadinama fantominiu įterpimu ir yra ypatingas nesikartojančio skaitymo atvejis.

Sandorių izoliacijos lygiai

Atskyrimo lygis yra sandorio savybė, kuri lemia operacijos nepriklausomumą nuo kitų lygiagrečiai vykdomų operacijų.

Standartas pateikia šiuos keturis izoliacijos lygius, kuriuos naudojant išvengiama tam tikrų lygiagrečių problemų:
- READ_UNCOMMITTED- nefiksuotas skaitymas. Šis izoliacijos lygis išsprendžia „prarasto naujinimo“ problemą, tačiau galima gauti skirtingus rezultatus toms pačioms užklausoms, neatsižvelgiant į operacijos įvykdymą (galbūt „nešvaraus skaitymo“ problema). Tai yra žemiausias DBVS naudojamas izoliacijos lygis ir užtikrina maksimalų lygiagretumą.
- READ_COMMITTED- fiksuotas skaitymas. Šis izoliacijos lygis apsaugo nuo „nešvaraus skaitymo“ problemos, tačiau leidžia gauti skirtingus rezultatus už tas pačias užklausas atliekant operaciją (išsaugoma „nepakartotinio skaitymo“ galimybė);
- REPEATABLE_READ- pakartotinis skaitymas. Šis izoliacijos lygis išsprendžia "nepakartotinio skaitymo" problemą. Šiame lygyje vis dar galima vykdyti INSERT teiginius, kurie veda į „fantominio įterpimo“ konfliktinę situaciją. Šis lygis yra naudingas, jei naujų eilučių pridėjimas neturi įtakos SQL sakinių vykdymui;
- SERIALIZUOJAMAS- nuoseklus vykdymas. Trečias lygis. Šis lygis garantuoja visų aukščiau aprašytų lygiagretumo problemų prevenciją, tačiau atitinkamai laikomasi žemiausio lygiagretumo laipsnio, nes operacijų apdorojimas (su prieiga prie tų pačių išteklių) atliekamas tik nuosekliai.

Lygiagrečių operacijų prieigos ir izoliacijos lygių problemos sprendimas lentelės pavidalu gali būti pavaizduotas taip („+“ - problema pašalinta):

SQL serverio lygiu izoliacijos lygį galite nustatyti patys:
visam seansui, pavyzdžiui, pagal nurodymą
NUSTATYTI SANDORIŲ IZSALIAVIMO LYGIS, GALINTA SERIALIZUOTI

konkrečiai užklausai naudojant konstrukciją WITH
PASIRINKITE pavadinimą IŠ Sutarčių SU SERIALIZUOJAMU

Išsiaiškinkite dabartinės sesijos metu nustatytą izoliacijos lygį
pasirinkite Transakcijos_izolacijos_lygį iš sys.dm_exec_sessions
kur session_id = @@spid

Duomenų užrakto valdymo automatinis režimas (senasis režimas, kuris buvo naudojamas 8.0 versijoje) naudoja operacijų izoliavimo lygius REPEATABLE_READ Ir SERIALIZUOJAMAS teikia duomenų bazių valdymo sistema. Šie operacijų izoliavimo lygiai užtikrina nuoseklų ir nuoseklų duomenų skaitymą, nereikalaujant jokių papildomų užrakto valdymo pastangų iš kūrėjo.

Valdomas užrakinimo režimas (pradedant nuo 8.1 versijos) leidžia padidinti vartotojo vienodumą kliento ir serverio režimu naudojant žemesnį duomenų bazės operacijų izoliavimo lygį ( READ_COMMITTED); toks pat izoliacijos lygis nustatytas pagal numatytuosius nustatymus
ir MS SQL serveryje. Įrašant duomenis į operaciją, integruoti kalbos objektai automatiškai užrakina reikiamus duomenis. Tačiau skaitydamas kūrėjas turi valdyti duomenų užraktus tais atvejais, kai verslo logika reikalauja nuoseklaus ir nuoseklaus sandorio duomenų skaitymo.

8.3 versijos valdomas režimas naudoja izoliacijos lygį READ_COMMITTED_SNAPSHOT.

išvadas

Sandoriai yra būtinas DBVS mechanizmas, aktyviai naudojamas 1C:Enterprise. Norint išspręsti lygiagretumo problemas, operacijos DBVS gali būti atliekamos skirtingais izoliacijos lygiais.

1C:Enterprise naudojamas izoliacijos lygis READ_COMMITTED išsprendžia „Prarastas naujinimas“ ir „Nešvarus skaitymas“ problemas: pakeisti duomenys užrakinami iki operacijos pabaigos tiek nuskaitymui, tiek modifikavimui (įvedamas išskirtinis užraktas).

Izoliacijos lygis READ_COMMITTED neišsprendžia „Nepasikartojančio skaitymo“ ir „Phantominio skaitymo“ problemų. Norėdami išspręsti šias problemas, turite naudoti 1C:Enterprise valdomus užraktus, įdiegtus programiškai.

8.3 naudojamas lankstesnis izoliacijos lygis READ_COMMITTED_SNAPSHOT.

Pavadinimas pasirodė patrauklus, bet užvirė. Iš karto pasakysiu, kad kalbėsime apie 1C. Mieli 1C vartotojai, jūs nežinote, kaip dirbti su sandoriais ir nesuprantate, kokios yra išimtys. Prie šios išvados priėjau pažvelgęs į didelį 1C kodo kiekį, sugeneruotą vietinėje įmonėje. Įprastose konfigūracijose visa tai yra gana gerai, tačiau darbo su duomenų baze požiūriu nekompetentingai parašytas siaubingas kiekis pasirinktinio kodo. Ar kada nors matėte klaidą „Ši operacija jau susidūrė su klaidomis“? Jei taip, tada straipsnio pavadinimas tinka ir jums. Pagaliau išsiaiškinkime, kas yra operacijos ir kaip teisingai jas tvarkyti dirbant su 1C.

Kodėl turėtume skambinti pavojaus varpais?

Pirmiausia išsiaiškinkime, kas yra klaida „Šioje operacijoje jau įvyko klaidų“. Tiesą sakant, tai labai paprastas dalykas: bandote dirbti su duomenų baze jau atšauktoje (atšauktoje) transakcijoje. Pavyzdžiui, kažkur buvo iškviestas CancelTransaction metodas, o jūs bandote jį atlikti.

Kodėl tai blogai? Kadangi ši klaida nieko nepasako apie tai, kur iš tikrųjų įvyko problema. Kai ekrano kopija su tokiu tekstu ateina į palaikymą iš vartotojo, o ypač serverio kodo, su kuriuo niekas negali interaktyviai bendrauti, tai... Norėjau parašyti „kritinė klaida“, bet maniau, kad tai madingas žodis, kurio niekas nemoka. daugiau dėmesio... Tai asilas. Tai programavimo klaida. Tai nėra atsitiktinis gedimas. Tai klaida, kurią reikia nedelsiant ištaisyti. Nes kai jūsų foninio serverio procesai naktį sugenda ir įmonė pradeda sparčiai prarasti pinigus, tada „Šioje operacijoje jau įvyko klaidų“ yra paskutinis dalykas, kurį norite matyti diagnostikos žurnaluose.

Žinoma, yra tikimybė, kad serverio technologinis žurnalas (jis įjungtas gamyboje, tiesa?) kažkaip padės diagnozuoti problemą, bet šiuo metu aš nesugalvoju, kaip tiksliai. kad surastume tikrąją šios klaidos priežastį. Tačiau tikroji priežastis yra viena - programuotojas Vasya gavo išimtį sandorio metu ir nusprendė, kad kažkada nebuvo bloga mintis: „Tik pagalvok, tai klaida, judėkime toliau“.

Kas yra operacijos 1C

Nepatogu rašyti apie elementarias tiesas, bet, matyt, šiek tiek prireiks. 1C operacijos yra tokios pačios kaip operacijos DBVS. Tai nėra kai kurios specialios „1C“ operacijos, tai yra operacijos DBVS. Pagal bendrą operacijų idėją jie gali būti visiškai įvykdyti arba neįvykdyti. Visi per operaciją atlikti duomenų bazės lentelių pakeitimai gali būti nedelsiant anuliuoti, tarsi nieko nebūtų įvykę.

Toliau turite suprasti, kad 1C nepalaiko įdėtųjų operacijų. Tiesą sakant, jie nepalaikomi „1C“, bet iš viso nepalaikomi. Bent jau tos DBVS, su kuriomis gali dirbti 1C. Pavyzdžiui, įdėtos operacijos neegzistuoja MS SQL ir Postgres. Kiekvienas „įdėtas“ iškvietimas į StartTransaction tiesiog padidina operacijų skaitiklį, o kiekvienas iškvietimas į „CommitTransaction“ tiesiog sumažina šį skaitiklį. Toks elgesys aprašytas daugelyje knygų ir straipsnių, tačiau išvados iš tokio elgesio, matyt, nėra pakankamai analizuojamos. Griežtai kalbant, SQL yra vadinamasis. SAVEPOINT, bet 1C jų nenaudoja, ir šis dalykas yra gana specifinis.

Kodas anglų kalba

Ne visai. Visiškai nenoriu kartoti pavyzdžių anglų kalba vien tam, kad linksminčiau šventųjų karų ir šventųjų karų gerbėjus.

Jūs tikriausiai rašote tokį kodą, tiesa? Pateiktame kodo pavyzdyje yra klaidų. Bent trys. Ar žinai kokius? Iš karto pasakysiu apie pirmąjį; jis susijęs su objektų užraktais ir nėra tiesiogiai susijęs su sandoriais. Apie antrąją – kiek vėliau. Trečioji klaida yra aklavietė, kuri atsiras lygiagrečiai vykdant šį kodą, tačiau tai yra atskiro straipsnio tema; dabar jos nenagrinėsime, kad neapsunkintume kodo. „Google“ raktinis žodis: aklavietės valdomos spynos.

Atminkite, kad kodas yra paprastas. Jūsų 1C sistemose to tiesiog yra daug. Ir jame vienu metu yra bent 3 klaidos. Laisvalaikiu pagalvokite, kiek klaidų yra sudėtingesniuose scenarijuose dirbant su jūsų 1C programuotojų parašytomis operacijomis :)

Objektų spynos

Taigi, pirma klaida. 1C yra objektų užraktai, vadinamieji „optimistiniai“ ir „pesimistiniai“. Nežinau, kas sugalvojo terminą, būčiau jį nužudęs :). Visiškai neįmanoma prisiminti, kuris iš jų už ką atsakingas. Apie juos buvo rašyta išsamiai, kaip ir kitoje bendrojoje IT literatūroje.

Problemos esmė ta, kad nurodytame kodo pavyzdyje keičiamas duomenų bazės objektas, tačiau kitoje sesijoje gali būti interaktyvus vartotojas (arba gretimo fono gija), kuris taip pat pakeis šį objektą. Čia vienas iš jūsų gali gauti klaidą „įrašas pakeistas arba ištrintas“. Jei taip atsitiks interaktyvioje sesijoje, vartotojas subraižys užpakalį, prisiekia ir bandys iš naujo atidaryti formą. Jei tai atsitiks fono gijoje, turėsite to ieškoti žurnaluose. O žurnalas, kaip žinia, yra lėtas, o ELK rietuvių 1C rąstams įrengia tik keli žmonės mūsų pramonėje... (mes, beje, esame tarp tų, kurie steigia ir padeda kitiems įsirengti :) )

Trumpai tariant, tai erzina klaida ir geriau jos nedaryti. Todėl kūrimo standartuose aiškiai parašyta, kad prieš keičiant objektus būtina ant jų uždėti objekto užraktą naudojant " Katalogo objektas. Užraktas() Tada gretutinė sesija (kuri taip pat turi tai padaryti) negalės pradėti atnaujinimo operacijos ir gaus laukiamą, kontroliuojamą gedimą.

O dabar apie sandorius

Išsprendėme pirmą klaidą, pereikime prie antrosios.

Jei nepateiksite išimčių tikrinimo šiuo metodu, išimtis (pavyzdžiui, labai tikėtina, kad taikant „Write()“ metodą) išmes jus iš šio metodo nebaigus sandorio. „Rašymo“ metodo išimtis gali būti taikoma dėl įvairių priežasčių, pavyzdžiui, suveikia kai kurie verslo logikos programų patikrinimai arba įvyksta aukščiau minėtas objekto užraktas. Bet kokiu atveju antroji klaida sako: Kodas, nuo kurio prasidėjo operacija, neatsako už jos užbaigimą.

Būtent taip ir pavadinčiau šią problemą. Mūsų statiniame 1C kodo analizatoriuje, pagrįstame „SonarQube“, tokią diagnostiką įdiegėme net atskirai. Dabar dirbu prie jo kūrimo, o 1C programuotojų, kurių kodas ateina pas mane analizuoti, vaizduotė kartais mane šokiruoja ir kelia baimę...

Kodėl? Nes 90% atvejų išimtys, išmestos operacijos viduje, neleis šios operacijos įvykdyti ir sukels klaidą. Reikėtų suprasti, kad 1C automatiškai grąžina nebaigtą operaciją tik grįžęs iš scenarijaus kodo į platformos kodo lygį. Kol esate 1C kodo lygyje, operacija išlieka aktyvi.

Pakilkime vienu lygiu aukštyn skambučių krūvoje:

Pažiūrėk, kas atsitiks. Mūsų probleminis metodas iškviečiamas iš kažkur išorėje, aukščiau kamino. Šio metodo lygiu kūrėjas neįsivaizduoja, ar labai naudingo ir svarbaus kodo metodo viduje bus kokių nors operacijų, ar ne. O jei bus, ar jie visi bus užbaigti... Mes visi čia dėl taikos ir inkapsuliacijos, tiesa? Metodo „ImportantCode“ autorius neturėtų galvoti apie tai, kas tiksliai vyksta jo iškviečiamo metodo viduje. Ta pati, kurioje sandoris apdorojamas neteisingai. Dėl to bandymas dirbti su duomenų baze po to, kai iš sandorio buvo išmestas išimtis, greičiausiai baigsis taip: „Šiame sandoryje bla bla...“

Operacijų paskirstymas įvairiais būdais

Antroji „saugaus sandorio“ kodo taisyklė: Operacijų nuorodų skaičius metodo pradžioje ir jo pabaigoje turi turėti tą pačią reikšmę. Negalite pradėti operacijos vienu metodu ir baigti kitu. Tikriausiai galima rasti šios taisyklės išimčių, bet tai bus kažkoks žemo lygio kodas, parašytas kompetentingesnių žmonių. Apskritai taip rašyti negalima.

Pavyzdžiui:

Aukščiau pateiktas nepriimtinas šūdas kodas. Negalite rašyti metodų, kad skambinantysis atsimintų ir sektų galimas (arba tikėtinas – kas žino) operacijas kituose metoduose, kuriuos iškviečia. Tai yra inkapsuliavimo pažeidimas ir spagečių kodo paplitimas, kurio negalima atsekti sveiku protu.

Ypač smagu prisiminti, kad tikrasis kodas yra daug didesnis nei sintetiniai 3 eilučių pavyzdžiai. Sandorių pradžios ir pabaigos paieška šešiuose įdėjimo lygiuose – tai tiesiogiai skatina intymius pokalbius su autoriais.

Bandoma pataisyti kodą

Grįžkime prie pradinio metodo ir pabandykime jį ištaisyti. Iš karto pasakysiu, kad objekto užrakto kol kas netaisysime, kad neapsunkintume pavyzdinio kodo.

Pirmasis tipinio 1C slapyvardžio požiūris

Paprastai 1C programuotojai žino, kad įrašant gali būti padaryta išimtis. Jie taip pat bijo išimčių, todėl stengiasi jas visas sugauti. Pavyzdžiui, taip:

Na, viskas pagerėjo, tiesa? Juk dabar galimos įrašymo klaidos apdorojamos ir net registruojamos. Išimtys nebebus metamos rašant objektą. O žurnale net matosi, ant kurio objekto, aš netingėjau ir į pranešimą įdėjau nuorodą, o ne lakonišką „Klaida rašant katalogą“, nes dažnai mėgsta rašyti visada skubantys kūrėjai. Kitaip tariant, yra susirūpinimas vartotoju ir didėja kompetencijos.

Tačiau patyręs 1C vartotojas pasakys, kad ne, jis nepagerėjo. Tiesą sakant, niekas nepasikeitė, o gal net pablogėjo. Taikant metodą „Rašyti ()“, pati 1C platforma pradės rašymo operaciją, o ši operacija jau bus įdėta mūsų atžvilgiu. Ir jei dirbant su 1C duomenų baze operacija atšaukiama (pavyzdžiui, išmesta verslo logikos išimtis), tada mūsų aukščiausio lygio operacija vis tiek bus pažymėta kaip „sugadinta“ ir negali būti įrašyta. Dėl to šis kodas išliks problemiškas, o bandant įsipareigoti bus rodomas pranešimas „Klaidos jau įvyko“.

Dabar įsivaizduokite, kad kalbame ne apie mažą metodą, o apie gilų skambučių steką, kur pačioje apačioje kažkas paėmė ir „atleido“ pradėtą ​​operaciją iš savo metodo. Aukščiausio lygio procedūros gali net neįsivaizduoti, kad kas nors pradėjo sandorius. Dėl to visas kodas sugenda dėl neaiškios klaidos, kurios iš esmės neįmanoma ištirti.

Kodas, kuriuo pradedama operacija, reikalingas norint ją užbaigti arba atšaukti. Nepriklausomai nuo jokių išimčių. Kiekviena kodo šaka turėtų būti ištirta, siekiant išsiaiškinti, ar metodas išeina neįsipareigojant arba neatšaukus operacijos.

Darbo su operacijomis metodai 1C

Nebūtų nereikalinga priminti, ką 1C mums paprastai suteikia dirbant su sandoriais. Tai yra gerai žinomi metodai:

• Pradėti operaciją ()
• Įvykdyti operaciją ()
• Atšaukti operaciją ()
• TransactionActive()

Pirmieji 3 metodai yra akivaizdūs ir daro tai, ką sako jų pavadinimai. Paskutinis metodas grąžina True, jei operacijų skaitiklis yra didesnis už nulį.

Ir yra įdomi savybė. Operacijų išėjimo metodai (Įsipareigoti ir Atšaukti) pateikia išimtis, jei operacijų skaičius yra nulis. Tai yra, jei paskambinsite vienam iš jų ne operacijos metu, įvyks klaida.

Kaip teisingai naudoti šiuos metodus? Tai labai paprasta: turite perskaityti aukščiau suformuluotą taisyklę:

Kaip laikytis šios taisyklės? Pabandykime:

Jau aukščiau supratome, kad metodas „Daryk ką nors“ yra potencialiai pavojingas. Tai gali padaryti tam tikrą išimtį, o sandoris „nuskaitys“ iš mūsų metodo. Gerai, pridėkime galimą išimčių tvarkyklę:

Puiku, pastebėjome įvykusią klaidą, bet ką turėtume su ja daryti? Rašyti žinutę į žurnalą? Na, gal jei klaidų registravimo kodas turėtų būti būtent tokio lygio ir čia laukiame klaidos. O jei ne? O jei nesitikėjome klaidų? Tada turėtume tiesiog praleisti šią išimtį ir leisti su ja susidoroti kitam architektūros sluoksniui. Tai daroma naudojant operatorių „CauseException“ be argumentų. Šiuose jūsų „Javascript“ tai daroma lygiai taip pat su metimo operatoriumi.

Taigi, palaukite... Jei tik išmestume išimtį toliau, tai kam iš viso reikalingas Bandymas? Štai kodėl: taisyklė verčia mus užtikrinti, kad būtų užbaigta pradėta operacija.

Dabar atrodo, kad tai gražu. Tačiau prisimename, kad nepasitikime Do Something () kodu. Ką daryti, jei viduje esantis autorius neskaitė šio straipsnio ir nežino, kaip dirbti su sandoriais? O jeigu jis ten nuneštų ir paskambintų CancelTransaction metodu arba, priešingai, tai padarytų? Mums tai labai svarbu išimčių tvarkytojas neišmetė naujos išimties, kitaip pradinė klaida bus prarasta ir trikčių šalinimas taps neįmanomas. Ir mes prisimename, kad „Commit“ ir „Cancel“ metodai gali padaryti išimtį, jei operacija neegzistuoja. Čia praverčia TransactionActive metodas.

Galutinė versija

Galiausiai galime parašyti teisingą, „neatitinkančią sandorį“ kodo versiją. Štai jis:

**UPD: komentaruose buvo pasiūlyta saugesnė parinktis, kai „CommitTransaction“ yra „Attempt“ bloke. Ši konkreti parinktis rodoma čia; anksčiau fiksavimas buvo po bloko Bandymas-Išimtis.

Palaukite, bet klaidų gali atsirasti ne tik „Atšaukti operaciją“. Kodėl tada „CommitTransaction“ nėra supakuota į tą pačią būseną su „TransactionActive“? Vėlgi, naudojant tą pačią taisyklę: Kodas, kuris pradėjo operaciją, turėtų būti atsakingas už jos užbaigimą. Mūsų sandoris nebūtinai yra pirmasis; jis gali būti įdėtas. Abstrakcijos lygmeniu mes privalome rūpintis tik savo sandoriu. Visi kiti neturėtų mums būti įdomūs. Jie svetimi, mes neturėtume už juos atsakyti. Būtent jie NETURIŲ. Nereikėtų bandyti nustatyti tikrojo operacijų skaitiklio lygio. Tai vėl sulaužys inkapsuliaciją ir sukels „išteptą“ operacijų valdymo logiką. Tikrinome tik aktyvumą išimčių tvarkyklėje ir tik siekdami įsitikinti, kad mūsų tvarkytojas nesugeneruos naujos išimties, „paslėpdamos“ senąją.

Pertvarkymo kontrolinis sąrašas

Pažvelkime į kai kurias dažniausiai pasitaikančias situacijas, kurioms reikalingas kodo įsikišimas.

Šablonas:

Įvyniokite jį į „saugų“ dizainą su „Pabandykite, išlik gyvas ir palikite išimtį“.

Šablonas:

Analizė ir pertvarkymas. Autorius nesuprato, ką daro. Saugu pradėti įdėtas operacijas. Nereikia tikrinti būklės, tereikia pradėti įdėtą operaciją. Žemiau modulyje jis tikriausiai vis dar yra iškreiptas su jų fiksavimu. Tai garantuotas hemorojus.

Maždaug panašus variantas:

panašiai: sudaryti sandorį pagal sąlygą yra keista. Kodėl čia yra sąlyga? Ką, kažkas kitas jau galėjo įrašyti šią operaciją? Teismo priežastis.

Šablonas:

1. įdiekite kontroliuojamą užrakinimą, kad išvengtumėte aklavietės
2. įveskite iškvietimą į blokavimo metodą
3. apvyniokite "bandyk", kaip parodyta aukščiau

Šablonas:

Išimties atveju ši operacija nebebus baigta. Nėra prasmės tęsti ciklo. Kodą reikia perrašyti, patikrinant pradinę užduotį. Be to, pateikite informatyvesnį klaidos pranešimą.

Pagaliau

Aš, kaip tikriausiai jau atspėjote, esu vienas iš žmonių, kuriems patinka 1C platforma ir jos plėtra. Žinoma, yra priekaištų dėl platformos, ypač „Highload“ aplinkoje, tačiau apskritai ji leidžia nebrangiai ir greitai sukurti labai kokybiškas įmonės programas. ORM, GUI, žiniatinklio sąsajos, ataskaitų teikimo ir daug daugiau teikimas. Komentaruose apie Habré jie dažniausiai rašo visokius įžūlius dalykus, tad vaikinai – pagrindinė 1C, kaip ekosistemos, problema nėra platforma ar pardavėjas. Tai per žema įėjimo riba, leidžianti į pramonę patekti žmonėms, kurie nesupranta, kas yra kompiuteris, duomenų bazė, klientas-serveris, tinklas ir visa tai. 1C labai palengvino įmonės programų kūrimą. Per 20 minučių galiu parašyti pirkimų/pardavimų apskaitos sistemą su lanksčiomis ataskaitomis ir web klientu. Po to man lengva pagalvoti, kad didesniu mastu galite rašyti panašiai. Kažkaip 1C viską padarys viduje, nežinau kaip, bet tikriausiai tai padarys. Leiskite man parašyti "StartTransaction()"....

Kiekvienas klientas turi savo pasikartojančius įpročius ir tradicijas. Nesvarbu, ar tai mėgstamiausia apsipirkimo diena, ar pageidaujate vidutinės produkto kainos, ar papildomos produkto parinktys. Visa ši informacija padės paskatinti klientą apsipirkti antrą kartą ir iš naujo vartotojo tapti nuolatiniu.

Nuo vienkartinių pirkinių pereiname prie nuolatinių klientų

Na, jums pavyko konvertuoti klientą. Tai puiku, bet kas toliau? Pagal statistiką, nuo 30% iki 80% pirkėjų elektroninės prekybos industrijoje užsakymą atlieka tik vieną kartą per visą savo gyvavimo ciklą. Žaidimų pramonėje 60% klientų atlieka antrą užsakymą. Kaip galime sulaukti lojalių klientų su tokiais nuviliančiais skaičiais?

Šis klausimas kelia nerimą rinkodaros specialistams visame pasaulyje. Jie sunkiai dirba, dėdami visas pastangas, kad klientai iš vienkartinių klientų taptų nuolatiniais. Ar tai būtų pradiniai užsakymai mažmeninėje prekyboje ar indėliai internetiniuose žaidimuose. Kodėl antroji tvarka tokia svarbi? Jei klientas atlieka antrą užsakymą arba atlieka antrą įnašą, tikimybė, kad bus atliktas trečias užsakymas, padidėja dešimt kartų, palyginti su klientais, kurie atliko tik vieną užsakymą.

Žemiau esančioje lentelėje pateikiami dešimties pirmaujančių Europos ir JAV elektroninės prekybos įmonių duomenys. Kaip matyti iš grafiko, tikimybė atlikti kitą operaciją didėja didėjant dabartinių operacijų skaičiui.

Daugelis įmonių sugrupuoja vienkartinius klientus į vieną grupę ir naudoja skirtingus metodus bei pranešimus, kad paskatintų antrą kartą pirkti. Skamba kaip geras planas, tiesa? Vienaip ar kitaip, visi grupės klientai yra vienkartiniai pirkėjai. Bet mes čia tam, kad aptartume kitokį požiūrį. Šis antrasis metodas apima vienkartinių klientų grupės padalijimą į skirtingus segmentus pagal jų pirmojo sandorio ypatybes. Pasinerkime giliau ir apsvarstykime būtinas tokio segmentavimo sąlygas.

Savaitės diena

Mes surinkome duomenis ir atlikome testus, o rezultatai buvo tokie patys, kokių tikėjomės. Iš esmės antrasis indėlis buvo paliktas tą pačią savaitės dieną kaip ir pirmasis. Tai matyti iš didžiausios tikimybės reikšmės, esančios kvadrato įstrižainėje.

Šių dviejų operacijų priklausomybė gali padėti geriau nukreipti reklaminę veiklą skirtingoms vienkartinių klientų grupėms (šiuo atveju turime 7 grupes pagal pirmosios operacijos dieną) ir priminti apie antrąją operaciją atitinkamomis dienomis. Įdomesnis žingsnis yra patikrinti šią hipotezę mažmeninėje prekyboje.

Galime matyti panašią situaciją. Klientai antrą kartą perka tą pačią savaitės dieną kaip ir pirmąjį. Svarbu pažymėti, kad mažmeninės prekybos sektoriuje sklaida buvo didesnė nei sporto lažybų sektoriuje. Bet pati priklausomybė pasireiškė kiekvienai įmonei. Populiariausia apsipirkimo diena yra pirmadienis, mažiausiai populiari – sekmadienis. Jei atsižvelgsime į tik vieno prekės ženklo užsakymų priklausomybes, gautume tai.

Turime paprastą šio elgesio sporto lažybose paaiškinimą, bet kodėl matome tokį rezultatą mažmeninėje prekyboje? Priežastis gali būti ta, kad pirkėjai turi tam tikrus savo gyvenimo modelius. Ketvirtadieniais ir penktadieniais einate į sporto salę, savaitgaliais leidžiate laiką su šeima, pirmadieniais vėluojate darbe, o penktadienį susitinkate su draugais. Atsižvelgiant į visus kitus, pirkimo modelis neatrodo keistas.

Dienos laikai

Ryšys tarp pirmojo ir antrojo užsakymo pagal paros laiką atrodo akivaizdus. Klientai, pirmą kartą užsisakę vėlai vakare, greičiausiai pateiks antrą užsakymą tuo pačiu metu.

Prekių kaina užsakyme

Kaip duomenų šaltiniai naudojami skirtingi prekės ženklai, todėl kiekvienam prekės ženklui nustatėme atskirus segmentus su prekės verte. Taip susidarė 6 kainų grupės.

Dauguma klientų, kurių užsakymai buvo pateikti žemos kainos intervale, antrajame užsakyme liko tame pačiame diapazone.

Išvada

2017-10-31

Kaip sukurti operacijos variantą naudojant SHD0?

Klausimo paaiškinimas

Viename iš savo pastabų aprašiau veiksmų, kuriuos reikia atlikti, norint paslėpti lauką operacijos metu, seką. Mechanizmas, kuriuo galima atlikti šią operaciją, yra gerai žinomas daugeliui konsultantų. Leiskite jums priminti, kad šio mechanizmo pavadinimas yra sandoris SHD0.

Šioje pastaboje noriu apsvarstyti veiksmų, kuriuos reikia atlikti, kad būtų įgyvendintas reikalavimas, seką:

• Atskira prieiga prie vieno informacijos tipo laukų dviem su juo dirbančioms vartotojų grupėms, jei jie turi tokio pat lygio įgaliojimus šiam informacijos tipui. Kitaip tariant, kai kuriuos laukus padarykite prieinamus vieniems vartotojams, o kitus – kitiems.

Iš šaltinio duomenų: operacija, su kuria dirba vartotojai, yra PA30. Informacijos tipas šiuo atveju neturi reikšmės. Konkrečiai savo pavyzdyje naudosiu HR administravimo infotipą.

Informacinis tipas yra geras pavyzdys 0002 - "Asmeniniai duomenys"

Taip suformuluokime vadinamojo galių atribojimo problemą:

• Laukas Mar.Statusas Infotype 0002 "Asmens duomenys" turi būti nepasiekiamas redaguoti (ty tik skaityti);
• Laukas Galioja nuo dabartinės šeiminės padėties datos Informacijos tipas 0002 „Asmens duomenys“ turi būti paslėptas.

Problemos sprendimas

Norint išspręsti aukščiau iškeltą problemą, būtina atlikti kelis nuoseklius veiksmus, kurie bus aptarti toliau. Trumpai:

1. Sukurti atskirą operaciją vartotojų grupei, kuriai reikia pakeisti prieigos lygį į infotype laukus;
2. Sukurti ekrano variantą, kuriame sukonfigūruoti laukų matomumą, po to priskirti ekrano variantą sukurtam operacijos variantui (pasirodė per daug gremėzdiška, bet iš tikrųjų nieko sudėtingo).
3. Sukurkite šios operacijos variantą, priskirdami jam ekrano variantą, kuriame sukonfigūruotas atitinkamas lauko matomumas;
4. Sukurkite pasirinktinį vaidmenį, į kurį įtrauksite operaciją ir priskirkite ją vartotojams;
5. Atlikite testavimą.

1. Sukurkite naują operaciją

Kadangi pagrindinis sandoris yra PA30, imkime tai kaip pagrindą, nukopijuodami į naują. Tai galima padaryti per sandorį SE93

Lentelėje T588A nukopijuokite esamą įrašą su operacijos kodu PA30 naujam įrašui ir bandykite iš naujo pradėti naują operaciją

Sandoris pradedamas sėkmingai. Pereikime prie kito punkto.

2. Sukurkite naujos operacijos variantą

Sukuriame naujos operacijos variantą, kuriame apibrėžiame prieigos prie infotipo laukų lygį. Leiskite jums priminti, kad man reikia pakeisti laukų prieigos lygį " Mar.Statusas"Ir" Galioja nuo dabartinės šeiminės padėties datos". Šie veiksmai turi būti atlikti sandoryje SHD0.

Lauke Sandorio kodas nurodykite naujos operacijos pavadinimą (žr. #1 punktą. Naujos operacijos sukūrimas)

2.1 Ekrano varianto kūrimas

Skirtuke „Ekrano variantai“ reikia sukurti ekrano variantą, naudojamą infotipui 0002. Šiame variante laukams turite taikyti norimas rodymo taisykles. Viskas, ką jums reikia žinoti, yra atitinkamas modulių telkinys ir ekrano numeris (norėdami tai padaryti, informacijos tipo redagavimo ekrane pasirinkite iš meniu Sistema -> Būsena)

Šiame vaizdo įrašo fragmente parodyta veiksmų, kuriuos reikia atlikti norint sukurti ekrano variantą, seka

Ekrano parinktis sukurta. Jokių pokyčių kol kas nepastebėta.

2.2 Ekrano varianto priskyrimas operacijos variantui

Sukurtą ekrano variantą priskirkite operacijos variantui, tada suaktyvinkite sukurtą operacijos variantą

2.3 Testavimas

Bandymo scenarijus yra labai paprastas:

• Pradėkite sandorį PA30, pasirinkite personalo numerį, atidarykite informacijos tipą redaguoti 0002 ir patikrinkite, ar aukščiau pateikti laukai rodomi be pakeitimų

• Pradėkite sandorį ZPA30, ir atlikti lygiai tą pačią veiksmų seką

Skirtumas akivaizdus, ​​vadinasi, užduotis sėkmingai atlikta.

Žodis „sandoris“ pas mus atėjo tik devintojo dešimtmečio pabaigoje. Tai buvo šiuolaikinės bankų sistemos raidos ir bendro kompiuterių bumo laikotarpis. Tada ši sąvoka pradėjo atsirasti šnekamojoje ir literatūrinėje kalboje. Ir nors paprasti žmonės retai susiduria su problemomis su programuotojais, visiems tenka susidurti su bankais. Beveik bet kokia operacija – nuo ​​sąskaitos būsenos patikrinimo iki sudėtingų mokėjimų pervedimų banke – gali būti kvalifikuojama kaip operacijos. Šis žodis bankinėse operacijose vartojamas beveik dažniau nei tokios sąvokos kaip „pinigai“ ar „kreditas“. Tačiau tik nedaugelis banko klientų visiškai supranta jo esmę.

Žodžio prasmė

Sandoriai yra tam tikros bet kokių objektų sąveikos per tam tikrą laikotarpį procedūros. Tokias procedūras suformavo programuotojai. Jie turi aiškų procedūrinį pobūdį. Bet koks sandoris yra trijų pagrindinių komponentų derinys:

• prašymas;
• vykdymas;
• ataskaita.

Įprasto sandorio procesas gali būti gana sudėtingas, tačiau šios procedūros rezultatas turi tik dvi būsenas. Tai yra, sandoris gali būti baigtas arba ne.

Banko operacijos

Ką reiškia žodis „sandoris“? Kokie procesai vyksta, kai tai įvyksta? Tiksliau sakant, operacijos yra bet kokios bankinės operacijos, susijusios su lėšų judėjimu. Tačiau dažniausiai šis terminas vartojamas naudojant elektronines sąskaitas faktūras. Arba tai tiesiogiai nurodo operacijas banko kortelėmis.

Frazė „atlikti operacijas“ reiškia operacijas naudojant elektroninę sąskaitą. Tai apima komunalinių mokesčių mokėjimą, prekių pirkimą parduotuvėje naudojant plastikinę kortelę, atlyginimų ir stipendijų įnešimą ir daugybę kitų piniginių operacijų.

Sandorių rūšys

Bankininkystėje yra dviejų tipų operacijos:

1. Internetinės operacijos – tai manipuliavimas negrynaisiais pinigais prisijungiant prie banko centro realiu laiku. Ryškiausias pavyzdys yra darbas su terminalu.
2. Operacijos neprisijungus – tai bankinės operacijos vykdymas be tiesioginio dalyvių kontakto. Pavyzdžiui, darbuotojų atlyginimų įskaitymas. Lėšos nurašomos iš organizacijos sąskaitos, o darbuotojas gauna tik pranešimą apie jo einamosios sąskaitos likučio papildymą.

Norėdami geriau suprasti bankinių operacijų esmę, panagrinėkime keletą jų variantų.

Piniginė operacija

Paprasčiausias tokios operacijos pavyzdys – pervedimas tarp savo sąskaitų, pinigų gavimas ar įnešimas, grynųjų pinigų įnešimas per bankomatą ar terminalą. Tokias operacijas bankas dažniausiai atlieka be komisinių. Sudėtingesnė situacija yra su pervedimais tarp dviejų skirtingų asmenų – toje pačioje finansų įstaigoje pervedimo mokestis gali siekti 3%. Jei kalbame apie skirtingus šalies bankus, komisiniai bus dar didesni. Brangiausias pervedimas yra į užsienio institucijas, nes, be komisinio mokesčio, jos dažnai taiko vadinamąjį operacijos mokestį.

Vertimai

Perkėlimai iš vienos paskyros į kitą kartais sukelia erzinančių klaidų. Mažiausias gavėjo pavardės rašybos netikslumas gali baigtis blokuoti manipuliavimą elektronine apsaugos sistema. Automatinis sandoris išspręs problemą. Taip atsitinka, pavyzdžiui, kai lėšos įskaitomos į gavėjo balansą naudojant banko kortelės numerį. Tai žymiai sumažina klaidos tikimybę. Jei operacija iš naujo nustatoma, pinigai tiesiog grąžinami į savininko likutį. Tiesa, tai įvyksta per dešimt ar penkiolika kalendorinių dienų.

Jei siuntėjas neturi banko sąskaitos, galite pasinaudoti pinigų pervedimo paslauga. Žymiausi tarptautiniai operatoriai yra MoneyGram, Western Union, Anelik, Contact ir kt. Pagrindinis tokių operacijų privalumas – didelis operacijų greitis. Pagrindinis trūkumas yra gana didelis komisinis atlyginimas.

Ką daryti, jei sandoris nepavyksta?

Atsiradus neįprastai situacijai, susijusiai su lėšų pervedimu, turite nedelsdami apie tai pranešti bankui ar terminalo operatoriui. Tokiu atveju yra didelė tikimybė, kad pinigai grįš į siuntėjo likutį arba bus panaudoti pagal paskirtį.
Operatorius padės, jei:

• Sandorio metu įvyko gedimas (užšalo programa, dingo elektra), o pinigai jau buvo dingę. Skambutis karštąja linija įrašys jūsų prašymą. Patikrinę ir pašalinę klaidą, specialistai operaciją galės atlikti rankiniu būdu.
• Terminalas ar bankomatas neišdavė operacijos kvito. Priežastis gali būti nereikšminga – aparate trūksta kasos juostos. Susisiekus su operatoriumi, jums bus pasiūlytas kvito dublikatas. Paprastai jis siunčiamas nurodytu el. pašto adresu.
• Nurodytoje detalėje yra klaida. Pinigai dingo, bet gavėjas niekada jų nematė.
  Operatorius gali padėti išspręsti šią problemą: pavyzdžiui, rasti klaidą gavėjo sąskaitos numeryje. Tokiu atveju pinigai kliento nepasiekia vien dėl saugumo taisyklių. Tokios lėšos banko neišimamos, o saugomos 10 dienų specialioje laikinoje sąskaitoje. Jei siuntėjas laiku susisieks su finansų įstaiga, nurodys operacijos laiką, pervedimo sumą ir atsakys į kelis klausimus, pinigai bus atblokuoti. Atskaičius operacijos mokestį, suma grąžinama į siuntėjo balansą.

Kaip matote, bankinės operacijos yra įdomi, būtina procedūra kiekvieno iš mūsų gyvenime. Kitą kartą darydami paprastą pavedimą ar išimdami pinigus iš kortelės pagalvokite, kiek tokios manipuliacijos palengvina mūsų gyvenimą. Juk dabar tikriausiai jau žinote, kas yra sandoriai. Žodžio reikšmė jums nėra paslaptis.

Daugeliui kyla klausimas, kas yra sandoris? Juk šis žodis iškyla nuolat, ypač jei žmogus dirba su pinigais. Jei imtume globaliai – duomenų mainų operacijų seka, po kurios atliekami sistemos pakeitimai.

Dažniausiai šis terminas vartojamas atliekant pinigų pervedimus ir perkant prekes. Tai gali būti:

• Grynųjų pinigų išėmimas iš bankomato ar banko skyriaus;
• Tam tikro skaičiaus akcijų pirkimas biržoje;
• Atsiskaitymas kortele parduotuvėje.

Kai tik operacija patvirtinama ir pinigai išsiųsti, operacija laikoma sėkmingai baigta. Pinigai nurašomi iš pirkėjo ar įstaigos kliento sąskaitos, o prekės pervedamos asmeniui. Galima sakyti, kad sandoris yra būdas savanoriškai pervesti pinigus iš asmens sąskaitos paslaugą teikiančiam asmeniui. Visos operacijos yra registruojamos finansų įstaigos duomenų bazėje. Nesvarbu, ar operacija buvo sėkminga, ar ne. Pavyzdžiui, neteisingai įskaičius lėšas į banko kortelę.

Tačiau nemanykite, kad sandorio sąvoka taikoma tik finansų sektoriui. IT įmonės taip pat dažnai vartoja šį terminą, ypač kai kalbama apie duomenų bazių programavimą. Šiuo atveju terminas reikš tam tikrą duomenų bazės pakeitimų seką.

Čia taip pat yra dvi taikymo parinktys. Kai operacija patvirtinama, jai priskiriamas „Įsipareigojimas“, tačiau jei dėl kokių nors priežasčių atsisakoma, priskiriamas „Atšaukimas“. Dažniausiai tai atsitinka, kai jie norėjo padalyti vieną iš skaičių iš nulio arba įvedė sumą, kuri neatitinka anksčiau įvestos į duomenų bazę.

Rūšys

Dažniausias operacijos panaudojimo atvejis yra atsiskaitymas mokėjimo kortele iš banko bet kurio prekybos centro, parduotuvės ar finansų įstaigos teritorijoje. Operacija pradedama tada, kai savininkas pageidauja sumokėti už prekes, po to savo banko kortelę atiduoda už kasą atsakingam darbuotojui.

Toliau kortelė dedama į specialų terminalą, kur tereikia patvirtinti tolesnę operaciją. Norėdami tai padaryti, turite įvesti duomenis ir iš anksto nustatytą PIN kodą. Tada terminalas nuspręs, ar įvestas slaptažodis buvo teisingas, ar turėtų būti atmestas. Bet kokiu atveju informacija apie sandorį bus įrašyta į konkrečią duomenų bazę. Taip nutinka dėl duomenų perdavimo į šią kortelę aptarnaujančią mokėjimo sistemą. Ir jau šiame etape vyksta pilnas įvestų duomenų autentiškumo patikrinimas. Juk mokėjimo važtare jų gali būti arba nebūti.

Bet jei viskas teisinga, operacija sėkmingai užbaigiama ir siunčiama tiesiai į išduodantį banką. Šios mokėjimo kortelės gamyba buvo vykdoma per jį. Tada informacija apie operaciją siunčiama į spaudos centrą, kuriame nustatoma informacija apie teises naudotis mokėjimo sistema.

Verta paminėti, kad jei viename iš etapų aptinkama klaida ar duomenų neatitikimas, sandoris tiesiog atsisakomas.

Naudojimo sritys

Įvairiose taikymo srityse vartojami skirtingi žodžio „sandoris“ žymėjimai:

• Ekonomika reiškia lėšų pervedimą iš vienos srauto sąskaitos į kitą. Tai ypač pasakytina apie pirkimo ir pardavimo sandorius;
• Operacijos su bankomatais lemia grynųjų pinigų išdavimą klientui, kuris naudojo banko kortelę ar sąskaitos numerį jas gauti;
• Politinis paaiškinimas apima susitarimą dėl abipusiai naudingų sąlygų tarp dviejų partijų.

Daug kas priklauso nuo banko išduotos kortelės. Debeto ir kredito kortelės tvarkomos skirtingai. Tiesioginę įtaką turi ir prisijungimo prioritetas, kurį nustato kortelę išdavusi finansų įstaiga. Atsižvelgiant į šiuos veiksnius, operacijos greitis skirsis.

Sandoriai su nedidelėmis pinigų sumomis atrodo paprastesni. Jei asmuo parametruose nurodė tam tikrą nustatymą, operacijos metu jis turės galimybę neįvesti slaptažodžio. Ji bus vykdoma automatiškai ir, jei sąskaitoje bus pakankamai lėšų, jos bus nurašytos, o informacija apie operaciją įrašoma į duomenų bazę.

Netgi su finansais visiškai nesusijusios sritys naudoja „sandorių“ sąvoką. Psichologija pateikiama kaip pavyzdys. Šios srities specialistai sandoriu vadina apsikeitimą dirgikliais, kurie atsiranda dviejų asmenų pokalbio metu. Ši programa yra šiek tiek toli, bet turi teisę egzistuoti. Dabar jūs žinote, kas yra sandoriai.

Turite žinoti bent jau aukščiau pateiktą informaciją apie sandorius, nes šiuolaikiniame pasaulyje be jų tiesiog neįmanoma. Tai reiškia, kad vis tiek turėtumėte turėti minimalią idėją.