komunikat przy wystawianiu faktur o braku pozycji domyślnej

[netsystem24.pl]

Witam !
Czy byłaby możliwość sprawdzania podczas wystawiania faktur automatem, czy wszyscy uzytkownicy mający zaznaczone automatyczne wystawianie faktur mają dopisaną domyślną pozycję do fakturowania ?

trafiło mi się juz kilka razy, że przeoczyłem przez to wystawienie faktury dla klienta na czas.

pozdrawiam Tomasz Przybysz

[Pyxis]

Napisz jaka wg Ciebie program mial by podjac akcje po wykryciu takiego przypadku.

[netsystem24.pl]

Wg. mnie powinien być komunikat o fakcie z wymienionymi ludkami, u których są braki oraz pytanie czy kontynuować czy nie.

pozdrawiam T.P.

[Pyxis]

Czyli podczas generowania FV przogram przerywagenerowanie i pojawia sie okno z komunikatem, ze jest taki user. I co dalej?

[netsystem24.pl]

Raczej proponowałbym sprawdzenie przed generacją faktur, lub raport po wydrukowaniu dla których osób nie została wystawiona faktura.

[Pyxis]

No ale nadal nie wiem jak to sobie wyobrazasz technicznie.
Sa osoby ktorym nie chcemy wystawiac FV i oni tez w takim raporcie byli by ujeci.

Postaram sie rozwiazac jakos ten problem "po swojemu"

[netsystem24.pl]

ok. napiszę jak informatyk informatykowi - myślę że po naciśnięciu przycisku generacji (lub po wejściu do tej funkcji) - program powinien sprawdzać czy dla wszystkich użytkowników dla których jest zaznaczone wystawiaj automatycznie faktury - jest ustawiona pozycja domyślna na fakturę.
Jeżeli jest program generuje faktury, jeżeli nie ma u niektórych - wyświetla listę osób i pyta co robić dalej.

Myślę że teraz trochę bardziej zrozumiale piszę.

pozdrawiam T.P.

[Pyxis]

Bardzo "pracochlonny" algorytm

Popatrzymy , podzialamy

[netsystem24.pl]

na bazie sql-owej byłoby szybciej (rodzaj bazy czuć przy każdej operacji wyszukiwania i filtrowania).


pozdrawiam T.P.

[Pyxis]

Hehe... magia SQLa pewnie by zadzialala.

BTW: Ja tez robie zapytania SQLowe do tabeli Paradoxa.

[netsystem24.pl]

rzecz w tym że tu nie o sposób pytania chodzi a obsługę na poziomie silnika bazy - plikowa zawsze będzie obsługiwana tak samo nawet jeżeli użyje się komponentów sql.
Baza sql-owa ma lepszy silnik - bardziej zoptymalizowany - poza tym zapytania transakcyjne są mniej obciążające, gdyż tam nie robi się seek-u na plikach - co czuć w pyxisie zwłaszcza na przewijaniu filtrowanych list (także np na generowaniu faktur).
Na bazie sql trwało by to moment (tzn. sporo krócej).
Ale o tym już rozmawialiśmy kiedyś - sporo roboty. Jakbym miał na tyle czasu to może sam bym się wziął za taki system - ale tu jest ciągle problem .
Na ta chwilę także mi bardzo nie pasuje sposób rozliczania faktur trudno się w tym zorganizować. Wg mnie powinny być wpłaty osobno jak na koncie klienta - a później dopiero logika rozliczania faktur -bo ludki wpłacają przeróżnie za 1 m-c, 2-mc, 3-mc - cholery można dostać żeby dojść kto zalega a kto nie.
wpłaty rozliczają się za dziwne miesiące - a wg. mnie powinny się rozliczać faktury od najstarszej - chyba że ręcznie rozliczę którąś sam.

No dobra kończę bo będzie że tylko narzekam.

[Pyxis]

Na ta chwilę także mi bardzo nie pasuje sposób rozliczania faktur trudno się w tym zorganizować. Wg mnie powinny być wpłaty osobno jak na koncie klienta - a później dopiero logika rozliczania faktur -bo ludki wpłacają przeróżnie za 1 m-c, 2-mc, 3-mc - cholery można dostać żeby dojść kto zalega a kto nie.
wpłaty rozliczają się za dziwne miesiące - a wg. mnie powinny się rozliczać faktury od najstarszej - chyba że ręcznie rozliczę którąś sam.

I tak sie to mniejwiecej rozlicza. Od najstarszej faktury na liscie faktur i najstarszego nieoplaconego miesiaca w tabeli oplat. Nie wiem czemu jest to dla Ciebie niejasne i zagmatwane.

Jak lient wplaci za 3 miesiace to rejestrujesz w tabeli oplat i program generuje Ci jego FV w przyszlosci jako rozliczone.

Kurde, to jest proste jak ...

[netsystem24.pl]

Nie tak.

Gość płaci za trzy zaległe np. i płaci w miesiacu 10
a i rozlicza mi 10,11,12 a powinno 7,8,9
jak już rozliczy 10 to automatycznie później rozlicza nowsze. I to jest trochę do d.. - bo muszę ręcznie to poprawiać tzn. rozbijać na pojedyncze miesiące i wpisywać odpowiednie miesiące. Przeważnie na to nie mam czasu - a skoro mam system chciałbym sobie pomóc.

Wydaje mi się że takie proste relacje platność rozliczenie faktury - jak to ma miejsce przy masówce nie do końca działa tak jak trzeba.
poza tym w tabeli płatności byloby miło widzieć czy klient za dany okres miał płacić, czy nie. Fajne jest to zestawienie - ale do niego muszę siadać z listą od kiedy każdy user ma umowę i czy od danego miesiąca miał płacić czy nie.

Jednym słowem trochę za dużo roboty na piechotę.

[Pyxis]

Bo nie robisz "bilansu otwarcia" w tabeli usera. Program pierwsza oplate abonamentowa w tabeli ksieguje na miesiac biezacy. Aby bylo inaczej na miesiac poprzedzajacy pierwszy miesiac wymagalnosci abonamentu wpisujesz abonament z kwota 0 zl. Czyli w Twoim przypadku przy wprowadzaniu tego klienta, po podpisaniu umowy powinienes zrobic mu w tabeli oplat wpis na czerwiec z kwota 0 zl. Pyxis by "wiedzial" ze ma wynagac oplaty za lipiec i zaczynalby ich ksiegowanie o tego miesiaca.

Musze chyba pomyslec nad osobnym polem na ten "bilans otwarcia" umieszczanym na karcie usera, bo juz ktoras osoba ma z tym problem.

[netsystem24.pl]

Hmm wydaje się bez sensu skoro wyznacznikiem do płatności kiedy jest faktura. Prosty join i już wiadomo od kiedy klient ma placić, gdyby np pola dla których była wystawiona faktura wyświetlały się innym kolorem - byłoby lux (pisze o raporcie wpłat) - co do rozliczania - to zrobiłbym join z fakturami sortowany datami faktur z warunkiem "rozliczona=nie"
Oczywiście nie oglądałem bazy - ale reguły są takie same więc myślę że nie odstajesz od normy.

Nie wiem skąd pomysł żeby rozliczać fakturę w miesiącu wpłaty ?
Jak dla mnie powinno być jakieś powiązanie z dokumentami - bo później można bzdury pooglądać na indeksie zaległości.