Keskustelu: Nettisivujen teko: Verkkokaupan tuotteiden päivämäärä sidonnainen saatavuus

Moi

Olen tässä pyöritellyt hajatelmia, että miten toteuttaisin sellaisen tuotteen/verkkokauppatoiminnon, jolla saatavuus sidotaan tiettyyn päivämäärään taikka ajanjaksoon.

Esim. vuorokaudessa voi olla tarjollla 20 tuotetta tai vkloppuna 40 tai lauantaisin 10.

Yksinkertaisesti ajattelin, että kannassa voisi olla taulu, jossa on sarakkeet:

tuoteid,päivämäärä_tai_ajanjakso,rajoitus,saatavuus,käytetty,varattuna,saatavilla,loppu,

Käytännössä, kun selataan tuotesivua, niin silloin haetaan kannasta ko. tuotteelle pvm-kohtaiset rajoitteet ja saatavuus (siis vain alkuperäisestä saatavuudesta poikkevat, kun eihän sinne kantaan laiteta joka vuorokaudelle/ajanjaksolle automaattisesti saatavuutta).
Nuo loppu ja saatavilla ovat lähinnä helpottamaan/nopeuttamaan tarkistusta/hakua.
Tuotteita ei voi ostaa menneisyyteen, joten käytetään tuoteid lisäksi nykypvm suodattimena haussa(>=nykypvm).
Näistä on siis tarkoitus tehdä kalenterivalinta, jossa on esim. vihreä, keltainen ja punainen indikaattorit sekä lukumäärä.

Tuotteita on arviolta 300 ja käytännössä ainakin 3-4kk ajanjakson päähän saatavuustietoja eli 30*4*300 eli 36 000 riviä ts. ei palio paskakaan.

Ja tilauksen jälkeen sitten joko luodaan uusi rivi ko. pvm tai päivitetään olemassa olevaa (tilattu siis jo aiemmin).

Kannattaako tämmönen iteroida vai onko jo nyt havaittavissa ongelmia horisontissa?

Kannattaisi kirjoittaa auki myös se, mikä on lähtökohtainen ongelma, ei vain sitä, kuinka sen on ajatellut ratkaista. Ratkaisusi voi olla paitsi huono niin myös täysin väärä, vaikka näyttäisikin ihan hyvältä. En usko, että olisit muuten vain päättänyt, että kaupassa täytyy tarjontaa rajoittaa eri päivinä poikkeamaan todellisesta varastosaldosta.

Niin siis tilaajan tulee valita haluamansa ts. saatavilla oleva pvm, kun tilaa tuotetta.Pvm on ikään kuin tuotteen ominaisuus ja varastosaldo.

Tällä halutaan
1) estää "ei oo" myynti,
2) näyttää tilaajalle, että onko saatavilla ja paljonko, mikäli on tilaamassa useamman kuin yhden ja
3) ylipäätään mahdollistaa pvm-kohtainen rajoitus.

Vastasikos tämä kysymykseen? Vai mitenkä tuo lähtökohtainen ongelma tulis kuvata?

Jos et halua myydä ei oota, eikö olis vain helpoin rajoittaa maksimi tilausmäärä sen hetkiseen varastosaldoon, mistä myöskin tilaaja näkee paljonko tuotteita on saatavilla.

Jos haluat kertoa paljonko tuotteita on mahdollisesti tulossa lähitulevaisuudessa, kerro se erikseen, elä sotke sitä varastosaldoon ja rajoituksiin. Sitäpaitsi myyt ei oota, jos olet rajoittanut tämän päivän myynnin 20 tuotteeseen ja sait tehtyä vain 15 tuotetta.

Miksi haluat vuorokausi kohtaiset myynnin rajoitukset? Mitä hyötyä kuvittelet sillä saavuttavasi?

Kyse ei ole varsinaisesti omasta halusta / tarpeesta vaan yhteisön eli "tuotteet" ovat yhteisön "tuottamia".

Tuotteet ovat myöskin digitaalisia, joten varsinaista tuotantoa taikka varastoa ei ole.

Ehkä ongelman lähtökohtaa kuvaa parhaiten se, että samoja tuotteita myydään muuallakin.
Eli yhteisön jäsenellä voi olla yhteensä 20 kpl saatavilla per pvä, mutta haluaakin tässä yhteydessä tarjota niistä vain 10, jottei tule päällekkäisyyksiä muiden "myyntikanavien" kanssa.

Olikos tästä apua hahmottamaan ongelmaa?

Multibyte kirjoitti:

Olikos tästä apua hahmottamaan ongelmaa?

En näe mitään ongelmaa. Tuon voi toteuttaa vaivattomasti ihan millä tahansa tavalla vaan mikä "ylläpidon" eli saatavuustietojen syöttämisen kannalta on helpointa. Ehkä ei kannata hirveän monimutkaista systeemiä tehdä jos sille ei oikeasti ole tarvetta. Olen itse esimerkiksi tehnyt varausjärjestelmän jossa pystyi määrittämään viikonpäivittäin toistuvia aikoja ja kuinka paljon etukäteen ajat voi varata. Silti 99% käyttäjistä halusi määritellä ajat viikko kerrallaan.

Sinänsä kun kyse on digitaalisista tuotteista, niin tuntuu turhalta edes laittaa mitään varastosaldoa, koska digitaalisia tuotteitahan voi lähtökohtaisesti monistaa rajattomasti. Arvelen kuitenkin että tässä on kyse pikemminkin joidenkin tilien saldoista mitään myydään.

Näin näillä digituotteilla on kuitenkin vahva sidonnaisuus tosimaailman kanssa, joten siksi niille pitää asettaa rajoitus.

Sen tiedän jo nyt, että tuolle grezin mainitsemalle ns. suunnitellusta poikkeamiselle ei ole tarvetta.
Saatavuus muuttuu lähtökohtaisesti vuosittain, jos silloinkaan. Mahdollisesti jokin sesonkiaika voi vaikuttaa saatavuuteen ja sellainenkin on suhteellisen helppo lisätä jälkikäteen, jos vaikuttaa siltä, että sellaiselle olisi oikeasti kysyntää.

Ajanvarausten yhteydessä on aina kyse kahden eri instanssi sitoutumisesta varattuun resurssiin eli tapaamisajankohtaan.
Omassani ei ole tätä kahdensuuntaista "ongelmaa" ja vain tuotteen tilaaja ns. sitoutuu.

Tarkoitus on tosiaan tehdä hyvin yksinkertainen ylläpito. Pinnan alla voi sitten tapahtua ihmeitä...

Ja pätkä offtopicia tähän eli mitä nyt olen joskus yrittänyt assiakkaille jotain toimittaa, niin homma on yleensä kaatunut siihen, kun eivät osaa kertoa, että minkälaisen haluavat ts. miten se tukisi heidän toimintaa. Vastaavasti jos tarjoaa jotain mutulla, niin ei tietenkään kelpaa.

Mutta niinhän se on, että sitä saa mitä tilaa. Jos tilataan tilausjärjestelmä, niin ei riitä, että tilataan "tilausjärjestelmä y tuotteille".
Olen yrittänyt selittää asiaa itselleni siten, että tietotekniikasta mitään tietämättömät yli keski-ikäiset olettavat tietokoneen tekevän kaikkea mahdollista kuin itsestään vaikka todellisuudessa se ei tee yhtään mitään ellei sitä käsketä eli ts. ohjelmoida. Ja lopulta kun esittää kenties assiakkaille kysymyksiä heille itsestäänselvistä asioista, niin pidetään jotenkin tyhmänä tms. kun ei tajuta, että myynnissä on tasan yhtä monta tapaa kuin on tekijäkin.

Tästä tulikin mieleeni eräs tapaus, joka myy verkossa sellaisilla 20-40 e tilauksia.
Hän välttämättä haluaa laskuttaa kaikki tilaukset eikä tarjota verkkopankkimaksuja.
Tämä siitä syystä, että maksutoiminnoista tulee kustannuksia.
Koitin sitten sanoa, että maksat tällä hetkellä 50€ / palvelimesta, jonka saisi alle 10€ /kk ja sillä säästöllä kattaisi verkkopankkikulut sen lisäksi, että kaikki laskutukseen ja sen seurantaa menevä aika ja raha säästyisi ja toimitus voisi nopeutua, kun maksu näkyy tyypillisesti heti tilillä tai ainakin siitä saadaan vahvistus.
Mutta ei.

Eli tapoja on monia.

Vaikea neuvoa tietämättä tarkemmin tuotteiden laadusta, mutta jos ne sattuvat olemaan lippuja jonkinlaisiin tilaisuuksiin tai esityksiin, niin suosittelisin, että jokainen "näytös" olisi oma tuotteensa. Asiakkaita kuitenkin luultavasti kiinnostaa saapua juuri valitsemanaan ajankohtana. Eli sinulla olisi prototyyppituote, jota vain kopioisit varsinaiseen tuotetauluun esim. kahta viikkoa ennen näytöstä. Tämäntapaisen järjestelmän hallinnoiminen on helpompaa kuin kaiken pitäminen yhdessä taulussa.

Mikset vaan lisää sarakkeita myynnin alku ja loppupäivämäärille per tuote? ja mikäli kuluva päivä on kyseisen aikajakson sisällä, tuote näkyy myynnissä.
Jos tuotteita on myynnissä tietty erä, lisää myös varastosaldo. Jos tuote taasen on uniikki, esimerkiksi taideteos, lisää sille oma tietonsa jolloin tuotetta voi ostaa vain kerran.

Eli:

Saatavuus alken ja päättyen - jos ei asetettu tuote on jatkuvassa myynnissä, jos taasen asetettu näkyvyys aika-alueen mukaan
Varastosaldo (kpl määrä) - Jos tätä ei aseteta tuotteessa ei ole kappalemäärärajoituksia. Jos asetettu, tuote pysyy myynnissä saldon mennessä nollaan.
Uniikki - Jos tämä on asetettu, tuote voidaan myydä vain kerran jonka jälkeen poistuu myytävien tuotteiden joukosta itsestään.

Hmm, mun pitänee vielä hieman kirkastaa tätä ajatusta sekä itselleni että teille.

Yritän tässä nyt vielä kääntää asian voitoksi.
Eli kyseessä on siis "tuote", jolle ei varsinaisesti ole varastosaldoa.
Tuotteen saatavuus on vain sidottu esim. arkipäiviin, vknloppuun, jopa jokaiselle viikon päivälle erikseen tai aikavälille.

Käytännössä tuotetta on siis saatavilla ikuisesti, mutta kuitenkin rajoitettu määrä per ajankohta. Ei siis lähtökohtaisesti ole loppu ja alkupvm vaan on vain tietty rajoitus ja saatavuus ikuisesti. Sille ei voi myöskään luoda kantaa, koska se paisuisi "äärettömyyksin".

Sen, joka laittaa tuotteen myyntiin, tarvitsee vain määrittää rajoitusmäärä(t) ja siihen haluamansa rajoitusaika: arkipäivät, viikonloppu, viikko, kuukausi tai sitten pvm/aikaväli.

Tämän jälkeen kannassa on siis merkinnät rajoituksista ja tilausten kertyessä kulutuksen mukaan tulee joko uusi rivi kantaan tilauksessa määritetylle ajankohdalle tai sitä vastaavan rivin "saldoa" vähennetään.
(Alkusaldo luodaan dynaamisesti 1. tilauksen yhteydessä.)

Tällä tavoin kanta saadaan pidettyä mahdollisimman pienenä. Samalla se mahdollistaa hyvin yksinkertaisen tavan ladata esim. kalenterivalitsinta varten jsonia, jossa on rajoitustiedot sekä saatavuustiedot niistä ajankohdista, joille kohdistuu tilauksia ja loppu kalenterin voi olla ns. oletusvihreällä (täysi saatavuus).

Ja vielä tähdentäisin sitä ajatusta, että tässä ei ole sitä kahdensuuntaista sitoutumista kuten on ajanvarauksessa taikka näytöksessä.
Tässä ei siis voi eikä tarvitse ennakoida. Tuotetta on saatavilla tästä hetkestä ikuisuuteen, mutta vain rajoitusta vastaava määrä per rajoituksessa määritetty ajankohta.

Evot, kai mää vaan teen tämän katon mitä siitä tulee...