Infrastructure for Electronic Business on the Internet
Figura A.54 tubacionit të Produktit: grup tipik i fazave
Yüklə 5,92 Mb.
|
- Bu səhifədəki naviqasiya:
- Figura A.55 Struktura e Planit të tubacionit
- Figura A.56 Blerje tubacion
- A.5.10 The OPP Komponentet të Këshillit të Ministrave të përfshira në paketë SSCE
- A.5.10.2 Komponenti per Informacion Produkt Faza
- SELECT * NGA Produkt KU = SKU " DHE Emri LIKE%%
- A.5.10.3 DefaultShopperlnfo Komponenti per Informacion Shopper Faza
- A.5.10.4 initialization Rendit Faza
- A.5.10.5 Kontrollo Rendit Faza
- A.5.10.7 Çmimi Rregullo Faza Item
- ConditionOrderKey = ConditionOperator SKU = ConditionValue = = 123
- A.5.10.8 Rendit Rregullo Faza
- A.5.10.9 Nëntotali Faza e Rendit
- A.5.10.10.1. Fixed Shipping Komponenti
- A.5.10.10.2 LinearShipping Komponenti
- A.5.10.10.3 TableShippingADO Komponenti
- 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
- A.5.10.13 Rendit Gjithsej Faza
- A.5.10.14 Inventari Faza
- A.5.10.15 Faza Kontrollo Blerje
- UPDATE prod_table inventory_field SET = inventory_field KU SKU =
- A.6 Automatik Credit Card Payment Brenda ASP Aplikime
- A.6.1 Instalimi i Komponenti Procesi
- : \ \ system32 \ inetsrv \ komponentët Pastaj, në komandën e shpejtë, shtypni : regsvr32 ExactAXl.ocx
- A.6.2 Përdorimi i Komponentit
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:
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.
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:
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.
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.
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:
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ë.
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:
_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ë:
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.
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ë:
- 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:
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ë:
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:
Ë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:
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ë:
Këto janë hapat e nevojshëm për të kryer, në mënyrë që të kryejnë transaksionin e pagesës:
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: 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:
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. Yüklə 5,92 Mb. Dostları ilə paylaş:
|