Idea Phoca Cart

To je ve VM řešitelné jedině tak, že ignoruju způsob platby a zavedu dobírku přímo do způsobu dopravy, tak definuju způsoby dopravy jako ČP (70) a ČP na dobírku (90) a PPL (90) a PPL na dobírku (130)

To je asi nejrozumnější cesta. Proč by to nefungovalo s paypalem? Prostě se přidají další dva způsoby:
čp předem 70
čp na dobírku 90
ppl předem 90
ppl na dobírku 130
čp paypal 70
ppl paypal 90


Všeobecně jsou zde limity - doprava se vybírá před platbou a ne naopak, to by taky mohlo skončit nekonečným cyklem: vyberu dopravu a na základě dopravy se mi změní podmínky platby, vyberu platbu a na základě platby se mi změní podmínky dopravy, a takto pořád dokola.

Řešením může být zpoplatnění platby:
čp 50
ppl 70

vyberu čp a zobrazí se mi dvě platební metody:
na dobírku + 20 (celkem 70)
předem + 20 (celkem 90)

Ovšem to už může být celkem zmatečný jak pro nakupujícího tak pro prodejce, protože do toho ještě může vstoupit DPH. Zkusím se na to podívat, ale jestli to jde vyřešit prvním způsobem, bylo by to pro všechny strany přehlednější :idea:

Každopádně vazba doprava x platba by asi měla existovat. Příklad:

V administraci nastavím, že platba A se zobrazí jen u dopravy A a platba B jen u dopravy B, platba C se zobrazí u všech možných doprav.

Tedy návaznost:
- uživatel vybere stát ČR, zobrazí se mu doprava pro ČR a na tu dopravu bude navazovat platba, která bude uzpůsobena dopravě.
- pokud vybere stát Slovensko, zobrazí se jiná doprava a na tu může být navázána jiná platba, popř. platby

Otázka je zda komplikovat systém, který má být co nejjednodušší a zavést poplatek za platbu (+ jeho možné DPH)? Nebo prostě tyto poplatky řešit ve více variantách dopravy?

H13 napsal: Otázka je zda komplikovat systém, který má být co nejjednodušší a zavést poplatek za platbu (+ jeho možné DPH)? Nebo prostě tyto poplatky řešit ve více variantách dopravy?

To je asi ta nejpodstatnější otázka, z mé zkušenosti to ale provozovatelé eshopů vyžadují. Jak píšete, řešitelné to je vše na úrovni dopravy, ale pak je v podstatě způsob platby k ničemu, degraduje se na pouhou jedinou volbu a z hlediska přehlednosti by pak bylo skoro lepší ho tam nemít a dopravu nazvat "doprava a platba". Při větším množství dopravců (řekněme ČP, PPL a osobní odběr) a větším množství plateb (dobírka, na účet, PayPal a např. GoPay) to však udělá poměrně velké pole možností, které bude pro zákazníky poněkud matoucí (zde by to bylo 12 kombinovaných možností místo tří doprav a následně 4 plateb). Kvůli osobnímu odběru navíc musíte vymýšlet název způsobu platby dobírkou, tak aby nepůsobil nepatřičně

Nekonečný cyklus by hrozit neměl, protože při výběru platby by mi již systém měl nabídnout jen ty způsoby, které odpovídají filtrům. Tj. pouze ty, které odpovídají zvolenému způsobu dopravy. Při případné následné změně dopravy by stačilo jen odkontrolovat, zda zvolený způsob platby je v povoleném seznamu a pokud ne, zachovat se jako při prvotní volbě (nezvolit žádný, případně zvolit první / výchozí apod.)

Nekonečný cyklus by hrozit neměl, protože při výběru platby by mi již systém měl nabídnout jen ty způsoby, které odpovídají filtrům. Tj. pouze ty, které odpovídají zvolenému způsobu dopravy. Při případné následné změně dopravy by stačilo jen odkontrolovat, zda zvolený způsob platby je v povoleném seznamu a pokud ne, zachovat se jako při prvotní volbě (nezvolit žádný, případně zvolit první / výchozí apod.)

No myslel jsem to jako závislost obou dvou navzájem, což by byl problém, pokud vybereš dopravu, podle ní se uzpůsobí platba, pokud by ale byla doprava závislá opačně na platbě, výběrem platby by zase došlo k tomu, že by mohla přibýt/ubýt další možnost v dopravě, pokud by se vybrala ta, zase by mohla přibýt/ubýt možnost v platbě, atd.atd. Ale to by bylo hodně špatný řešení, takže v podstatě zůstávají dva nezávislý body:

1) možnost platby být závislá na dopravě (vybere se doprava a na základě výběru dopravy se vyselektují položky pro platbu) - to zní logicky, a je to tuším proveditelný - prostě se k platbě přiřadí, že se jako možnost zobrazí jen v případě určité dopravy ...

2) cena za platbu (plus možnost: bez DPH, DPH, s DPH)

Zatímco 1) je asi jasná, u 2) by to nějak mělo hrát s účetnictvím, tedy ty pravidla by měly být takový, aby to pak odpovídalo účetnictví - s tímhle já žádnou zkušenost nemám a na faktuře jsem ještě neviděl "poplatek" za platbu. Tedy bylo by dobrý, pokud s tím má někdo zkušenosti (jak se to zobrazí v objednávce, jak potom na faktuře, jak to jde do účetnictví, atd.)

Díky.

ad 1/ přesně tak jsem to myslel, asi jsem se na začátku špatně vyjádřil
ad 2/ Setkal jsem se zatím s dvěma variantami:

a/ na faktuře opravdu figurují obě částky jako zvláštní řádky, obvykle nazvané něco jako "Přepravné" a "Doběrečné"
b/ na faktuře se obě částky sečtou do jedné, i když jsou v košíku vyčíslené zvlášť

Nevím ale přesně zda z hlediska DPH doběrečné může být v jiné sazbě než dopravné, pokud se nepletu tak přeprava poštou je osvobozena od DPH (přeprava PPL ale ne), a nevím jestli v ten okamžik je osvobozena celá částka, včetně doběrečného (nebo případného připojištění apod.), nebo jen čistě částka za přepravu... Zkusím to ještě ověřit.

Ahojte, nečetl jsem diskuzi, ale k DPH na přepravné a doběrečné....
I když je pošta osvobozena od DPH (jen některé služby, ne vše), tak Ty jako provozovatel eshopu tuto službu nakupuješ a následně fakturuješ, takže jak na doběrečné, tak přepravné musíš DPH uplatnit.

Prostě je jedno, zda nakoupíš přepravu s DPH nebo ne - pokud jsi plátce DPH, musíš ho k fakturované částce připočíst, a to ve výši 21%

HonzaG

honzag napsal: Prostě je jedno, zda nakoupíš přepravu s DPH nebo ne - pokud jsi plátce DPH, musíš ho k fakturované částce připočíst, a to ve výši 21%

Trochu jsem hledal a z tohoto principu je jedna vyjímka - to když poštovné fakturované zákazníkovi nepřesáhne náklady s ním spojené (prostě když zákazníkovi fakturuju za poštovné stejnou nebo menší částku, kterou jsem zaplatil poště). Pak by se mělo z hlediska účetnictví jednat o "Přeúčtování třetí straně", a DPH i zakázníkovi bude nulové.

Ok, já to teď beru spíš z programátorskýho hlediska:

a) u dopravného je možnost nastavit daň (např. DPH) - to už existuje
b) a pokud by existoval i nějaký případ, že to stejný se dá účtovat i na platbu, pak je dobrý tam tu možnost dát.

Když to srnu:

1) dopravné a DPH - ta možnost tam teď je
2) platba - poplatek za platbu by měl být možný a měla by být i možnost nastavení DPH pro tento poplatek
3) závislost platby:

Např dopravné teď může být závislé na: zemi, regionu, konečné částce, váze
U platby jsme se shodli, že může být závislá na dopravě (závislostí mám na mysli to, že na základě výběru dopravy se zobrazý druhy plateb odpovídající kritériím)

Teď vzniká další otázka, má být zobrazení platby závislé i na zemi, regionu a částce nákupu? Jde o to, že to se už dá řešit přes dopravu. Pokud se platba zobrazuje na základě dopravy a doprava se zobrazí na základě kriterií jako je země, region a konečná částka pak by teoreticky platba tyto kritéria mít nemusela. Ale zase na druhou stranu je přehlednější, pokud budou jasný pravidla jako u dopravy, tedy:

a) u dopravy jsou možný kritéria: země, region, konečná částka (samozřejmě bez dopravy), váha
b) co u platby? doprava, konečná částka (bez dopravy, s dopravou?), země?, region?

H13 napsal: a) u dopravy jsou možný kritéria: země, region, konečná částka (samozřejmě bez dopravy), váha
b) co u platby? doprava, konečná částka (bez dopravy, s dopravou?), země?, region?

Byl bych pro filtry i u platby, např. dobírku můžu nabízet jen do částky 30.000 nad ní chci platbu předem (dopravou bych to opět musel řešit krkolomně přes dvě dopravy). Omezení bych umožnil dle dopravy (o tom je celá naše diskuse ), dle země (viz příklad z praxe se slovenskem), dle částky (viz příklad z praxe s maximální výší objednávky na dobírku). Region je v českých podmínkách asi nesmysl, v USA by smysl dávat mohl, pokud tam již ostatní podmínky budou, asi není důvod jej také nezahrnout.

U částky si myslím že je zbytečné zahrnovat částku za dopravu (nebo dávat tuto možnost). Ta by již měla být obvykle zlomkem částky za objednávku, tzn. i kdyby tam teoreticky nějaký rozdíl nastal, měl by být spíše minimální.

U obou nastavení bych se ještě přimlouval o možnost nastavení klasického ACL (přístupové úrovně Joomly) - to by umožnilo např. VIP zákazníkům definovat dopravy zdarma.

No u těch skupin je to zase složitější, přidá se ACL pro platbu, musí se přidat pro dopravu, pak pro kategorie, produkty, atd. a tím může vzniknout nekontrolovatelnej systém ACL, jako je teď v Joomle!, kterýmu 99% lidí nerozumí ( resp. nikdo přesně neví, zda nastavil vše co nataveno být mělo)

Takže vzniká další otázka, v případě implementace ACL a skupin, kde všude?

Produkt
Doprava
Platba

ACL v Joomla řeším jedině přes ACL Manager for Joomla! . Jinak se to opravdu pořádně nedá uhlídat, to souhlasím.

H13 napsal: Takže vzniká další otázka, v případě implementace ACL a skupin, kde všude?

Nemyslel jsem ACL ve smyslu omezování backend aktivit, ale ve smyslu frontend zobrazování, tj. možnost k dopravě a platbě přiřadit Přístup (Access) tj. hodnoty jako Public, Guest, Registered, Special apod. To, jak jsem koukal, v administraci to už lze u produktů a kategorií, přidal bych to tedy i k dopravám a platbám. Jinde by to asi nemělo smysl, snad jen ještě u Form Fields (např. po velkoobchodních zákaznících budu chtít navíc vyplnit IČ, DIČ a třeba kontakt na fakturanta)...

Souhlasím, že plnohodnotné ACL je komplikované, a skoro až zbytečně členěné. V eshopu asi těžko budu určovat, že admin může upravovat dopravy ale platby už ne, a navíc ještě jen nějaké dopravy :S

Přiřazení přístupové úrovně (Access level) si ale myslím je poměrně jednoduché a přehledné a umožnilo by vytvářet eshop pro různé skupiny zákazníků (přiřazování do skupin by řešila už Joomla sama o sobě ve správci uživatelů)....

Ok, pak tedy:

- Produkty
- Doprava
- Platba
- případně Form Fields

...a kategorie (ale u těch už to v administraci je)

Tak jsem se to snažil nějak zapracovat do Alpha2 verze:
www.phoca.cz/news/808-phoca-cart-develop...-0-0-alpha2-released

Kromě jiného:
- ACL pro kategorie, produkty, dopravu, platbu a formulářové pole
- možnost zpoplatnit platbu
- kritéria pro zobrazení platby: země, region, částka, doprava, ...

Pro testování je připraven balíček s demo daty, viz:
www.phoca.cz/documents/116-phoca-cart-co...o-data-in-phoca-cart

Každopádně děkuji všem za nápady a tipy.

Demo:
Phoca Cart Demo