Wat jullie moeten weten over dit project. Het betreft een webwinkel welke wordt ontwikkeld voor de verkoop, code blijft in eigen beheer en word door mij gehost.
De beheerder
Ik probeer het zo in te richten dat de eigenaar (beheerder) alleen maar data hoeft in te voeren. Om de webwinkel te activeren dient de beheer minimaal 1 account te hebben bij sisow, targetpay en / of mollie.
De bezoeker
Bezoekt de webwinkel -> bekijkt een product (of niet) -> Voegt het product toe aan basket (of niet) -> Uitchecken (of niet) -> laatse fase systeem: controlles uitvoeren (opgehaalde data) en de betaling klaarzetten (data invoeren en data updaten (opgehaalde data)).
de webwinkel
Tabellen (relevant):
-winkelmand; houd alle toegevoegde producten 7 dagen vast gekoppeld aan IP.
- bestelling: record uit winkelmand met corresponderende ID gaat naar tabel bestelling met status 'open'.
de technieken
php 5 procedurele code structuur (sorry). en voor de betalingen wil ik deze schil gebruiken (credits @ Barry - fruitcake.nl) van THE PHP LEAGUE: https://github.com/thephpleague/omnipay
Nogmaals ik heb geen ervaring met het afhandelen van betalingen alle suggesties en vraagtekens adhv van mijn blauwdruk (schets) is meer dan welkom.
en voor de betalingen wil ik deze schil gebruiken (credits @ Barry - fruitcake.nl) van THE PHP LEAGUE.
Welke schil is dit? (link ontbreekt) Omnipay?
Dan denk ik dat je minimaal 3 tabellen nodig hebt voor het bijhouden van informatie omtrent bestellingen:
orders: kapstok voor orders
order_regels: de producten en aantallen en prijzen op het moment van bestelling
transacties: alle informatie over het doen van een betaling voor order X, bevat tevens de status van de betaling
Overigens kun je in een aantal losstaande scripts een betaalmethode testen in test-modus, dit kan los van andere (procedurele) code. Indien een betaalsite informatie terugstuurt naar jouw site dan moet dit laatste ook mogelijk zijn, oftewel, je testsite moet bereikbaar zijn via het internet, je kunt betaaloplossingen dan ook niet echt goed ontwikkelen vanaf je lokale machine ("localhost"). Het internet kent jouw "localhost" niet, tenzij deze niet achter een firewall zit (DMZ) of poorten doormapt en je een hostname hebt of een extern IP doorcommuniceert.
Omnipay gaat er ook prat op dat deze goed gedocumenteerd is, dus ik zou zeggen: lees en volg de handleiding - heb je dit al geprobeerd?
Link is toegevoegd. Mijn webwinkel staat online (testen is dus mogelijk - maar daar ben ik nog niet aan begonnen).
Waarom tabel order_regels en transacties niet samenvoegen ?
en voor de geïnteresseerde een link naar de uitgever met een aantal voorbeelden en instructies: http://omnipay.thephpleague.com/
Thomas - 28/04/2016 15:47 (laatste wijziging 28/04/2016 15:48)
Moderator
Citaat:
Waarom tabel order_regels en transacties niet samenvoegen ?
order_regels bevat informatie waar een order inhoudelijk uit bestaat.
Dit heeft niets te maken met de status/informatie van een (betalings)transactie.
Als er al een verband zou zijn tussen de twee dan is dit via de orders tabel (en dus niet de order_regels tabel).
Als je dit soort dingen modelleert kun je de volgende "truuk" gebruiken: identificeer de verschillende "spelers" (entiteiten) in je applicatie en schrijf de verbanden uit in lopende zinnen, bijvoorbeeld:
Een klant plaatst een order (bestelling).
Een order bestaat uit orderregels.
Een klant verricht na afloop een betaling(stransactie).
Een betaling(stransactie) hoort bij een order.
et cetera
Maak vervolgens een tekeningetje (diagram) waarbij je deze entiteiten uitschrijft en met elkaar verbindt via lijnen als hier een relatie tussen is. Je hebt dan een (zij het wat abstracte) specificatie voor je databasediagram.
Zorg er ook voor dat je de functionaliteit van een relationele database kunt gebruiken. Hiervoor moet je in MySQL gebruik maken van de InnoDB database-engine. Dit stelt je in staat om foreign keys en database-transacties (dit heeft niets met de transacties-tabel te maken overigens) kunt gebruiken zodat je administratieve data in een strak keurslijf komt te zitten waarmee je af kunt dwingen dat de data in deze tabellen consistent blijft.
Winkelmand Bestelling Betaling log
ID (ai) != ID (niet ai) == ID (niet ai)== ID (niet ai)
IP == IP == IP == (geen ip)
status == status == status == status
Bedrag != bedrag == bedrag == bedrag
datum != datum == datum == datum
De tabel bestelling zou uiteen moeten vallen in wat jij beschrijft (kortingscode, totaalkorting, bedrag (ex of incl btw), factuur- en bezorgadres) maar alles wat over producten inhoudelijk gaat zou ik opnemen in een aparte tabel (de order_regels). "aantal producten" lijkt mij niet echt relevant? En als je dit nodig hebt is dit makkelijk afleidbaar uit de order_regels tabel. Productinformatie hoort ook in je database thuis lijkt mij. Je zou je winkelmand op kunnen slaan in je database, maar deze zou je ook (tijdelijk) kunnen bijhouden in iemands sessie?
Ik zou alle tabellen, behalve koppeltabellen wellicht, voorzien van een auto_increment veld. Dit geeft je namelijk altijd een middel om op een unieke manier aan een record te refereren.
Heb je trouwens ook nagedacht over de volgende zaken:
- voorraadbeheer, hoe zorg je ervoor dat men niet (veel) meer bestelt dan dat er op voorraad is?
- productinformatie (dit zal ook een beetje afhangen van de grootte van je assortiment) hoe zorg je ervoor dat je de producten makkelijk kunt zoeken en vinden in je webshop?
Als dit je eerste schreden zijn met betrekking tot database-ontwerp / het programmeren van een grote applicatie dan weet ik trouwens niet of dit de beste plaats is om hiermee te starten. Maar je kunt dit altijd proberen natuurlijk. Wel komen hier (webshop) een heleboel zaken bij elkaar.
Het is iets wat groter geworden dan ik wilde. mijn idee was om een 1-product webwinkel te ontwikkelen. Maar ik hou het relatief klein.
Max 6 cat's (geen sub-cat!) en max 10 producten per cat. Ik denk dat mijn eventuele doelgroep winkeliers (fysieke) geen zin hebben om het hele assortiment aan te bieden. Op deze wijze hoeft ik bijvoorbeeld geen pagina-navigatie voor categorieën, geen fulltext search engine want alles is direct te navigeren vanuit de index etc.
Maar hoe ziet het volgende er dan uit:
Als een bezoeker wat in zijn winkelmand stopt (tabel: winkelmand ID + 1) maar vervolgens geen verdere actie onderneemt. Volgens jouw suggestie krijg je dan dus dat een volgende bezoeker die wat in zijn winkelmand stopt bijv het ID 10 heeft, en het corresponderende betaling ID 5 ?
Als een bezoeker wat in zijn winkelmand stopt (tabel: winkelmand ID + 1) maar vervolgens geen verdere actie onderneemt. Volgens jouw suggestie krijg je dan dus dat een volgende bezoeker die wat in zijn winkelmand stopt bijv het ID 10 heeft, en het corresponderende betaling ID 5 ?
Ik snap niet precies wat je hiermee bedoelt. Je zult op een of andere manier een gebruiker moeten identificeren en koppelen aan de winkelmand op het moment dat deze boodschappen in zijn winkelmandje doet als je deze winkelmanden in de database opslaat. Zoals ik het zie is de inhoud van een winkelmandje nogal tijdelijk van aard. Een sessie zou dan ook een geschiktere plaats zijn voor een winkelmand dan een database. Hoe houd je anders bij:
- of de inhoud van winkelmanden die in de database staan opgeslagen nog actueel is (hoop outdated rotzooi in je database? nein danke)
- van wie deze winkelmanden zijn, er moet dan een soort permanent verband zijn met een gebruiker, een koppeling via een sessie (die kan verlopen) gaat dan niet echt meer, je zou dan mensen eerst aan moeten sporen om een account te maken en in te loggen ofzo?
index.php
../bezoekers/winkelmand (request-method=POST header naar betalen)
../bezoekers/betalen (header naar de betaalpagina (mollie)).
../Toevoeging/Functies/Betaling/Mollie/API/betaling (haalt gegevens op (controleer) en header naar externe pagina van mollie).
../Toevoeging/Functies/Betaling/Mollie/API/Webhoop (mollie bezoekt mij URL - update status betalling).
../Toevoeging/Functies/Betaling/Mollie/API/return (bezoeker komt terug van betaalscherm) header naar /Bezoekers/ontvangen/id
../bezoekers/ontvangen (hier weergeef ik de melding van betaling).
index.php
../bezoekers/winkelmand (request-method=POST header naar betalen)
../bezoekers/betalen (header naar de betaalpagina (mollie)).
../Toevoeging/Functies/Betaling/Mollie/API/betaling (haalt gegevens op (controleer) en header naar externe pagina van mollie).
../Toevoeging/Functies/Betaling/Mollie/API/Webhoop (mollie bezoekt mij URL - update status betalling).
../Toevoeging/Functies/Betaling/Mollie/API/return(bezoeker komt terug van betaalscherm)header naar /Bezoekers/ontvangen/id
../bezoekers/ontvangen (hier weergeef ik de melding van betaling).
Enigsinds lastig was het feit dat ik toch IP gebonden ben gaan werken in mijn DB tabel en daar de gegevens permanent opsla, was even tricky om de scheiding te maken als mensen al betaalt hebben maar nog een keer iets bestellen.
enfin, alles werkt (in test modus) DB wordt netjes bijgewerkt, winkelmand wordt goed bijgewerkt.
Het enige wat niet werkt, klinkt heel lullig is het rekenwerk.
Ik las in jouw PHP variable tutorial dat niet elke float zich gedraagt zoals je zou verwachten.
Volgens mij is dat in mijn winkelwagen-afreken weergave hetzelfde probleem, de ene keer gaat het rekenen (plus, min, keer) wel goed, andere keer blijkbaar niet. Formaat van de bedragen is altijd 100.00 of 10000.00, ik laat de prijs met rust in de DB, voor de weergave gebruikt ik uiteraard number_format() maar ook als ik prijzen opsla in de DB zorg ik dat de prijzen "schoon" zijn.
Je kan producten toevoegen, zodra het bedrag niet rond is (op EUROs) dan zie je in de rechter kolom dat de cumulatieve prijs van de regel producten niet goed wordt verwerkt.
Enig idee ?
Thomas - 11/05/2016 00:33 (laatste wijziging 11/05/2016 00:33)
Moderator
Dat kan ik zo niet zien aan de buitenkant.
Waarom sla je niet alles op in eurocenten (kun je integers gebruiken in plaats van floats)? Dan hoef je ook niets af te ronden. En het formatteren doe je dan met number_format() vlak voor het weergeven. Dan hoef je ook helemaal niets aan de bedragen aan te passen?
<?php
$bedrag = 10002; // 100 euro, 2 cent, oftewel 10002 eurocenten
// een functie voor het formatteren van een bedrag is wellicht wel handig
function formatBedrag($in) {
// alleen bij WEERGAVE deel je door 100
return number_format($in/100, 2, ',', '.');
}
$som = $bedrag * 3; // niks geen lastige functies, gewoon rekenen in PHP
echo formatBedrag($som);
?>
Dat kun je ook nog opvangen door enkel numerieke-invoer te accepteren.
Thomas - 17/05/2016 14:53 (laatste wijziging 17/05/2016 14:56)
Moderator
Inderdaad, wat @JointJeff zegt, dat kun je op een andere plaats en manier oplossen. Dat zou niet tot gevolg moeten hebben dat dit je hele dataset in een bepaalde weergavevorm dwingt waarmee je alleen op een uiterst onhandige manier mee kunt rekenen...
Zoals ik al aangaf, als iemand een bedrag moet invoeren kun je dit desnoods splitsen in twee aparte formuliervelden (euro's en centen). Wanneer je deze data submit maak je hier één bedrag van (in eurocenten):
bedrag = euro's * 100 + centen
Overigens als je verder wilt discussiëren over dit topic, verwijder dan svp de opgelost-markering via het oorspronkelijke bericht.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.