O Prestashopu

Link: http://prestahost.eu/prestashop-modules/cs/home/32-bankovni-prevod-plus.html

K tvorbě  modulu Bankovní převod PLUS  mě přivedla rada kterou jsem na?el na jednom fóru. Její smysl zhruba v tomto smyslu: "Zalo? si účty u různých bank,  platba bude téměř okam?itá a peníze bude? mít pod kontrolou". 

Pochopitelně nabízet platbu na více platebních účtů není tak úplně ekvivalent platební brány, minimálně z toho důvodu ?e připsání plateb je nutno ručně kontrolovat. Nicméně pokud je  kontrola toku peněz pro Vás prioritou, modul určitě vyu?ijete.

Hlavní funkce modulu:

• libovolný počet účtů mezi kterými lze vybírat ji? na stránce s platbou
• vazba na dopravce (případně zákaznickou skupinu,  nebo měnu) individuálně pro jednotlivé účty
• mo?nost  předposlední stránku objednávky buď přeskočit nebo na ní vypsat podrobný souhrn, podobně jako to umí modul Dobírka plus
• mo?nost zakázat modul (resp. konkrétní účet) pokud nějaký produkt v ko?íku není skladem

Podrobný popis funkcí najdete na stránce modulu, vyzkou?et si jej pak mů?ete na demu .

Link: http://world-trek.cz/cs/

Cestovní kanceláře a? na výjimky potřebují specializované software. Častou slabinou těchto ře?ení je poněkud příli? standardní a omezená funkcionalita webové prezentace nabídky.  S jedním klientem jsme se dohodli ?e ře?ením by mohlo být právě propojení s Prestashopem proto?e

• prestashop má sám o sobě velmi dobré mo?nosti grafické prezentace produktů
• PS je velmi dobře roz?iřitelný a modifikovatelný
• strukturovaná databáze PS a zabudovaný CSV import zjednodu?í propojení externím software
• existují tématické PS ?ablony zaměřené na prodej zájezdů

Na výsledek se mů?ete podívat zde

Import/Export do externího software zajistil personál klienta, tj. k tomu se nemohu vyjádřit. Jinak ale bylo úprav na straně PS potřeba relativně málo

• přidat do detailu dal?í pole vyu?ívaná externím software (např. "Rozsah slu?eb"  nebo datumy odjezdu a příjezdu)
• doprogramovat vyhledávání zájezdů podle data
• nasadit modul blogu
• a pár dal?ích maličkostí

Je?tě to není zřejmě v?e, v plánu je např. instalace modulu pro nahrávání dokladů do administrace klientů, ale i tak mohu říci ?e mě příjemně překvalila relativní snadnost se kterou se PS podařilo na web cestovní kanceláře adaptovat.

Zbo?í.cz se na přechod na nový formát připravovalo opravdu důkladně - s předstihem jej oznámilo, publikovalo specifikace, zprovoznilo validátor. Proto jsem svůj modul pro export zbo?í do srovnávačů mohl s předstihem připravit ji? na podzim minulého roku. A také jej v klidu testovat, proto?e někteří moji klienti pře?li na nový feed je?tě před jeho oficiálním uvedením do provozu.

Nicméně chybička se vloudila - zapoměl jsem na staré verze prestashopu. Tak?e kdy? tento týden pře?lo zbo?í na novou specifikaci, začali se mi ozývat majitelé star?ích verzí PS a modul pro export do srovnávačů jsem musel narychlo upravovat.

Pokud se Vás tento problém také týká tak situace je momentálně taková:

modul je funkční pro PS 1.4

výsledný feed  projde validátorem pro nový formát

lze mapovat kategorie pro zbo?í i heureka

lze exportovat dopravce pro heureku

 Funkcionalita je k dispozici od verze modulu 3.10

Od verze 1.5 začal Prestashop objednávky označovat písmeny. To má určitou logiku, ale např. pro bankovní převod se řetězec jako variabilní symbol pou?ít nedá. Proto se rychle objevily moduly které to ře?í, nejoblíbeněj?í z nich je asi modrefchange .  S modulem jsem se trochu trápil (v kombinaci s dobírkou zdvojoval zobrazenou cenu objednávky v administraci) ale po men?ích úpravách jej pou?ívám na hostingu zcela bez problémů ji? několik let.

Během posledních 10 dnů jsem ale ře?il dva případy nefunkčních objednávek daných asi kombinací modrefchange s podobným modulem order_ref (change order reference free od prestapoint).  V prvním případě se jednalo o externí eshop kam si majitelka iniciativně oba moduly nahrála sama.

Příznaky:

- objednávka nejde dokončit (bílá stránka)

- v error logu hlá?ka "premature headers end"

- v administraci jsou oba moduly instalovány (nemyslím ?e musí být nutně povoleny)

Popravdě jsem to příli? nezkoumal, je mo?né ?e modrefchange je v tom "nevinně", tj. nemusí být nainstalován a stačí pouhá přítomnost "order_ref". Spí?e to ale bude ta kombinace,  nezdá se mi ale pravděpodobné ?e by někdo uvolnil modul s tak zásadní vadou.  V ka?dém případě, pomoc není slo?itá.  Odinstalovat oba moduly, přes ftp se přesvědčit ?e zmizel soubor /override/classes/Order.php, případně jej smazat. Smazat /cache/class_index.php . Poté znovu nainstalovat jen jeden z modulů.

Pokud se obchodník stane plátcem DPH, obvykle nechce zvedat ceny. Proč by to také dělal,   sám nakupuje bez DPH, respektive si DPH odečte.  Nasadit ke v?em produktům DPH a přepočítat a poní?it jejich cenu lze hromadně a celkem snadno.  V postupu ní?e předpokládám ?e máte přístup do databáze přes phpMyAdmin, předponu tabulek ps_, nepou?íváte multishop a máte jen jedno daňové pravidlo s číslem 1.

1) V phpMyAdmin si v zálo?ce Export odzálohujte tabulky

ps_product

ps_product_shop

ps_product_attribute

2) Tamté? v zálo?ce SQL proveďte dotazy:

UPDATE ps_product SET price=(price * 0.82644628), id_tax_rules_group=1;

UPDATE ps_product_shop s LEFT JOIN ps_product p  ON p.id_product=s.id_product AND s.id_shop=1 SET s.price=p.price, s.id_tax_rules_group=p.id_tax_rules_group;

 UPDATE ps_product_attribute SET price=(price * 0.82644628);

UPDATE ps_product_attribute_shop s LEFT JOIN ps_product_attribute p  ON p.id_product_attribute=s.id_product_attribute AND s.id_shop=1 SET s.price=p.price;

Sám jsem to v poslední době dělal u několika hostovaných eshopů, problémy nebyly a ceny sedí přesně. Pouze pou?ívám jiný nástroj pro práci s databází, ale to by mělo vliv jen pokud by se něco zkazilo a bylo potřeba změny vracet.