W dniu 2010-06-27 11:27, Robert Kois pisze:
> Dnia Sat, 26 Jun 2010 11:11:57 +0200, Przemysław Adam Śmiejek napisał(a):
>>> Jeszcze raz ci napiszę, celem eliksiru jest wymiana komunikatów
>>> rozliczeniowych. I to zadanie wypełnia
>> Ale jakość przekazywanych komunikatów jest niska.
> Wystarczająca do tego by rozliczyć płatnosci.

Ale niewystarczająca aby rozliczać je wygodnie i bez konieczności
obsługi przez człowieka.

>>> Ależ kto ci broni wprowadzić sobie dane klientów do bazy i identyfikować
>>> ich po numerze rachunku
>> Czyli muszę zaprogramować bazę i import do niej danych. A to jest mało
>> dostępne dla większości.
> No patrz, masz beznadziejnie zorganizowane rozliczenia.

Ano, od początku piszę, że to beznadziejnie zaprojektowali.


> Powinieneś coś z
> tym zrobić. no ale w tym momencie wygenerowałoby ci to koszty (albo
> oprogramowania, albo czasu poświęconego na wklepywanie).

Ano. Dlatego najlepiej jakby bank udostępniał to w rozsądnej postaci
normalnej. O czym piszę od początku.

>>> i powiedzmy nazwie (ja nadal uważam, że dane
>>> adresowe są w tym przypadku zbędne i nadmiarowe).
>> No nie są priorytetowe, owszem. Ale nie zaszkodzi jak są.
> Nie zaszkodziłoby jakby był regon, nip, pesel i parę innych rzeczy. Tylko
> po co?

Pewnie po nic, bo by rozdmuchiwało dane. Mówimy o danych, które i tak są
przesyłane, tylko nie rozdzielone. Więc akurat dodatnie jednego średnika
rozdzielającego nie jest dramatem.

>>>> Po drugie: powiązanie 1:1 konta z kontrahentem to duże uproszczenie. To
>>>> relacja często 1:n, a czasami wręcz n:n.
>>> Zaczynasz powoli rozumieć, że prosto nie jest.
>> Ja? Ja od początku mówiłem, że nie jest prosto i gdyby całość była
>> zaprojektowana zgodnie z teorią baz danych, to by było prosto.
>
> Teorie są zawsze śliczne, i jeszcze raz, elixir to nie baza danych, służy
> do rozliczeń między bankami.

A więc jeszcze raz: Czyli do synchronizacji danych pomiędzy bazami.
Niestety gubi część informacji zawartych w tych bazach. Co uważam za
bezsensowne, bo koszt niegubienia byłby zerowy.

> Po to powstał. Prawdopodobnie miał być jak
> najprostszy by łatwo było się do niego dostosować.

No właśnie teraz jest skomplikowany. Moje założenia upraszczają go.

>>>>> Nie. Ale nie widzę powodu by bank (odbiorca przelewu) przechowywał dane
>>>>> nadawcy w takiej samej formie jak dane swoich klientów.
>>>> A ja widzę. Choćby po to, żeby dać potrzebne narzędzie klientom.
>>> Dla mnie potrzebnym narzędziem byłby natychmiastowy "eliksir" do wszystkich
>>> banków. Jakoś nie ma.
>> Ale to jest utopia, w przeciwieństwie do zaprojektowania protokołu
>> wymiany tak, żeby dzielił dane sensownie.
> Dlaczego, to wcale nie tak bardzo skomplikowane.

Jest. Przesyłanie danych ,,na żywo'' pomiędzy wieloma bankami to
skomplikowane zadanie. Trzeba uwzględniać wiele przypadków i możliwości,
łącznie ze strefami czasowymi i innymi pierdołami.
Oraz wydajnością systemów. Zauważ, że nawet e-maile po świecie nie
latają na żywo. Jak wysyłam z mojego serwerka (5 adresów), to i idzie na
żywo. A jak np. operuję na WP, to już zauważyłem cykle przetwarzania.

>Za to koszt po stronie
> banków byłby spory a zysk (dla banku) niewielki. Pewnie kiedyś zrobią.

Nie sądzę. Tam chyba jeszcze jakieś inne są ZONKi, skoro nawet pomiędzy
mBankiem a Multibankiem idzie eliksirem, choć to prawie że jeden bank.

Ba! W początkach działania Inteligo, przelewy z Inteligo na Inteligo
szły w porach eliksirów tylko. Aczkolwiek potem szybko to uprościli.

Myślę, że tam jeszcze jakieś formalnoprawne są blokady, bo banki między
sobą ślą dane i te dane trzeba odpowiednio chyba przetworzyć jeszcze, bo
jak robię wewnątrz bazy mBankowej update i zmieniam stany kont, to
bankowo się nic nie zmienia. Ale już przy przelewie z obcego banku, one
jakoś pomiędzy sobą muszą to weryfikować oraz rozliczać prowizje i inne
pewnie duperele.

Do tego, jak se siądziemy i będziemy przerzucać pomiędzy kontami na
mBanku 10 groszy, to pół biedy, wygeneruje się długa historia operacji i
może się ktoś wkurwi w końcu, a może nie. A jak zrobisz to pomiędzy
bankami, to możesz np. przynieść spore straty banku na prowizje.

>>> Tak btw to ciekawe czy bank ma prawo przetwarzać
>>> takie dane kogoś kto nie jest jego klientem (ciekawe czy ustawodawca o tym
>>> pamiętał).
>> Ależ jest klientem. Wysyła do tamtego banku pieniądze. Jak Ty wysyłasz
>> do mnie list, to oskarżysz mnie o przetwarzanie danych, choć nie jestem
>> twoim klientem?
> Błedna analogia. Ja nie wysyłam pieniędzy bankowi, bank jest tylko
> pośrednikiem. Jakby poczta skanowała sobie wszystkie adresy z kopert i
> trzymała w bazie to by było bliższe temu co mamy przy przelewach

No i to robi. Tzn. niekoniecznie poczta i niekoniecznie w listach
nierejestrowanych (stąd ich nazwa), ale już np. kurier ma w bazie. Nawet
coraz częściej przez WWW możesz sobie sprawdzić kto i komu wysyłał i
nawet nazwisko tego, co odebrał.


>>> Jakich zestawień?
>> Opisałem je w wyjściowym liście.
> Ale rozdzielenie nazwy nadawcy od adresu nadal ci nie da tego co byś
> chciał.

Ja postuluję o rozdzielenie numeru konta od nadawcy jako priorytet
najwyższy, oraz podział na podstać jaką opisałem, jako priorytet niższy.

>>> Skoro nie masz pewności co w danej nazwie jest i po czym
>>> ją sortować. Nie ma standardów.
>> No i powinny być. Powinno być:
> [ciach]
> No to jeszcze teraz grzecznie ustal rozmiary pól

Nie jest to konieczne. Stosując zasadę KISS i normalny tekstowy
protokół, można nie ograniczać rozmiarów lub ograniczyć je technicznie
na wartości na tyle duże, że będzie to pomijalne.

> i ich wymagalność.


Wymagalność identyczna jak teraz. Niech będą i wszystkie puste, jeśli
chcesz mi anonimowy przelew nadać. Chodzi o to, że jeśli już bank dane
takie przesyła, żeby ich nie sklejał w 1 całość.

> I nagle
> zobaczysz, że są dane które pasować nie będą.

To się je zmiksuje jak obecnie. Ale to będą przypadki specjalne.


> Albo ich w danym momencie nie
> będzie.

No to nie będzie.

> A potem dostosuj wszystkie systemy bankowe do twojej wizji.

Nie widzę problemu. Skoro są dostosowane do obecnej wizji, to w czym
problem? Pakują w 1 pole? Pakują. To w 1 fazie wdrożenia by pakowały
nadal w 1 pole. A potem stopniowo by zaczęły pakować w odpowiednie pola,
bo i czemu nie, a klienci zadowoleni.

>> Aczkolwiek samo oddzielenie numeru
>> konta w osobne pole byłoby krokiem naprzód.
> Pretensje do mbanku.

Wysłałem.

>> Nie rozumiesz zagadnienia. Obecny format też można uznać za fajny, bo
>> odpowiednio wykwalifikowany pracownik przeklepie to do bazy i już.
>>
>> Sęk w tym, że jak muszę dokonać zestawienia: MOJE WPŁATY NA PRĄD ZA
>> OSTATNIE 5 LAT na przykład, albo MOJE PRZYCHODY OD xyz OD 2003, to
>> obecny format mBankowy nie pozwala tego uczynić szybko i wygodnie, tylko
>> wymaga żmudnej, wielogodzinnej analizy.
>
> Jakbyś od 5 lat wpisywał sobie wszystkie płatności tak jak chcsz do własnej
> bazy danych to nie miałbyś problemu.

No właśnie. Czyli wymaga nakładu pracy z mojej strony. Nie ważne czy
jednorazowego trwającego wiele godzin czy rozłożonego na kawałki,
trwającego sumarycznie jeszcze więcej godzin.

> Nie robiłeś tego a przeciez eksport do
> cvsa od początku chyba był taki.

A nawet go nie było.

> A teraz mirmiłujesz.

Nie rozumiesz zagadnienia :(


>> Albo chciałbym automatycznie wczytywać to do systemu rozliczeń.
> Niestety nikt nie obiecywał ci, że historia transakcji na coś takiego
> pozwoli

I to automatycznie sprawia, że nie wolno mi sugerować, że powinna?

--
Przemysław Adam Śmiejek