Infrastructure for Electronic Business on the Internet


Figura A.54 tubacionit të Produktit: grup tipik i fazave



Yüklə 1,07 Mb.
səhifə17/18
tarix14.09.2018
ölçüsü1,07 Mb.
1   ...   10   11   12   13   14   15   16   17   18

Figura A.54 tubacionit të Produktit: grup tipik i fazave

Qëllimi i tubacionit Produkti është për të mbledhur informacion në lidhje me prodhimet dhe për të treguar atyre në faqe product.asp. Këto janë shpjegime të hollësishme për fazat e paraqitur në Figura A.54:

  • Product Info - këtë fazë është përdorur për të grumbulluar informacion nga baza e të dhënave, në lidhje me produktet e listuara në objektin OrderForm. Aktiviteti minimale komponent pritet të kryer është për spastrim nëpërmjet mbledhjes Items dhe kopje të të gjitha informatat nga baza e të dhënave për secilin artikull në OrderForm. komponentëve shtesë në këtë fazë mund të llogarisë ose kopje disa informata shtesë në lidhje me disa Artikujve: për shembull, pesha produkt si një bazë për llogaritjen e çmimeve të mëtejshme. Në fund të fazës së, vëzhgimit është bërë në mënyrë të përcaktuar nëse të gjitha të dhënat e nevojshme në lidhje me produktet janë të shkruara në OrderForm.

  • Blerës Informacion - kjo fazë mund të përdoret për të shkruar informacion rreth klientit (blerësit potencial). Kjo është e dobishme në qoftë se baza e të dhënave është bërë që përmbajnë të dhëna në lidhje me konsumatorët, me qëllim që të menaxhojë konceptet më të avancuara, si zbritje për disa grupe të konsumatorëve, etj Është e rëndësishme të thuhet se kjo fazë mund të jetë i detyrueshëm fshi. Në këtë rast, asgjë nuk do të kontrollohen në fund fazë.

  • Item Çmimi - qëllimi i kësaj faze është të përcaktojë çmimin aktual (çmimi bazë, pa ndonjë shpenzim shtesë ose zbritje), për çdo produktit pika brenda objektit OrderForm. Kjo vlerë është caktuar pastaj në regularprice pronës iadjust në fjalor e çdo send. Në fund të kësaj faze, të kontrolloni është bërë në qoftë se vlera _iadjust_regularprice është caktuar për çdo send.

  • Item Rregullo Çmimi - këtë fazë është përdorur për të llogaritur çmimin e kur të gjithë zbritje janë shtuar. Çmimi i rregulluar është i shkruar më pas në

iadjustcurrentprice fushë. Në fund të tubacionit, kontrolloni është bërë për të përcaktuar nëse të gjitha fushat _iadjust_currentprice janë të vendosur për çdo send.

  • Inventari - kjo është faza e fundit, dhe është përdorur për të kontrolluar nëse ka kopje të mjaftueshme të produktit në të aksioneve. Në qoftë se produkti është në dispozicion në sasi të caktuar kopjesh, e duhur

backorder inventarit është vendosur. Nuk ka asnjë kontroll për të kryer në fund të kësaj faze.

Ka situata në të cilat ky tubacion nuk është përdorur për procesin e rendit. Në situata të tilla, OrderForm nuk përmban urdhëroi në të gjitha pikat. Për shembull, nëse dikush dëshiron të mbledhë informacion në lidhje me disa produkte, është vetëm sa për të krijuar OrderForm objekt të ri, vënë ato produkte si disa urdhëra fiktive, dhe pastaj të kalojë në objekt OrderForm nëpërmjet tubacionit Produktit.

A.5.8 tubacionit Plani

Figura A.55 tregon pamjen vizuale e tubacionit të Planit. Ajo tregon se tubacioni Produkti është vetëm një mesin e tubacionit të Planit. Tubacioni Plani është përdorur për të përcaktuar çmimin e plotë të rendit, përfshirë pazar dhe tarifat e tatimit. Ky tubacion është përdorur zakonisht në dy vende në programin: për të treguar çmimi i përgjithshëm i shportë pazar, dhe në faqen e pagesës për të cilën është llogaritur çmimi i përgjithshëm i rendit (në fakt, një lloj projekt-ligji i paraqitet e konsumatorit).

Këto janë shpjegime të hollësishme për fazat e nuk shpjegohet para:

  • Informacione Merchant - ajo është përdorur për të vendosur të dhënat në lidhje me shitës. Kjo fazë është i detyrueshëm, dhe asgjë nuk është e kontrolluar në fund të saj.

  • Rendit initialization - kjo fazë është fillimin informacion në lidhje me rendin, duke kontrolluar nëse shuma e saktë e produktit është caktuar për secilin artikull (Itemfn]. Sasia). Në fund të kësaj faze, të kontrolluar sistemin e ngulitur kryen disa detyra, të tilla si vendosjen e

ID qëllim nëse nuk është përcaktuar tashmë, duke krijuar _oadjust_adjustedprice për 
çdo send me duke marrë parasysh sasinë e produkteve në 
pika, fshirja e disa pronave ato duhet të rishkruhet çdo herë kjo 
naftësjellësit është nisur, etj,




Figura A.55 Struktura e Planit të tubacionit

Rendit Kontrolloni - vërteton se që mund të jenë të përpunuara. Kjo fazë gjeneron gabim në fund, nëse me qëllim përmban asnjë faqe. Qëllimi i secilit komponent në këtë fazë duhet të jenë ose më tej për të kontrolluar vlefshmërinë e rendit (me disa kritere të caktuar), ose për të lejuar zbulimin dhe korrigjimin e problemeve përgjegjës për përçarje qëllim të përpunimit.

Rendit Rregullo Çmimi - kjo fazë duhet vendosur pronë _oadjust_adjustedprice për çdo artikull, duke llogaritur disa zbritje të veçanta në nivel të rendit të gjithë. Për shembull, në qoftë se vlera që shkon mbi disa sasi, pastaj disa zbritje të veçanta mund të shtohet.

  • Rendit Nëntotali - këtë fazë llogarit vlerën e rendit gjithë (para tatimit dhe dërgesa janë shtuar). Kjo Nëntotali është caktuar pastaj në pronë oadjustsubtotal. Kjo vlerë përcaktohet zakonisht nga mbledhje e thjeshtë e të gjitha pronave _oadjust_adjustedprice. Arsyeja pse kjo mbledhje është kryer në këtë fazë, dhe jo në një fazë të vonë, qëndron në faktin se shuma integrale do të përdoren në fazat e mëposhtme, për shembull për llogaritjen e taksave (se operacioni nuk varet vetëm në pika të veçanta costs , por në total të tyre, shumë). Kjo shumë do të tregohet si çmimi i shportës pazar gjithë, sepse konsumatori ende nuk ka vendosur për të blerë atë, dhe të dhënat shtesë për konsumatorin, si adresa, nuk dihet ende. Kjo do të thotë se taksave dhe dërgesën e taksave nuk mund të llogaritur ende, por ende konsumatorëve duhet të jenë të informuar në lidhje me çmimin e parë të rendit të plotë.

  • Postimi - këtë fazë përcakton koston e transportit detar i cili duhet të përfshihen për koston finale. Koston e transportit detar është caktuar në

pronës shippingtotal. Në fund të fazës së, ajo është bërë kontroll në se kjo pronë është e vendosur apo jo. Nëse jo, një gabim është krijuar.

  • Trajtimi - si tregtar, kjo fazë përcakton paketimin dhe trajtimin e shpenzimeve, të cilat do të shtohen në koston e fundit e rendit.

  • Tax - kjo është faza e fundit para se të llogaritjes kosto totale. Në këtë fazë, tatimi llogaritet dhe caktohet të pronës taxtotal. Vini re se disa pjesë të taksave mund të llogaritet në fazat e mëparshme, në disa raste të veçanta. Tatimi i llogaritur tashmë është caktuar pastaj me pasurinë taxincluded. Gjithashtu, edhe pse ajo nuk do të kontrollohen për saktësinë, taksat e veçanta mund të llogaritet dhe të ruhen në objekt OrderForm për secilin artikull të veçantë. Kjo duhet bërë për ripërdorimin e mundshme të informacionit nga objekti OrderForm në mbajtjen e proces-libër më vonë.

  • Rendit Totali - në këtë fazë, çmimi përfundimtar i rendit është llogaritur, zakonisht nga përmbledhje e taksave, anijeve, trajtimin dhe Nëntotali vlerat tashmë të përmbajtura në objektin OrderForm. Shuma përfundimtare është caktuar pastaj në total të pronës totale e objektit OrderForm. Kjo fushë është i kontrolluar në fund të fazës së.

  Figura A.56 Blerje tubacion



Qëllimi i këtij tubacioni është të përdorni një shembull i OrderForm që tashmë ka kaluar (me sukses) nëpërmjet tubacionit Plani, dhe pastaj të përfundojë blerjen me trajtimin e transaksioneve financiare të nevojshme.

Siç tregohet në Figura A.56, tubacioni i blerjes përbëhet nga vetëm tri faza:

  • Blerje Shiko - kjo fazë mund të përdoret për të verifikuar se OrderForm është gati për në procesion e pagesës. Kjo mund të kontrolloni se OrderForm ka kaluar me të vërtetë nëpërmjet tubacionit Planit, që do të thotë se gjithsej pronë e përgjithshme është caktuar saktë, dhe se të gjitha të dhënat e nevojshme lidhur me pagesën janë në dispozicion. Asnjë i kontrolleve të sistemit të kryhet në fund të kësaj faze.

  • Pagesa - në këtë fazë, transaksionet e pagesave janë kryer. Qëllimi është ose për të pranuar apo të hidhni pagesën nga autorizimin kartë krediti, llogari rrjedhëse të klientit i përgjithshëm, kontaktuar Gateway transaksioneve Provider, etj Në fund të fazës së, kontrollon sistemin e nëse prona _payment_auth_code është caktuar saktë. Kjo pronë jo vetëm që paraqet kodin e identifikimit të transaksionit, por ajo gjithashtu paraqet njohjen që transaksioni ka përfunduar si duhet.

  • Prano - kjo është në fazën përfundimtare, dhe ajo është përgjegjëse për aktivitetet që duhet të kryhet pas blerjes është bërë. Aktivitetet e tilla janë, për shembull, update inventarit, regjistrimi informacion në lidhje me qëllim, e-mailing njohjen për konsumatorin (-quajtur projekt-ligjin në mënyrë elektronike), etj Kjo është faza me dëshirë, dhe ajo nuk përmban asnjë kontrolluar në fund . Vlen të theksohet se ekziston një mekanizëm për ruajtjen e rendit e informacionit, që mund të përdoret nga

  • thjeshtë ruajtje të dhënave të përmbajtura në OrderForm objekt direkt në bazën e të dhënave. Gjatë këtij operacioni, pronat e ka emrin e tyre duke filluar me një nënvizuar (për shembull, gjithsej në total) nuk janë të regjistruar në bazën e të dhënave.

A.5.10 The OPP Komponentet të Këshillit të Ministrave të përfshira në paketë SSCE

Ky seksion do të japë koment të shkurtër mbi OPP VKM disa përbërës që janë dorëzuar së bashku me paketë software SSCE.

A.5.10.1 Komponenti Scriptor

Komponenti i Scriptor është qëllim i përgjithshëm-komponenti i vetëm që është paraqitur në këtë seksion: ajo nuk është për qëllim ndonjë fazë të veçantë të ndonjë tubacionit. Ky është komponenti i përgjithshëm që mund të përdoret për të ekzekutuar të shkrimit në përputhje me Host Interface Windows shkruar. shembuj tipike të Scripts tilla janë VBScript, JavaScript, PerlScript, etj Kjo praktikisht do të thotë se në brendësi të shkrimit ekziston një ndërfaqe të Këshillit të Ministrave, e cila lejon përdorimin e të gjitha komponentëve të Këshillit të Ministrave të regjistruar në server duke instantiation thjeshtë në brendësi të shkrimit.

Objekti Këshillit të Ministrave të Këshillit të Ministrave bëhet objekt OPP një herë ai do të zbatojë të Këshillit të Ministrave interfaces nevojshme për ndërveprim me tubacionin. Këto objekt mund të krijohen me vegla standarde si Visual C + + dhe Visual Basic, ose duke përdorur komponentë Scriptor SSCE. Në rastin e fundit, ne jemi duke folur për tashmë të përfunduar objektin OPP me funksionin vetëm të jetë në gjendje për të ekzekutuar kodin e programit të shkrimit. Me komponent Scriptor në dorë, është e mundur për të krijuar objekte të Këshillit të Ministrave OPP në gjendje për të ekzekutuar disa të përpunimit të veçanta mbi objektin OrderForm, ose për të ekzekutuar disa kërkesave të veçantë në sfond të përpunimit kryesore, gjoja se kërkesat e tilla nuk mund të mbulohet nga komponente standarde.

mënyrë tipike e veprimeve do të ishte për të filluar me krijimin e faqe duke përdorur Faqes Fondacioni magjistar dhe Store Builder Wizard, që të dyja janë të përfshira në paketën e SSCE. Pastaj, duke përdorur Editor tubacionit, një komponent i Scriptor OPP mund të shtohet në purchase.pcf që është krijuar nga Wizard ndërtues Site. Script vetë mund të mbahen brenda brenda PCF file., Ose jashtë në file të veçantë. Nëse versioni i brendshëm është zgjedhur, Editor tubacionit hap editor teksti që do të përdoret për të hyrë në dorëshkrim. Tre metoda janë të përcaktuara tashmë në një dorëshkrim të tillë: MSCSExecute, MSCSOpen dhe MSCSCIose.

Metoda MSCSOpen përmban kodin kryesore, dhe se kodi është përgjegjës për kryerjen e funksionimit thelbin e komponentit. Siç është programi kryesor modul, duhet të jetë i pranishëm në të shkrimit. Metoda MSCSOpen është duke u ekzekutuar pasi objekti është krijuar, dhe kjo paraqet një lloj konstruktor. Kështu, që metoda është duke u përdorur nisja e komponentit. Metoda MSCSClose thirret një herë shkatërrimin komponent duhet të kryhet. Ajo korrespondon me furë për të djegur plehrat në object-oriented gjuhë të përbashkët. Ndërmjet veprimeve të tjera, metoda e MSCSClose është përgjegjës për mbylljen e lidhur me bazën e të dhënave.

A.5.10.2 Komponenti per Informacion Produkt Faza

Ky komponent është e ndërtuar vetëm në komponentë të destinuara për përdorim në fazën e Informacionit Produktit. Për çdo artikull nga OrderForm ajo kryen një pyetje të veçantë mbi bazën e të dhënave produkteve. Disa informata shtesë lidhur me këtë komponent do të vijnë me radhë.

  • ConnectionString - përcakton tekstin lidhje ODBC përdoret për të hyrë në bazën e të dhënave. Nëse kjo vlerë nuk jepet, ajo është lexuar nga konteksti i tubacionit.

  • Query - Pyetje SQL e tekstit, i cili do të thirret për çdo element veçmas.

  • ParameterList - përmban presje palimituar parametrat listë, për qëllim të dërguar në pyetje.

Konteksti tubacion është grup i objekteve dhe pronave të kuptueshme për komponentët e tubacionit. Nëse prona Query ka vetëm një fjalë, atëherë supozohet të jetë tregues për pyetjen brenda objektit QueryMap. QueryMap Objekti është përdorur vetëm si enë pyetje. Kjo është përcaktuar në mënyrë tipike në të përcaktuara në dosjen global.asa, në mënyrë që të jetë në dispozicion me kërkesën ASP. Duke mos pasur parasysh nëse është përcaktuar pyetje të drejtpërdrejtë ose nëpërmjet objektit QueryMap, është e mundur të parametrave të futur nga Lista Parametri në të.Si shembull, merrni parasysh pyetjen e mëposhtme:

SELECT * NGA Produkt KU = SKU '? " DHE Emri LIKE'%?%

'me të barabartë ParameterList të 'Item.SKU, Item.Name'.

Për secilin produkt (pika), një herë pyetjen thirret, të dy pyetje shënon do të ndryshohet me aktual produkt ID dhe te përkatës emrin e saj, siç përcaktohet me listën parametër. Si rezultat i kësaj përmbarimit pyetjes, komponenta e vë vizë nga çdo kolona (tabela Produkt atribut) në objektin OrderForm në pronat e quajtur _product_ColumnName. Për shembull, në qoftë se disa kolona nga tabela Produkti është titulluar Çmimi, atëherë QueryProductlnfoADO krijon pasurinë productprice. Kjo pronë është e cakton vlera e kolonën përkatëse të rezultatit të pyetjes. Është e rëndësishme të thuhet se vetëm rreshtin e parë të vlerave nga tabela rezulton janë caktuar. rreshtave të tjera, nëse ekzistojnë, janë injoruar. Në pyetje të rregullt, si një në shembullin e mëparshëm, vetëm një rresht është kthyer.

A.5.10.3 DefaultShopperlnfo Komponenti per Informacion Shopper Faza

Kjo kopje komponent të dhënat nga Shopper objekt i fjalor kontekstin tubacionit në objektin OrderForm. Komponenti i shkruan vlerat * blerës në OrderForm, dhe lexon vlerat Blerës nga konteksti i tubacionit. Kjo do të thotë se ajo krijon vetitë e OrderForm, secili mbante emrin dhe vlera të njëjta me pasurinë e objektit Shopper. Megjithatë, ky objekt do të zakonisht është bosh, sepse është e vështirë për të shitet lehtë për të mbajtur të dhënat aktuale për klientët në këtë faqe interneti. Përndryshe, një mekanizëm i përshtatshëm duhet të ofrohet, si regjistrimin e konsumatorëve para blerja, ose kur vijnë në vend.

A.5.10.4 initialization Rendit Faza

Kjo fazë contains ndërtuar jo në komponente të përcaktuara në kuptim të diskutohet më parë. Megjithatë, tubacioni Plani automatikisht krijon një shembull të komponentit RequiredOrderlnit. Kjo komponentë është pjesë e logjikës së përdorur për të kryer kontroll në fund të komponentës. Ndër të tjera, duke kontrolluar veprimet e mëposhtme janë kryer:

  • Nëse OrderForm.orderlD është e barabartë me NULL, një tjetër (unike) identifikuesi qëllim është krijuar

  • Vendos për të NULL vlerat e mëposhtme në OrderForm: _total_total, _oadjust_adjustedprice, _oadjust_subtotal, shippingtotai,taxtotal, handlingtotal, _tax_included dhe

_payment_auth_code. Kjo siguron për këte para se të hyjnë në tubacion. Kjo është e rëndësishme, sepse shumica e komponentëve janë të përcaktimit të vlerës të pasurisë vetëm në qoftë se prona nuk është përcaktuar më parë.

A.5.10.5 Kontrollo Rendit Faza

Urdhëri Check fazë është në situatë të ngjashme disi si faza e fillimit të Rendit. Në këtë rast, duke kontrolluar është kryer nga komponentë RequiredOrderCheck. Kjo komponentë thjesht kontrolle në qoftë se ka të paktën një artikull në mbledhjen OrderForm. Në qoftë se mbledhja është bosh, ajo shton një mesazh në mbledhjen gabimet blerjen e objektit OrderForm, duke treguar një gabim.Ky gabim zakonisht çon në ndalur tubacionit.

DefaultltemPrice Komponenti A.5.10.6 për çmimin Faza

Komponentet e fazës së çmimeve janë përgjegjës për ngritjen e vlerave Item._iadjust_regularprice për secilin artikull të veçanta të përfshira në mënyrë. E ndërtuar vetëm në komponenti për qëllim të përdoret në këtë fazë është DefaultltemPrice. Ajo thjesht kopje e vlerës së pronës Item._product_list_price në pronë ltem._iadjust_regularprice. Ajo duhet të jetë e qartë se tubacioni është dashur për të krijuar një farë mënyre vlerën e përshtatshme për Item.productjistprice. Kjo pronë duhet të krijohen në fazën Info Produktit. Kjo do të thotë më tej se, në qoftë se ky komponent do të përdoret për të krijuar të çmimit, të dhënat produkt tryezë e cila është lexuar në fazën e produktit duhet të përmbajë të dhëna kolonën listprice. Natyrisht, e gjithë kjo mund të shmanget duke shkruar komponent i ri (për shembull, komponenti Scriptor), i cili do të përdoret për nxjerrjen e çmimeve të prodhimeve dhe të kopje e tyre në Item.iadjustregularprice.

A.5.10.7 Çmimi Rregullo Faza Item

Kjo fazë është përdorur për të balancuar çmimin në mënyrë të tillë që të çmimeve reflekton ekzistencën e disa oferta të veçanta dhe kushtet e shitjes. Rezultati është caktuar pastaj me pasurinë Item._iadjust__currentprice. Paketa SSCE përmban dy ndërtuar në komponentet për këtë fazë:

  • SaleAdjust komponenti - ajo kryen kontrolloni nëse produkti është ofruar në shitje, dhe sipas përgjigje, rregullon çmimi. Kjo komponentë krahason datën e tanishme me periudhën mes datave të vendosur në Item._product_sale_start dhe pronat Item._product_sale_end, dhe nëse ajo qëndron në mes, Item._product_sale_price është kopjuar me pasurinë Item.iadjustcurrentprice. Ajo vjen nga se QueryProductlnfoADO krijon tri fusha për shtyllat nga tabela e produkteve: salestart, saleend, dhe sale_price.

  • Komponenti ItemPromo - kjo është paksa më e komplikuar versionin e komponentit të mëparshme, me dallimin se të nevojshme vlerat

  • nuk janë marrë nga baza e të dhënave, por pritet që të gjendet në komponentin e pronave. Këto janë pronat:

  • StartDate - data në të cilën fillon shitjen.

  • EndDate - data kur mbaron shitjes.

  • ConditionOrderKey - pasuria që ConditionOperator thirret në.

  • ConditionOperator - operatori që është përdorur për të përcaktuar se çfarë objekte janë në shitje, dhe të cilat nuk janë.

  • Kushti Vlera - vlera që është krahasuar me ConditionOrderKey.

  • DiscountType - përshkruan llojin e zbritjes është në dorë: e caktuar, ose në lidhje me çmimin (përqindje).

  • DiscountValue - vlera numër i plotë që përfaqëson vlerën e zbritje, kjo vlerë është e interpretuar në lidhje me vlerës DiscountType.

Komponenti i parë ItemPromo kryen kontrolloni nëse Item._iadjust_currentprice ndoshta vendosur tashmë nga disa komponentë të tjerë. Nëse e vërtetë, asgjë nuk është bërë më tej. Përndryshe, këto veprime janë kryer. Së pari, kjo është e përcaktuar nëse data e tanishme është brenda intervalit bounded me StartDate dhe pronat EndDate. Nëse kjo është e saktë, atëherë është e kontrolluar nëse ConditionOrderKey dhe Kushti Vlera të qëndrojë në lidhje me ConditionOperator. Testi i fundit ka nevojë për një shembull:

ConditionOrderKey = ConditionOperator SKU = '' ConditionValue = = 123

Në këtë shembull, test duket si: SKU = 123. Tani kjo lidhje është testuar në korrektësinë.Nëse të dy kushte janë plotësuar, e zbritjes është aplikuar. Si tha para, DiscountValue është një vlerë integrale që mund të trajtohet si një zbritje absolute, apo përqindje të çmimit, në varësi të pronës DiscountType.

A.5.10.8 Rendit Rregullo Faza

Ndërtuar vetëm në komponent që e mbështet këtë fazë është komponent DBOrderPromoADO. Ky komponent është menduar për nxjerrjen e të gjitha informatat në lidhje ndoshta promovime ekzistues ata duhet të merren parasysh në fazën aktuale. Të dhënat janë nxjerrë nga invoking pyetjeve të përshtatshme për bazën e të dhënave, dhe të dhënat janë menduar të përmbajë

udhëzime në çfarë kushtesh zbritje do të aplikohet. Ata gjithashtu përshkruajnë në atë që thotë zbritje është aplikuar.

A.5.10.9 Nëntotali Faza e Rendit

Kjo komponentë llogarit-to-tani e njohur për shumë lart, dhe cakton atë në pronën OrderForm._oadjust_subtotal. Komponenta e vetme që SSCE fut për këtë fazë është DefaultOrderSubTotal.Kjo komponentë thjesht shton gjitha Item.oadjustadjustedprice vlerat dhe cakton shumën e OrderForm._oadjust_subtotal. Nuk zakonisht ka nevojë të shtoni komponentë të tjerë në këtë fazë, nëse disa llogaritje të tjera të veçanta është menduar të jetë kryer.

A.5.10.10 Postimi Faza

Anijeve Kostoja totale që është llogaritur nga komponentët kjo fazë është e caktuar në këtë fushë OrderForm._shipping_total. SSCE vjen me disa komponente krijuar për t'u përdorur në këtë fazë.I thjeshtë është komponent DefaultShipping: atë vetëm cakton zero për koston e transportit detar dhe është përdorur, siç pritet, në ato raste të rralla relativisht kur anijeve nuk është shtuar në çmimin. Shembull tipik i gjendjes tillë është shitja e softuerit që është ofruar për të shkarkimit nga tregtare në vend.

E shitës mund të ofrojë anijeve disa metoda për konsumatorin. Këto metoda zakonisht ndryshojnë në kosto dhe kohë e nevojshme për transportin e mallrave. Konsumatori zgjedh opsioni i preferuar në të njëjtën faqe në të cilën është futur adresa e anijeve. Lloji i transportit detar duhet të caktohet me pasurinë metodë OrderForm.shipping. Kjo vlerë do të përdoret nga komponentët fazë Shipping (përveç DefaultShipping, natyrisht), duke u përpjekur për llogaritjen e kostos përfundimtare të anijeve. 

A.5.10.10.1. Fixed Shipping Komponenti

Kjo komponentë shton koston fikse të rendit, në varësi të metodës anijeve. Ka disa prona të përfshira në këtë komponentë:

- Aplikoni Kur - përcakton cila metodë duhet të caktuar në fushën shippingjnethod në mënyrë që këtë komponent të llogaritur koston e transportit detar për rendin aktual. Ka tri vlerat të mundshme për këtë fushë: (1) në qoftë se "Gjithmonë" është vendosur, koston e transportit detar është shtuar edhe nëse metodë nuk është e caktuar, dhe (2) në qoftë se "A ka ndonjë vlerë" është vendosur, atëherë kostoja është caktuar vetëm nëse shippingjnethod ndryshon nga NULL: nuk është e rëndësishme se çfarë metodë është e zgjedhur, ndërsa një është e zgjedhur, (3) në qoftë se

fushën e përmban "të barabarta për të" metodë, pastaj koston e transportit detar është shtuar vetëm nëse fushë Metoda e barabartë në fushën shipping_method. Metoda - kjo pronë përcakton metodën e anijeve që të jetë në krahasim me OrderForm.shippingmethod. Vini re se krahasimi është rasti të ndjeshme.

  • Kosto - koston e transportit detar që duhet të shtohet, e matur në qindra e parave të njësisë bazë. Vetëm integrale vlerat janë të lejuara.

Komponenti i FixedShipping fushë duhet shippingmethod vetëm nga OrderForm të jetë funksional. Nëse i suksesshëm, ai shkruan vlera _shipping_total të OrderForm. Komponenti i nuk ka nevojë për vlera nga konteksti i tubacionit të jetë funksional.

Për të lehtësuar këtë çështje, ky komponent thjesht hedh një vështrim për të cilat metoda të anijeve që ka për qëllim, dhe në qoftë se metoda e specifikuar nga klienti është takuar, e përshtatshme kostoja e saj është shtuar. Përndryshe, anijeve kostoja është lënë për vlerën e mëparshme. Nëse disa anijeve metodë tjetër të marrë një kosto të caktuar të tjera për të shtuar, përdoruesi duhet vetëm të shtoni një tjetër komponent FixedShipping pas atij të mëparshëm, ngritjen e anijeve të tjera detaje metodë nëpërmjet saj. Në këtë rast, të komponentit të parë thjesht do të kalojë nëpër të të dhënave, duke e bërë asnjë ndryshim në koston e transportit detar. Një tjetër komponent do të kuptojnë se metoda është vendosur të përjashto vlerën e saj, dhe do të aplikojnë të anijeve koston e dytë. 

A.5.10.10.2  LinearShipping Komponenti

Kjo komponentë llogarit koston e transportit detar duke shumëzuar vlerën fikse dhënë me një ose më shumë vlerat e marra nga OrderForm. Ka disa prona të përfshira në këtë komponentë:

  • ApplyWhen - së bashku me fushën e Metoda, këtë fushë për të cilën specifikon metodat e anijeve të komponentit duhet të përdoren. Detajet janë të njëjta si për komponentë FixedShipping.

  • Metoda - metoda e anijeve, si në komponentë FixedShipping.

  • Rate - pjesa bazë (për qind) të çmimit të anijeve që duhet të shumëzohet me parametër vuri në fushën BasisItemKey.

  • BasisItemKey - përmban fushën OrderForm e cila është përdorur për të shumëfishohen vlerën Rate. Ekzistojnë katër formate të mundshme për këtë fushë:

  • Order.fieldname - për shembull Order.oadjustsubtotal, ky është formati të thjeshtë, kur një fushë qartë është përdorur për të shumëzoj Rate

  • Sum.fieldname - do të thotë se të gjitha vlerat e fushave të specifikuara me fieldname nga OrderForm duhet të përmblodhi, dhe pastaj të përdoret për të shumëzohuni; për shembull, numri i përgjithshëm kthimit Sum.Quantity e produkteve urdhëruar (jo artikuj)

  • Sumq.fieldname - kryen të ngjashme me Shuma, përveç vlera e fieldname është shumëzuar me sasinë e parë të fushës përkatëse, dhe vetëm pasi që mbledhje është kryer

- Count - kthimin e numrit të përgjithshëm të llojeve të produkteve në mënyrë.

Kjo komponentë përdor fushë _shipping_total për të ruajtur vlerën përfundimtare e llogaritjes së tij. Nga ana tjetër, komponent nuk ka nevojë për të dhëna shtesë nga konteksti i tubacionit të jetë funksional.

Komponenti Postimi linear është më së shumti përdoret shpesh në tre skenare të veçanta:

  • Nëse një nevojë për të llogaritur koston bazë të për qind të kostos totale rendit, në këtë rast, Order._oadjust_subtotal duhet të caktohen në BasisItemKey

  • Nëse anijeve kostoja totale është që të llogaritet në bazë të numrit të përgjithshëm të produkteve të urdhëruar, në këtë rast, Sum.Quantity duhet të caktohen në BasisItemKey

  • Nëse kostoja e transportit detar duhet të llogaritet në varësi të peshës produktit; në Sumq.Weight rast të tillë duhet të përdoret. Kjo sigurisht supozon se OrderForm përmban fushën Item.weight krijuar në fazat e tubacionit të mëparshëm.

A.5.10.10.3 TableShippingADO Komponenti

E tretë dhe e fundit e ndërtuar në komponentë për fazën Transport tregtar është komponent TableShippingADO. Është për qëllim të përdoret për llogaritjen e kostos të anijeve në bazë të dhënave të përmbajtura në bazën e të dhënave. Ideja bazë prapa këtij komponenti është të formojë tabelën në bazën e të dhënave që përcakton koston e transportit detar rrethana të ndryshme. Për shembull, tabela të tilla mund të përmbajë koston e transportit detar për çdo metodë e anijeve dhe pesha varg i tërë rendit. Kjo komponentë kryen llogaritjen në varësi të formatin tabelë përcaktohet nga përdoruesi, dhe e ndërtuar në mënyrë të përshtatshme queries. kombinim i tillë siguron përdoruesit me një mjet i fuqishëm për llogaritjen e kostos në kuptim të gjerë shumë.

Për shembull, supozojmë se këto Microsoft SQL server dorëshkrim është ekzekutuar:

TABELA dbo.healthy_shipping_costs CREATE (

shipping_method VARCHAR (20) NUK NULL, NULL NUK min_weight noton, noton max_weight NUK NULL, NULL int kosto nuk

FILLORE KRYESORE

(Shipping_method, min_weight, max_weight)

)

Pyetja e mëposhtme mund të përdoret për llogaritjen e anijeve

kostos:

kosto SELECT

NGA healthy_shipping_costs min_weight

DHE> peshë max?

DHE shipping_method =?
A.5.10.11 Trajtimi Faza

Komponentet në këtë fazë janë përdorur për të llogaritur koston e trajtimit. Kjo kosto ka të bëjë zakonisht me aktivitete si paketimin e prodhimit, përgatitjes përfundimtar në një mënyrë dhuratë, etj Komponentët janë mjaft të ngjashme me ato të paraqitura në fazën e tregtar, edhe ata janë të bazuara në fushë OrderForm.shippingmethod, dhe kanë emra të ngjashëm. Të gjitha komponentët janë shkruar vlera përfundimtare në fushën OrderForm.handlingtotal. Këto janë ndërtuar në komponentë të destinuara për përdorim në këtë fazë:

  • DefaultHandling - përcakton fushën handlingtotal në zero, dhe është përdorur kur nuk ka trajtimin e shpenzimeve të ekzistojnë.

  • FixedHandling - kryen të njëjtë si FixedShipping.

  • LinearHandling - komponenti ekuivalent me LinearShipping.

  • TableHandlingADO - llogarit shpenzimet e trajtimit të bazuar në të dhënat e nxjerra prej tabela bazën e të dhënave të përshtatshme, e tërë çështja është praktikisht i njëjtë si për komponentë TableShippingADO.

A.5.10.12 Tax Faza

Siç u tha më parë, kjo fazë është përdorur për të llogaritur të gjitha shpenzimet e tatimit që duhet të shtohet në mënyrë të kostos. llogaritjen e taksave mund të nganjëherë të jetë çështje mjaft misterioze, dhe komponentëve të pajiset me paketën SSCE ndoshta nuk do të jetë e mjaftueshme në shumë raste. Ndërtuar në komponentët janë të aftë të llogaritjes së tatimit sipas amerikane, japoneze, kanadeze pjesërisht dhe ligjet e Bashkimit Evropian. Për të llogaritur tatimi në vende të tjera, në qoftë se kodet e themel nuk janë adekuate për ato në vendet e listuara më sipër, komponentët doganore duhet të jetë me shkrim. Një duhet të jenë të vetëdijshëm se kjo detyrë duhet të kryhet me kujdesin maksimal. Është e rëndësishme të ceket një dukuri interesante sot: në shumë vende sot nuk janë ende të aftë për të zgjidhur problemet që ndodhin kur të konsumatorit është jashtë kufijve të vendit tregtare. Në këto raste, shpenzimet e taksave për eksport nuk janë paguar në të gjitha! Kjo gjithashtu do të thotë se taksave do të llogaritet vetëm për konsumatorët vendas. Sipas këtyre rasteve paradoks, nuk është një komponent paradoks me emrin DefaultTax, që thjesht cakton zero në fushën OrderForm._tax_total.

Në tekstin e mëposhtëm, një komponent SimpleVATTax do të paraqitet. Ky komponent zbatohet tatimi TVSH që është e rregulluar në vendet e Bashkimit Evropian. Është supozuar se fushë OrderForm.shiptocountry contains ISO kodin për vendin që dërgesa është dërguar në (kjo është karakter-kod tre, p.sh. SHBA).

Këto janë pronat e komponentit SimpleVATTax:

  • ApplyWhen - përcakton kushtet nën të cilat e taksës TVSH do të aplikohet. Nëse vendosur të "Gjithmonë", tatimi do të jetë gjithmonë llogaritet. Nëse vendosur të "A ka ndonjë vlerë", tatimi është shtuar vetëm nëse ship_to_country nuk është vendosur të NULL. Nëse vendosur të "barabartë" të vendit, atëherë tatimi është shtuar vetëm nëse është e barabartë në këtë fushë shiptocountry fushë shteti.

  • Shteti - e vargut që përmban emrin e vendit, ky emër është në krahasim me OrderForm.shiptocountry nëse fushë Apliko është vendosur të "barabartë për të" vendit, në mënyrë që të përcaktuar nëse taksave është i aplikueshëm për destinacionin e caktuar.

Është e rëndësishme të thuhet se tatimi llogaritet në nivel pika. Kjo shpie në përfundimin se taksave është pika-specifike. Fushën Item.RateltemKey përmban norma tatimore për llojin e produktit përkatës. Këto vlera duhet të krijohen në një nga fazat e tubacionit të mëparshme. Në rastin e përgjithshëm, nuk mund të ketë disa taksave shpenzimet specifike të caktuar në fushën OrderForm.taxincluded. Për këtë qëllim, komponentët doganore duhet të jetë e shkruar, për shkak të ndërtuar në ato janë vetëm vendosjen këtë pronë në zero.

Komponenti i SimpleVATTax prezanton një vështirësi në lidhje me këtë fakt se ky tatim nganjëherë mund të zbatohet edhe për të tjera

vendet brenda BE-së, por jashtë tregtare të vendit. Ky problem është i kapërcyer në mënyrë tipike, duke i shiptocountry në BE.

Vetëm për të treguar se si nganjëherë llogaritja e taksave mund të jetë e vështirë, kujtoj rastet kur tatimi është llogaritur për shpenzimet e transportit dhe trajtimit si. Kjo detyrë nuk mund të kryhet nga ana e ndërtuar në komponente, dhe nëse raste të tilla ndodh, komponenti me porosi duhet të jetë e shkruar.

A.5.10.13 Rendit Gjithsej Faza

E ndërtuar vetëm në komponentë të destinuara për përdorim në Totali fazën e Rendit është komponent DefaultTotal. Siç pritej, ky komponent thjesht shumat Nëntotali anijeve,, trajtimin dhe rezultatet fazë e taksave, si dhe cakton shumën e OrderForm. Totaltotal pronës.

A.5.10.14 Inventari Faza

Komponentet i takojnë në këtë fazë janë përdorur për të përcaktuar nëse produktet nga me qëllim ekzistojnë në sasi të urdhëruar në të aksioneve. Ka dy-në komponente: Lokale Inventari ndërtuar dhe Flaglnventory. I pari krahason fushë Sasia e çdo send me Item.productlocalinventory fushë që supozohet të përmbajë shumën në dispozicion të sendit përkatës. Kjo fushë është nisur në mënyrë tipike në fazën Info produkteve, si zakonisht me fushat e qëllimit të ngjashme. Nëse urdhëroi sasi është më i madh në dispozicion në aksione, diferenca është kopjuar në Item._inventory_backorder dhe ndoshta invokes the ndaloj tubacionit të informojë konsumatorin në lidhje me problemin. Pasuria DisallowBackorder e komponentit Locallnventory përcakton nëse duhet të tubacionit tezgë në qoftë se mungesa e furnizimit është zbuluar apo jo.

Komponenti i Locallnventory kryen kontroll mbi të aksioneve në nivel produkti (SKU). Kjo do të thotë se në qoftë se më shumë se një element permban me të njëjtin produkt, këto sasi janë përmblodhi para hetim furnizimit.

Komponenti i Flaglnventory, ndryshe me atë të mëparshme, kryen kontroll në nivel pika, duke e bërë asnjë mbledhje e sasisë, edhe në qoftë se disa sende të korrespondojnë me të njëjtin produkt.Në këtë rast, sasia në dispozicion duhet të jenë të pranishëm në pronë Item.productinstock. Si si si në Locallnventory, e DisallowBackorder përcakton nëse përmbarimi tubacionit duhet të ndalet në qoftë se mungesa e furnizimit është i pranishëm ose jo.

A.5.10.15 Faza Kontrollo Blerje

Kjo fazë kontrollon nëse çdo gjë është gati për të kryer pagesën apo jo. Komponenti i vetëm në SSCE për këtë fazë është ValidateCCNumber. Ajo kontrollon nëse data e skadimit të kartës së kreditit është e barabartë ose më tej datën e tanishme. Pastaj, numrin e kartës së kreditit është miratuar përmes algorithm për përcaktimin mundësinë kryesor që kjo kartë ekziston. Ekzistenca reale e kartës së kreditit dhe llogari themelor është miratuar së bashku me pagesën në fazën e mëposhtme. Nëse nuk arrin të kontrollojë ose kusht, e ndalon komponent ValidateCCNumber tubacionin dhe përcakton gabim në OrderForm._purchase_errors objekt.

A.5.10.16 Pagesa Faza

Brenda kësaj faze, komponentet tubacioni duhet të vërtetojë se-me kusht të dhënat e përdoruesit janë të mjaftueshme për të blerë për të kryer. Pas kësaj, përbërësit janë të përfshirë me veprimet e para. Në mënyrë që të bëjë të gjithë këtë, Gateway transaksioneve shërbimet Provider pritet. The SSCE nuk përmban asnjë element për këtë detyrë: komponentët e veçantë të përshtatshme për të zgjedhur transaksioneve Gateway Provider (TGP) duhet të përdoren në vend. Disa ofrojnë TGPs, si pjesë e përgjithshme të shërbimit të tyre, komponentëve SSCE që kryejnë të gjitha detyrat e nevojshme në lidhje me përpunimin e pagesave . mundësi të tjera për të shkruar është komponent doganore (p.sh. komponenti Scriptor) që do të përdorin metoda të veçanta për të hyrë në TGP të veçantë. Megjithatë, një tjetër mundësi është të ilustroj me shembull konkret e-xact komponenti E në komponent Scriptor që është përdorur më pas si një përkthyes të veçantë midis OPP dhe E xact komponent i-interface. Në fund të fazës së, logjika themelore kryen kontroll mbi OrderForm._payment_auth_code: kjo vlerë duhet të jetë vendosur në mënyrë të vazhduar.

Në qoftë se kartat e kreditit janë të përpunuara me dorë nga shitës, pastaj faza e pagesës mund të përmbajë DefaultPayment ndërtuar në komponentë që vendos OrderForm._payment_auth_code të "Besimi". Kjo qasje është fort nuk rekomandohet për arsye të dukshme.

A.5.10.17 Prano Faza

Kjo është faza finale, dhe ai embeds veprimet që duhet të kryhet pas blerjes është e angazhuar. Për shembull, informacion e aksioneve duhet të jetë i përditësuar, disa të dhëna mund të dërgohen të kompanive partnere, të tilla si furnizues, etj SSCE sjell disa komponente e hartuara për këtë fazë. Si shembull, vetëm SQLltemADO dhe komponentët SaveReceipt do të paraqitet.

Komponenti i SQLltemADO është përdorur për të rinovuar regjistrin e aksioneve. Të tre parametrat e këtij komponenti janë të rëndësishme:

  • ConnectionString - ajo është përdorur për të krijuar lidhje me bazën e të dhënave. Në qoftë se ky varg është e zbrazët, konteksti tubacioni është konsultuar për të dhënat lidhje.

  • QuerySQL - kërkimin që duhet të thirret për secilin artikull të veçantë nga e rendit. Kjo mund të jetë ose kërkimin e plotë, ose vetëm një referencë në pyetjen e përmbajtura në objektin QueryMap.

  • ParameterList - listën e parametrave, të përdorura si në tekstin e mëparshëm (p.sh. në QueryProdlnfoADO).

Për çdo send që, komponenti invokes pyetjen shënuar. Për shembull, një kërkim i aftë të krijimit të aksioneve informacion mund të jetë:

UPDATE prod_table

inventory_field SET = inventory_field? KU SKU =?
me kusht që ParameterList barabartë për të 'Item.Quantity, Item.SKU'

Dyqane komponent SaveReceipt të dhënat për këtë qëllim (për librin e mbajtur qëllimet) në bazën e të dhënave. Në përgjithësi, kjo mund të kryhet brenda phpBB ASP dikur përfundon tubacionit.Por, nuk ka arsye nuk ka për të përdorur këtë komponent për të njëjtin qëllim. SaveReceipt është duke përdorur objekt ReceiptStorage nga konteksti i tubacionit. Ky objekt përmban informacione të nevojshme për përditësimin e bazës së të dhënave, dhe është përdorur për të shkruar të gjitha informatat nga OrderForm në bazën e të dhënave. Duke fushën NoSaveKeyPrefix nga OrderForm, është e mundur për të shënuar disa artikuj nga nuk qëllim që të ruhen për bazën e të dhënave. Për shembull, nëse kjo fushë përmban _cc_ varg, atëherë të gjitha të dhënat në lidhje me kartat e kreditit nuk do të ruhen.

A.6 Automatik Credit Card Payment Brenda ASP Aplikime

Nga të gjitha teknologjitë në dispozicion për krijimin e faqeve e-commerce, ASP (Active Server Pages) e Microsoft Corp është një nga më popullor. Një mënyrë e mundshme për të arritur pagesën e kartës së kreditit është përdorimi i objekteve të Këshillit të Ministrave ActiveX ofruar nga E -xact Transacions Ltd, si dhe shërbimet e ofruara nga e njëjta kompani. Në fakt, E-xact shërben si një Provider Gateway transaksioneve në këtë rast. Të gjitha të dhënat e rëndësishme për të gjithë sistemin mund të gjendet në-për faqen zyrtare xact E AT -xact.com www.e . Në përgjithësi, pesë institucione duhet të jenë të përfshira në qoftë se dikush dëshiron të procesit të transaksioneve në këtë mënyrë:

  • Konsumatori ka një kartë krediti;

  • Tregtare është i pranishëm me një-commerce site e;

  • Transaksion Gateway Provider është i pranishëm;

  • Merchant posedon një llogari në një bankë, me lejen për të pranuar pagesa me kartë krediti;

  • Nuk është një institucion që ka dhënë konsumatorit me llogari kartë krediti, e cila është e aftë për të autorizuar kartat e kreditit dhe të transaksioneve.

Këto janë hapat e nevojshëm për të kryer, në mënyrë që të kryejnë transaksionin e pagesës:

  • Klienti zgjedh mallrave të kërkuar në shitës's site: lista e produkteve apo shërbimeve të zgjedhura gjendet zakonisht në shportën e blerjeve virtuale;

  • Pastaj, hapat e konsumatorit për të siguruar (SSL) faqe, mbushjen e të dhënave personale, adresa e anijeve, si dhe të dhënat në lidhje me pagesën me kartë krediti;

  • Pas të gjitha të dhënat janë të vendosur, ata janë dërguar në shitës's server;

  • Përdorimi i disa programeve të veçanta, me kusht që zakonisht nga e njëjta kompani që shërben si Provider Gateway transaksioneve (TGP), e shitës dërgon ato të dhëna të TGP;

  • TGP pastaj kryen transaksionin kartë krediti, kryen autorizimin kartë krediti (duke kontrolluar numrin e parave të gatshme në llogari);

  • Nëse të gjithë kontrollet e përfundoi mirë, e transferimit të parave është kryer

A.6.1 Instalimi i Komponenti Procesi

E-xact komponent e ofron objektin COM ActiveX që është përdorur në shitës's server, nga ana e tregtare e e-commerce software. Nga natyra e këtij objekti, ajo mund të aplikohet vetëm në serverat dhe platforma ku kjo mund të jetë regjistruar, dhe me server-side teknologjive në të cilat ajo mund të instantiated dhe të përdorura. Në këtë pikë, ne së pari kemi parasysh Informacionit Internet Server Microsoft dhe ASP. Emri i file që përmban të kontrollit ocx është ExactAXl.ocx, dhe kjo mund të shkarkohet së bashku me dokumentacionin nga xact.com www.e- .

Për t'u regjistruar ky komponent në server NT me IIS, duhet të ndiqni këto hapa. Kopjo skedarin ExactAXl.ocx në directory:

: \ \ system32 \ inetsrv \ komponentët

Pastaj, në komandën e shpejtë, shtypni: regsvr32 ExactAXl.ocx

Skedari regsvr.exe vjen së bashku me pjesën tjetër të paketës (komponenti dhe dokumentacionin).

A.6.2 Përdorimi i Komponentit

Para se të komponent është referohet, ajo duhet të jetë instantiated në kodin në mënyrë të zakonshme ASP. Për shembull, kodin e mëposhtëm mund të përdoren:

exactAuth SET = Server.CreateObject

("ExactAXl.preauthorization98x")

Ideja themelore pas kësaj është për të vendosur pronat e komponentit për vlerat e duhura, dhe pastaj vetëm për të thirrur metodën që fillon transaksion. Këto janë të rëndësishme pronat më të komponentës:

  • Shuma - sasia e transaksionit, të shprehura në dollarë amerikanë.

  • ccnum - konsumatorit karta krediti numrin, VIZA vetëm, Master Card dhe American Express janë të mbështetur në këtë moment

  • klient i rregullt - emrin e pronarit kartë krediti

  • ddmhip - Adresa IP që i takon në server TGP komunikon me përbërës, IP adresa të server-xact E është aktualisht 204.239.214.212, dhe kjo është vlera e parazgjedhur e kesaj prone

  • ddmhpord - portin e serverit TGP, prona vlerës së prezgjedhur është 2609. Ndryshe nga pasuria e mëparshme, këtë pikë vlera e parazgjedhur në portin e testimit: e-xact shërbimet e mund të testohen duke përdorur këtë numër port. Pa regjistrim, ky port mund të përdoret për të dërguar kërkesën për autorizim dhe për të kryer transaksionin. Sistemi do të veprojë si në qoftë se shërbimi i plotë ishte thirrur, me dallimin e vetëm se nuk ka para transferimit të vërtetë do të kryhet. Pas regjistrimit në xact E-është përfunduar, numri i portit duhet të zëvendësohet me 2610, dhe funksionalitetin e plotë do të jetë arritur. bashku me pjesën tjetër të paketës, të dy numrat e kartës së kreditit inekzistente do të pranohen, dhe këto shifra mund të përdoret për të testuar sistemin.

  • skadimit - data e skadimit të kartës së kreditit, në mmyy format, ku mm qëndron për shifra mujore, numri dy, dhe vv qëndron për vitin shifra numrin e dy, dy shifrat e fundit të vitit janë përdorur, për shembull 0200 qëndron për shkurt, 2000.

  • shitës - numri 13-shifror që identifikon llogari në bankën tregtare themelor

  • merchantaddress - adresën fizike të shitës

  • merchantname - emri tregtar / titull

  • merchantcity - qyteti ku shitës është vendosur

  • merchantemail - e-mail adresë e të shitës

  • fjalëkalim - password që është e nevojshme të thirret transaksion. Për transaksionet e testimit, të përdorni "testl vlera" për këtë pronë. Pasi komponent është e regjistruar në xact E-, fjalëkalimi do të marrë.

  • terminal - e-numri tetë shifror që identifikon terminalit "", ky luan i përdoruesit emrin-tregtare në lidhje me serverat E-xact dhe fjalëkalimin e pajisur me pasurinë e mëparshme. Gjatë periudhës së provës, kjo pronë duhet te behet 66001047

  • transactiontype - ka katër lloje të transaksioneve në dispozicion: Blerje, kthim, PreAuthorisationPurchase dhe PreAuthorisation-PurchaseCompletion. Kjo tregon një lloj të pronës e cila është e angazhuar.

Blerje është transaksion tipik që u paraqit në fillim të këtij seksioni. Ky transaksion është i aplikueshëm në rast se mallrat që shiten janë të një natyre të tillë që ato të mund të merret nga konsumatori menjëherë (për shembull, për të shkarkuar programet, shërbimet e ndryshme, etj.) Pas autorizimit, paratë është menjëherë duke u transferuar në shitës të llogaritur. Kjo procedurë zakonisht njihet si kapjen e menjëhershme të transaksionit, për arsye të dukshme.

PreAuthorisationPurchase kryen me autorizim kontrolluar nëse konsumatori posedon para të mjaftueshme në llogari. Nëse paratë është i pranishëm, ai është i bllokuar përkohësisht, por jo të transferohet në shitës të konsideratë. Kjo teknikë është përdorur zakonisht kur mallrat janë blerë të transportohen për konsumatorin.

lloj PreAuthorisationPurchaseCompletion e transaksionit thirret një herë e konsumatorit ka marrë artikujt e blerë. Në atë moment, fondet e mbyllur janë transferuar nga konsumatori për të shitës të konsideratë. Ajo duhet të jetë e qartë se në kuadër të PreAuthorisationPurchaseCompletion ajo duhet të ekzistojnë të dhënat që transaksioni PreAuthorisationPurchase ajo i referohet, pra që transaksioni duhet të kompletohet. Për të zgjidhur këtë problem, komponenti autnum prona është lexuar nga PreAuthorisationPurchase, dhe se të njëjtën vlerë shumë është caktuar për komponent njëjtën pronë, vetëm para transaksionit PreAuthorisationPurchaseCompletion thirret.

kthimit rimbursim të transaksioneve të parave nga shitës për të konsumatorit konsideratë.

Çdo transaksion thirret me thirrje me metodën sendToServer. Para kësaj, të gjitha pronat e nevojshme duhet të jenë të vendosur të përshtatshme. Komponenti përmban funksionet shtesë të cilat janë përdorur për të kontrolluar të përpunimit të transaksioneve, dhe për t'u kthyer bankës së përgjigje në formë të projekt-ligjit për konsumatorin. Mëposhtme shembull VBScript tregon çështjet e shpjegoi deri tani. Pjesa e parë e shembull është një kod HTML qe paraqet formën e nevojshme për të hyrë në të dhënat në lidhje me transaksionin. Kodi HTML përmban shpjegime të shkurtër që nuk janë pjesë e trupit kodin.




Dostları ilə paylaş:
1   ...   10   11   12   13   14   15   16   17   18


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2019
rəhbərliyinə müraciət

    Ana səhifə