Łukasz Wojciechowski napisał(a):
Jak spłodzę coś sensownego to napewno się podziele.
uhm. sprawdź to co commitnąłem. używam na małą skalę ale SOA#1, tzn od kiedy włączyłem nie mam problemów.
Możesz wskazać konkretnie ?
Ale co w przypadku gdy Klient ma np abonament na 64kbit/s na jeden z kompów a 128kbit/s na dwa inne (działające zamiennie) - taki oto przykład
[...]stosowane przez innych praktyki.
Taryfa występuje jako zobowiązanie i niema jako tako powiązania z hostami klienta.
Wszystko OK ale co w sytuacji, gdy klient ma wykupione dwie taryfy - np. 512kbit/s dla swojego kompa-zasysacza i 64kbit/s dla córki gadu-gadacza (przykład może mało realny ale to niema znaczenia)
Jak postapiłbyś wtedy ?
Olał ciepłym moczem. Ale nie jestem właścicielem żadej firmy więc wiesz. Znajomy właściciel ostatnio olał klienta bo ten miał problemy że gdy łączem 64 kbps ssie 8 KB/s a pingi są klasy >=500 ms. Klient 3-ci miesiąc czeka na założenie DSLa i pluje sobie w ucho.
Aktualnie to co jest Tobie potrzebne wymagałoby zmiany założeń w bazie i ui lmsa, aktualnie są robione finansowe zmiany a i jest co robić. 2 abonamenty? cóż rozbiłbym na 2 konta abonentów i 2 faktury.
Po prostu zadużo chromolenia aby usatysfakcjonować 1 klienta na 100. Jeśli chce mieć coś takiego to zaoferuj mu jakiś mini router+switch z vlanami klasy 1 wan + 4 lan z zarządzaniem pasmem. Kosztują teraz w okolicach do 200 zł pudełka które mu pozwolą na coś takiego i transfery w lanie z fullspeed + dodatkową separację.
Zbyt dużo własnych zmian w LMS'ie to powód dla którego zostałem przy v1.5 dlatego jestem ZA dokonywaniem jak najmniejszych zmian.
Wybiorę taki wariant. Założenie, że klient może mieć tylko jedno zobowiązanie i będzie to jedna ze zdefiniowanych taryf (LMSa używam tylko do zarządzania od strony "technicznej", do finansów jest inny system). A w przypadku, gdy klient będzie chciał mieć dwie różne taryfy to będzie "posiadał" dwa konta w LMS'ie - po jednym dla każdej taryfy. Dodatkowo - np taryfa 512kbit/s będzie wsytępowała w wersji 1, 2, 3, ... kompy bo są też sytuacje takie, że ktoś ma i płaci za dwa niezależne kompy na tej samej prędkości. Mając na sztywno zdefniowane taryfy będe mógł ustalić czy kilka hostów danego klienta ma być w jednej rurce czy każdy w oddzielnej. To będzie chyba najlepsze rozwiązanie.
Wszystko ładnie i pięknie ale przeróbki, które robię zostały wymuszone tym, że "zostaliśmy" LIR'em i chcemy dać każdemu klientowi publiczny adres IP więc z "frywolną" asdresacją/numeracją nie poszalejemy.
Więc baza adresów ip dodatkowa? hm. to co w lmsie jest nie miało być nigdy przygotowane na sytuacje "duży ISP". Po prostu nie ma tam miejsca na np dodatkowe ipki czy powiązania konkretnych 5 klas adresów z konkretnymi abonamentami i dopięcia jednego płatnika. po prostu nie jest to kobyła którą się przystosowywuje do lanu tylko na odwrót.
Nie wiem co masz na myśli pisząc "duży ISP" - do tej pory LMS w zakresie obsługi technicznej radzi sobie bez problemu z ilością hostów oscylującą w granicach 4 tys. przydzielonych do 14 sieci o wielkościach od /24 po /21. Do czasu opracowania całkowicie własnego systemu na bank będziemy korzystać z LMS'a.
ponownie - pytałem bardziej o przykłady postępowania stosowane przez was
Mam zasade: najmniejszym kosztem ugłaskać klienta. Ergo po co męczyć się skoro można coś zrobić prosto.
Hm. Jeśli bardzo mocno potrzebujesz mieć sytuację taką: Jan Kowalski .... abo 256 Ania kowalska abo 64 Koiwalski i sp-ka 1024
I wszystko na jedną fakturę to zrób tak: (venę mam, słuchaj mnie ludu, przemawiał będę [głosem króla Lemura z madakaskaru) a) żadne z w/w nie ma "wystawianej F-vat" b) należą do jednej grupy np Kowalski c) (tutaj zaczynają się zmiany które możesz spokojnie diffnąć i podesłać i sam 4 łapkami je dodam) d) zrób stronę z grupami powodującą że jakaś grupa może mieć atrybut "grupująca płatności" powoduje to że osoba "Kowalski" może należeć co najwyżej do jednej grupy tego typu e) skrypt wystawiający faktury lms-invoice skopiuj do lms-invoice-by-group, payments do payments-group. f) rzeczy takie jak ID klienta, adres etc... bierzemy z grupy, ostatniego dopisanego (do lmsa, o max ID z users ) traktujemy jako adres, konto abonamentowe etc... g) użytkownikom (aka clients) zawieś naliczanie aby zwykłe payments nie naliczało h) -group wystawia F-Vat zbiorczą i nalicza opłaty jednemu (maksymalnemu) klientowi
magia jest taka że jest to minimum zmian i pozwala na dodanie nawet do 1.4.x w/w funkcjonalności. "Maksymalny" też jest dobrany po to aby zrobić po prostu nowego gołego "płatnika" który może nie mieć nawet abonamentu i łatwo go było zmieniać.
oczywiście w/w wymaga mocnych testów i zmian chyba nawet w cutoff ale najszybciej to właśnie tak widzę.
To już wymaga zbyt wiele czasu a i przydatność jest mocno dyskusyjna - przynajmniej w moim przypadku.
dzięki za dyskusje
-- pozdrawiam Łukasz Wojciechowski