Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
W dniu 2012-05-07 17:14, Tomasz Chiliński pisze:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
U mnie to jest bez różnicy bo ta data jest zawsze taka sama, ale jeżeli już tak zmieniacie to może przy okazji jakiś dodatek do liczenia ustawowych odsetek ;)
W dniu 12-05-07 17:17, Daniel Kulesza pisze:
W dniu 2012-05-07 17:14, Tomasz Chiliński pisze:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
U mnie to jest bez różnicy bo ta data jest zawsze taka sama, ale jeżeli już tak zmieniacie to może przy okazji jakiś dodatek do liczenia ustawowych odsetek ;) _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Mam coś takiego napisane... ale jest troszkę ułomne.
Dorzuciłem tabelę z odsetkami, w której są pola opisujące odsetki (id, docid, data utworzenia, data aktualizacji, opóźnienie w dniach, wartość odsetek, itp.) Codziennie skrypcik sprawdza czy faktury są po terminie, jak są to sprawdza czy jest wpis w tabeli odsetki i jeżeli tak, to aktualizuje wpis z odsetkami. Jeżeli nie, tworzy nowy rekord.
Jest ułomne, bo nalicza odsetki dla każdej nierozliczonej faktury. Nawet jak klient zapłaci 99% wartości faktury i zabraknie mu 1gr, system liczy odsetki od całości.
Pozdrawiam
W dniu 7 maja 2012 17:14 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
moim zdaniem dobrze jest jak jest, po co kombinować.
On Mon, 7 May 2012 19:57:25 +0200, Marcin marcin@nicram.net wrote:
W dniu 7 maja 2012 17:14 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
moim zdaniem dobrze jest jak jest, po co kombinować.
Większość pewnie ma tak samo datę wystawienia i datę sprzedaży, ale problem pojawi się w momencie gdy będziesz chciał wystawić po sprzedaży. Zgodnie z ustawą jest na to czas 7-u dni. Więc hipotetyczna sytuacja:
Sprzedaż 1 stycznia Faktura 7 stycznia Termin płatności 1 dzień Termin płatności przypada na ... 2 stycznia? Odsetki naliczamy od momentu wymagalności czyli od ... 2 stycznia? Być może nawet zgodne z prawem, ale nielogiczne.
W dniu 08.05.2012 10:12, Rafał Ramocki napisał(a):
On Mon, 7 May 2012 19:57:25 +0200, Marcin marcin@nicram.net wrote:
W dniu 7 maja 2012 17:14 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
moim zdaniem dobrze jest jak jest, po co kombinować.
Większość pewnie ma tak samo datę wystawienia i datę sprzedaży, ale problem pojawi się w momencie gdy będziesz chciał wystawić po sprzedaży. Zgodnie z ustawą jest na to czas 7-u dni. Więc hipotetyczna sytuacja:
Sprzedaż 1 stycznia Faktura 7 stycznia Termin płatności 1 dzień Termin płatności przypada na ... 2 stycznia? Odsetki naliczamy od momentu wymagalności czyli od ... 2 stycznia? Być może nawet zgodne z prawem, ale nielogiczne.
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
On 05/08/2012 02:06 PM, Tomasz Chiliński wrote:
Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Numer faktury powinien zależeć od daty wystawienia. Kropka.
W dniu 08.05.2012 14:10, A.L.E.C napisał(a):
On 05/08/2012 02:06 PM, Tomasz Chiliński wrote:
Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Numer faktury powinien zależeć od daty wystawienia. Kropka.
Zastanawiałem się jak pole w bazie nazwać, żeby było krótko i jednocześnie jasno dawało do zrozumienia o co biega... sdatedeadline typu boolean czyli smallint w sql ? ;-)
Dnia 8 maja 2012 14:06 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały ciąg się rozjedzie... O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
Witam!
Faktura musi mieć numer unikatowy (tylko).
W dniu 10.05.2012 11:40, Jacek Cieplok pisze:
Dnia 8 maja 2012 14:06 Tomasz Chilińskitomasz.chilinski@chilan.com napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały ciąg się rozjedzie... O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
Nieprawada UoR mowi: "Faktura powinna zawierać numer kolejny, co oznacza, iż w jakimś przyjętym przez podatnika okresie powinien to być numer następny. Numeracja może obejmować miesiące, kwartały, lata, całość działalności podatnika - wg jego wyboru. Wystarczy przyjąć i konsekwentnie stosować jakąś zasadę."
-----Original Message----- From: lms-bounces@lists.lms.org.pl [mailto:lms-bounces@lists.lms.org.pl] On Behalf Of Me Sent: Thursday, May 10, 2012 3:08 PM To: lista użytkowników LMS Subject: Re: [lms] termin płatności faktury
Witam!
Faktura musi mieć numer unikatowy (tylko).
W dniu 10.05.2012 11:40, Jacek Cieplok pisze:
Dnia 8 maja 2012 14:06 Tomasz Chilińskitomasz.chilinski@chilan.com
napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały
ciąg się rozjedzie...
O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby
numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
-- pozdrawiamy JPK -------------------------- Biuro Obsługi Klienta ul. Starogardzka 45 83-010 Straszyn http://www.jpk.pl tel.: 0 801 080 234 z komórek: 0 58 741 72 72
_______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witam!
Podaj paragraf bo nie mogę znaleźć a szukałem tutaj (http://isap.sejm.gov.pl/DetailsServlet?id=WDU19941210591) oczywiście szukałem w tekście ujednoliconym...
W dniu 2012-05-10 22:49, Michał Szymoniak pisze:
Nieprawada UoR mowi: "Faktura powinna zawierać numer kolejny, co oznacza, iż w jakimś przyjętym przez podatnika okresie powinien to być numer następny. Numeracja może obejmować miesiące, kwartały, lata, całość działalności podatnika - wg jego wyboru. Wystarczy przyjąć i konsekwentnie stosować jakąś zasadę."
-----Original Message----- From: lms-bounces@lists.lms.org.pl [mailto:lms-bounces@lists.lms.org.pl] On Behalf Of Me Sent: Thursday, May 10, 2012 3:08 PM To: lista użytkowników LMS Subject: Re: [lms] termin płatności faktury
Witam!
Faktura musi mieć numer unikatowy (tylko).W dniu 10.05.2012 11:40, Jacek Cieplok pisze:
Dnia 8 maja 2012 14:06 Tomasz Chilińskitomasz.chilinski@chilan.com
napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały
ciąg się rozjedzie...
O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby
numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
-- pozdrawiamy JPK
Biuro Obsługi Klienta ul. Starogardzka 45 83-010 Straszyn http://www.jpk.pl tel.: 0 801 080 234 z komórek: 0 58 741 72 72
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Zasady wystawiania faktur określone zostały w rozporządzeniu Ministra Finansów z dnia 25 maja 2005 r. w sprawie m.in. wystawiania faktur (Dz. U. nr 95, poz. 798 ze zm.). W myśl § 9 ust. 1 ww. rozporządzenia, faktura stwierdzająca dokonanie sprzedaży powinna zawierać m.in. dzień, miesiąc i rok, albo miesiąc i rok dokonania sprzedaży oraz datę wystawienia i numer kolejny faktury oznaczonej jako "FAKTURA VAT". Natomiast w przypadku sprzedaży o charakterze ciągłym, podatnik może podać na fakturze miesiąc i rok dokonania sprzedaży.
W sprawach numeracji ma zastosowanie przepis art. 88 § 1 ustawy z dnia 29 sierpnia 1997 r. Ordynacja podatkowa (Dz. U. z 2005 r. nr 8, poz. 60 ze zm.). Zobowiązuje on bowiem podatników wystawiających rachunki m.in. do ich kolejnej numeracji oraz przechowywania kopii tych rachunków w kolejności ich wystawienia.
Art. 88. § 1. Podatnicy wystawiający rachunki są obowiązani kolejno je numerować i przechowywać kopie tych rachunków, w kolejności ich wystawienia, do czasu upływu okresu przedawnienia zobowiązania podatkowego. § 2. Przepis § 1 stosuje się odpowiednio do podatników obowiązanych do żądania rachunków.
-----Original Message----- From: lms-bounces@lists.lms.org.pl [mailto:lms-bounces@lists.lms.org.pl] On Behalf Of iNTERNET Sent: Thursday, May 10, 2012 11:27 PM To: lms@lists.lms.org.pl Subject: Re: [lms] termin płatności faktury
Witam!
Podaj paragraf bo nie mogę znaleźć a szukałem tutaj (http://isap.sejm.gov.pl/DetailsServlet?id=WDU19941210591) oczywiście szukałem w tekście ujednoliconym...
W dniu 2012-05-10 22:49, Michał Szymoniak pisze:
Nieprawada UoR mowi: "Faktura powinna zawierać numer kolejny, co oznacza, iż w jakimś przyjętym przez podatnika okresie powinien to być numer następny. Numeracja może obejmować miesiące, kwartały, lata, całość działalności podatnika - wg jego wyboru. Wystarczy przyjąć i konsekwentnie stosować
jakąś zasadę."
-----Original Message----- From: lms-bounces@lists.lms.org.pl [mailto:lms-bounces@lists.lms.org.pl] On Behalf Of Me Sent: Thursday, May 10, 2012 3:08 PM To: lista użytkowników LMS Subject: Re: [lms] termin płatności faktury
Witam!
Faktura musi mieć numer unikatowy (tylko).W dniu 10.05.2012 11:40, Jacek Cieplok pisze:
Dnia 8 maja 2012 14:06 Tomasz Chilińskitomasz.chilinski@chilan.com
napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały
ciąg się rozjedzie...
O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby
numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
-- pozdrawiamy JPK
Biuro Obsługi Klienta ul. Starogardzka 45 83-010 Straszyn http://www.jpk.pl tel.: 0 801 080 234 z komórek: 0 58 741 72 72
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
-- pozdrawiamy JPK -------------------------- Biuro Obsługi Klienta ul. Starogardzka 45 83-010 Straszyn http://www.jpk.pl tel.: 0 801 080 234 z komórek: 0 58 741 72 72
_______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Dnia 10 maja 2012 22:49 Michał Szymoniak ms@osw.pl napisał(a):
Nieprawada UoR mowi: "Faktura powinna zawierać numer kolejny, co oznacza, iż w jakimś przyjętym przez podatnika okresie powinien to być numer następny. Numeracja może obejmować miesiące, kwartały, lata, całość działalności podatnika - wg jego wyboru. Wystarczy przyjąć i konsekwentnie stosować jakąś zasadę."
-----Original Message----- From: lms-bounces@lists.lms.org.pl [mailto:lms-bounces@lists.lms.org.pl] On Behalf Of Me Sent: Thursday, May 10, 2012 3:08 PM To: lista użytkowników LMS Subject: Re: [lms] termin płatności faktury
Witam!
Faktura musi mieć numer unikatowy (tylko).W dniu 10.05.2012 11:40, Jacek Cieplok pisze:
Dnia 8 maja 2012 14:06 Tomasz Chilińskitomasz.chilinski@chilan.com napisał(a):
W dniu 08.05.2012 13:54, A.L.E.C napisał(a):
On 05/08/2012 01:46 PM, Tomasz Chiliński wrote:
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
Tomku. Nic innego tylko dodać radio buttony (albo select) obok pola z terminem, z dwoma opcjami do wyboru: "od daty sprzedaży", "od daty wystawienia".
Już nad tym myślałem, ale z drugiej strony jeśli użytkowników radio buttonów można byłoby policzyć na palcach jednej ręki, to nie wiem czy nie lepiej zmienić domyślnego sposobu ustalania terminu płatności i numeracji faktur. Właśnie - nie tylko o termi płatności chodzi - numer faktury też powinien być dostosowany do sposobu wyliczania terminu.
Witam, jak niby numeracja ma zależeć od daty sprzedaży? Przecież wówczas cały ciąg się rozjedzie... O ile mnie pamięć nie myli, faktury muszą mieć numerację rosnącą. Aby numeracja się zgadzała, należałoby ją prowadzić w cyklu dziennym.
-- pozdrawiamy JPK
Witam. Zgadzam się w pełni, nie może to być dowolny unikatowy numer. Numer kolejnej faktury musi być w danym okresie i ciągu inkrementowany co 1. Tutaj niestety nikt nie moze mieć wątpliwości. Pomijając problemy natury podatkowej nasuwające się mi przy tym konkretnym przykładzie (wystawienie 1. stycznia faktury za usługę z datą sprzedaży 1. lutego i terminem płatności 15. lutego), nie wyobrażam sobie jak miałaby - zgodnie z prawem - wygladać numeracja powiązana z datą sprzedaży, nie zaś wystawienia faktury.
W dniu 11.05.2012 16:34, Jacek Cieplok napisał(a):
Witam.
Witam.
Zgadzam się w pełni, nie może to być dowolny unikatowy numer. Numer kolejnej faktury musi być w danym okresie i ciągu inkrementowany co
Tutaj niestety nikt nie moze mieć wątpliwości. Pomijając problemy natury podatkowej nasuwające się mi przy tym konkretnym przykładzie (wystawienie 1. stycznia faktury za usługę z datą sprzedaży 1. lutego i terminem płatności 15. lutego), nie wyobrażam sobie jak miałaby - zgodnie z prawem - wygladać numeracja powiązana z datą sprzedaży, nie zaś wystawienia faktury.
No już nie pisz, że sobie nie wyobrażasz, bo nie trudno sobie akurat wyobrazić ;-) - numeracja ustalana dokładnie tak samo jak na podstawie daty wystawienia, tylko w oparciu o datę sprzedaży.
data sprzedaży czy data wystawienia, nie ma to znaczenia najmniejszego, i tak sprzedajesz po kolei więc po kolei są wystawianie faktury z odpowiednimi numeracjami. Jeśli miałbyś to robić ręcznie na kartce to już zmienia postać rzeczy, jednak jeśli robi to system automatycznie to nie ma to najmniejszego znaczenia :)
--- Pozdrawiam Piotr Zgódka E-mail: piotr@zgodka.net Website: www.klawiszowiec.net Telefon: +48 602 531 588 --------------------------------------------------------------------------------------------------------- Klawiszowiec.net - Encyklopedia Instrumentów Klawiszowych ---------------------------------------------------------------------------------------------------------
Niniejsza korespondencja może zawierać informacje o charakterze poufnym lub zastrzeżonym. Jeśli nie jesteście Państwo jej adresatem, pragniemy wskazać, iż jakiekolwiek wykorzystanie lub rozpowszechnianie niniejszego e-maila lub jego załączników jest niedozwolone. Jeśli otrzymaliście Państwo go omyłkowo, prosimy o niezwłoczną informację pod adresem piotr@zgodka.net oraz o skasowanie wiadomości.
W dniu 11 maja 2012 16:58 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
W dniu 11.05.2012 16:34, Jacek Cieplok napisał(a):
Witam.
Witam.
Zgadzam się w pełni, nie może to być dowolny unikatowy numer. Numer kolejnej faktury musi być w danym okresie i ciągu inkrementowany co 1. Tutaj niestety nikt nie moze mieć wątpliwości. Pomijając problemy natury podatkowej nasuwające się mi przy tym konkretnym przykładzie (wystawienie 1. stycznia faktury za usługę z datą sprzedaży 1. lutego i terminem płatności 15. lutego), nie wyobrażam sobie jak miałaby - zgodnie z prawem - wygladać numeracja powiązana z datą sprzedaży, nie zaś wystawienia faktury.
No już nie pisz, że sobie nie wyobrażasz, bo nie trudno sobie akurat wyobrazić ;-)
- numeracja ustalana dokładnie tak samo jak na podstawie daty wystawienia,
tylko w oparciu o datę sprzedaży.
-- Pozdrawiam Tomasz Chiliński, Chilan _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
On Tue, 08 May 2012 13:46:22 +0200, Tomasz Chiliński tomasz.chilinski@chilan.com wrote:
W dniu 08.05.2012 10:12, Rafał Ramocki napisał(a):
On Mon, 7 May 2012 19:57:25 +0200, Marcin marcin@nicram.net wrote:
W dniu 7 maja 2012 17:14 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Witam.
Co Wy na to, żeby wyliczanie terminu płatności faktury zmienić z względem daty wystawienia na względem daty sprzedaży? Myślę, że częściej w rzeczywistości opieramy się na terminie płatności liczonym względem daty sprzedaży, a nie wystawienia.
moim zdaniem dobrze jest jak jest, po co kombinować.
Większość pewnie ma tak samo datę wystawienia i datę sprzedaży, ale problem pojawi się w momencie gdy będziesz chciał wystawić po sprzedaży. Zgodnie z ustawą jest na to czas 7-u dni. Więc hipotetyczna sytuacja:
Sprzedaż 1 stycznia Faktura 7 stycznia Termin płatności 1 dzień Termin płatności przypada na ... 2 stycznia? Odsetki naliczamy od momentu wymagalności czyli od ... 2 stycznia? Być może nawet zgodne z prawem, ale nielogiczne.
Mi raczej chodziło o to, żeby nie wystawiać po sprzedaży, ale zgodnie ze sprzedażą - załóżmy, że chcemy komuś wystawić fakturę za luty i wtedy data wystawienia 1 stycznia data sprzedaży 1 lutego termin płatności 15 lutego
To w takim razie może data wystawienia + logika, która uniemożliwia zdefiniowanie terminu płatności w przeszłości?
Moim skromnym zdaniem jest ok, tak jak jest, bez potrzeby zmian. po co zmieniać coś co dobrze działa. IMHO są "ważniejsze" sprawy niż zmiana sposobu wyliczania płatności faktur, np. historia "użycia" adresu ip. znaczy się. Klient ma przyznany ip, rezygnuje z umowy i ten sam adres dostaje inny. przychodzi liścik z prokuratury a my nie mamy informacji kto miał w tamtym czasie dany adres, musimy wertować umowy :( wydaje mi się, że to powinno być załatwione w pierwszej kolejności.
W dniu 08.05.2012 14:21, Marcin napisał(a):
Moim skromnym zdaniem jest ok, tak jak jest, bez potrzeby zmian. po co zmieniać coś co dobrze działa. IMHO są "ważniejsze" sprawy niż zmiana sposobu wyliczania płatności faktur, np. historia "użycia" adresu ip. znaczy się. Klient ma przyznany ip, rezygnuje z umowy i ten sam adres dostaje inny. przychodzi liścik z prokuratury a my nie mamy informacji kto miał w tamtym czasie dany adres, musimy wertować umowy :( wydaje mi się, że to powinno być załatwione w pierwszej kolejności.
Tabela w bazie danych - nodesessions już jest. W oparciu o radiusa ładnie mi zbierają się logi sesji. ISC DHCPD to kupa jakich mało - teoretycznie można swoje skrypty uruchamiać z poziomu daemona dhcp w momencie, gdy jest odnowienie dzierżawy, ale projektanci sugerują, że to raczej do dyndns powinno być używane...
W dniu 8 maja 2012 14:27 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 08.05.2012 14:21, Marcin napisał(a):
Moim skromnym zdaniem jest ok, tak jak jest, bez potrzeby zmian. po co
zmieniać coś co dobrze działa. IMHO są "ważniejsze" sprawy niż zmiana sposobu wyliczania płatności faktur, np. historia "użycia" adresu ip. znaczy się. Klient ma przyznany ip, rezygnuje z umowy i ten sam adres dostaje inny. przychodzi liścik z prokuratury a my nie mamy informacji kto miał w tamtym czasie dany adres, musimy wertować umowy :( wydaje mi się, że to powinno być załatwione w pierwszej kolejności.
Tabela w bazie danych - nodesessions już jest. W oparciu o radiusa ładnie mi zbierają się logi sesji. ISC DHCPD to kupa jakich mało - teoretycznie można swoje skrypty uruchamiać z poziomu daemona dhcp w momencie, gdy jest odnowienie dzierżawy, ale projektanci sugerują, że to raczej do dyndns powinno być używane...
Nie tylko teoretycznie, ale praktycznie rowniez.
Wczesniej uzywalem dnsmasq (jako pierwszy DHCP potrafil wykonywac skrypty), ale sie sypal i w rezultacie przeszedlem na ISC DHCPD. Od tej pory ZERO problemow z serwerem dhcp oraz wykonywaniem skryptow. Uruchamiam je zarowno podczas uzyskiwania dzierzawy jak i po jej zwolnieniu.
W dniu 08.05.2012 14:32, Sławomir Paszkiewicz napisał(a):
W dniu 8 maja 2012 14:27 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com [1]> napisał:
W dniu 08.05.2012 14:21, Marcin napisał(a):
Moim skromnym zdaniem jest ok, tak jak jest, bez potrzeby zmian. po co zmieniać coś co dobrze działa. IMHO są "ważniejsze" sprawy niż zmiana sposobu wyliczania płatności faktur, np. historia "użycia" adresu ip. znaczy się. Klient ma przyznany ip, rezygnuje z umowy i ten sam adres dostaje inny. przychodzi liścik z prokuratury a my nie mamy informacji kto miał w tamtym czasie dany adres, musimy wertować umowy :( wydaje mi się, że to powinno być załatwione w pierwszej kolejności.
Tabela w bazie danych - nodesessions już jest. W oparciu o radiusa ładnie mi zbierają się logi sesji. ISC DHCPD to kupa jakich mało - teoretycznie można swoje skrypty uruchamiać z poziomu daemona dhcp w momencie, gdy jest odnowienie dzierżawy, ale projektanci sugerują, że to raczej do dyndns powinno być używane...
Nie tylko teoretycznie, ale praktycznie rowniez. Wczesniej uzywalem dnsmasq (jako pierwszy DHCP potrafil wykonywac skrypty), ale sie sypal i w rezultacie przeszedlem na ISC DHCPD. Od tej pory ZERO problemow z serwerem dhcp oraz wykonywaniem skryptow. Uruchamiam je zarowno podczas uzyskiwania dzierzawy jak i po jej zwolnieniu.
O to może podzielisz się ze wszystkimi takimi skryptami Sławku? ;-)
W dniu 8 maja 2012 15:00 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
O to może podzielisz się ze wszystkimi takimi skryptami Sławku? ;-)
Moge sie podzielic. Ogolnie podczas tych skryptow sprawdzane iptables w poszukiwaniu wpisu IP<>MAC dla usera, ktory sie podlacza. Jak istnieje to nie jest nic wykonywane, bo zakladamy ze dzierzawa nie wygasla. Jak nie ma - to jest dopisywana ta para do iptables oraz wpis do bazy.
Zapobiega to zmianie adresu IP w sieci wifi
Jak zmienisz MAC to AP Cie rozlaczy.
W dniu 8 maja 2012 15:04 użytkownik Marcin marcin@nicram.net napisał:
W dniu 8 maja 2012 15:03 użytkownik Sławomir Paszkiewicz < paszczus@gmail.com> napisał:
Zapobiega to zmianie adresu IP w sieci wifi
hmm, a co ze zmianą MAC?
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 8 maja 2012 15:06 użytkownik Sławomir Paszkiewicz <paszczus@gmail.com
napisał:
Jak zmienisz MAC to AP Cie rozlaczy.
a jak podepne się z "prawidłowym" aczkolwiek zmienionym mac'iem? wezmę sobie mac od sąsiada albo innymi sposobami? w każdym bądź razie będę się podpinał "prawidłowym" według systemu mac'iem to co wówczas, wpuścisz takiego klienta czy odrzucisz?
No chyba sam znasz odpowiedz na to pytanie.
W dniu 8 maja 2012 15:15 użytkownik Marcin marcin@nicram.net napisał:
W dniu 8 maja 2012 15:06 użytkownik Sławomir Paszkiewicz < paszczus@gmail.com> napisał:
Jak zmienisz MAC to AP Cie rozlaczy.
a jak podepne się z "prawidłowym" aczkolwiek zmienionym mac'iem? wezmę sobie mac od sąsiada albo innymi sposobami? w każdym bądź razie będę się podpinał "prawidłowym" według systemu mac'iem to co wówczas, wpuścisz takiego klienta czy odrzucisz?
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Ogolnie jesli kogos to w ogole interesuje, to moj skrypt bazuje na tym: http://eduroam.pl/Dokumentacja/eduroam_zapobieganie_zmianie_IP.pdf
Na tej podstawie dziala ok 30 instytucji w PL i jest ok ;-) Oczywiscie jest uwierzytelnianie po radiusie. To tylko dodatkowy bajer.
W dniu 8 maja 2012 15:17 użytkownik Sławomir Paszkiewicz <paszczus@gmail.com
napisał:
No chyba sam znasz odpowiedz na to pytanie.
W dniu 8 maja 2012 15:15 użytkownik Marcin marcin@nicram.net napisał:
W dniu 8 maja 2012 15:06 użytkownik Sławomir Paszkiewicz < paszczus@gmail.com> napisał:
Jak zmienisz MAC to AP Cie rozlaczy.
a jak podepne się z "prawidłowym" aczkolwiek zmienionym mac'iem? wezmę sobie mac od sąsiada albo innymi sposobami? w każdym bądź razie będę się podpinał "prawidłowym" według systemu mac'iem to co wówczas, wpuścisz takiego klienta czy odrzucisz?
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 08.05.2012 15:19, Sławomir Paszkiewicz napisał(a):
Ogolnie jesli kogos to w ogole interesuje, to moj skrypt bazuje na tym: http://eduroam.pl/Dokumentacja/eduroam_zapobieganie_zmianie_IP.pdf [5]
Na tej podstawie dziala ok 30 instytucji w PL i jest ok ;-) Oczywiscie jest uwierzytelnianie po radiusie. To tylko dodatkowy bajer.
To taka ręcznie wykonana namiastka opcji dhcp client snooping, bo do option 82 jeszcze daleko, ale faktem jest, że dostęp do internetu mają tylko ci co dzierżawę z dhcp mają!
W dniu 08.05.2012 15:19, Sławomir Paszkiewicz napisał(a):
Ogolnie jesli kogos to w ogole interesuje, to moj skrypt bazuje na tym: http://eduroam.pl/Dokumentacja/eduroam_zapobieganie_zmianie_IP.pdf [5]
Na tej podstawie dziala ok 30 instytucji w PL i jest ok ;-) Oczywiscie jest uwierzytelnianie po radiusie. To tylko dodatkowy bajer.
Te skrypty to jakoś szczególnie interesujące nie są. Jak wygląda fragment ISC dhcpd.conf, który wywołuje skrypty?
on commit {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientMAC = concat (suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 2, 1))),2),":",suffix (concat("0", binary-to-ascii (16, 8, "", substring(hardware, 3, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 4,1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 5, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "",substring(hardware, 6, 1))),2));
execute("/usr/sbin/foo", "add", clientMAC, clientIP);
}
Podczas przydziania dzierzawy. Analogicznie dla on relase i on expiry.
W dniu 8 maja 2012 15:28 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 08.05.2012 15:19, Sławomir Paszkiewicz napisał(a):
Ogolnie jesli kogos to w ogole interesuje, to moj skrypt bazuje na tym: http://eduroam.pl/**Dokumentacja/eduroam_**zapobieganie_zmianie_IP.pdfhttp://eduroam.pl/Dokumentacja/eduroam_zapobieganie_zmianie_IP.pdf[5]
Na tej podstawie dziala ok 30 instytucji w PL i jest ok ;-) Oczywiscie jest uwierzytelnianie po radiusie. To tylko dodatkowy bajer.
Te skrypty to jakoś szczególnie interesujące nie są. Jak wygląda fragment ISC dhcpd.conf, który wywołuje skrypty?
-- Pozdrawiam Tomasz Chiliński, Chilan ______________________________**_________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/**mailman/listinfo/lmshttp://lists.lms.org.pl/mailman/listinfo/lms
W dniu 08.05.2012 15:30, Sławomir Paszkiewicz napisał(a):
on commit {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientMAC = concat (suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 2, 1))),2),":",suffix (concat("0", binary-to-ascii (16, 8, "", substring(hardware, 3, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 4,1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 5, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "",substring(hardware, 6, 1))),2));
execute("/usr/sbin/foo", "add", clientMAC, clientIP);
}
W skrypcie robisz jakiegoś forka, żeby od razu proces główny zakończył swoje działanie i pozwoliło to na kontynuowane pracy dla dhcpd? Z tego co piszą w dokumentacji wynika, że skrypt uruchamiany z poziomu execute jest wykonywany synchronicznie co oznacza, że dhcpd nie będzie kontynuowało swoich operacji, np. kolejnych przydziałów dzierżaw, dopóki skrypt nie zakończy działania. Nie miałeś z tym problemu?
Na poczatku byly problemy tego typu, ze w momencie gdy 2 userow sie podlaczalo w tym samym momencie to czasami sie zdarzalo tak, ze nie byly dopisywane regulki iptables. Po dodaniu sleep-a problemy sie skonczyly. Przy okazji tych regulek dodaje rowniez wpisy do bazy MySQL i mam tam nieco rozbieznosci, mozliwe ze jest to spowodowane tym co mowisz, aczkolwiek pewien nie jestem. Moze to jakis trop. Poza tym problemow nie ma.
W dniu 8 maja 2012 15:37 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 08.05.2012 15:30, Sławomir Paszkiewicz napisał(a):
on commit {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientMAC = concat (suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 2, 1))),2),":",suffix (concat("0", binary-to-ascii (16, 8, "", substring(hardware, 3, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 4,1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware, 5, 1))),2),":",suffix (concat ("0", binary-to-ascii (16, 8, "",substring(hardware, 6, 1))),2));
execute("/usr/sbin/foo", "add", clientMAC, clientIP);
}
W skrypcie robisz jakiegoś forka, żeby od razu proces główny zakończył swoje działanie i pozwoliło to na kontynuowane pracy dla dhcpd? Z tego co piszą w dokumentacji wynika, że skrypt uruchamiany z poziomu execute jest wykonywany synchronicznie co oznacza, że dhcpd nie będzie kontynuowało swoich operacji, np. kolejnych przydziałów dzierżaw, dopóki skrypt nie zakończy działania. Nie miałeś z tym problemu?
-- Pozdrawiam Tomasz Chiliński, Chilan ______________________________**_________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/**mailman/listinfo/lmshttp://lists.lms.org.pl/mailman/listinfo/lms
W dniu 8 maja 2012 14:27 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Tabela w bazie danych - nodesessions już jest.
to widać, ale tu nie chodzi o sesje, tylko o przynależność do klienta.
W oparciu o radiusa ładnie mi zbierają się logi sesji.
no zgadza się, radius ładnie to loguje, ale baza bardzo szybko się rozrasta. oczywiście jak są zmienne ip to jest jedyne i najlepsze źródło przydzielonych ip. ale jeśli przypisujemy klientowi adres na sztywno, to taka historia w lmsie by się przydała.
ISC DHCPD to kupa jakich mało - teoretycznie można swoje skrypty uruchamiać z poziomu daemona dhcp w momencie, gdy jest odnowienie dzierżawy, ale projektanci sugerują, że to raczej do dyndns powinno być używane...
z drugiej strony to są kolejne mechanizmy :) nie lepiej to rozwiązać w samym lms? jak robimy update w nodes to robi nam się update w tabeli np. nodeshistory.
uczestnicy (12)
-
A.L.E.C -
Daniel Kulesza -
iNTERNET -
Jacek Cieplok -
Marcin -
Me
-
Michał Szymoniak -
Piotr Zgódka -
Piotrek S. -
Rafał Ramocki -
Sławomir Paszkiewicz -
Tomasz Chiliński