W dniu 2010-06-25 10:10, Robert Kois pisze:
> Dnia Thu, 24 Jun 2010 19:34:32 +0200, Przemysław Adam Śmiejek napisał(a):
>
>>>> Czyli już sam eliksir jest spierdolony....
>>> Ale dlaczego spierdolony?
>> Poszukaj sobie jakiegoś tekstu o bazach danych i postaciach normalnych.
>> Ta urąga dowolnej postaci.
>
> Elixir nie jest bazą danych.

Ale o ile dobrze rozumiem, jest protokołem transmisji danych pomiędzy
bazami.

>>> Uproszczony po prostu.
>> Nie uproszczony, a skomplikowany nadmiernie z zepsutymi własnościami
>> sortowania i wyszukiwania. Zupełnie niezgodny nawet z bardzo liberalnymi
>> i bałaganiarskimi postaciami normalnymi, o bardziej wymagających nie
>> wspominam.
> Bzdura. Elixir nie służy do sortowania, wyszukiwania itp.

Tak, do tego służy SZBD.

>>>> Ja pierdzielę, czy na takim
>>>> poziomie systemy projektują gimnazjaliści? Przecież o podziale pól w
>>>> bazie to w I klasie liceumu się naucza.
>>> Ale dla elixiru te dane są nieistotne.
>> Eliksir to sposób przesyłu danych pomiędzy bazami, mylę się? A skoro
>> tak, to nie powinien psuć tych baz.
> A on je psuje?

Psuje.

> Kto powiedział, że bank otrzymujący przelew ma trzymać dane
> nadawcy w formie dla ciebie wygodnej?

Powinien otrzymać w postaci, w jakiej są w bazach banków.

> Banku odbiorcy dane nadawcy nie
> powinny obchodzić. Bo i niby dlaczego.

No jak dlaczego? Dlatego, że to istotne dane w transakcjach.
Postulujesz, żeby je całkiem wycofać?

>>> Podejrzewam, ze zaprojektowano to
>>> tak by jak najprościej było się dołaczyć do systemu.
>> Podział na pola nic by nie skomplikował.
> Ale widziałeś kiedyś jakąś bazę z prawdziwymi danymi klientów?

Oczywiście.

> Bo zabawny
> pomysł, że podzielimy na pola: Imię, Nazwisko, Ulica, Miejscowość to możesz
> sobie w gimnazjum stosować. Przelewy robią też firmy, robione też są z kont
> wspólnych, niektórzy mają 2 imiona, niektórzy 3. I parę innych drobiazgów.

No i? To przeszkadza na oddzielenie ulicy od miejscowości, a nazwy od
tychże. Przecież nie wymagałem rozdziału imienia od nazwiska.


> Jeszcze raz. Elixir nie jest do tego by ci się wygodnie dane sortowało.
> Zrób sobie bazę danych klientów i sortuj po jednoznacznym numerze rachunku.

Tego również mBank nie rozdziela.

> To ci cvs z mbanku da (jak już rozdzielą pole z nadawcą od pola z tytułem
> przelewu).

I numerem konta odbiorcy. Aczkolwiek nadal to będzie wymagało
specjalnego oprogramowania. Ale owszem, będzie już lepiej.

>>> Z punktu widzenia
>>> eliksiru tych danych mogłoby wogóle nie być.
>> <złośliwość>Kim są wogóle? Co chwilę je widuję w sieci, a wciąż nie
>> wiadomo co to :D</złośliwość>
> Chyba za głębokie dla mnie.

Zauważyłem.

Wyjaśnienie: Pisałeś coś o jakiś wogólach. Sporo osób o nich pisze w
Sieci. Niestety nie umiem znaleźć definicji wogóli i są one dla mnie
bytem obcym.

--
Przemysław Adam Śmiejek

do góry

(25.06.2010 10:49), Przemysław Adam Śmiejek wrote:
> W dniu 2010-06-25 10:10, Robert Kois pisze:
[...]
>> Chyba za głębokie dla mnie.
>
> Zauważyłem.
>
> Wyjaśnienie: Pisałeś coś o jakiś wogólach. Sporo osób o nich pisze w
> Sieci. Niestety nie umiem znaleźć definicji wogóli i są one dla mnie
> bytem obcym.

Bo zamiast wprost zwrócić uwagę że popełnił błąd ortograficzny, to się
przez 2 posty wyzłośliwiasz.

Tak samo opisujesz problem do banku i dziwisz się że cię nie rozumieją.

p. m.

do góry

W dniu 2010-06-25 11:16, mvoicem pisze:
> Bo zamiast wprost zwrócić uwagę że popełnił błąd ortograficzny, to się
> przez 2 posty wyzłośliwiasz.

To tak tylko na marginesie było. Wydawało mi się, że skoro mu zwróciłem
uwagę, to załapie.



--
Przemysław Adam Śmiejek

do góry

Dnia Fri, 25 Jun 2010 10:49:18 +0200, Przemysław Adam Śmiejek napisał(a):

>>>>> Czyli już sam eliksir jest spierdolony....
>>>> Ale dlaczego spierdolony?
>>> Poszukaj sobie jakiegoś tekstu o bazach danych i postaciach normalnych.
>>> Ta urąga dowolnej postaci.
>> Elixir nie jest bazą danych.
> Ale o ile dobrze rozumiem, jest protokołem transmisji danych pomiędzy
> bazami.

Jest systemem rozliczeniowym.

>>>>> Ja pierdzielę, czy na takim
>>>>> poziomie systemy projektują gimnazjaliści? Przecież o podziale pól w
>>>>> bazie to w I klasie liceumu się naucza.
>>>> Ale dla elixiru te dane są nieistotne.
>>> Eliksir to sposób przesyłu danych pomiędzy bazami, mylę się? A skoro
>>> tak, to nie powinien psuć tych baz.
>> A on je psuje?
> Psuje.

Nie psuje, przekazuje dokładnie to co dostaje. Nie modyfikuje danych.

>> Kto powiedział, że bank otrzymujący przelew ma trzymać dane
>> nadawcy w formie dla ciebie wygodnej?
> Powinien otrzymać w postaci, w jakiej są w bazach banków.

A w każdym banku jest inaczej. Tu pole na 40 znaków tam na 80, tu najpierw
nazwisko, tam najpierw imiona. Jak już mówiłem to dałoby się bez problemu
zrobić ale nie do tego projektowano elixir. Działa - nie zmieniają. Swoje
zadania wypełnia.

>> Banku odbiorcy dane nadawcy nie
>> powinny obchodzić. Bo i niby dlaczego.
> No jak dlaczego? Dlatego, że to istotne dane w transakcjach.

Niby dlaczego istotne? Numer rachunku jest wystarczający do identyfikacji
nadawcy. Dla wygody odbiorcy (podkreślam wygody) wystarczyłaby sama nazwa
nadawcy i tytuł przelewu.

> Postulujesz, żeby je całkiem wycofać?

Nie. Ale nie widzę powodu by bank (odbiorca przelewu) przechowywał dane
nadawcy w takiej samej formie jak dane swoich klientów.

>> Bo zabawny
>> pomysł, że podzielimy na pola: Imię, Nazwisko, Ulica, Miejscowość to możesz
>> sobie w gimnazjum stosować. Przelewy robią też firmy, robione też są z kont
>> wspólnych, niektórzy mają 2 imiona, niektórzy 3. I parę innych drobiazgów.
> No i? To przeszkadza na oddzielenie ulicy od miejscowości, a nazwy od
> tychże. Przecież nie wymagałem rozdziału imienia od nazwiska.

No to po co komu taki podział? Nie masz łatwej metody ustalenie co jest
nazwiskiem, imionami, nazwą firmy, czy co tam sobie wymyślisz.
Dane adresowe nadawcy przelewu imho nie powinny być przesyłane, bo nie są
potrzebne do identyfikacji nadawcy.

>> Jeszcze raz. Elixir nie jest do tego by ci się wygodnie dane sortowało.
>> Zrób sobie bazę danych klientów i sortuj po jednoznacznym numerze rachunku.
> Tego również mBank nie rozdziela.

Problem mbanku nie Elixiru.

>>>> Z punktu widzenia
>>>> eliksiru tych danych mogłoby wogóle nie być.
>>> <złośliwość>Kim są wogóle? Co chwilę je widuję w sieci, a wciąż nie
>>> wiadomo co to :D</złośliwość>
>> Chyba za głębokie dla mnie.
> Zauważyłem.
> Wyjaśnienie: Pisałeś coś o jakiś wogólach. Sporo osób o nich pisze w
> Sieci. Niestety nie umiem znaleźć definicji wogóli i są one dla mnie
> bytem obcym.

Wystarczyło podkreślić i wytknąć błąd.

--
Kojer

do góry

W dniu 2010-06-25 12:44, Robert Kois pisze:
>>> Kto powiedział, że bank otrzymujący przelew ma trzymać dane
>>> nadawcy w formie dla ciebie wygodnej?
>> Powinien otrzymać w postaci, w jakiej są w bazach banków.
> A w każdym banku jest inaczej. Tu pole na 40 znaków tam na 80, tu najpierw
> nazwisko, tam najpierw imiona. Jak już mówiłem to dałoby się bez problemu
> zrobić ale nie do tego projektowano elixir. Działa - nie zmieniają. Swoje
> zadania wypełnia.

No to go źle zaprojektowano. Wystarczyło zaprojektować właściwie i już.
I banki by je wypełniały. Gdyby Bank miał nie pasujące pola, to by się
dostosował i już.

>>> Banku odbiorcy dane nadawcy nie
>>> powinny obchodzić. Bo i niby dlaczego.
>> No jak dlaczego? Dlatego, że to istotne dane w transakcjach.
> Niby dlaczego istotne? Numer rachunku jest wystarczający do identyfikacji
> nadawcy.

Nieprawda.
Po pierwsze: Człowiek nie jest w stanie tego ogarnąć, a mozolne
porównywanie jest szaleństwem.

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.

> 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.

>>> Bo zabawny
>>> pomysł, że podzielimy na pola: Imię, Nazwisko, Ulica, Miejscowość to możesz
>>> sobie w gimnazjum stosować. Przelewy robią też firmy, robione też są z kont
>>> wspólnych, niektórzy mają 2 imiona, niektórzy 3. I parę innych drobiazgów.
>> No i? To przeszkadza na oddzielenie ulicy od miejscowości, a nazwy od
>> tychże. Przecież nie wymagałem rozdziału imienia od nazwiska.
> No to po co komu taki podział?

Opisałem. Dla zrobienia zestawień.

> Nie masz łatwej metody ustalenie co jest
> nazwiskiem, imionami, nazwą firmy, czy co tam sobie wymyślisz.

Nazwa to nazwa. Owszem, podział na imiona i nazwiska byłby miły, ale
rzadko przydatny, a jak piszesz, rodzący trochę więcej problemów. Choć
niewiele.

> Dane adresowe nadawcy przelewu imho nie powinny być przesyłane, bo nie są
> potrzebne do identyfikacji nadawcy.

Są. Czasami nadawca ma wiele oddziałów, wiele adresów etc.

>>> Jeszcze raz. Elixir nie jest do tego by ci się wygodnie dane sortowało.
>>> Zrób sobie bazę danych klientów i sortuj po jednoznacznym numerze rachunku.
>> Tego również mBank nie rozdziela.
> Problem mbanku nie Elixiru.

No to go zgłaszam.

>>>>> Z punktu widzenia
>>>>> eliksiru tych danych mogłoby wogóle nie być.
>>>> <złośliwość>Kim są wogóle? Co chwilę je widuję w sieci, a wciąż nie
>>>> wiadomo co to :D</złośliwość>
>>> Chyba za głębokie dla mnie.
>> Zauważyłem.
>> Wyjaśnienie: Pisałeś coś o jakiś wogólach. Sporo osób o nich pisze w
>> Sieci. Niestety nie umiem znaleźć definicji wogóli i są one dla mnie
>> bytem obcym.
> Wystarczyło podkreślić i wytknąć błąd.

No to przecież napisałem o jakie słówko mi chodzi.

--
Przemysław Adam Śmiejek

do góry

Dnia Fri, 25 Jun 2010 12:56:00 +0200, Przemysław Adam Śmiejek napisał(a):

>>>> Kto powiedział, że bank otrzymujący przelew ma trzymać dane
>>>> nadawcy w formie dla ciebie wygodnej?
>>> Powinien otrzymać w postaci, w jakiej są w bazach banków.
>> A w każdym banku jest inaczej. Tu pole na 40 znaków tam na 80, tu najpierw
>> nazwisko, tam najpierw imiona. Jak już mówiłem to dałoby się bez problemu
>> zrobić ale nie do tego projektowano elixir. Działa - nie zmieniają. Swoje
>> zadania wypełnia.
> No to go źle zaprojektowano. Wystarczyło zaprojektować właściwie i już.
> I banki by je wypełniały. Gdyby Bank miał nie pasujące pola, to by się
> dostosował i już.

Hehehehe.
Jeszcze raz ci napiszę, celem eliksiru jest wymiana komunikatów
rozliczeniowych. I to zadanie wypełnia

>>>> Banku odbiorcy dane nadawcy nie
>>>> powinny obchodzić. Bo i niby dlaczego.
>>> No jak dlaczego? Dlatego, że to istotne dane w transakcjach.
>> Niby dlaczego istotne? Numer rachunku jest wystarczający do identyfikacji
>> nadawcy.
> Nieprawda.
> Po pierwsze: Człowiek nie jest w stanie tego ogarnąć, a mozolne
> porównywanie jest szaleństwem.

Ależ kto ci broni wprowadzić sobie dane klientów do bazy i identyfikować
ich po numerze rachunku i powiedzmy nazwie (ja nadal uważam, że dane
adresowe są w tym przypadku zbędne i nadmiarowe).

> 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.

>> 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. Tak btw to ciekawe czy bank ma prawo przetwarzać
takie dane kogoś kto nie jest jego klientem (ciekawe czy ustawodawca o tym
pamiętał).

>>>> Bo zabawny
>>>> pomysł, że podzielimy na pola: Imię, Nazwisko, Ulica, Miejscowość to możesz
>>>> sobie w gimnazjum stosować. Przelewy robią też firmy, robione też są z kont
>>>> wspólnych, niektórzy mają 2 imiona, niektórzy 3. I parę innych drobiazgów.
>>> No i? To przeszkadza na oddzielenie ulicy od miejscowości, a nazwy od
>>> tychże. Przecież nie wymagałem rozdziału imienia od nazwiska.
>> No to po co komu taki podział?
> Opisałem. Dla zrobienia zestawień.

Jakich zestawień? Skoro nie masz pewności co w danej nazwie jest i po czym
ją sortować. Nie ma standardów.

>> Nie masz łatwej metody ustalenie co jest
>> nazwiskiem, imionami, nazwą firmy, czy co tam sobie wymyślisz.
> Nazwa to nazwa. Owszem, podział na imiona i nazwiska byłby miły, ale
> rzadko przydatny, a jak piszesz, rodzący trochę więcej problemów. Choć
> niewiele.

No to w czym problem? Jak już ci oddzielą tytuł przelewu to sortuj po całej
nazwie.

>> Dane adresowe nadawcy przelewu imho nie powinny być przesyłane, bo nie są
>> potrzebne do identyfikacji nadawcy.
> Są. Czasami nadawca ma wiele oddziałów, wiele adresów etc.

I jak rozumiem z różnych oddziałów dostajesz tego samego dnia przelewy o
tej samej kwocie i nie masz jak tego zidentyfikować? Może poproś by ci
numer faktury w tytule przelewu wpisywali, będzie prościej.



--
Kojer

do góry

Dnia Fri, 25 Jun 2010 10:24:36 +0200, witrak() napisał(a):

> Problem w tym, że powyższe uwagi w całości są jak "kulą w płot" - skoro
> inne banki mogą generować dane w zadowalającym klientów formacie...

Ale ja nie dyskutuję o mbanku, odniosłem się tylko do elixiru.

--
Kojer

do góry

W dniu 2010-06-25 14:08, Robert Kois pisze:
>> No to go źle zaprojektowano. Wystarczyło zaprojektować właściwie i już.
>> I banki by je wypełniały. Gdyby Bank miał nie pasujące pola, to by się
>> dostosował i już.
> Hehehehe.
> Jeszcze raz ci napiszę, celem eliksiru jest wymiana komunikatów
> rozliczeniowych. I to zadanie wypełnia

Ale jakość przekazywanych komunikatów jest niska.

>>>>> Banku odbiorcy dane nadawcy nie
>>>>> powinny obchodzić. Bo i niby dlaczego.
>>>> No jak dlaczego? Dlatego, że to istotne dane w transakcjach.
>>> Niby dlaczego istotne? Numer rachunku jest wystarczający do identyfikacji
>>> nadawcy.
>> Nieprawda.
>> Po pierwsze: Człowiek nie jest w stanie tego ogarnąć, a mozolne
>> porównywanie jest szaleństwem.
> 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.

> 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ą.

>> 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.

>>> 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.


> 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?


>>>>> Bo zabawny
>>>>> pomysł, że podzielimy na pola: Imię, Nazwisko, Ulica, Miejscowość to możesz
>>>>> sobie w gimnazjum stosować. Przelewy robią też firmy, robione też są z kont
>>>>> wspólnych, niektórzy mają 2 imiona, niektórzy 3. I parę innych drobiazgów.
>>>> No i? To przeszkadza na oddzielenie ulicy od miejscowości, a nazwy od
>>>> tychże. Przecież nie wymagałem rozdziału imienia od nazwiska.
>>> No to po co komu taki podział?
>> Opisałem. Dla zrobienia zestawień.
> Jakich zestawień?

Opisałem je w wyjściowym liście.

> 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ć:

Nazwa kontrahenta
adres kontrahenta
kod kontrahenta
miasto kontrahenta
kraj kontrahenta
tytuł przelewu
konto nadawcy
+ daty

Lub w wersji rozbudowańszej, ale MI to już nie jest potrzebne i
faktycznie wymagało by zmian nieco szerszych:

Nazwisko lub nazwa kontrahenta
imię kontrahenta
adres kontrahenta
kod kontrahenta
miasto kontrahenta
kraj kontrahenta
tytuł przelewu
konto nadawcy
+ daty


>>> Nie masz łatwej metody ustalenie co jest
>>> nazwiskiem, imionami, nazwą firmy, czy co tam sobie wymyślisz.
>> Nazwa to nazwa. Owszem, podział na imiona i nazwiska byłby miły, ale
>> rzadko przydatny, a jak piszesz, rodzący trochę więcej problemów. Choć
>> niewiele.
> No to w czym problem? Jak już ci oddzielą tytuł przelewu to sortuj po całej
> nazwie.

No ale już po miastach nie posortuję. Aczkolwiek samo oddzielenie numeru
konta w osobne pole byłoby krokiem naprzód.


>>> Dane adresowe nadawcy przelewu imho nie powinny być przesyłane, bo nie są
>>> potrzebne do identyfikacji nadawcy.
>> Są. Czasami nadawca ma wiele oddziałów, wiele adresów etc.
> I jak rozumiem z różnych oddziałów dostajesz tego samego dnia przelewy o
> tej samej kwocie i nie masz jak tego zidentyfikować? Może poproś by ci
> numer faktury w tytule przelewu wpisywali, będzie prościej.


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.

Albo chciałbym automatycznie wczytywać to do systemu rozliczeń.

--
Przemysław Adam Śmiejek

do góry

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ż 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. Powinieneś coś z
tym zrobić. no ale w tym momencie wygenerowałoby ci to koszty (albo
oprogramowania, albo czasu poświęconego na wklepywanie).

>> 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?

>>> 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. Po to powstał. Prawdopodobnie miał być jak
najprostszy by łatwo było się do niego dostosować.

>>>> 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. Za to koszt po stronie
banków byłby spory a zysk (dla banku) niewielki. Pewnie kiedyś zrobią.

>> 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

>> Jakich zestawień?
> Opisałem je w wyjściowym liście.

Ale rozdzielenie nazwy nadawcy od adresu nadal ci nie da tego co byś
chciał.

>> 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 i ich wymagalność. I nagle
zobaczysz, że są dane które pasować nie będą. Albo ich w danym momencie nie
będzie. A potem dostosuj wszystkie systemy bankowe do twojej wizji.
to da się zrobić jak zmienisz ustawę i zmusisz banki do tego. Jak myślisz,
kto za to zapłaci?

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

Pretensje do mbanku.

> 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. Nie robiłeś tego a przeciez eksport do
cvsa od początku chyba był taki. A teraz mirmiłujesz.

> Albo chciałbym automatycznie wczytywać to do systemu rozliczeń.

Niestety nikt nie obiecywał ci, że historia transakcji na coś takiego
pozwoli

--
Kojer

do góry

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

do góry