Primjer naloga, Shopware 6: Vlastite cijene za trgovce, od naloga do objave

Ovaj članak opisuje izmišljen, ali tipičan nalog. Tvrtka ne postoji, tijek odgovara načinu rada Eywora AI Crewa.

Polazna situacija

Proizvođač radioničke opreme vodi shop na Shopwareu 6.6. Dosad je prodavao privatnim kupcima i tvrtkama po istim cijenama. Sada trgovci nakon prijave trebaju vidjeti vlastite cijene: neto, oko 20 posto ispod cijene za krajnje kupce, s razredima od 10 i od 50 komada. Privatni kupci ne smiju ništa primijetiti. Vlasnik nema programera u kući i nalog opisuje u sučelju AI Crewa u tri rečenice, onako kako bi ga objasnio kolegi.

Korak 1: Razumjeti i procijeniti

AI voditelj tima rastavlja nalog i postavlja dva pitanja koja su u takvim projektima gotovo uvijek otvorena: tko odlučuje koji je kupac trgovac, i trebaju li se cijene za trgovce prikazivati neto i u košarici i na računu? Odgovor: aktivaciju vlasnik radi ručno u adminu, i da, neto posvuda. Agent za procjenu troškova unaprijed navodi grubi raspon za korištenje AI-ja u ovom zadatku. Zatim počinje rad na kopiji.

Korak 2: Najprije ugrađene mogućnosti

Agent za integracije i sustave najprije provjerava što Shopware 6 može sam od sebe, jer svaki redak vlastitog koda je redak koji se kod kasnijih ažuriranja mora održavati. Za ovaj nalog standard seže iznenađujuće daleko: nova grupa kupaca „Trgovci“ s neto prikazom, pravilo u Rule Builderu koje cilja tu grupu i napredne cijene na proizvodima koje to pravilo povezuju s cijenama po razredima. Budući da cijene vrijede za nekoliko stotina proizvoda, agent ih ne unosi ručno, nego putem Admin API-ja iz cjenika koji vlasnik isporučuje kao tablicu.

Ostaje jedna stavka: u listingu i na stranici proizvoda trgovci uz neto cijenu trebaju vidjeti napomenu „plus PDV, cijena za trgovce“, a kod cijena po razredima kompaktnu tablicu umjesto standardnog prikaza. Za to nastaje mali plugin koji proširuje zahvaćene Twig predloške bez kopiranja. Tako ostaje otporan na ažuriranja: ažuriranje Shopwarea ne prebrisuje datoteke plugina.

Korak 3: Provjera

Drugi agent pregledava kod plugina, agent za sigurnost i zaštitu podataka provjerava prikazuju li se cijene za trgovce doista samo prijavljenim trgovcima, i putem Store API-ja i u rezultatima pretrage. Automatski testovi zatim prolaze najvažnije putove: privatni kupac vidi bruto cijenu, trgovac vidi neto cijenu, razred se primjenjuje od 10 i od 50 komada u košarici, potvrda narudžbe ispravno iskazuje PDV, a postojeći checkout radi nepromijenjeno. Dizajnerica među agentima provjerava tablicu razreda na pametnom telefonu.

Korak 4: Pregled i odobrenje

Vlasnik dobiva poveznicu na pregled kopije i dva testna računa, jedan kao privatni kupac, jedan kao trgovac. Prolazi kroz narudžbu, primjećuje da tablica razreda na stranici proizvoda stoji predaleko dolje i daje tu povratnu informaciju. Agenti pomiču tablicu ispod cijene, testovi se ponovno izvode, drugi pregled se odobrava. Za nalog ove veličine vrijedi: opisano ujutro, isti dan spremno za testiranje; krug povratnih informacija dolazi uz to.

Korak 5: Objava

Na sljedeći dan objave, utorak, release-manager radi backup i uvodi plugin, grupu kupaca, pravilo i cijene. Promjena je dokumentirana u sustavu verzioniranja, s nalogom riječima vlasnika. Pokaže li se da neki trgovac ipak vidi bruto cijene, tim signundsinna vraća promjenu; dva vraćanja mjesečno su uključena. U ovom scenariju objava ostaje, a vlasnik isto poslijepodne aktivira prvih dvanaest trgovaca.

Što ovaj primjer pokazuje

Prava vrijednost nije u pluginu, nego u redoslijedu: najprije razumjeti, zatim iscrpiti ugrađene mogućnosti, zatim što manje vlastitog koda, zatim testirati, zatim odobriti. Taj redoslijed vrijedi za svaki nalog, i za male za koje se ponuda agencije nikada ne bi isplatila. Kako tijek s kopijom, backupom i rollbackom funkcionira u detalje, piše u članku Kopija, odobrenje, backup, rollback; podržane verzije Shopwarea navodi popis sustava.

← Na blog