PYXIS (forum)

napisałem wyraźnie że wg. mnie v2 nic nie wnosi dla mnie więc nie kupuję.. czytaj człowieku a nie piszesz bzdury
Co twoja wypowiedź wnosi w temat?
ps. pewne błędy wychodzą w trakcie używania

Jezeli za blad uwazasz dzialanie algorytmow rozliczen w programie niezgodznie z Twoimi wyobrazeniami na ten temat, to ten "blad" byl zawsze - w wersji demo i shareware tez. Od poczatku istnienie programu.
Te wersje demo i shareware sa publikowane wlasnie w celu przetestowania dalania mechanizmow programu i wiekszosc kupujacych sie z nimi zapoznaje wlasnie na tym etapie. Nie chce aby ktos kupowal kota w worku.
To samo dotyczy v2. Jest wersja demonstracyjna i opis w changelogu. Jak uzytkownik uzna ze mu sie przydadza nowe finkcjonalnosci i chce wspierac nadal wdrazanie nowych - bardzo sie z tego ciesze. Jesli wystarcza mu finkcjonalnosc v1 - szanuje decyzje. Nie traktuje tego w kategoriach nagrody i kary. To sa sprawy handlowe.

proszę mi powiedzieć tylko jedną rzecz
dlaczego tabela opłat użytkowników oraz rozliczonych faktur nie może równać się wartości wpływu na rachunek? W czym tkwi problem?


Moim zdaniem, powoduje to, że nie ma możliwości sprawdzić czy faktury są dobrze rozliczone jeśli użytkownik ma różne kwoty wpłat w porównaniu z fakturami wystawionymi i wpłatami w programie.
Prosty przykład:

MIESIĄĆ | FAKT. WYST | WPŁATA | SALDO WN | SALDO MA | WPISY w OPŁ. UŻ | UWAGI
(narastająco) |(narastająco)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
miesiąc1 | 39zł | 39zł | 0zł | 0zł | 39zł (gen. przy "zar.abon.") |
miesiąc2 | 39zł | 40zł | 0zł | 1zł | 39zł (gen. przy "zar.abon.") |
miesiąc3 | 39zł | 0zł | 38zł | 0zł | 39zł (gen. przy "zar.abon.". Rozl. z wpł m-ca 4) |
miesiąc4 | 39zł | 80zł | 0zł | 3zł | 39zł (gen. przy "zar.abon.". Rozl. z wpł m-ca 4) |
miesiąc5 | 39zł | 39zł | 0zł | 3zł | 39zł |
miesiąc6 | 39zł | 40zł | 0zł | 4zł | 39zł |
miesiąc7 | 39zł | 0zł | 35zł | 0zł | 39zł (gen. przy "zar.abon.". Rozl. z wpł m-ca 8 |
miesiąc8 | 39zł | 82zł | 0zł | 8zł | 39zł (gen. przy "zar.abon.". Rozl. z wpł m-ca 8 |
miesiąc9 | 39zł | 39zł | 0zł | 8zł | 39zł |
miesiąc10| 39zł | 39zł | 0zł | 8zł | 39zł |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 miesięcy| 390zł | 398zł | 0zł | 8zł | 390zł

Zapisy w nawiasach (narastająco) są dla SALDA WN i MA

Mamy tutaj ewidentną nadpłatę 8zł. Opłaty użytkownika oraz rozliczenie faktur wskazuje o 8 zł mniej (według Pana przepisu na rozliczenia).

Nie mamy też możliwości sprawdzenia czy użytkownik ma nadpłatę czy nie, bowiem saldo prawdziwe jest inne od "opłat użytkownika". Zatem niech mi Pan powie w jakim celu służy tabela "opłaty użytkownika" skoro nie odzwierciedlają one jego faktycznych wpływów na rachunek mojej firmy?

Bo nie wszyscy wystawiaja FV albo nie zawsze wystawiaja i nie na wszystko. Takie obliczanie zaleglosci na podstawie zaleglosci okresow abonamentowych przy naszej dzialalnosci jest wygodniejsze niz liczenie salda, bo akcje odnosnie np blokowania odbywaja sie na podstawie okresu zaleglosci a nie kwoty.

Wystarczy zsumować saldo wpłat klienta (rzeczywiste, które np. było by odzwierciedlone w "opłatach użytkownika") i podzielić je przez "kwotę z szablonu faktury abonamentowej". Wychodzi nam wtedy stosunek wpłat/należności a zatem liczba miesięcy zalegających/nadpłaconych. Na tej podstawie można też przeliczać kwotę zaległą.
Mielibyśmy dwie pieczenie na jednym ogniu i nie powodowało by to problemów dla tych co wystawiają faktury.

Możliwości poprawnego rozliczania faktur jest wiele, ale MUSI być to na podstawie prawdziwych wpłat na rachunek firmowy a nie fikcji z "opłat klienta", bo za 5 lat sprawdzając klienta nikt nie będzie szukał jego przelewów w wyciągach bankowych i porównywał ich z programem, jeśli klient dopatrzy się nadpłaty lub niezgodności finansowej.

Teraz widzi Pan że w tym przypadku mamy błąd logiczny algorytmu księgowania?

A teraz pomysl co bedzie, jesli zmienimy w trakcie umowy szablon FV abonamentowej usera (na inna kwote).

BTW: Przy rozliczaniu FV w tabeli oplat dodaja sie automatyczne wpisy za jaka FV zostala zarejestrowana ta wplata. mamy tez podglad historii platnosci masowych. Do szyskiego udaje sie dojsc i znalezc. Sprawdzone w praktyce.

często Pan zmienia szablon z kwotą? częściej niż kilkuset klientów robiąc zamieszanie przy wpłatach?
wiem,wiem to nie odpowiedź na pytanie....ale czy teraz jest poprawnie jeśli nie ma odwzorowania na faktyczne wpłaty?

Rozwiązaniem problemu blokad było by zastosowanie wpłat/szablonu faktury (tak jak przedstawiłem wyżej) lecz należało by przestrzegać jednej prostej zasady (blokowane przez program automatycznie), nawet chyba bardziej logicznej (TP tak stosuje)
Nie ma możliwości zawierać nowych umów lub aneksów gdy klient nie ma zerowego salda. Wtedy mamy pewność że zmieniamy szablon tylko wtedy gdy saldo jest zerowe.

Zatem zasada że klient ma nierozliczony miesiąc (niższą kwotą abonamentową) i podnosimy mu kwotę (na wyższą kwotę abonamentową) i zmienia się przelicznik wpłat/szablony faktury nie ma zastosowania bo zaczynamy od zera. Było by to podobne jak gdybyśmy podpinali nowego usera z zerowym saldem.


Nie prawdę Pan pisze, że "Do wszystkiego udaje się dojść i znaleźć. Sprawdzone w praktyce."
Przedstawiłem Pana sposób wpisywania, księgowania wpłat w "opłatach użytkownika" i rozbieżności jakie przy tym powstają a rzeczywistym saldem wpłat i Pan nadal twierdzi że po kilkunastu miesiącach mam rzeczywisty obraz wpłat i dostępu do nich.

Jeśli czegoś tutaj nie wiem to niech mi Pan przedstawi swój sposób wglądu do wpłat klienta. Ale taki realny...nie z "opłat uzytkowników"

Pyxis pisze:BTW: Przy rozliczaniu FV w tabeli oplat dodaja sie automatyczne wpisy za jaka FV zostala zarejestrowana ta wplata. mamy tez podglad historii platnosci masowych. Do szyskiego udaje sie dojsc i znalezc. Sprawdzone w praktyce.

To nie wpłaty się rozlicza na podstawie faktur tylko faktury na podstawie wpłat. Faktura jest tylko podstawą prawną, nic więcej.

Przykład:
Gdy ktoś(nawet przypadkowa osoba) wpłaci panu pieniądze na konto (nawet przez pomyłkę), odprowadza Pan z tego podatek dochodowy, i nie ma Pan obowiązku oddawać tych pieniędzy jeśli ta osoba się nie upomni. Podatek jest odprowadzony, a zatem Pan się z obowiązku podatkowego wywiązał. Tak to prawnie wygląda. Dlatego tez powinien Pan podejść do tematu że faktury rozliczane są na podstawie wpłat klienta a nie odwrotnie.

Zmian abonamentu moze sie odbywac jescze przed uplywem terminu platnosci FV za wczesniejszy okres abonamentowy. U mnie dosyc czesto klienci dilaczaja drugi komputer czy konsole (lub rezygnuja z takich dodatkow).
Zeby sprawa byla jasna, to w Pyxisie rozlicza sie FV na podstawie wplat - tak jak pisalem wczesniej.

Mysle, ze nie ma sensu udowadniac sobie swoich racji. Najwazniejsze jest to, ze Pyxis pozwala na pilnowanie rozliczen z uzytkownikami w roznych sytuacjach. ISPy naprawde maja cala game sposobow rozliczen z klientami. Jesli system dziala poprawnie to nie mam zamiaru tego zmieniac. Z mojej strony EOT.

Pyxis pisze:Zmian abonamentu moze sie odbywac jescze przed uplywem terminu platnosci FV za wczesniejszy okres abonamentowy.

np. W niczym nie przeszkadza by klient wyzerował saldo w momencie gdy chce podpisać nową umowę. I tak musi podpisać aneks lub umowę....

Pyxis pisze: U mnie dosyc czesto klienci dilaczaja drugi komputer czy konsole (lub rezygnuja z takich dodatkow).

Nie rozumie do czego to? Pomieszane wątki?

Pyxis pisze:Zeby sprawa byla jasna, to w Pyxisie rozlicza sie FV na podstawie wplat - tak jak pisalem wczesniej.

Nie zauważyłem. Tylko dlaczego naciśnięcie "rozlicz abonament" dodaje wpłate w opłatach użytkownika!?

Pyxis pisze:Mysle, ze nie ma sensu udowadniac sobie swoich racji. Najwazniejsze jest to, ze Pyxis pozwala na pilnowanie rozliczen z uzytkownikami w roznych sytuacjach. ISPy naprawde maja cala game sposobow rozliczen z klientami.

Tylko który sposób jest ten właściwy w PYXIS. Jak Pana to zonk..bo nie działa dobrze jak wcześniej wspomniałem.

Pyxis pisze:Jesli system dziala poprawnie to nie mam zamiaru tego zmieniac. Z mojej strony EOT.

Albo Pan nie rozumie tego co napisałem wyżej, albo Pan w żywe oczy kłamie. Coś tu jest nie tak.

Prawda jest taka. Jak czytam forum to nie tylko ja zgłaszałem ten problem w rozliczeniach. Jak się nie chce lub nie można to trzeba powiedzieć a nie szukać za wszelką cenę wymówki.

Ja też mam dość, po co tłumaczyć jak ktoś nie wykazuje chęci rozwiązania błędu