Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Sklepy internetowe - obliczanie ceny
peter13135
post 10.08.2012, 12:04:24
Post #1





Grupa: Zarejestrowani
Postów: 1 447
Pomógł: 191
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Jestem w trakcie kończenia sklepu internetowego (tzn. jestem jednym z wykonawców). Jak w każdym sklepie, jedną z funkcjonalności także tego sklepu jest wpisywanie ceny za dany produkt i wysokość podatku vat. Na podstawie ceny (która jest w domyśle ceną netto) i wysokości podatku vat obliczana jest cena brutto.
Klientowi zaczął teraz przeszkadzać ten system (gdy sklep jest praktycznie gotowy). Uważa, że obecny sposób działania jest błędny. Według niego to powinno być tak, że wpisujemy do panelu cenę brutto, a cena netto powinna być obliczana na podstawie ceny brutto i vatu.
W specyfikacji/umowie nie było nic wspomniane na ten temat. Czy takie coś jest może standardem w sklepach internetowych ?

Nie wiem jak mam się zachować w tej sprawie, klient miał dużo dodatkowych "domyślnych" wymagań, które nie były ujęte w umowie i je dla świętego spokoju robiłem, ale powoli mnie to przestaje bawić.

Kieruję do was zapytanie: Czy waszym zdaniem jest to rzecz oczywista i powinienem tak zrobić jak klient sobie życzy, czy może dodatkowa funkcjonalność ?

Ten post edytował peter13135 10.08.2012, 12:07:30


--------------------
:)
Go to the top of the page
+Quote Post
crazy191
post 10.08.2012, 12:16:08
Post #2





Grupa: Zarejestrowani
Postów: 79
Pomógł: 6
Dołączył: 20.04.2009

Ostrzeżenie: (0%)
-----


Jak dla mnie nie jest to standardem i możesz spokojnie bronić swojej racji.
Nie ustalone = dodatkowa zapłata
Go to the top of the page
+Quote Post
cojack
post 10.08.2012, 12:22:30
Post #3





Grupa: Zarejestrowani
Postów: 898
Pomógł: 80
Dołączył: 31.05.2008

Ostrzeżenie: (20%)
X----


To nie jest oczywiste. W żaden sposób. Jak ja pisałem sklep dla klienta, to miałem podobny mankament, z tym że ten chciał przeliczać z netto na brutto i z powrotem. Gubiły się grosze biggrin.gif Ale to przez zaokrąglanie w javascript. Dorób mu po prostu pole cena brutto i niech se wpisuje netto lub brutto i przeliczaj z jednej na drugą, tylko nie w javascripcie. Ciekawe czy sobie przypomni o marży ^^ Możesz wyjść na przeciw jego wymaganiom i dodać pole marży podawane w procentach. Ale to już Twoja indywidualna decyzja.

@edit
a zapomniałbym, jeżeli podaje brutto to przelicz na netto, i oblicz raz jeszcze brutto podmieniając wartość by mieć pewność że się grosze nie zgubią. Nie powinno się przeliczać z brutto na netto.

@edit2
jeszcze jedna dobra praktyka, o której chciałbym Ci powiedzieć przechowuj w bazie liczby rzeczywiste, nie zaokrąglaj ich przy zapisie tylko w widoku.

Ten post edytował cojack 10.08.2012, 12:26:47


--------------------
cojack blog - mój blog (na jakiś czas off).
"jak czegoś nie wiem, to nie myślę że wiem" - moja domena
Go to the top of the page
+Quote Post
peter13135
post 10.08.2012, 12:39:31
Post #4





Grupa: Zarejestrowani
Postów: 1 447
Pomógł: 191
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Dziękuje za odpowiedzi wink.gif
Problem z groszami póki co pomińmy. Jeśli podejmę się zrobienia tej roboty to wtedy chętnie skorzystam ze wskazówek wink.gif.
Cytat
To nie jest oczywiste. W żaden sposób. Jak ja pisałem sklep dla klienta, to miałem podobny mankament, z tym że ten chciał przeliczać z netto na brutto i z powrotem.

Okej, ale w specyfikacji nie było uwzględnione jak to przeliczanie ma się odbywać. Czy więc może wymagać, żeby było tak, a nie inaczej skoro w specyfikacji nei jest o tym nic wspomniane ? Wybrałem sposób taki jaki wybrałem (moim zdaniem bardziej oczywisty i częściej spotykany, jak sam piszesz - obliczanie ceny netto na podstawie brutto jest raczej kiepskim pomysłem). Od początku istnienia sklepu to przeliczanie działa bez zmian, a dopiero teraz klientowi to zaczyna przeszkadzać.

Delikatnie mówiąc mnie to drażni, bo umawialiśmy się na początku na prosty sklep, a teraz wychodzi coś innego. Nie mam rodziny na głowie, a praktyka zawsze się przyda, więc godzę się na kolejne "poprawki", ale jednak teraz muszę trochę przystopować, bo innych obowiązków mi nie ubywa.


--------------------
:)
Go to the top of the page
+Quote Post
phpion
post 10.08.2012, 12:44:42
Post #5





Grupa: Moderatorzy
Postów: 6 065
Pomógł: 859
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza




Jakiś rok temu miałem bardzo podobny przypadek z jednym klientem. W końcu zebrałem się i poszedłem po poradę prawną. Reasumując: jeśli coś nie jest doprecyzowane w specyfikacji to przyjmuje się, że zleceniodawca godzi się na wykonanie tego według uznania wykonawcy. Od strony prawnej zatem jesteś "na górze". Tym bardziej, że zakładam, że klient od dłuższego czasu miał wgląd w projekt i już dawno mógł zareagować na sposób obliczania ceny, a tego nie zrobił. Kwestia tylko co w przypadku gdy klient się uprze i zagrozi nie odebraniem projektu z powodu tej niezgodności z jego wymaganiami. Decyzję w takiej sytuacji będziesz musiał podjąć samodzielnie. Ja akurat ustąpiłem...
Go to the top of the page
+Quote Post
cojack
post 10.08.2012, 12:46:42
Post #6





Grupa: Zarejestrowani
Postów: 898
Pomógł: 80
Dołączył: 31.05.2008

Ostrzeżenie: (20%)
X----


Hmmm to daj mu delikatnie do zrozumienia że tego nie było w dokumentacji, i jeżeli chce taką funkcjonalność to dopiero po skończeniu projektu i za dodatkową zapłatę. Jeżeli masz umowę i dokumentację, trzymaj się swojego. Ale czasami jest dobrze pójść klientowi na rękę, wiesz poślizgi itp będzie się mniej krzywił. Z tym że też bez przesady by robić wszystko co mu się wymyśli w trakcie pisania oprogramowania. Ogarnąć taką komunikację z klientem to jest na prawdę duża sztuka. Powodzenia.


--------------------
cojack blog - mój blog (na jakiś czas off).
"jak czegoś nie wiem, to nie myślę że wiem" - moja domena
Go to the top of the page
+Quote Post
phpion
post 10.08.2012, 12:50:42
Post #7





Grupa: Moderatorzy
Postów: 6 065
Pomógł: 859
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza




~cojack dobrze pisze. Do tego rada ode mnie: jeśli przeczuwasz, że mogą być problemy z klientem to wszystko uzgadniajcie w takiej formie, by pozostał po tym ślad. Żadnych rozmów telefonicznych, wszystko mailowo lub w formie aneksów do umowy. Potem klient wyprze Ci się w żywe oczy ustaleń, zagrozi oddaniem sprawy do sądu za niewykonanie zlecenia, przez co poniósł straty finansowe itd. Ja raz się sparzyłem i teraz jestem ostrożniejszy.
Go to the top of the page
+Quote Post
jaworr
post 10.08.2012, 12:50:54
Post #8





Grupa: Zarejestrowani
Postów: 27
Pomógł: 5
Dołączył: 29.09.2010

Ostrzeżenie: (0%)
-----


Wpadłeś trochę w błędne koło. Ja osobiście staram się przed rozpoczęciem pracy nad danym projektem dopiąć wszystko na ostatniu guzik, spisać wszystko na umowie, specyfikacje techniczną jak najbardziej szczegółowo opisać, oraz uczulić klienta na to, że wykonuje to co mamy zapisane w umowie. Wszelakie "dodatkowe bonusy", w postaci takich kwiatków jak Twój klient wymaga, powinny być wyceniane oddzielnie, a klient powienien wiedzieć o tym, że wymagając poprawek których nie było w umowie na etapie programowanie sklepu, będą wyceniane oddzielnie ( nie koniecznie tanio smile.gif ).

Pozdrawiam, życzę powodzenia z użeraniem się z natrętnymi klientami.
Go to the top of the page
+Quote Post
phpion
post 10.08.2012, 12:55:00
Post #9





Grupa: Moderatorzy
Postów: 6 065
Pomógł: 859
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza




Cytat(jaworr @ 10.08.2012, 13:50:54 ) *
Ja osobiście staram się przed rozpoczęciem pracy nad danym projektem dopiąć wszystko na ostatniu guzik

Czasem jest to niewykonalne. Ja np. miałem zapis w umowie, że będę otrzymywał projekty graficzne w formie plików psd. Spoko luz, ale otrzymywałem je jako płaskie jpg zapisane w postaci psd. Kolejna kwestia to specyficzne rozumienie pojęć przez klientów. W moim przypadku np. klient wyszukiwarką określił menu, a poprzez pozycjonowanie rozumiał promowanie. Tak więc z pozoru jasne sformułowania mogą być różnie rozumiane przez strony.
Go to the top of the page
+Quote Post
peter13135
post 10.08.2012, 12:55:02
Post #10





Grupa: Zarejestrowani
Postów: 1 447
Pomógł: 191
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cóż, wszystkiego trzeba się nauczyć wink.gif Faktycznie sparzyłem się bardzo mocno. Zdrugiej strony, lepiej mieć taką lekcję wcześniej niż później.

Dziękuję bardzo za odpowiedzi wink.gif


--------------------
:)
Go to the top of the page
+Quote Post
jaworr
post 10.08.2012, 13:21:05
Post #11





Grupa: Zarejestrowani
Postów: 27
Pomógł: 5
Dołączył: 29.09.2010

Ostrzeżenie: (0%)
-----


Cytat(phpion @ 10.08.2012, 13:55:00 ) *
Czasem jest to niewykonalne. Ja np. miałem zapis w umowie, że będę otrzymywał projekty graficzne w formie plików psd. Spoko luz, ale otrzymywałem je jako płaskie jpg zapisane w postaci psd. Kolejna kwestia to specyficzne rozumienie pojęć przez klientów. W moim przypadku np. klient wyszukiwarką określił menu, a poprzez pozycjonowanie rozumiał promowanie. Tak więc z pozoru jasne sformułowania mogą być różnie rozumiane przez strony.

Dlatego podkręślę, że się staram dopiąć. W większości przypadków nie da się tego osiągnąć, ale też nie powinniśmy siadać do pracy z tzw. "marszu" bez jakichkolwiek większych czy mniejszych ustaleń co do wykonywanej pracy.
Go to the top of the page
+Quote Post
athabus
post 10.08.2012, 15:18:28
Post #12





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Ze względu na charakter pracy sklepu (tj. sprzedaż detaliczna) raczej należało przyjąć, że klient będzie chciał wprowadzać cenę brutto (bo taka się wyświetla). Z ceną brutto jest ten problem, że np. chcesz mieć na stronię 69,99 i teraz co? Celować aż się trafi?

Jednak w praktyce też bardzo przydatne jest posiadanie ceny netto - bo tak na prawdę na jej podstawie obliczasz marże itp.
W ogóle w samy systemie IMO powinna być przechowywana cena netto - bo ją się da przeliczyć dokładnie na cenę brutto, co w odwrotnym kierunku jest już problematyczne. Teraz jeszcze powstaje problem czy oprogramowanie sklepowe pracuje w metodologii brutto (kasy fiskalne tak pracują) czy metodologii netto (większość programów magazynowych pracuje domyślnie w metodologii netto z możliwością zmiany na burtto). Ogólnie temat wydawałoby się trywialny, ale przysparza trochę problemów w "realu". Wyjście z ceny netto rozwiązuje ten problem w dużej mierze, bo nie ma problemów z zaokrąglaniem itp.

Ale już tak poza wszystkim to problem jest dla mnie dość prosty jeśli rozumiem istotę problem. Po prostu napisz klientowi dodatkowe pole cena brutto i przeliczaj za pomocą JS - to kilka linijek kodu. Oczywiście do bazy przesyłaj cenę netto. Jeśli klientowi chodzi jedynie o wygodę wprowadzania cen to to będzie najlepsze wyjście.
Go to the top of the page
+Quote Post
O$iek
post 10.08.2012, 15:56:55
Post #13





Grupa: Zarejestrowani
Postów: 45
Pomógł: 16
Dołączył: 28.02.2009
Skąd: Łódź

Ostrzeżenie: (0%)
-----


Znam przypadek pewnej dużej firmy. Formularz internetowy, w który użytkownik musi podać imię, nazwisko i inne dane. Nikt nie wpadł na to, że ludzie wpiszą swoje dane tak:
jan kowalski
JAN KOWALSKI
Przez co na kartach z chipem, drukowało małymi literami(dużymi, to jeszcze z Bogiem sprawa) i klienci byli niezadowoleni, że muszą płacić 10 zł za nową kartę z poprawionymi danymi. Oczywiście firma ta mogła dodać "poprawianie" wpisanych tak danych jako dodatkową funkcjonalność. Wyliczyli to na 20h, 180zł/roboczogodzina wink.gif


--------------------
Helpers gonna help ;)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 25.02.2020 - 03:51