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ść ?

Jak dla mnie nie jest to standardem i możesz spokojnie bronić swojej racji.
Nie ustalone = dodatkowa zapłata

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 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.

Dziękuje za odpowiedzi
Problem z groszami póki co pomińmy. Jeśli podejmę się zrobienia tej roboty to wtedy chętnie skorzystam ze wskazówek .

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.

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...

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 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.

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 ).

Pozdrawiam, życzę powodzenia z użeraniem się z natrętnymi klientami.

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.

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

Dziękuję bardzo za odpowiedzi

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.

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.

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