Witam,

napisałem do nich w sprawie złego eksportu do CSV mejla na początku
czerwca. Po tygodniu mniej więcej odpisali:

uprzejmie informuje, ze nie mamy zgloszonego problemu z opcja
eksportu historii. Jednakze jesli caly czas wystepuje u Pana na
rachunku blad proponuje aby Pan zlozyl dyspozycje na wyjasnienie
zaistnialej sytuacji

Napisałem im więc:

========
Problem występuje u wszystkich. Proszę przeczytać dyskusję na grupie
pl.banki:

http://groups.google.com/group/pl.biznes.banki/browse_thread/thread/51046c08159e2e6/1fffe0ef088e63f6

Nie ma tam wiele listów, a myślę, że wyjaśnia problem szerzej.
========

Znów minęło 10 dni i dostałem odpowiedź :

========
  uprzejmie informujďż˝, ďż˝e drogďż˝ mailowďż˝ mogďż˝ udzielaďż˝ jedynie ogďż˝lnych
informacji dotycz�cych produkt�w oferowanych przez mBank. W celu
z�o�enia dyspozycji na wyja�nienie prosz� o kontakt z mLini�
telefonicznie pod numerem 801300800 lub 426300800.
========



Normalnie szczyt genialności.



--
Przemysław Adam Śmiejek

(23.06.2010 14:43), Przemysław Adam Śmiejek wrote:
[...]

========
  uprzejmie informujďż˝, ďż˝e drogďż˝ mailowďż˝ mogďż˝ udzielaďż˝ jedynie ogďż˝lnych
informacji dotycz�cych produkt�w oferowanych przez mBank. W celu
z�o�enia dyspozycji na wyja�nienie prosz� o kontakt z mLini�
telefonicznie pod numerem 801300800 lub 426300800.
========

Dosłownie z takim kodowaniem pliterek czy ci się źle przekleiło?

A swoją drogą - to jednak w pewnym sensie sam sobie jesteś winien.
Zamiast od adama i ewy wytłumaczyć co i jak, dałeś linka na grupę co
jest odstraszające:

1. bo jakiś link,
2. bo niedysponent może nie wiedzieć co to grupa dyskusyjna
3. bo trzeba się wczytać, jednak to jest dyskusja, są głosy za i przeciw ...

Więc dałeś im niejako pretekst żeby cię spuścili na drzewo. Jakbyś
normalnie się pytał - to jest (niewielka) szansa że byś się dopytał.

p. m.

W dniu 2010-06-23 15:10, mvoicem pisze:

(23.06.2010 14:43), Przemysław Adam Śmiejek wrote:
[...]

========
  uprzejmie informujďż˝, ďż˝e drogďż˝ mailowďż˝ mogďż˝ udzielaďż˝ jedynie ogďż˝lnych
informacji dotycz�cych produkt�w oferowanych przez mBank. W celu
z�o�enia dyspozycji na wyja�nienie prosz� o kontakt z mLini�
telefonicznie pod numerem 801300800 lub 426300800.
========

Dosłownie z takim kodowaniem pliterek czy ci się źle przekleiło?

Takim, ale nie wiem na ile to wina szmaciatego Thunderbirda. Listy od
nich z definicji źle działają.

A swoją drogą - to jednak w pewnym sensie sam sobie jesteś winien.
Zamiast od adama i ewy wytłumaczyć co i jak, dałeś linka na grupę co
jest odstraszające:

1. bo jakiś link,

No do wątku w guglu.

2. bo niedysponent może nie wiedzieć co to grupa dyskusyjna

Nie musi. Gugiel to przecie wyświetla w przeglądarce.

Więc dałeś im niejako pretekst żeby cię spuścili na drzewo. Jakbyś
normalnie się pytał - to jest (niewielka) szansa że byś się dopytał.

Dobrze, jeszcze raz im napiszę.

--
Przemysław Adam Śmiejek

Przemysław Adam Śmiejek pisze:

Dobrze, jeszcze raz im napiszę.

   Napisz. Ja rzuciłem okiem na dyskusję, i w sumie teĹź bym nie wiedział, o co Ci konkretnie chodziło i na jakie pytanie mam odpowiadać.

--
Liwiusz

W dniu 2010-06-23 15:20, Liwiusz pisze:

Przemysław Adam Śmiejek pisze:

Dobrze, jeszcze raz im napiszę.

  Napisz. Ja rzuciłem okiem na dyskusję, i w sumie teĹź bym nie wiedział,
o co Ci konkretnie chodziło i na jakie pytanie mam odpowiadać.

No jak? Przecie wyraźnie napisane, że nie są oddzielone elementy
przelewu, tylko jest on wpakowany w jedno pole i nie da się go użyć do
filtrowania czy sortowania.

--
Przemysław Adam Śmiejek

Przemysław Adam Śmiejek pisze:

W dniu 2010-06-23 15:20, Liwiusz pisze:

Przemysław Adam Śmiejek pisze:

Dobrze, jeszcze raz im napiszę.

  Napisz. Ja rzuciłem okiem na dyskusję, i w sumie teĹź bym nie wiedział,
o co Ci konkretnie chodziło i na jakie pytanie mam odpowiadać.

No jak? Przecie wyraźnie napisane, że nie są oddzielone elementy
przelewu, tylko jest on wpakowany w jedno pole i nie da się go użyć do
filtrowania czy sortowania.

"czy ktoś wie może, czy mBank planuje naprawić eksport do CSV? Opcja ta
pojawiła się już dawno temu, ale wciąż nie działa. Co modernizacja
systemu, to sprawdzam, ale wciąż niestety eksportuje całą zawartość
opisu przelewu do jednej komórki i wciąż nie umiem filtrować po
kontrahentach, co jest istotne."


Ja tu nie widzę opisu problemu. Co to właściwie znaczy, że "opis przelewu" jest w jednej komórce? Jak jest w jednej, to niech będzie w jednej. Niby dlaczego opis przelewu (który rozumiem jako "tytuł przelewu") ma być dzielony na dwie komórki?

Chcesz rozwiązania problemu, to go opisz dokładnie, a nie linkujesz do jakichś trollowych dyskusji.

--
Liwiusz

(23.06.2010 15:57), Liwiusz wrote:

Przemysław Adam Śmiejek pisze:

W dniu 2010-06-23 15:20, Liwiusz pisze:

Przemysław Adam Śmiejek pisze:

Dobrze, jeszcze raz im napiszę.

  Napisz. Ja rzuciłem okiem na dyskusję, i w sumie teĹź bym nie wiedział,
o co Ci konkretnie chodziło i na jakie pytanie mam odpowiadać.

No jak? Przecie wyraźnie napisane, że nie są oddzielone elementy
przelewu, tylko jest on wpakowany w jedno pole i nie da się go użyć do
filtrowania czy sortowania.

"czy ktoś wie może, czy mBank planuje naprawić eksport do CSV? Opcja ta
pojawiła się już dawno temu, ale wciąż nie działa. Co modernizacja
systemu, to sprawdzam, ale wciąż niestety eksportuje całą zawartość
opisu przelewu do jednej komórki i wciąż nie umiem filtrować po
kontrahentach, co jest istotne."


Ja tu nie widzę opisu problemu. Co to właściwie znaczy, że "opis
przelewu" jest w jednej komórce? Jak jest w jednej, to niech będzie w
jednej. Niby dlaczego opis przelewu (który rozumiem jako "tytuł
przelewu") ma być dzielony na dwie komórki?

Chcesz rozwiązania problemu, to go opisz dokładnie, a nie linkujesz do
jakichś trollowych dyskusji.

Fakt, brakuje tutaj jasno napisanego że opis przelewu jest złączony w
jednej komórce z nadawcą przelewu. Trzeba się domyślać z tego że "nie
umiem filtrować po kontrahentach".

A we wszelkich kontaktach z *liniami, supportami itd... trzeba się
wyrażać maksymalnie jasno, inaczej mają doskonały pretekst do tego żeby
spuścić na drzewo.

p. m.

W dniu 2010-06-23 15:57, Liwiusz pisze:

Chcesz rozwiązania problemu, to go opisz dokładnie, a nie linkujesz do
jakichś trollowych dyskusji.

Nie trollowych, a normalnych. Ale OK, napisałem im tak:

===========

Witam,

spróbuję jeszcze raz. To nie problem mój z moim kontem, a wszystkich.
Format pliku CSV oznacza, że można go filtrować, sortować i przetwarzać
przy pomocy róşnego oprogramowania, w tym arkusza kalkulacyjnego.
Warunkiem jest to, żeby poszczególne pola były oddzielone zgodnie z
zasadą, znakiem średnika lub podobnym, byle schematycznie.

Niestety w waszych plikach CSV wrzucono w jedno pole tytuł przelewu i
dane nadawcy. Nie jest więc możliwe zrobienie zestawień typu ,,wszystkie
przelewy do Kowalskiego'', ,,wszystkie przelewy do ludzi z Zabrza'',
,,wszystkie przelewy o tytule KACZKA'' czy ,,wszystkie przelewy na konto
X''.

Prawidłowo zbudowany plik CSV odpowiadałby polom w bazie danych, a więc
zlane w jedno pole powinno zostać podzielone np. tak:

Nazwa kontrahenta; adres kontrahenta; miasto kontrahenta; konto kontrahenta

wtedy można by zastosować choćby arkusz do zrobienia newralgicznych
zestawień. W tej chwili jest to po prostu niemożliwe.

Dlatego proszę o przekazanie problemu technikom, a nie odsyłanie mnie do
mLinii, która mi nie pomoże, bo nic więcej autoryzacja moja nie wniesie.

===========


czy teraz jasno, czy jeszcze za mało?

--
Przemysław Adam Śmiejek

(23.06.2010 20:33), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-23 15:57, Liwiusz pisze:

Chcesz rozwiązania problemu, to go opisz dokładnie, a nie linkujesz do
jakichś trollowych dyskusji.

Nie trollowych, a normalnych. Ale OK, napisałem im tak:

===========

Witam,

spróbuję jeszcze raz. To nie problem mój z moim kontem, a wszystkich.
Format pliku CSV oznacza, że można go filtrować, sortować i przetwarzać
przy pomocy róşnego oprogramowania, w tym arkusza kalkulacyjnego.
Warunkiem jest to, żeby poszczególne pola były oddzielone zgodnie z
zasadą, znakiem średnika lub podobnym, byle schematycznie.

Niestety w waszych plikach CSV wrzucono w jedno pole tytuł przelewu i
dane nadawcy. Nie jest więc możliwe zrobienie zestawień typu ,,wszystkie
przelewy do Kowalskiego'', ,,wszystkie przelewy do ludzi z Zabrza'',
,,wszystkie przelewy o tytule KACZKA'' czy ,,wszystkie przelewy na konto
X''.

Prawidłowo zbudowany plik CSV odpowiadałby polom w bazie danych, a więc
zlane w jedno pole powinno zostać podzielone np. tak:

Nazwa kontrahenta; adres kontrahenta; miasto kontrahenta; konto kontrahenta

wtedy można by zastosować choćby arkusz do zrobienia newralgicznych
zestawień. W tej chwili jest to po prostu niemożliwe.

Dlatego proszę o przekazanie problemu technikom, a nie odsyłanie mnie do
mLinii, która mi nie pomoże, bo nic więcej autoryzacja moja nie wniesie.

===========


czy teraz jasno, czy jeszcze za mało?

Jasno, ale pewnie ci odpowiedzą że dziękują za sugestię, postarają się
ją uwzględnić w swoich planach modernizacji serwisu :).

No bo chyba się nie spodziewasz że nagle zmienią funkcjonalność serwisu :).

p. m.

W dniu 2010-06-23 20:43, mvoicem pisze:

Jasno, ale pewnie ci odpowiedzą że dziękują za sugestię, postarają się
ją uwzględnić w swoich planach modernizacji serwisu :).

No bo chyba się nie spodziewasz że nagle zmienią funkcjonalność serwisu :).

Nie musi być nagle, byle przy następnej zmianie zmienili. To tylko kilka
linijek kodu generującego dane.

--
Przemysław Adam Śmiejek

Dnia Wed, 23 Jun 2010 20:50:28 +0200, Przemysław Adam Śmiejek napisał(a):

Nie musi być nagle, byle przy następnej zmianie zmienili. To tylko kilka
linijek kodu generującego dane.

Obawiam się jednak, że nie, bo jakby było jak mówisz, to raczej dawno by już to zmienili.



--
xbartx

W dniu 2010-06-24 08:27, xbartx pisze:

Obawiam się jednak, że nie, bo jakby było jak mówisz, to raczej dawno by już to zmienili.

Po prostu nie myśleli o tym. No chyba ze faktycznie w bazie też tak
trzymają w 1 polu.

--
Przemysław Adam Śmiejek

(24.06.2010 10:24), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-24 08:27, xbartx pisze:

Obawiam się jednak, że nie, bo jakby było jak mówisz, to raczej dawno by już to zmienili.

Po prostu nie myśleli o tym. No chyba ze faktycznie w bazie też tak
trzymają w 1 polu.

Mogli pomyśleć ale wcześniej użyć funkcji generującej dane do csv w
kilku innych miejscach tego czy innego oprogramowania, więc zmiana wiąże
się z poprawieniem w kilkunastu innych miejscach.

p. m.

W dniu 2010-06-24 12:31, mvoicem pisze:

Mogli pomyśleć ale wcześniej użyć funkcji generującej dane do csv w
kilku innych miejscach tego czy innego oprogramowania, więc zmiana wiąże
się z poprawieniem w kilkunastu innych miejscach.

Przecież raz zmieniasz ciało funkcji generującej.


--
Przemysław Adam Śmiejek

(24.06.2010 12:52), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-24 12:31, mvoicem pisze:

Mogli pomyśleć ale wcześniej użyć funkcji generującej dane do csv w
kilku innych miejscach tego czy innego oprogramowania, więc zmiana wiąże
się z poprawieniem w kilkunastu innych miejscach.

Przecież raz zmieniasz ciało funkcji generującej.

I wysypuje ci się oprogramowanie w kilkunastu miejscach, bo spodziewa
się X kolumn w danych, a ma X+2.

W bardziej skomplikowanym oprogramowaniu zmiana pierdułki w jednym
miejscu może skutkować zaskakującymi efektami ubocznymi w miejscach
które wydawałyby się być tematycznie dość odległe.

p. m.

W dniu 2010-06-24 13:59, mvoicem pisze:

(24.06.2010 12:52), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-24 12:31, mvoicem pisze:

Mogli pomyśleć ale wcześniej użyć funkcji generującej dane do csv w
kilku innych miejscach tego czy innego oprogramowania, więc zmiana wiąże
się z poprawieniem w kilkunastu innych miejscach.

Przecież raz zmieniasz ciało funkcji generującej.

I wysypuje ci się oprogramowanie w kilkunastu miejscach, bo spodziewa
się X kolumn w danych, a ma X+2.

Przecie mówimy o funkcji generującej CSV.

W bardziej skomplikowanym oprogramowaniu zmiana pierdułki w jednym
miejscu może skutkować zaskakującymi efektami ubocznymi w miejscach
które wydawałyby się być tematycznie dość odległe.

Ale to końcowa funkcja.

--
Przemysław Adam Śmiejek

(24.06.2010 19:29), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-24 13:59, mvoicem pisze:

(24.06.2010 12:52), Przemysław Adam Śmiejek wrote:

W dniu 2010-06-24 12:31, mvoicem pisze:

Mogli pomyśleć ale wcześniej użyć funkcji generującej dane do csv w
kilku innych miejscach tego czy innego oprogramowania, więc zmiana wiąże
się z poprawieniem w kilkunastu innych miejscach.

Przecież raz zmieniasz ciało funkcji generującej.

I wysypuje ci się oprogramowanie w kilkunastu miejscach, bo spodziewa
się X kolumn w danych, a ma X+2.

Przecie mówimy o funkcji generującej CSV.

A skąd wiesz w jakim formacie ta funkcja dostaje dane i z jakich funkcji?

W bardziej skomplikowanym oprogramowaniu zmiana pierdułki w jednym
miejscu może skutkować zaskakującymi efektami ubocznymi w miejscach
które wydawałyby się być tematycznie dość odległe.

Ale to końcowa funkcja.

Skąd wiesz? Nawet jeżeli tak - to skąd wiesz że nie jest "początkowa"
dla innych części kodu? Albo że razem z innymi częściami kodu nie używa
funkcji ktĂłra te dane generuje?


p. m.

Dnia Wed, 23 Jun 2010 20:43:57 +0200, mvoicem napisał(a):

Niestety w waszych plikach CSV wrzucono w jedno pole tytuł przelewu i
dane nadawcy. Nie jest więc możliwe zrobienie zestawień typu ,,wszystkie
przelewy do Kowalskiego'', ,,wszystkie przelewy do ludzi z Zabrza'',
,,wszystkie przelewy o tytule KACZKA'' czy ,,wszystkie przelewy na konto
X''.

Cóż, może być problem, szczególnie z tymi ludźmi z Zabrza bez przeszukania
całego pola. Z eliksiru dostają (z tego o co pytasz):

Nazwa i adres zleceniodawcy Poszczególne wiersze oddzielone od siebie symbolem "|" 4*35 aV (czyli 4 wiersze po 35 znaków alfanumerycznych) i jest to pole
wymagalne o zmiennej długości

Szczegóły płatności
Poszczególne wiersze oddzielone od siebie symbolem "|"
4*35 an (czyli 4 wiersze po 35 znaków alfanumerycznych lub numerycznych),
pole niewymagalne

n = numeryczne 0 - 9
a = alfanumeryczne; zapisane są w cudzysłowie " " (Hex 22)
Poszczególne linie oddzielone są znakiem "|" (Hex 7C).
V = pole zmiennej długości (variable)


Czyli powinni móc oddzielić dane nadawcy od tytułu przelewu. Podział danych
nadawcy na poszczególne składniki może być dość skomplikowane.
--
Kojer

W dniu 2010-06-24 12:28, Robert Kois pisze:

Czyli powinni móc oddzielić dane nadawcy od tytułu przelewu. Podział danych
nadawcy na poszczególne składniki może być dość skomplikowane.

Czyli już sam eliksir jest spierdolony.... Ja pierdzielę, czy na takim
poziomie systemy projektują gimnazjaliści? Przecież o podziale pól w
bazie to w I klasie liceumu się naucza.

--
Przemysław Adam Śmiejek

Dnia Thu, 24 Jun 2010 12:53:57 +0200, Przemysław Adam Śmiejek napisał(a):

Czyli powinni móc oddzielić dane nadawcy od tytułu przelewu. Podział danych
nadawcy na poszczególne składniki może być dość skomplikowane.

Czyli już sam eliksir jest spierdolony....

Ale dlaczego spierdolony? Uproszczony po prostu.

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. Podejrzewam, ze zaprojektowano to
tak by jak najprościej było się dołaczyć do systemu. Z punktu widzenia
eliksiru tych danych mogłoby wogóle nie być.

--
Kojer

W dniu 2010-06-24 13:14, Robert Kois pisze:

Dnia Thu, 24 Jun 2010 12:53:57 +0200, Przemysław Adam Śmiejek napisał(a):

Czyli powinni móc oddzielić dane nadawcy od tytułu przelewu. Podział danych
nadawcy na poszczególne składniki może być dość skomplikowane.

Czyli już sam eliksir jest spierdolony....

Ale dlaczego spierdolony?

Poszukaj sobie jakiegoś tekstu o bazach danych i postaciach normalnych.
Ta urąga dowolnej postaci.

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.

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.

Podejrzewam, ze zaprojektowano to
tak by jak najprościej było się dołaczyć do systemu.

Podział na pola nic by nie skomplikował.

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





--
Przemysław Adam Śmiejek

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.
 

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.

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? Kto powiedział, że bank otrzymujący przelew ma trzymać dane
nadawcy w formie dla ciebie wygodnej? Banku odbiorcy dane nadawcy nie
powinny obchodzić. Bo i niby dlaczego.
 

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? 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.
Oczywiście to da się zrobić, ale to są koszty. 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.
To ci cvs z mbanku da (jak już rozdzielą pole z nadawcą od pola z tytułem
przelewu).
 

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.

--
Kojer

Robert Kois wrote:
....

Elixir nie jest bazą danych.
 

....

Bzdura. Elixir nie służy do sortowania, wyszukiwania itp.

....

A on je psuje? Kto powiedział, że bank otrzymujący przelew ma trzymać dane
nadawcy w formie dla ciebie wygodnej? Banku odbiorcy dane nadawcy nie
powinny obchodzić. Bo i niby dlaczego.
 

....

Ale widziałeś kiedyś jakąś bazę z prawdziwymi danymi 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.
Oczywiście to da się zrobić, ale to są koszty. 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.
To ci cvs z mbanku da (jak już rozdzielą pole z nadawcą od pola z tytułem
przelewu).

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

To co może powstrzymywać przed zrobieniem tego samego przez mBank to głupota zarządzających tegoż, tragiczny poziom ichniego zespołu projektantów/programistów i skrajne lekceważenie potrzeb i dezyderatów klientów.


witrak()

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

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

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

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

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

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

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

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

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

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

Dnia Sun, 27 Jun 2010 13:09:41 +0200, Przemysław Adam Śmiejek napisał(a):

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ż są rozliczane bez udziału człowieka. To ty masz problem bo wymagasz od
historii transakcji czegoś do czego nie została ona zaprojektowana. Jeszcze
raz, bo chyba nie rozumiesz o czym rozmawiamy. Elixir nie został
zaprojektowany do prowadzenia rozliczeń i ewidencji przez ostatecznego
odbiorcę przelewów, to system rozliczeniowy dla banków.
 

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.

Znaczy beznadziejnie zaprojektowali to, że nie chce ci się samemu prowadzić
rozliczeń?

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.

Myśle, że za odpowiednią kwotę jakiś bank ci coś takiego udostępni. Jak
będziesz miał odpowiednie obroty to pewnie zrobią dedykowane rozwiązania
dla ciebie (pewnie są robione takie rzeczy pod odpowiednio duzych
klientów).
 

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.

Ale dlaczego wymagasz tego od elixiru? Bank dostaje na nazwę nadawcy 4
linie po 35 znaków. O ile wiem (nie chce mi się sprawdzać) średnik nie jest
znakiem niedozwolonym. Namów wszystkie banki by je wstawiały. Co nie zmieni
faktu, że nadal nie bardzo wiadomo co w danym polu będzie.

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.

Nie ma żadnej synchronizacji danych. Zrozum to.

Niestety gubi część informacji zawartych w tych bazach. Co uważam za
bezsensowne, bo koszt niegubienia byłby zerowy.

Pokaż jak w tej chwili wprowadzić to co proponujesz zerowym kosztem.
Zerowym po stronie KIRu i po stronie banków. 

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 upraszczają, to co proponujesz mogłoby działać gdyby struktura danych
we wszystkich bazach bankowych była jednakowa. Nie jest. Dostosowanie nie
jest darmowe. Ba, w wielu przypadkach mogłoby być bardzo kosztowne.

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.

Technicznie nie jest. Oczywiście wymagane byłyby centra pośredniczące (tak
jak teraz) ale jest to do zrobienia.

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

Nie sądzę.

Zrobią, jak będzie odpowiednio duże zapotrzebowanie (patrz rozwiązanie
angielskie o którym ktoś tu kiedyś pisał).

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

 NIE IDZIE ELIXIREM! Idzie w godzinach sesji elixirowych. Dlaczego nie ma
online pytaj władz banku.

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.

Od tego jest KIR, robiłby to samo w ramach przelewów online. Jest cała masa
poważniejszych problemów niż to co wymieniasz.

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.

A ktoś obiecywał, że takie przelewy będą za darmo? 

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.

Nie robi. Robiłaby skanując każdą kopertę i obrabiając dane tak, by bez
problemu dało się do nich dotrzeć.
A ja nadal nie chcę, by obcy bank z którym nie mam żadnej umowy obrabiał
moje dane.

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.

No ale to nadal kieruj do mbanku. Tak btw to ciesz się, że na zestawieniu
transakcji ten numer rachunku masz, część banków go nie daje.
Zajrzałem do eurobanku, jest jeszcze gorzej :)
Wygląda to tak:
28-04-2010;28-04-2010;Przelew przychodzący zewnętrzny NAZWA FIRMY S.A.ULICA
10002-486 WARSZAWAWynagrodzenie za kwiecień 2010 ;KWOTA PLN;SALDO PLN;

tak nie ma podziału pomiędzy nazwą, ulicą, tytułem (nawet spacji nie ma), w
pdfie przynajmniej entery są :)

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.

[ciach]

A teraz dostosujdo tego wszystkie banki i KIR.

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.

Takie życie. Tak btw to widziałem kiedyś jakieś programy które jakoś sobie
z tym radziły (nie testowałem). Czyli wystarczy sobie kupić. No ale to
musiałbyś zapłacić.
 

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

A nawet go nie było.

I jakoś żyłeś.

A teraz mirmiłujesz.

Nie rozumiesz zagadnienia :(

Rozumiem.

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?

Ale ty sugerujesz, że coś jest zjebane bo nie robi rzeczy do których nie
było projektowane. O ile wiem, różne banki mają dla firm jakieś narzędzia
do tego, ale to raczej płatne jest.

--
Kojer

W dniu 2010-06-27 14:08, Robert Kois pisze:

Ależ są rozliczane bez udziału człowieka. To ty masz problem bo wymagasz od
historii transakcji czegoś do czego nie została ona zaprojektowana. Jeszcze
raz, bo chyba nie rozumiesz o czym rozmawiamy. Elixir nie został
zaprojektowany do prowadzenia rozliczeń i ewidencji przez ostatecznego
odbiorcę przelewów, to system rozliczeniowy dla banków.

Co nie przeszkadza, że gdyby nie psuł danych, to by nie szkodziło tej
funkcji.

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.

Znaczy beznadziejnie zaprojektowali to, że nie chce ci się samemu prowadzić
rozliczeń?

Argument od czapy. Jak w Inteligo historia była tylko 3 miesiące wstecz,
to była idealnie zaprojektowana tylko mi się nie chciało notować wstecz
i wybrałem mBank. A jakby np. jakiś bank uznał, że nie udostępnia
historii wcale, to też byłoby idealnie zaprojektowane, tylko ja za dużo
wymagam.

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.
I to czy mi się chce zatrudniać referenta d/s wklepywania w mój system
to sprawa poboczna.

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.

Myśle, że za odpowiednią kwotę jakiś bank ci coś takiego udostępni. Jak
będziesz miał odpowiednie obroty to pewnie zrobią dedykowane rozwiązania
dla ciebie (pewnie są robione takie rzeczy pod odpowiednio duzych
klientów).

Ale po co dedykowane? Zwłaszcza, że mBank podział na pola już ma, wbrew
temu co twierdziłeś. Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

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.

Ale dlaczego wymagasz tego od elixiru? Bank dostaje na nazwę nadawcy 4
linie po 35 znaków.

Czyli bardzo dobrze.

Linia 1: Nazwa, część 1.
Linia 2: Nazwa, część 2.
Linia 3: Ulica
Linia 4: Kod i Miejscowość

Nie trzeba przerabiać protokołu. Technicznie już wszystko jest i chyba
nawet jest wykorzystywane, skoro to działa.

 O ile wiem (nie chce mi się sprawdzać) średnik nie jest

znakiem niedozwolonym. Namów wszystkie banki by je wstawiały.

No wreszcie załapałeś ! Bezkosztowo, wystarczy się tylko umówić.

Co nie zmieni
faktu, że nadal nie bardzo wiadomo co w danym polu będzie.

Jeżeli się umówią (co chyba już nastąpiło, skoro mój mBank ma to
podzielone na właściwe kawałki) co do kolejności, to wiadomo.

Niestety gubi część informacji zawartych w tych bazach. Co uważam za
bezsensowne, bo koszt niegubienia byłby zerowy.

Pokaż jak w tej chwili wprowadzić to co proponujesz zerowym kosztem.

Sam pokazałeś.

Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

Zerowym po stronie KIRu i po stronie banków.

Ależ proszę. KIR nawet nie zauważa różnicy. Banki niedostosowane
również. Kolejne banki dostosowują się przy okazji, w miarę modyfikacji
systemów.

Co zresztą chyba już nastąpiło.

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 upraszczają, to co proponujesz mogłoby działać gdyby struktura danych
we wszystkich bazach bankowych była jednakowa. Nie jest.

A jakie inne mają? Układ danych w Polsce jest dość typowy. Nie sądzę,
żeby któryś bank jakoś cudował inaczej. Najwyżej będzie niezgodny z ver.
2, a całość odbędzie się tak, jak odbywa teraz.

Dostosowanie nie
jest darmowe. Ba, w wielu przypadkach mogłoby być bardzo kosztowne.

Dodanie separatora przy kolejnych przeróbkach to jednorazowy koszt i
naprawdę niewielki. Jego wyłapanie nieco większy, ale również jest to
bez wpływu na dalsze działanie systemu, więc przy okazji, jednorazowo
można spokojnie strzelić.

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.

Technicznie nie jest. Oczywiście wymagane byłyby centra pośredniczące (tak
jak teraz) ale jest to do zrobienia.

No jest do zrobienia, ale technicznie jest to skomplikowane i bardzo
kosztowne.

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

Nie sądzę.

Zrobią, jak będzie odpowiednio duże zapotrzebowanie (patrz rozwiązanie
angielskie o którym ktoś tu kiedyś pisał).

Nie kojarzę, jakie są rozwiązania tamże?

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

NIE IDZIE ELIXIREM! Idzie w godzinach sesji elixirowych. Dlaczego nie ma
online pytaj władz banku.

No jak widać powód jakiś jest. Podejrzewam, że prawno-księgowy.

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.

Od tego jest KIR, robiłby to samo w ramach przelewów online.

Biorąc pod uwagę skomplikowanie zadania i różnice pomiędzy terminami
sesji wychodzących i przychodzących, to nie jest to takie proste.

Jest cała masa
poważniejszych problemów niż to co wymieniasz.

Pewnie tak, dlatego słabo to widzę.

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.

A ktoś obiecywał, że takie przelewy będą za darmo?

No więc pewnie większość woli jednak tanio lub za darmo i 3 razy
dziennie niż drogo natychmiastowo.

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.

Nie robi.

Wyciąłeś o kurierach, to się wypchaj.

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.

No ale to nadal kieruj do mbanku. Tak btw to ciesz się, że na zestawieniu
transakcji ten numer rachunku masz, część banków go nie daje.
Zajrzałem do eurobanku, jest jeszcze gorzej :)
Wygląda to tak:

Eurobank to w ogóle nie jest bank, tylko targowiskowa zabawka w
landrynkowej kolorystyce.

28-04-2010;28-04-2010;Przelew przychodzący zewnętrzny NAZWA FIRMY S.A.ULICA
10002-486 WARSZAWAWynagrodzenie za kwiecień 2010 ;KWOTA PLN;SALDO PLN;

tak nie ma podziału pomiędzy nazwą, ulicą, tytułem (nawet spacji nie ma), w
pdfie przynajmniej entery są :)

No wiec właśnie. Zastanawiam się, kto im systemy pisze...

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.

[ciach]
A teraz dostosujdo tego wszystkie banki i KIR.

KIRu nie trzeba, a banki się mogą dostosowywać sukcesywnie.

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

A nawet go nie było.

I jakoś żyłeś.

Tak, żyłem również bez internetu, bez konta, bez samochodu, bez żony i
bez łysiny i dużego brzuszka.

Dyskusję o jakości czegokolwiek uznaję za bezsensowną przy argumentach
,,kiedyś tego nie było i ludzie żyli''.

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?

Ale ty sugerujesz, że coś jest zjebane bo nie robi rzeczy do których nie
było projektowane.

Owszem. Podobnie jak skopano wiele protokołów sieciowych. Ale jakoś nie
machnięto ręką i je poprawiono. I nawet Onet się ugiął niedawno i już
umożliwia szyfrowane transmisje poczty.


--
Przemysław Adam Śmiejek

Dnia Sun, 27 Jun 2010 19:41:00 +0200, Przemysław Adam Śmiejek napisał(a):

Co nie przeszkadza, że gdyby nie psuł danych, to by nie szkodziło tej
funkcji.

Nie psuje, przekazuje dokładnie to co dostaje.

Znaczy beznadziejnie zaprojektowali to, że nie chce ci się samemu prowadzić
rozliczeń?

Argument od czapy. Jak w Inteligo historia była tylko 3 miesiące wstecz,
to była idealnie zaprojektowana tylko mi się nie chciało notować wstecz
i wybrałem mBank. A jakby np. jakiś bank uznał, że nie udostępnia
historii wcale, to też byłoby idealnie zaprojektowane, tylko ja za dużo
wymagam.

Bank musi udostępniać historię, ale nie musi to być w takiej formie jak
sobie życzysz. Za dodatkowe rzeczy może chcieć kasy. 

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.

Ależ pozwala, tylko nie takie jak sobie życzysz.

Myśle, że za odpowiednią kwotę jakiś bank ci coś takiego udostępni. Jak
będziesz miał odpowiednie obroty to pewnie zrobią dedykowane rozwiązania
dla ciebie (pewnie są robione takie rzeczy pod odpowiednio duzych
klientów).

Ale po co dedykowane? Zwłaszcza, że mBank podział na pola już ma, wbrew
temu co twierdziłeś.

Nic nie twierdziłem, pokazałem ci kawałek specyfikacji pliku eliksirowego,
wygooglany zresztą na stronach mbanku.

Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

Pewnie mają, ale może nie chcą dawać za darmo.

Ale dlaczego wymagasz tego od elixiru? Bank dostaje na nazwę nadawcy 4
linie po 35 znaków.

Czyli bardzo dobrze.
Linia 1: Nazwa, część 1.
Linia 2: Nazwa, część 2.
Linia 3: Ulica
Linia 4: Kod i Miejscowość
Nie trzeba przerabiać protokołu. Technicznie już wszystko jest i chyba
nawet jest wykorzystywane, skoro to działa.

Co robisz jak nazwa firmy ma 80 znaków? Przycinamy? A jak są 2 firmy które
różnią się tylko ostatnim wyrazem nazwy?
 

 O ile wiem (nie chce mi się sprawdzać) średnik nie jest

znakiem niedozwolonym. Namów wszystkie banki by je wstawiały.

No wreszcie załapałeś ! Bezkosztowo, wystarczy się tylko umówić.

Błąd, to nie jest bezkosztowo. Te średniki soft musi wstawiać a potem
obrobić. Krasnoludki za mleko tego nie zrobią.

Co nie zmieni
faktu, że nadal nie bardzo wiadomo co w danym polu będzie.

Jeżeli się umówią (co chyba już nastąpiło, skoro mój mBank ma to
podzielone na właściwe kawałki) co do kolejności, to wiadomo.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi. Prosty parser to załatwia, ale jak bank przekaże błędne
dane klientowi to kilent będzie domagał się odszkodowania. Bez porządnego
podziału nie są w stanie zagwarantować 100% zgodności. I to, że ty się nie
przejmiesz jak raz dostaniesz obcięta nazwę ma dla banku małe znaczenie.
 

Niestety gubi część informacji zawartych w tych bazach. Co uważam za
bezsensowne, bo koszt niegubienia byłby zerowy.

Pokaż jak w tej chwili wprowadzić to co proponujesz zerowym kosztem.

Sam pokazałeś.
Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.

NNie da się, jeżeli nie mamy porządnie opisanego formatu to wyjątki nas
zjedzą. Ot weź sobie jakiegoś hiszpana z kilkoma imionami.

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

I padamy jak coś jest za długie. Tak btw to zdajesz sobie sprawę, że nie
wszędzie na świecie są kody pocztowe?

Zerowym po stronie KIRu i po stronie banków. 

Ależ proszę. KIR nawet nie zauważa różnicy. Banki niedostosowane
również. Kolejne banki dostosowują się przy okazji, w miarę modyfikacji
systemów.

Niestety nie jest tak pięknie. No i nadal jakoś modyfikacje systemów
uznajesz za bezkosztowe. Nie są.

Co zresztą chyba już nastąpiło.

Nic nie nastąpiło. Zauważyłbyś to jakby ci się chciało poszukać jak działa
elixir.
 

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 upraszczają, to co proponujesz mogłoby działać gdyby struktura danych
we wszystkich bazach bankowych była jednakowa. Nie jest.

A jakie inne mają? Układ danych w Polsce jest dość typowy. Nie sądzę,
żeby któryś bank jakoś cudował inaczej. Najwyżej będzie niezgodny z ver.
2, a całość odbędzie się tak, jak odbywa teraz.

Nie jest tak pięknie.

Dostosowanie nie
jest darmowe. Ba, w wielu przypadkach mogłoby być bardzo kosztowne.

Dodanie separatora przy kolejnych przeróbkach to jednorazowy koszt i
naprawdę niewielki. Jego wyłapanie nieco większy, ale również jest to
bez wpływu na dalsze działanie systemu, więc przy okazji, jednorazowo
można spokojnie strzelić.

Jak pokazałem wyżej to nie takie proste

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

Nie sądzę.

Zrobią, jak będzie odpowiednio duże zapotrzebowanie (patrz rozwiązanie
angielskie o którym ktoś tu kiedyś pisał).

Nie kojarzę, jakie są rozwiązania tamże?

Nie pamiętam nazwy. Część banków to wdrożyła, przelewy dochodzą w parę
minut podobno.
 

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.

A ktoś obiecywał, że takie przelewy będą za darmo?

No więc pewnie większość woli jednak tanio lub za darmo i 3 razy
dziennie niż drogo natychmiastowo.

Daltego jak coś się pojawi to będzie obok istniejącego systemu i pewnie
płatne dodatkowo, przynajmniej na początku. Przelewy też kiedyś kosztowały
więcej.
 

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.

Nie robi.

Wyciąłeś o kurierach, to się wypchaj.

Bo nie ma to związku. Jeszcze raz zapytam. Chcesz by obcy bank mógł sobie
sprofilować cię jako klienta i trzymać sobie posortowane dane komu i za co
płacisz? A potem wykorzystać to np. przy twoim wniosku kredytowym? Ja bym
wolał nie.

Eurobank to w ogóle nie jest bank, tylko targowiskowa zabawka w
landrynkowej kolorystyce.

Akurat mbank mógłby się od nich paru rzeczy nauczyć. Szczególnie w zakresie
oferty produktowej. Bo co mi po świetnym systemie jak oferta do dupy.
 

No wiec właśnie. Zastanawiam się, kto im systemy pisze...

Akurat oidp oni sami sobie napisali.

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.

[ciach]
A teraz dostosujdo tego wszystkie banki i KIR.

KIRu nie trzeba, a banki się mogą dostosowywać sukcesywnie.

Tylko, że to co proponujesz nie zadziała zawsze. A banki bardzo nie lubią
płacić za błędy. Oczywiście możnaby przeprojektować system (oprzeć choćby
na xmlu) i dałoby to taką funkcjonalność jaką chcesz. Wszystko oparte na
dotychczasowym formacie można najwyżej oprotezować i niektórzy to robią a
niektórzy nie

Ale ty sugerujesz, że coś jest zjebane bo nie robi rzeczy do których nie
było projektowane.

Owszem. Podobnie jak skopano wiele protokołów sieciowych. Ale jakoś nie
machnięto ręką i je poprawiono. I nawet Onet się ugiął niedawno i już
umożliwia szyfrowane transmisje poczty.

Przy takim podejściu to www jest zjebane bo nie możesz sobie w prosty
sposób posortować danych tak przesyłanych.

--
Kojer

W dniu 2010-06-27 21:47, Robert Kois pisze:

Dnia Sun, 27 Jun 2010 19:41:00 +0200, Przemysław Adam Śmiejek napisał(a):

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.

Ależ pozwala, tylko nie takie jak sobie życzysz.

Nie. Nie pozwala zgodnie z zasadami SZBD.

Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

Pewnie mają, ale może nie chcą dawać za darmo.

Nie widzę możliwości zapłacenia za poprawny plik CSV.

Ale dlaczego wymagasz tego od elixiru? Bank dostaje na nazwę nadawcy 4
linie po 35 znaków.

Czyli bardzo dobrze.
Linia 1: Nazwa, część 1.
Linia 2: Nazwa, część 2.
Linia 3: Ulica
Linia 4: Kod i Miejscowość
Nie trzeba przerabiać protokołu. Technicznie już wszystko jest i chyba
nawet jest wykorzystywane, skoro to działa.

Co robisz jak nazwa firmy ma 80 znaków? Przycinamy? A jak są 2 firmy które
różnią się tylko ostatnim wyrazem nazwy?

Wg ciebie nie ma to najmniejszego znaczenia.

Poza tym, czemu mnie pytasz dlaczego tak chujowo zaprojektowani
eliksira? Przecież on taki jest.

 O ile wiem (nie chce mi się sprawdzać) średnik nie jest

znakiem niedozwolonym. Namów wszystkie banki by je wstawiały.

No wreszcie załapałeś ! Bezkosztowo, wystarczy się tylko umówić.

Błąd, to nie jest bezkosztowo. Te średniki soft musi wstawiać a potem
obrobić. Krasnoludki za mleko tego nie zrobią.

Uważasz, że linijka:

dane = imię + nazwisko + cośtam

wykonuje się tak bardzo wydajniej, że linijka

dane = imię + ";" + nazwisko + ";" + cośtam

będzie takim kosztem?

Sparsowanie tego też będzie mniejszym kosztem niż parser zgadujący.

Co nie zmieni
faktu, że nadal nie bardzo wiadomo co w danym polu będzie.

Jeżeli się umówią (co chyba już nastąpiło, skoro mój mBank ma to
podzielone na właściwe kawałki) co do kolejności, to wiadomo.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

Prosty parser to załatwia, ale jak bank przekaże błędne

dane klientowi to kilent będzie domagał się odszkodowania. Bez porządnego
podziału nie są w stanie zagwarantować 100% zgodności. I to, że ty się nie
przejmiesz jak raz dostaniesz obcięta nazwę ma dla banku małe znaczenie.

Strasznie coś kręcisz i mącisz. Przed chwilą te dane były zupełnie bez
znaczenia dla ciebie, teraz znów jest tragedia, jak coś się nie uda
czasami i jest to powód do pozostania przy systemie, gdy zupełnie nie ma
nic....

Zresztą, przykład mBanku wykazuje, że jakoś bank to dzieli i nie uznali
tego za bezsensowne, tylko dokonują podziału.

Niestety gubi część informacji zawartych w tych bazach. Co uważam za
bezsensowne, bo koszt niegubienia byłby zerowy.

Pokaż jak w tej chwili wprowadzić to co proponujesz zerowym kosztem.

Sam pokazałeś.
Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.

NNie da się, jeżeli nie mamy porządnie opisanego formatu to wyjątki nas
zjedzą. Ot weź sobie jakiegoś hiszpana z kilkoma imionami.

No i? Zupełnie nie koliduje.

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

I padamy jak coś jest za długie.

Jako i teraz.

Tak btw to zdajesz sobie sprawę, że nie
wszędzie na świecie są kody pocztowe?

No i? Eliksir działa w Polsce.

Zresztą, taki format danych w Polsce jest stosowany nagminnie, a wyjątki
zagraniczne jakoś się do niego nagina.

Co zresztą chyba już nastąpiło.

Nic nie nastąpiło. Zauważyłbyś to jakby ci się chciało poszukać jak działa
elixir.

Jakoś mBank sobie radzi.

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 upraszczają, to co proponujesz mogłoby działać gdyby struktura danych
we wszystkich bazach bankowych była jednakowa. Nie jest.

A jakie inne mają? Układ danych w Polsce jest dość typowy. Nie sądzę,
żeby któryś bank jakoś cudował inaczej. Najwyżej będzie niezgodny z ver.
2, a całość odbędzie się tak, jak odbywa teraz.

Nie jest tak pięknie.

A jednak.

Jak pokazałem wyżej to nie takie proste

Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
analogicznie jak teraz.

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.

Nie robi.

Wyciąłeś o kurierach, to się wypchaj.

Bo nie ma to związku.

Ma.

Jeszcze raz zapytam. Chcesz by obcy bank mógł sobie
sprofilować cię jako klienta i trzymać sobie posortowane dane komu i za co
płacisz?

Przecież nie w ten sposób banki to przetwarzają i nie ma to związku z
moim podziałem.

A potem wykorzystać to np. przy twoim wniosku kredytowym?

Po pierwsze: Czemu nie? Dla mnie np. czad, że od 10 lat jestem klientem
mBanku i na podstawie historii mi dają różne rzeczy od ręki i nie muszę
latać i załatwiać wniosków w kolorach tęczy.

Po drugie: Nie o tym mowa, zupełnie.

Eurobank to w ogóle nie jest bank, tylko targowiskowa zabawka w
landrynkowej kolorystyce.

Akurat mbank mógłby się od nich paru rzeczy nauczyć. Szczególnie w zakresie
oferty produktowej. Bo co mi po świetnym systemie jak oferta do dupy.

Zależy pewnie z jakiej oferty produktowej korzystasz. Eurobank się w
końcu dorobił oferty dla przedsiębiorców? Bo kiedyś nie miał zupełnie. A
ofertę dla nie-przedsiębiorców też miał lichutką w zakresie, w jakim
korzystam.

No wiec właśnie. Zastanawiam się, kto im systemy pisze...

Akurat oidp oni sami sobie napisali.

No ale tępota podobna mBankowej. Z łapanki biorą programistów i testerów?

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.

[ciach]
A teraz dostosujdo tego wszystkie banki i KIR.

KIRu nie trzeba, a banki się mogą dostosowywać sukcesywnie.

Tylko, że to co proponujesz nie zadziała zawsze.

Zadziała. Co najwyżej nie zawsze dobrze rozpozna pola. Ale Twoja
alternatywa jest: nie rozpoznawać w ogóle pól.

A banki bardzo nie lubią
płacić za błędy.

Ale czym płacić i za jakie błędy? Proponujesz ,,nie da się 100%
skutecznie, nie dawajmy wcale''. Bez sensu i nieżyciowe.

Oczywiście możnaby przeprojektować system (oprzeć choćby
na xmlu) i dałoby to taką funkcjonalność jaką chcesz. Wszystko oparte na
dotychczasowym formacie można najwyżej oprotezować i niektórzy to robią a
niektórzy nie

Czyli się u niektórych da. I jak czasami się nie uda, to trudno.
Wystarczy nie gwarantować tego pod kosztem odszkodowania.

Ale ty sugerujesz, że coś jest zjebane bo nie robi rzeczy do których nie
było projektowane.

Owszem. Podobnie jak skopano wiele protokołów sieciowych. Ale jakoś nie
machnięto ręką i je poprawiono. I nawet Onet się ugiął niedawno i już
umożliwia szyfrowane transmisje poczty.

Przy takim podejściu to www jest zjebane bo nie możesz sobie w prosty
sposób posortować danych tak przesyłanych.

Co to jest www wg ciebie? Wg mnie to zbiór mniej lub bardziej ze sobą
powiązanych dokumentów rozproszonych po całym świecie. Nie jest to baza
danych, nie ma porządku umożliwiającego sortowanie i też sortowanie nie
jest potrzebne.

Nikt nie chce sortować wszystkich pism przesyłanych np. pomiędzy
mieszkańcami a zarządami ich spółdzielni mieszkaniowych.


--
Przemysław Adam Śmiejek

Dnia Sun, 27 Jun 2010 22:10:26 +0200, Przemysław Adam Śmiejek napisał(a):

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.

Ależ pozwala, tylko nie takie jak sobie życzysz.

Nie. Nie pozwala zgodnie z zasadami SZBD.

Pozwala. To że ty nie możesz to inna sprawa.
 

Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

Pewnie mają, ale może nie chcą dawać za darmo.

Nie widzę możliwości zapłacenia za poprawny plik CSV.

Zapytaj banku, może udostępniają narzędzia, a może nie. Ino elixir nie ma
nic do tego.

[ciach]

Co robisz jak nazwa firmy ma 80 znaków? Przycinamy? A jak są 2 firmy które
różnią się tylko ostatnim wyrazem nazwy?

Wg ciebie nie ma to najmniejszego znaczenia.

Ale dla ciebie ma. Mi wystarczyłaby sama nazw (a nawet jej część
wystarczająca mi do identyfikacji nadawcy)a, ty domagasz się pozostałych
danych adresowych. Z mojego punktu widzenia działa (z dokładnością do
spieprzonego cvsa z mbanku).
 

Poza tym, czemu mnie pytasz dlaczego tak chujowo zaprojektowani
eliksira? Przecież on taki jest.

Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
Nie jest baza danych, jest systemem rozliczeniowym.

Błąd, to nie jest bezkosztowo. Te średniki soft musi wstawiać a potem
obrobić. Krasnoludki za mleko tego nie zrobią.

Uważasz, że linijka:
 dane = imię + nazwisko + cośtam
wykonuje się tak bardzo wydajniej, że linijka
dane = imię + ";" + nazwisko + ";" + cośtam
będzie takim kosztem?
Sparsowanie tego też będzie mniejszym kosztem niż parser zgadujący.

A parsery to się same napiszą.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

To zależy od punktu widzenia.
 

Prosty parser to załatwia, ale jak bank przekaże błędne

dane klientowi to kilent będzie domagał się odszkodowania. Bez porządnego
podziału nie są w stanie zagwarantować 100% zgodności. I to, że ty się nie
przejmiesz jak raz dostaniesz obcięta nazwę ma dla banku małe znaczenie.

Strasznie coś kręcisz i mącisz. Przed chwilą te dane były zupełnie bez
znaczenia dla ciebie, teraz znów jest tragedia, jak coś się nie uda
czasami i jest to powód do pozostania przy systemie, gdy zupełnie nie ma
nic....

Jeszcze raz, mnie to zwisa. Ale może znajdzie się klient który za coś
takiego pozwie bank.

Zresztą, przykład mBanku wykazuje, że jakoś bank to dzieli i nie uznali
tego za bezsensowne, tylko dokonują podziału.

Jeszcze raz, co bank robi z tym co dostanie z elixiru to ich sprawa. Jakbyś
nie zauważył ja nie bronię banku. czepiam się tylko twojego pobredzania o
elixirze

Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.

NNie da się, jeżeli nie mamy porządnie opisanego formatu to wyjątki nas
zjedzą. Ot weź sobie jakiegoś hiszpana z kilkoma imionami.

No i? Zupełnie nie koliduje.

Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
masz problem.
 

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

I padamy jak coś jest za długie.

Jako i teraz.

Ale teraz nikt nie traktuje tego jako kluczową daną. Jest to czysto
informacyjne.
 

Tak btw to zdajesz sobie sprawę, że nie
wszędzie na świecie są kody pocztowe?

No i? Eliksir działa w Polsce.
Zresztą, taki format danych w Polsce jest stosowany nagminnie, a wyjątki
zagraniczne jakoś się do niego nagina.

O tym, że obcokrajowiec może mieć konto w Polsce chyba wiesz. No i nadal
mamy problem z firmami które potrafią mieć długie nazwy.

Co zresztą chyba już nastąpiło.

Nic nie nastąpiło. Zauważyłbyś to jakby ci się chciało poszukać jak działa
elixir.

Jakoś mBank sobie radzi.

A pan Zitek sobie wklepuje dane do programu księgowego i też mu działa.
Tylko co to ma wspólnego z formatem danych w elixirze?
 

Jak pokazałem wyżej to nie takie proste

Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
analogicznie jak teraz.

Ale teraz to nie ma znaczenia.
 

Jeszcze raz zapytam. Chcesz by obcy bank mógł sobie
sprofilować cię jako klienta i trzymać sobie posortowane dane komu i za co
płacisz?

Przecież nie w ten sposób banki to przetwarzają i nie ma to związku z
moim podziałem.

Ale zdecydowanie im ułatwia sprawę przy takim obrobieniu danych.

A potem wykorzystać to np. przy twoim wniosku kredytowym?

Po pierwsze: Czemu nie? Dla mnie np. czad, że od 10 lat jestem klientem
mBanku i na podstawie historii mi dają różne rzeczy od ręki i nie muszę
latać i załatwiać wniosków w kolorach tęczy.

A na podstawie twoich przelewów z mbanku takie pekao stwierdzi np. że masz
kochankę, płacisz alimenty i na dodatek kupiłeś samochód o jakiegoś ich
klienta. A ty nawet nie będziesz wiedział, że bank takie dane ma (bo to, że
mbank ma to wiesz bo sam im te dane dałeś).
 

No wiec właśnie. Zastanawiam się, kto im systemy pisze...

Akurat oidp oni sami sobie napisali.

No ale tępota podobna mBankowej. Z łapanki biorą programistów i testerów?

Aż zapytam, co zaprojektowałeś i napisałeś. Pokażesz jakieś rekomendacje?
Bo wypowiadasz się jakbyś autorytetem w tej dziedzinie był. Bo teoretyzować
to każdy potrafi.
 

A banki bardzo nie lubią
płacić za błędy.

Ale czym płacić i za jakie błędy? Proponujesz ,,nie da się 100%
skutecznie, nie dawajmy wcale''. Bez sensu i nieżyciowe.

Jeżeli chcesz na jakimś narzędziu oprzeć własne rozliczenia to lepiej, żeby
to działało zawsze, a nie tylko czasami.

Co to jest www wg ciebie? Wg mnie to zbiór mniej lub bardziej ze sobą
powiązanych dokumentów rozproszonych po całym świecie. Nie jest to baza
danych, nie ma porządku umożliwiającego sortowanie i też sortowanie nie
jest potrzebne.

Elixir nie jest bazą danych, to (w uproszczeniu) zbiór plików z
komunikatami i sortowanie nie jest potrzebne.
 

Nikt nie chce sortować wszystkich pism przesyłanych np. pomiędzy
mieszkańcami a zarządami ich spółdzielni mieszkaniowych.

Dlaczego? Zarząd pewnie by chciał, to bardzo wygodne by było, tylko koszt
stworzenia czegoś takiego przekroczyłby oczekiwane zyski.

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

--
Kojer

W dniu 2010-06-28 09:04, Robert Kois pisze:

Dnia Sun, 27 Jun 2010 22:10:26 +0200, Przemysław Adam Śmiejek napisał(a):

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.

Ależ pozwala, tylko nie takie jak sobie życzysz.

Nie. Nie pozwala zgodnie z zasadami SZBD.

Pozwala. To że ty nie możesz to inna sprawa.

Wg Twojej interpretacji nie pozwala.

Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

Pewnie mają, ale może nie chcą dawać za darmo.

Nie widzę możliwości zapłacenia za poprawny plik CSV.

Zapytaj banku, może udostępniają narzędzia, a może nie. Ino elixir nie ma
nic do tego.

Owszem, omawiamy kilka spraw:

a) czemu mBank nie daje dobrego csv
b) czy eliksir ma psuć pola czy nie

[ciach]

Co robisz jak nazwa firmy ma 80 znaków? Przycinamy? A jak są 2 firmy które
różnią się tylko ostatnim wyrazem nazwy?

Wg ciebie nie ma to najmniejszego znaczenia.

Ale dla ciebie ma.

Dzięki, że mówisz za mnie.

Mi wystarczyłaby sama nazw (a nawet jej część
wystarczająca mi do identyfikacji nadawcy)a, ty domagasz się pozostałych
danych adresowych. Z mojego punktu widzenia działa (z dokładnością do
spieprzonego cvsa z mbanku).

No więc Tobie moja wersja nie szkodzi. MI moja wersja daje bonusy.

Poza tym, czemu mnie pytasz dlaczego tak chujowo zaprojektowani
eliksira? Przecież on taki jest.

Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
Nie jest baza danych, jest systemem rozliczeniowym.

z protokołem transmisji danych pomiędzy bazami, który to protokół mógłby
być lepiej zaprojektowany.

Błąd, to nie jest bezkosztowo. Te średniki soft musi wstawiać a potem
obrobić. Krasnoludki za mleko tego nie zrobią.

Uważasz, że linijka:
 dane = imię + nazwisko + cośtam
wykonuje się tak bardzo wydajniej, że linijka
dane = imię + ";" + nazwisko + ";" + cośtam
będzie takim kosztem?
Sparsowanie tego też będzie mniejszym kosztem niż parser zgadujący.

A parsery to się same napiszą.

Obecny parser mBanku jakoś działa i jakoś się napisał. Więc chyba mBank
uznał że warto.

Przecież nie mówię: ,,Zmusić wszystkich do parsera'', tylko ,,dać taką
możliwość''. Kto chce, skorzysta. Dla niekorzystających nie generuje to
żadnych kosztów. Dla korzystających daje możliwości.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

To zależy od punktu widzenia.

Pokaż zalety z wersji ,,nie działa wcale''.

Prosty parser to załatwia, ale jak bank przekaże błędne

dane klientowi to kilent będzie domagał się odszkodowania. Bez porządnego
podziału nie są w stanie zagwarantować 100% zgodności. I to, że ty się nie
przejmiesz jak raz dostaniesz obcięta nazwę ma dla banku małe znaczenie.

Strasznie coś kręcisz i mącisz. Przed chwilą te dane były zupełnie bez
znaczenia dla ciebie, teraz znów jest tragedia, jak coś się nie uda
czasami i jest to powód do pozostania przy systemie, gdy zupełnie nie ma
nic....

Jeszcze raz, mnie to zwisa. Ale może znajdzie się klient który za coś
takiego pozwie bank.

A teraz nie pozwie?

Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.

NNie da się, jeżeli nie mamy porządnie opisanego formatu to wyjątki nas
zjedzą. Ot weź sobie jakiegoś hiszpana z kilkoma imionami.

No i? Zupełnie nie koliduje.

Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
masz problem.

A teraz nie masz? Przecie ograniczenie pól już istnieje.

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

I padamy jak coś jest za długie.

Jako i teraz.

Ale teraz nikt nie traktuje tego jako kluczową daną. Jest to czysto
informacyjne.

No i niech takie zostanie, skoro się boisz pozwów.

Tak btw to zdajesz sobie sprawę, że nie
wszędzie na świecie są kody pocztowe?

No i? Eliksir działa w Polsce.
Zresztą, taki format danych w Polsce jest stosowany nagminnie, a wyjątki
zagraniczne jakoś się do niego nagina.

O tym, że obcokrajowiec może mieć konto w Polsce chyba wiesz.

No i? Jakoś banki stosują to nagminnie i żyją z tym.

No i nadal
mamy problem z firmami które potrafią mieć długie nazwy.

Mamy. Nie moja wina, że zaprojektowano eliksir z ciasnymi ograniczeniami.

Co zresztą chyba już nastąpiło.

Nic nie nastąpiło. Zauważyłbyś to jakby ci się chciało poszukać jak działa
elixir.

Jakoś mBank sobie radzi.

A pan Zitek sobie wklepuje dane do programu księgowego i też mu działa.

I kosztuje.

Tylko co to ma wspólnego z formatem danych w elixirze?

Nic, najlepiej jakby eliksir przesyłał dane tak zmiksowane, żeby w ogóle
ich rozpakowanie trwało miesiąc i wymagało pracy sztabu osób. AMEN.

Dla mnie EOT.

Jak pokazałem wyżej to nie takie proste

Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
analogicznie jak teraz.

Ale teraz to nie ma znaczenia.

I nadal nie musi mieć. Może być tylko wygodą dla Tristana i podobnych.

A potem wykorzystać to np. przy twoim wniosku kredytowym?

Po pierwsze: Czemu nie? Dla mnie np. czad, że od 10 lat jestem klientem
mBanku i na podstawie historii mi dają różne rzeczy od ręki i nie muszę
latać i załatwiać wniosków w kolorach tęczy.

A na podstawie twoich przelewów z mbanku takie pekao stwierdzi np. że masz
kochankę, płacisz alimenty i na dodatek kupiłeś samochód o jakiegoś ich
klienta.

Niech se stwierdza. Zresztą zupełnie nie widzę związku z moim podziałem
danych a tą wiedzą.

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków, to jak to ma
działać? Może działać tylko, jak będzie miało już gotowe dane, więc
właśnie wtedy, gdy będzie wg mojej wersji. A wtedy wystarczy mi arkusz.

--
Przemysław Adam Śmiejek

Dnia Mon, 28 Jun 2010 12:39:40 +0200, Przemysław Adam Śmiejek napisał(a):

Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.

Ależ pozwala, tylko nie takie jak sobie życzysz.

Nie. Nie pozwala zgodnie z zasadami SZBD.

Pozwala. To że ty nie możesz to inna sprawa.

Wg Twojej interpretacji nie pozwala.

Znaczy wiesz lepiej niż ja co chciałem powiedzieć.
 

Czyli jednak banki chyba się jakoś dogadały albo
mają w mBanku bardzo dobry parser.

Pewnie mają, ale może nie chcą dawać za darmo.

Nie widzę możliwości zapłacenia za poprawny plik CSV.

Zapytaj banku, może udostępniają narzędzia, a może nie. Ino elixir nie ma
nic do tego.

Owszem, omawiamy kilka spraw:
a) czemu mBank nie daje dobrego csv

Ja o tym nie rozmawiam, mnie to zwisa, mam w mbanku 6 groszy.

b) czy eliksir ma psuć pola czy nie

Elixir NIE PSUJE! Przyjmij to w końcu do wiadomości. Tak samo jak FTP nie
psuje przesyłanych plików.

No więc Tobie moja wersja nie szkodzi. MI moja wersja daje bonusy.

Ale moja jest aktualną z dokładnością do tego, że przesyłane są nadmiarowe
rzeczy. Ciekawe, że jakoś nie płaczesz by wymagane było podanie wszystkich
danych przy definiowaniu przelewu. Wpisujesz przy robieniu przelewu
wszystkie dane adresowe odbiorcy?

Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
Nie jest baza danych, jest systemem rozliczeniowym.

z protokołem transmisji danych pomiędzy bazami, który to protokół mógłby
być lepiej zaprojektowany.

O widze, że przeszedłeś z beznadziejnie zaprojektowany na mógłby być lepiej
zaprojektowany. I tu się z tobą zgadzam. Mógłby ale nie jest. W czasach gdy
go projektowano nie widziano potrzeby takiego rozdzielania danych.
Aktualnie koszt sensownych zmian mógłby być spory. Podejrzewam, ze pomysły
na zmianę są.
 

A parsery to się same napiszą.

Obecny parser mBanku jakoś działa i jakoś się napisał. Więc chyba mBank
uznał że warto.

Ale to nadal nie jest bezkosztowo. 

Przecież nie mówię: ,,Zmusić wszystkich do parsera'', tylko ,,dać taką
możliwość''. Kto chce, skorzysta. Dla niekorzystających nie generuje to
żadnych kosztów. Dla korzystających daje możliwości.

Ale przecież taka możliwość jest, czyli podział na 4 linie. Kto chce to z
tego korzysta.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

To zależy od punktu widzenia.

Pokaż zalety z wersji ,,nie działa wcale''.

Nie generuje błedów, klient musi sobie tego sam pilnować i to jego problem
a nie banku.
 

Jeszcze raz, mnie to zwisa. Ale może znajdzie się klient który za coś
takiego pozwie bank.

A teraz nie pozwie?

A masz jakieś gwarancje poprawności? Zrozum, jeżeli chcesz wprowadzać
system całościowo to musi być wyspecyfikowany do najdrobniejszych
szczegółów. Bo potem każda poprawka specyfikacji wymaga poprawek w dużej
ilości systemów.

Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
masz problem.

A teraz nie masz? Przecie ograniczenie pól już istnieje.

No jest, do 140 znaków.
 

Wersja 2: Tak, jak podałem, każda linia ma znaczenie

I padamy jak coś jest za długie.

Jako i teraz.

Ale teraz nikt nie traktuje tego jako kluczową daną. Jest to czysto
informacyjne.

No i niech takie zostanie, skoro się boisz pozwów.

Ja się nie boję. Pokazuję ci pewne mozliwe przyczyny i ograniczenia.

No i nadal
mamy problem z firmami które potrafią mieć długie nazwy.

Mamy. Nie moja wina, że zaprojektowano eliksir z ciasnymi ograniczeniami.

No ja nadal mam nadzieję, że pokażesz świetny projekt nie mający wad i
mieszczący się w aktualnej specyfikacji i rozmiarach komunikatów. Sensowny
projekt.

Jakoś mBank sobie radzi.

A pan Zitek sobie wklepuje dane do programu księgowego i też mu działa.

I kosztuje.

Jak wszystko, co nie zmienia faktu, że i to i to to protezy, ale koszty
mniejsze niż przeprojektowanie i wdrożenie od nowa.
 

Tylko co to ma wspólnego z formatem danych w elixirze?

Nic, najlepiej jakby eliksir przesyłał dane tak zmiksowane, żeby w ogóle
ich rozpakowanie trwało miesiąc i wymagało pracy sztabu osób. AMEN.
Dla mnie EOT.

No skoro się unosisz.

Jak pokazałem wyżej to nie takie proste

Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
analogicznie jak teraz.

Ale teraz to nie ma znaczenia.

I nadal nie musi mieć. Może być tylko wygodą dla Tristana i podobnych.

Ale to już masz. Wystarczy, że wymusisz na mbanku podział pola na 4 linie w
cvsie. Polecisz najprostszym rozwiązaniem czyli 2 linie na nazwę, 2 na
adres.

Niech se stwierdza. Zresztą zupełnie nie widzę związku z moim podziałem
danych a tą wiedzą.

Jednym prostym zapytaniem analityk dostanie dane o wszystkich przelewach
które do tego banku wysłałeś. Ale zostawmy to bo to inna kwestia.
 

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków,

Było mówić, ze chcesz wszystko za darmochę.

to jak to ma działać? Może działać tylko, jak będzie miało już gotowe dane, więc
właśnie wtedy, gdy będzie wg mojej wersji. A wtedy wystarczy mi arkusz.

Zapytaj twórców, napisali pewnie mniej lub bardziej skomplikowanego
parsera. Zresztą wersja Lite jest za darmo a "Przeglądanie transakcji -
filtry podstawowe" ma. Sprawdź.

--
Kojer

W dniu 2010-06-28 14:30, Robert Kois pisze:

Dnia Mon, 28 Jun 2010 12:39:40 +0200, Przemysław Adam Śmiejek napisał(a):

No więc Tobie moja wersja nie szkodzi. MI moja wersja daje bonusy.

Ale moja jest aktualną z dokładnością do tego, że przesyłane są nadmiarowe
rzeczy. Ciekawe, że jakoś nie płaczesz by wymagane było podanie wszystkich
danych przy definiowaniu przelewu. Wpisujesz przy robieniu przelewu
wszystkie dane adresowe odbiorcy?

Odbiorca dane swoje zna, podobnie jak bank odbiorcy i wklepanie danych
odbiorcy to tylko informacja dla mnie, żeby mi się na historii odłożyło.
Więc jak se nie wklepię, to nie będę miał. Zmuszanie mnie, żebym sobie
wklepywał to, czego nie chcę, to inna sprawa niż masakrowanie csvała.

Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
Nie jest baza danych, jest systemem rozliczeniowym.

z protokołem transmisji danych pomiędzy bazami, który to protokół mógłby
być lepiej zaprojektowany.

O widze, że przeszedłeś z beznadziejnie zaprojektowany na mógłby być lepiej
zaprojektowany.

Jedno z drugim nie jest sprzeczne. Jest beznadziejnie zaprojektowany i
nie ma ku temu powodów, więc mógłby być lepiej.

Przecież nie mówię: ,,Zmusić wszystkich do parsera'', tylko ,,dać taką
możliwość''. Kto chce, skorzysta. Dla niekorzystających nie generuje to
żadnych kosztów. Dla korzystających daje możliwości.

Ale przecież taka możliwość jest, czyli podział na 4 linie. Kto chce to z
tego korzysta.

A jest ustalony standard ich znaczenia, jak tak, to luz.

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

To zależy od punktu widzenia.

Pokaż zalety z wersji ,,nie działa wcale''.

Nie generuje błedów,

Generuje.

klient musi sobie tego sam pilnować i to jego problem
a nie banku.

Analogicznie jak w wersji mojej, o ile bank nie daje gwarancji.

Jeszcze raz, mnie to zwisa. Ale może znajdzie się klient który za coś
takiego pozwie bank.

A teraz nie pozwie?

A masz jakieś gwarancje poprawności?

A pisałem coś o ich dawaniu w mojej wersji?

Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
masz problem.

A teraz nie masz? Przecie ograniczenie pól już istnieje.

No jest, do 140 znaków.

No i dodanie 5 separatorów skróci je do 145. To czyni tragedię?

No i nadal
mamy problem z firmami które potrafią mieć długie nazwy.

Mamy. Nie moja wina, że zaprojektowano eliksir z ciasnymi ograniczeniami.

No ja nadal mam nadzieję, że pokażesz świetny projekt nie mający wad i
mieszczący się w aktualnej specyfikacji i rozmiarach komunikatów. Sensowny
projekt.

Znaczy mam zaprojektować coś sensownego w zdupczonej specyfikacji? No to
skoro ma być 100% kompatybilne, to dodajemy separatory i ustalamy
kolejność danych. Kto się nie stosuje ma dokładnie to, co w chwili
obecnej i nic mu nie psujemy. Kto się stosuje, ma łatwiejsze działanie
parsera.

Jak pokazałem wyżej to nie takie proste

Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
analogicznie jak teraz.

Ale teraz to nie ma znaczenia.

I nadal nie musi mieć. Może być tylko wygodą dla Tristana i podobnych.

Ale to już masz. Wystarczy, że wymusisz na mbanku podział pola na 4 linie w
cvsie.

No to mówię, że skopali.

Polecisz najprostszym rozwiązaniem czyli 2 linie na nazwę, 2 na
adres.

O ile faktycznie tak się banki umówiły, to luz.

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków,

Było mówić, ze chcesz wszystko za darmochę.

Rozumiesz słowo POMIJAJĄC?

to jak to ma działać? Może działać tylko, jak będzie miało już gotowe dane, więc
właśnie wtedy, gdy będzie wg mojej wersji. A wtedy wystarczy mi arkusz.

Zapytaj twórców, napisali pewnie mniej lub bardziej skomplikowanego
parsera. Zresztą wersja Lite jest za darmo a "Przeglądanie transakcji -
filtry podstawowe" ma. Sprawdź.

Nie dał se rady. Zresztą mają "nowinkę" z 2007, że mbank coś zmienił i
naprawiają.
Sprzedaż też mają wstrzymaną. Więc pewnie umarło śmiercią naturalną.


--
Przemysław Adam Śmiejek

Dnia Mon, 28 Jun 2010 15:14:57 +0200, Przemysław Adam Śmiejek napisał(a):

No więc Tobie moja wersja nie szkodzi. MI moja wersja daje bonusy.

Ale moja jest aktualną z dokładnością do tego, że przesyłane są nadmiarowe
rzeczy. Ciekawe, że jakoś nie płaczesz by wymagane było podanie wszystkich
danych przy definiowaniu przelewu. Wpisujesz przy robieniu przelewu
wszystkie dane adresowe odbiorcy?

Odbiorca dane swoje zna, podobnie jak bank odbiorcy i wklepanie danych
odbiorcy to tylko informacja dla mnie, żeby mi się na historii odłożyło.
Więc jak se nie wklepię, to nie będę miał. Zmuszanie mnie, żebym sobie
wklepywał to, czego nie chcę, to inna sprawa niż masakrowanie csvała.

Tu akurat nie mówimy o masakrowaniu csvała a o nadmiarowości przesyłanych
danych. To wypełniasz czy nie? Bo jak nie to jakoś sobie radzisz z
rozliczeniami po samej nazwie.
 

Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
Nie jest baza danych, jest systemem rozliczeniowym.

z protokołem transmisji danych pomiędzy bazami, który to protokół mógłby
być lepiej zaprojektowany.

O widze, że przeszedłeś z beznadziejnie zaprojektowany na mógłby być lepiej
zaprojektowany.

Jedno z drugim nie jest sprzeczne. Jest beznadziejnie zaprojektowany i
nie ma ku temu powodów, więc mógłby być lepiej.

Nie jest, ale ciągle czekam, ze pokażesz coś lepszego. Bo na razie to
prezentujesz postawę małego jasia który krzyczy, że autobus jest
beznadziejnie zaprojektowany bo nie ma zamontowanej karuzeli w środku.
 

Przecież nie mówię: ,,Zmusić wszystkich do parsera'', tylko ,,dać taką
możliwość''. Kto chce, skorzysta. Dla niekorzystających nie generuje to
żadnych kosztów. Dla korzystających daje możliwości.

Ale przecież taka możliwość jest, czyli podział na 4 linie. Kto chce to z
tego korzysta.

A jest ustalony standard ich znaczenia, jak tak, to luz.

Nie, ale nikt ci nie broni takiego założenia przyjąć, w sporej części
pewnie zadziała a reszta to wyjątki na które się zgadzasz przecież.
 

Jak widać z twoich kiepskich przykładów powyżej to może działać ale
niekoniecznie musi.

I tak jest lepsze niż brak w ogóle działania.

To zależy od punktu widzenia.

Pokaż zalety z wersji ,,nie działa wcale''.

Nie generuje błedów,

Generuje.

Nie ma funkcjonalności to nie ma błedów z nią związanych.
 

klient musi sobie tego sam pilnować i to jego problem
a nie banku.

Analogicznie jak w wersji mojej, o ile bank nie daje gwarancji.

Twoja wersja wymaga zmian, to co jest teraz działa. Teraz to ty musisz się
dostosować.

Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
masz problem.

A teraz nie masz? Przecie ograniczenie pól już istnieje.

No jest, do 140 znaków.

No i dodanie 5 separatorów skróci je do 145. To czyni tragedię?

Nie, ale wymaga zmian i sensu nie ma. Aktualnie już są separatory co 35
znaków.

Znaczy mam zaprojektować coś sensownego w zdupczonej specyfikacji? No to
skoro ma być 100% kompatybilne, to dodajemy separatory i ustalamy
kolejność danych. Kto się nie stosuje ma dokładnie to, co w chwili
obecnej i nic mu nie psujemy. Kto się stosuje, ma łatwiejsze działanie
parsera.

Tylko, że to osiągamy dzieląc na linie. Bez żadnych kosztów, procent błędów
może trochę większy ale sam nie chciałeś żadnych gwarancji.
 

Ale to już masz. Wystarczy, że wymusisz na mbanku podział pola na 4 linie w
cvsie.

No to mówię, że skopali.

Jak już mówiłem to problem mbanku, mnie to wisi.
 

Polecisz najprostszym rozwiązaniem czyli 2 linie na nazwę, 2 na
adres.

O ile faktycznie tak się banki umówiły, to luz.

Ale po co miały się umawiać? Im to tak naprawdę do niczego potrzebne nie
jest. Część może tak robi, część może nie. Nie podejrzewam jakiegoś
superparsera w mbanku, pewnie lecą tego typu metodą mając w poważaniu
błędy.

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków,

Było mówić, ze chcesz wszystko za darmochę.

Rozumiesz słowo POMIJAJĄC?

Brzmiało to jak wyrzut.
 

to jak to ma działać? Może działać tylko, jak będzie miało już gotowe dane, więc
właśnie wtedy, gdy będzie wg mojej wersji. A wtedy wystarczy mi arkusz.

Zapytaj twórców, napisali pewnie mniej lub bardziej skomplikowanego
parsera. Zresztą wersja Lite jest za darmo a "Przeglądanie transakcji -
filtry podstawowe" ma. Sprawdź.

Nie dał se rady. Zresztą mają "nowinkę" z 2007, że mbank coś zmienił i
naprawiają.
Sprzedaż też mają wstrzymaną. Więc pewnie umarło śmiercią naturalną.

Poszukaj czegoś innego, mam za ciebie odwalać robotę? Mi to do niczego nie
potrzebne.

--
Kojer

W dniu 2010-06-28 15:57, Robert Kois pisze:

Więc jak se nie wklepię, to nie będę miał. Zmuszanie mnie, żebym sobie
wklepywał to, czego nie chcę, to inna sprawa niż masakrowanie csvała.

Tu akurat nie mówimy o masakrowaniu csvała a o nadmiarowości przesyłanych
danych. To wypełniasz czy nie? Bo jak nie to jakoś sobie radzisz z
rozliczeniami po samej nazwie.

Nie rozumiem tego zdania.

Tylko, że to osiągamy dzieląc na linie. Bez żadnych kosztów, procent błędów
może trochę większy ale sam nie chciałeś żadnych gwarancji.

No ale jak to zaproponowałem, to marudziłeś, że źle.

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków,

Było mówić, ze chcesz wszystko za darmochę.

Rozumiesz słowo POMIJAJĄC?

Brzmiało to jak wyrzut.

Bo jest to wada, że muszę kupować zewnętrzne narzędzia, ale poza tym
torem dyskusji, więc pomińmy.

Poszukaj czegoś innego, mam za ciebie odwalać robotę? Mi to do niczego nie
potrzebne.

I znów nie zrozumiałeś. Teraz już całościowo z mojej strony EOT.

--
Przemysław Adam Śmiejek

Dnia Mon, 28 Jun 2010 16:30:09 +0200, Przemysław Adam Śmiejek napisał(a):

Więc jak se nie wklepię, to nie będę miał. Zmuszanie mnie, żebym sobie
wklepywał to, czego nie chcę, to inna sprawa niż masakrowanie csvała.

Tu akurat nie mówimy o masakrowaniu csvała a o nadmiarowości przesyłanych
danych. To wypełniasz czy nie? Bo jak nie to jakoś sobie radzisz z
rozliczeniami po samej nazwie.

Nie rozumiem tego zdania.

Skoro dane odbiorcy nie są ważne to czemu ważne sa dane nadawcy. No
możliwe, że tylko dostajesz przelewy a sam ich nie wykonujesz, ale do
kompletu rozliczeń powinieneś miec obie strony.
 

Tylko, że to osiągamy dzieląc na linie. Bez żadnych kosztów, procent błędów
może trochę większy ale sam nie chciałeś żadnych gwarancji.

No ale jak to zaproponowałem, to marudziłeś, że źle.

O Matko Boska. No bo z mojego punktu widzenia to jest źle (a dokładniej:
nie jest dobrze).

http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków,

Było mówić, ze chcesz wszystko za darmochę.

Rozumiesz słowo POMIJAJĄC?

Brzmiało to jak wyrzut.

Bo jest to wada, że muszę kupować zewnętrzne narzędzia, ale poza tym
torem dyskusji, więc pomińmy.

Poszukaj banku który da ci to za darmo. Albo płać. Nie ma darmowych
obiadków.

Poszukaj czegoś innego, mam za ciebie odwalać robotę? Mi to do niczego nie
potrzebne.

I znów nie zrozumiałeś. Teraz już całościowo z mojej strony EOT.

No to proponuję byś zamiast bez sensu dyskutować poczytał sobie o
rozliczeniach międzybankowych i KIRze, bo z postów obok widać, że masz
przyzerowe pojęcie o tym jak to działa.

--
Kojer

W dniu 2010-06-28 18:15, Robert Kois pisze:

Dnia Mon, 28 Jun 2010 16:30:09 +0200, Przemysław Adam Śmiejek napisał(a):

Więc jak se nie wklepię, to nie będę miał. Zmuszanie mnie, żebym sobie
wklepywał to, czego nie chcę, to inna sprawa niż masakrowanie csvała.

Tu akurat nie mówimy o masakrowaniu csvała a o nadmiarowości przesyłanych
danych. To wypełniasz czy nie? Bo jak nie to jakoś sobie radzisz z
rozliczeniami po samej nazwie.

Nie rozumiem tego zdania.

Skoro dane odbiorcy nie są ważne to czemu ważne sa dane nadawcy.

Czasami są ważne, a czasami nie. Jak są, to sobie wklepię, a jak nie są,
to po co mnie zmuszać? Wklepuje dla siebie.

Dane nadawcy są po pierwsze zazwyczaj ważniejsze, a po drugie są już
wklepane i tylko system ma je przenieść.

No
możliwe, że tylko dostajesz przelewy a sam ich nie wykonujesz, ale do
kompletu rozliczeń powinieneś miec obie strony.

Owszem, dlatego w większości przypadków wklepuję. Choć czasami tylko
imię i nazwisko, bo czasami tyle mi wystarcza. Nie mówię, że adres jest
tak ważny w większości przypadków. Przy przychodzących prędzej, można go
np. użyć do zaadresowania przesyłki. Choć akurat ja nie handluję, więc
mi mniej.



--
Przemysław Adam Śmiejek

Chcesz nie głosować na Jarka?
Najpierw zobacz: http://hungry.w.of.pl/pro-life.htm

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

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

Problem w tym, ze elixir to nie jest zadna baza danych, i nie moze byc
w zwiazku z tym w zadnej postaci normalnej.
W szczegolnosci, niezbedne jest kazdorazowe przesylanie danych obu
stron (byc moze zmiennych).

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.

Ale elixir z zalozenia ma przenosic te dane, ktore przenosi, i innych ma
nie przenosic. Np. ma z zalozenia nie przenosic takich rzeczy jak numer
klienta itp.

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.

Skad informacja, ze idzie eliksirem?

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.

Dosc ciekawa koncepcja.

Ale juĹź przy przelewie z obcego banku, one
jakoś pomiędzy sobą muszą to weryfikować oraz rozliczać prowizje i inne
pewnie duperele.

Jesli juz dowiedziales sie o postaciach normalnych, to teraz moze czas
na transakcyjnosc. BTW prowizje itp. to typowo sprawy wewnetrzne banku.

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

No i jak to tam wyglada w sprawie postaci normalnych?

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.

To jakie wartosci zaproponujesz? Wez pod uwage, ze Eliksir nie powstal
dzis.

Brak ograniczenia? Co bedzie, gdy ktos wpisze np. terabajtowy tytul?
--
Krzysztof Halasa

W dniu 2010-06-27 22:40, Krzysztof Halasa pisze:

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.

Skad informacja, ze idzie eliksirem?

To znaczy idzie w momentach sesji, razem z sesjami. Chodziło mi o to, że
pomimo braku konieczności korzystania z KIR i teoretycznie łatwej
realizacji onlinowości w praktyce, tego się nie robi. Więc jakiś powód
jest, nicht wahr?

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.

Dosc ciekawa koncepcja.

Jeżeli jej masz coś do zarzucenia, to powiedz.

Ale juĹź przy przelewie z obcego banku, one
jakoś pomiędzy sobą muszą to weryfikować oraz rozliczać prowizje i inne
pewnie duperele.

Jesli juz dowiedziales sie o postaciach normalnych, to teraz moze czas
na transakcyjnosc.

Bez związku z tematem

BTW prowizje itp. to typowo sprawy wewnetrzne banku.

Nieprawda. Choćby prowizje dla KIR. Ale również banki jakoś między sobą
rozwiązują stany posiadania, bo już się nie wozi sztabek złota, prawdaż?

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

No i jak to tam wyglada w sprawie postaci normalnych?

Nie wiem, rzadko korzystam. Wiem, że było wpisane w bazę.

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.

To jakie wartosci zaproponujesz?

Nie wiem, bo nie znam dokładnie mechanizmów działania. Jeżeli to format
binarny ze sztywnymi polami, to pewnie bez większej modyfikacji można
tylko wykorzystać obecne pola. Jeżeli tekstowy, to w zasadzie
ograniczenia nie występują. Można założyć, że i 1000 znaków ma nazwa.

Brak ograniczenia? Co bedzie, gdy ktos wpisze np. terabajtowy tytul?

Przecież nie zakładamy nieskończoności tylko wartości logiczne. Zresztą
teraz też są ograniczenia. I skoro teraz ilość znaków niewielka jest OK,
to jak wprowadzić podział na pola w nazwie, to nagle będzie dramatem?
Jaja sobie robicie.


--
Przemysław Adam Śmiejek

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

To znaczy idzie w momentach sesji, razem z sesjami. Chodziło mi o to, że
pomimo braku konieczności korzystania z KIR i teoretycznie łatwej
realizacji onlinowości w praktyce, tego się nie robi. Więc jakiś powód
jest, nicht wahr?

Pewnie jest, mysle ze wiecej niz jeden. Ale to nie ma nic wspolnego
z Eliksirem, oprocz tego, ze akurat (byc moze) godziny sie pokrywaja.

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.

Dosc ciekawa koncepcja.

Jeżeli jej masz coś do zarzucenia, to powiedz.

Musialbym ksiazke napisac. Ale sa juz takie.

Ale juĹź przy przelewie z obcego banku, one
jakoś pomiędzy sobą muszą to weryfikować oraz rozliczać prowizje i inne
pewnie duperele.

Jesli juz dowiedziales sie o postaciach normalnych, to teraz moze czas
na transakcyjnosc.

Bez związku z tematem

Przeciwnie, wlasnie transakcyjnosc ma scisly zwiazek z tematem. Nie ma
zadnego "rozliczania prowizji" ani wzajemnej weryfikacji, kazdy przelew
to transakcja, ktora jest wykonywana "atomowo", bez zadnej weryfikacji,
tylko na podstawie zawartosci informacji Elixir oraz bazy danych banku
(jednego). I tak wlasnie ma byc, inaczej nie da sie tego sensownie
zrobic.

BTW prowizje itp. to typowo sprawy wewnetrzne banku.

Nieprawda. Choćby prowizje dla KIR.

Prawda. Prowizje dla KIR to zupelnie inna sprawa, obciazaja zupelnie
inne konto i to cos takiego, jak np. MIF przy transakcjach karcianych.

Ale również banki jakoś między sobą
rozwiązują stany posiadania, bo już się nie wozi sztabek złota,
prawdaĹź?

Jasne, ale to zupelnie niezalezne sprawa, ma z tym jeszcze mniej
wspolnego niz prowizje dla KIR. Bank po prostu musi pilnowac srodkow na
rachunku w NBP (i innych) i tyle. Sam pojedynczy przelew zlecony przez
Kowalskiego na rzecz Nowaka nie ma tu nic do rzeczy.

Przecież nie zakładamy nieskończoności tylko wartości logiczne. Zresztą
teraz też są ograniczenia. I skoro teraz ilość znaków niewielka jest OK,
to jak wprowadzić podział na pola w nazwie, to nagle będzie dramatem?
Jaja sobie robicie.

Ale jakie chcesz wprowadzic te ograniczenia, konkretnie? Bo w tej chwili
sa dosc konkretne.
Kontynuujac analogie z listami, to tak jakbys chcial wprowadzic dla
adresata i nadawcy pola na "imie", "nazwisko", "ulice", "numer domu",
"numer lokalu" itd. Owszem, kod pocztowy moze byc wyodrebniony, bo
wystepuje zawsze (podobnie jak np. numer rozliczeniowy albo numer
konta). Ale inne rzeczy? Chcialbys miec takie "okienka" na kopercie?
--
Krzysztof Halasa

Ciach....


Widzę, że rozpętała się niezła dyskusja dotykająca poniekąd rzeczy o których mam pewne pojęcie ;-).

W poruszonych tematach chciałbym poruszyć kilka kwestii:

1. Jeżeli już banki i KIR ustalą "rubryczki" do wpisywania adresu, nazwy itd., to jak zagwarantować,  że zlecając przelew przez kanał internetowy zamiast adresu wpiszę nazwę a zamiast nazwy adres? Albo inne jeszcze kombinacje...

2. To nie zupełnie tak, że to KIR narzuca format wymiany danych. Format ten powstał na bazie formatu komunikatów SWIFT, wykorzystywanych przez banki na całym świecie, a banki w Polsce przyjęły ten format - po co tworzyć coś nowego, jeżeli to co jest działa i się sprawdza, a poza tym jest w miarę kompatybilne z "całym światem". Na marginesie - po wejściu do strefy euro będzie konieczność stosowania się do wymogów SEPA, a tam już jest XML i więcej danych można przekazać.

3. Kir nie pobiera prowizji, tylko opłaty. Nie zależnie od kwoty przesyłanej transakcji (przelewu) jest to taka sama kwota.

4. Każda modyfikacja systemu bankowego kosztuje. Nawet dostawienie średnika, tam gdzie go nie było. Jeżeli taka modyfikacja jest przydatna (nawet nie niezbędna) dla jednego klienta banku, to nikt jej nie wprowadzi za free.; -)

5. Do "rekoncyljacji" płatności można użyć jednej z wielu aplikacji typu Money/Quicken/Budżet Domowy. Dość dobrze funkcjonujące programy pozwalają na import danych w wielu formatach i przypisanie odbiorca/nadawca oraz podział na kategorie. Na marginesie, czytałem ostatnio, że producentom takich programów powoli przestaje się to opłacać, a więc nie ma jakiegoś szczególnego popytu na takie aplikacje/usługi.



--
Pozdrawiam,
MacGregor

W dniu 2010-06-28 13:17, Krzysztof Halasa pisze:

> Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

>> To znaczy idzie w momentach sesji, razem z sesjami. Chodziło mi o

to, Ĺźe

>> pomimo braku konieczności korzystania z KIR i teoretycznie łatwej
>> realizacji onlinowości w praktyce, tego się nie robi. Więc jakiś powód
>> jest, nicht wahr?

> Pewnie jest, mysle ze wiecej niz jeden. Ale to nie ma nic wspolnego
> z Eliksirem, oprocz tego, ze akurat (byc moze) godziny sie pokrywaja.

Ale to nie ma związku. Uprościłem sformułowanie, bo nie o to chodzi. W
pełnej jasności wypowiedzi brzmi to tak:

Robert: Przelewy powinny iść natychmiastowo i pewnie niedługo tak będzie.

Ja: Nie jestem przekonany, bo nawet w ramach tak ściśle ze sobą
związanych banków jak mBank i Multibank nie idą natychmiastowo, tylko w
terminach pokrywających się z eliksirem.

Podejrzewam, że formalnie te przelewy są jako przelewy zewnętrzne i
rozpakowują się przy przetwarzaniu eliksiru, nawet jak nie idą w KIR.

> Przeciwnie, wlasnie transakcyjnosc ma scisly zwiazek z tematem. Nie ma
> zadnego "rozliczania prowizji" ani wzajemnej weryfikacji, kazdy przelew
> to transakcja, ktora jest wykonywana "atomowo",

Atomowość nie ma związku.  Przelew w ramach mBanku teĹź jest transakcją
atomową.

> bez zadnej weryfikacji,
> tylko na podstawie zawartosci informacji Elixir oraz bazy danych banku
> (jednego).

Nie wierzę, że mBank przyjmie dowolną informację i na jej podstawie mi
zwiększy stan konta. Przecież te numerki na koncie odpowiadają stanowi
finansowemu ,,sejfu'' banku.  Rozliczenie musi być przeprowadzone tak,
żeby banki między sobą rozliczyły stany posiadania (przesłały sobie
,,sztabki złota''). Np.

Ja sobie to skrĂłtowo wyobraĹźam tak:

Robimy rozliczenie, sesja 1:
Multi do mBanku => 1 miliard
mBank do multi ==> 0,5 miliarda
Wysyłamy ciężarówkę z 0,5 miliarda pomiędzy sejfami.

>>> BTW prowizje itp. to typowo sprawy wewnetrzne banku.

>> Nieprawda. Choćby prowizje dla KIR.

> Prawda. Prowizje dla KIR to zupelnie inna sprawa, obciazaja zupelnie
> inne konto i to cos takiego, jak np. MIF przy transakcjach karcianych.

No ale muszą być rozliczane. Od czegoś ten KIR jest.

>> Ale również banki jakoś między sobą
>> rozwiązują stany posiadania, bo już się nie wozi sztabek złota,
>> prawdaĹź?

> Jasne, ale to zupelnie niezalezne sprawa, ma z tym jeszcze mniej
> wspolnego niz prowizje dla KIR. Bank po prostu musi pilnowac srodkow na
> rachunku w NBP (i innych) i tyle. Sam pojedynczy przelew zlecony przez
> Kowalskiego na rzecz Nowaka nie ma tu nic do rzeczy.

No o ile idzie w ramach 1 banku. O ile idzie pomiędzy bankami, to
zawartości tychże sejfów się różnią.

>> Przecież nie zakładamy nieskończoności tylko wartości logiczne.

Zresztą

>> teraz też są ograniczenia. I skoro teraz ilość znaków niewielka

jest OK,

>> to jak wprowadzić podział na pola w nazwie, to nagle będzie dramatem?
>> Jaja sobie robicie.

>
> Ale jakie chcesz wprowadzic te ograniczenia, konkretnie? Bo w tej chwili
> sa dosc konkretne.

A to juĹź kwestia o czym rozmawiamy. Czy:

a) Jak powinien wyglądać idealny system?

czy:

b) jak zmodyfikować obecny?

czy

c) jak nałożyć łatę na obecny, żeby był w 100% kompatybilny

Opierając się na danych Roberta, wersję (c) już podałem. Pozostawia ona
obecne ograniczenia więc nie ma o czym gadać. Wersja (b) nie wiem jak ma
wyglądać, bo nie znam niuansów technologicznych i na ile można mieszać.
Więc nie odpowiem. W wersji (a) oczywiście ograniczenia powinny być
podyktowane techniką, czyli faktycznie słanie 80PiB w każdym polu
niekoniecznie musi być dopuszczone i wydaje mi się, że wartości rozsądne
to maks 1000 znaków na pole. Ale nawet jak będzie 5000 to myślę, że się
nie zawali.

> Kontynuujac analogie z listami, to tak jakbys chcial wprowadzic dla
> adresata i nadawcy pola na "imie", "nazwisko", "ulice", "numer domu",
> "numer lokalu" itd. Owszem, kod pocztowy moze byc wyodrebniony, bo
> wystepuje zawsze (podobnie jak np. numer rozliczeniowy albo numer
> konta). Ale inne rzeczy? Chcialbys miec takie "okienka" na kopercie?

Nierzadko są.

Nie chciałbym, bo nie wypisuję adresów ręcznie, tylko drukuję na listach
i wkładam w kopertę z okienkiem, ale nadal nie widzę problemu. Jeśli
pijesz do ,,ojejku, nazwa firmy mi nie pasuje'' to przecie podałem
format uniwersalniejszy:


Nazwisko lub nazwa (linijka 1)
Imię lub nazwa (linijka 2)
Ulica
kod i miasto

Choć to i tak sztywny format, wpasowywany w sztywne istniejące ramy
(wersja c), bo jakby zrobić zwykły protokół tekstowy bez cudowania od
zera, to nie ma problemu, żeby wewnątrz te pola wręcz nazywać i dać
więcej możliwości do przesłania.



W dniu 2010-06-28 13:58, MacGregor pisze:

> Widz�, �e rozp�ta�a si� niez�a dyskusja dotykaj�ca poniek�d rzeczy o

kt�rych

> mam pewne poj�cie ;-).

http://www.grzegorz.net/oe/config.php
Jakbyś mógł naprawić konfigurację czytnika, bo krzaczki widzę :(

> W poruszonych tematach chcia�bym poruszy� kilka kwestii:
> 1. Je�eli ju� banki i KIR ustal� "rubryczki" do wpisywania adresu,

nazwy

> itd., to jak zagwarantowaďż˝,  ďż˝e zlecajďż˝c przelew przez kanaďż˝

internetowy

> zamiast adresu wpiszďż˝ nazwďż˝ a zamiast nazwy adres? Albo inne jeszcze
> kombinacje...

Po pierwsze: Dane te uzupełnia bank, przynajmniej w przypadku mBanku nie
mam możliwości ich zmiany.

Po drugie: To nie ma być system weryfikacji zapewniający pewność nazwy,
tylko system dający większe możliwości dla odbiorcy przetwarzania
danych. Jak ktoś celowo nadaje przelew na poczcie i wklepie nadawcę

Tata Grzybek, Toruń

to sam się prosi o zaliczenie jego wpłaty na poczet Taty Grzybka.
To co mówisz, to zupełnie inne zagadnienie.

> b�dzie konieczno�� stosowania si� do wymog�w SEPA, a tam ju� jest XML i
> wi�cej danych mo�na przekaza�.

Czyli jednak to nie jest tak, że ja coś od czapy wymyślam i że
faktycznie może coś być lepiej rozwiązane.

> 3. Kir nie pobiera prowizji, tylko op�aty. Nie zale�nie od kwoty

przesy�anej

> transakcji (przelewu) jest to taka sama kwota.

Ale pobiera i jest to odpowiednio rozliczane.

> 4. Ka�da modyfikacja systemu bankowego kosztuje. Nawet dostawienie

�rednika,

> tam gdzie go nie by�o. Je�eli taka modyfikacja jest przydatna (nawet

nie

> niezb�dna) dla jednego klienta banku, to nikt jej nie wprowadzi za

free.; -)

No nie sądzę, żebym ja był jeden. Skopali eksport do CSV i już.

> na kategorie. Na marginesie, czyta�em ostatnio, �e producentom takich
> program�w powoli przestaje si� to op�aca�, a wi�c nie ma jakiego�
> szczeg�lnego popytu na takie aplikacje/us�ugi.

Pewnie dlatego, że banki dają coraz większe możliwości. Choć wciąż kulawe.

--
 Przemysław Adam Śmiejek

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

Podejrzewam, że formalnie te przelewy są jako przelewy zewnętrzne i
rozpakowują się przy przetwarzaniu eliksiru, nawet jak nie idą w KIR.

Moze nie w tym przypadku, ale ogolnie rzecz biorac powody, dla ktorych
przelewy nie sa wykonywane natychmiast sa rozne i nie wszystkie wynikaja
z techniki.

> Przeciwnie, wlasnie transakcyjnosc ma scisly zwiazek z tematem. Nie ma
> zadnego "rozliczania prowizji" ani wzajemnej weryfikacji, kazdy przelew
> to transakcja, ktora jest wykonywana "atomowo",

Atomowość nie ma związku.  Przelew w ramach mBanku teĹź jest transakcją
atomową.

Bardzo ciekawe rzeczy piszesz, ale niestety nie maja one potwierdzenia
w rzeczywistosci. To ze przelew wewnetrzny w mBanku jest transakcja
"atomowa" ma dokladnie takie samo znaczenie: nie ma zadnego uzgadniania
czegokolwiek itp.

Nie wierzę, że mBank przyjmie dowolną informację i na jej podstawie mi
zwiększy stan konta. Przecież te numerki na koncie odpowiadają stanowi
finansowemu ,,sejfu'' banku.  Rozliczenie musi być przeprowadzone tak,
żeby banki między sobą rozliczyły stany posiadania (przesłały sobie
,,sztabki złota''). Np.

Ja sobie to skrĂłtowo wyobraĹźam tak:

Robimy rozliczenie, sesja 1:
Multi do mBanku => 1 miliard
mBank do multi ==> 0,5 miliarda
Wysyłamy ciężarówkę z 0,5 miliarda pomiędzy sejfami.

Bardzo smieszne, ale rzeczywistosc, zwlaszcza w kontekscie Eliksiru,
wyglada nieco inaczej. Nie ma zadnego wysylania "sztabek zlota", bo...
przeplywy eliksirowe kompensuja sie do zera :-)

> Prawda. Prowizje dla KIR to zupelnie inna sprawa, obciazaja zupelnie
> inne konto i to cos takiego, jak np. MIF przy transakcjach karcianych.

No ale muszą być rozliczane. Od czegoś ten KIR jest.

Jasne, ale to nie jest zwiazane z konkretnymi przelewami. Bank po prostu
placi A zl * B przelewow + C zl * D przelewow itd. To po prostu zwykle
koszty dzialalnosci. Jesli korzystasz z obcego platnego bankomatu to jak
sie z tego rozliczasz? Sa koszty i tyle.

Opierając się na danych Roberta, wersję (c) już podałem. Pozostawia ona
obecne ograniczenia więc nie ma o czym gadać. Wersja (b) nie wiem jak ma
wyglądać, bo nie znam niuansów technologicznych i na ile można mieszać.
Więc nie odpowiem. W wersji (a) oczywiście ograniczenia powinny być
podyktowane techniką, czyli faktycznie słanie 80PiB w każdym polu
niekoniecznie musi być dopuszczone i wydaje mi się, że wartości rozsądne
to maks 1000 znaków na pole. Ale nawet jak będzie 5000 to myślę, że się
nie zawali.

A jak przepakujesz te 1000 znakow do systemu, ktory tyle nie obsluguje?

> Kontynuujac analogie z listami, to tak jakbys chcial wprowadzic dla
> adresata i nadawcy pola na "imie", "nazwisko", "ulice", "numer domu",
> "numer lokalu" itd. Owszem, kod pocztowy moze byc wyodrebniony, bo
> wystepuje zawsze (podobnie jak np. numer rozliczeniowy albo numer
> konta). Ale inne rzeczy? Chcialbys miec takie "okienka" na kopercie?

Nierzadko są.

Powaznie? Nie przypominam sobie.

Nie chciałbym, bo nie wypisuję adresów ręcznie, tylko drukuję na listach
i wkładam w kopertę z okienkiem, ale nadal nie widzę problemu. Jeśli
pijesz do ,,ojejku, nazwa firmy mi nie pasuje'' to przecie podałem
format uniwersalniejszy:


Nazwisko lub nazwa (linijka 1)
Imię lub nazwa (linijka 2)
Ulica
kod i miasto

To teraz dodaj do tego listy "poste restante", albo np. takie, gdzie
trzeba podac jeszcze nazwe stanu.
Poza tym przeciez ten Twoj format przypomina jakby to, co mamy
w Eliksirze, nie?

Choć to i tak sztywny format, wpasowywany w sztywne istniejące ramy
(wersja c), bo jakby zrobić zwykły protokół tekstowy bez cudowania od
zera, to nie ma problemu, żeby wewnątrz te pola wręcz nazywać i dać
więcej możliwości do przesłania.

Tyle ze komunikaty trzeba nastepnie zaimportowac, i troche glupio bedzie
jesli najbardziej istotne elementy przekazu przy tym utracimy.
--
Krzysztof Halasa

W dniu 2010-06-28 16:51, Krzysztof Halasa pisze:

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

Podejrzewam, że formalnie te przelewy są jako przelewy zewnętrzne i
rozpakowują się przy przetwarzaniu eliksiru, nawet jak nie idą w KIR.

Moze nie w tym przypadku, ale ogolnie rzecz biorac powody, dla ktorych
przelewy nie sa wykonywane natychmiast sa rozne i nie wszystkie wynikaja
z techniki.

Dziękuję za napisanie tego samego, co ja.

Robimy rozliczenie, sesja 1:
Multi do mBanku => 1 miliard
mBank do multi ==> 0,5 miliarda
Wysyłamy ciężarówkę z 0,5 miliarda pomiędzy sejfami.

Bardzo smieszne, ale rzeczywistosc, zwlaszcza w kontekscie Eliksiru,
wyglada nieco inaczej. Nie ma zadnego wysylania "sztabek zlota", bo...
przeplywy eliksirowe kompensuja sie do zera :-)

Jakim cudem? Przelewam 100zł i w tej samej chwili ktoś z dużą ilością
kasy jest zmuszany do przelania 100zł do innego banku?

Opierając się na danych Roberta, wersję (c) już podałem. Pozostawia ona
obecne ograniczenia więc nie ma o czym gadać. Wersja (b) nie wiem jak ma
wyglądać, bo nie znam niuansów technologicznych i na ile można mieszać.
Więc nie odpowiem. W wersji (a) oczywiście ograniczenia powinny być
podyktowane techniką, czyli faktycznie słanie 80PiB w każdym polu
niekoniecznie musi być dopuszczone i wydaje mi się, że wartości rozsądne
to maks 1000 znaków na pole. Ale nawet jak będzie 5000 to myślę, że się
nie zawali.

A jak przepakujesz te 1000 znakow do systemu, ktory tyle nie obsluguje?

A którą wersję omawiam w związku z 1000 znaków?

Nie chciałbym, bo nie wypisuję adresów ręcznie, tylko drukuję na listach
i wkładam w kopertę z okienkiem, ale nadal nie widzę problemu. Jeśli
pijesz do ,,ojejku, nazwa firmy mi nie pasuje'' to przecie podałem
format uniwersalniejszy:


Nazwisko lub nazwa (linijka 1)
Imię lub nazwa (linijka 2)
Ulica
kod i miasto

To teraz dodaj do tego listy "poste restante", albo np. takie, gdzie
trzeba podac jeszcze nazwe stanu.

Bez związku piszesz. Mieszasz wersje a-b-c i w ten sposób się nie da
dyskutować.

Poza tym przeciez ten Twoj format przypomina jakby to, co mamy
w Eliksirze, nie?

Bo to wersja (c), o czym pisałem linijkę niżej.

Choć to i tak sztywny format, wpasowywany w sztywne istniejące ramy
(wersja c), bo jakby zrobić zwykły protokół tekstowy bez cudowania od
zera, to nie ma problemu, żeby wewnątrz te pola wręcz nazywać i dać
więcej możliwości do przesłania.

Tyle ze komunikaty trzeba nastepnie zaimportowac, i troche glupio bedzie
jesli najbardziej istotne elementy przekazu przy tym utracimy.

A czemu chcesz stracić?

--
Przemysław Adam Śmiejek

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

Jakim cudem? Przelewam 100zł i w tej samej chwili ktoś z dużą ilością
kasy jest zmuszany do przelania 100zł do innego banku?

Trafiles w dziesiatke :-)

A jak przepakujesz te 1000 znakow do systemu, ktory tyle nie obsluguje?

A którą wersję omawiam w związku z 1000 znaków?

A tego to ja juz nie wiem.

To teraz dodaj do tego listy "poste restante", albo np. takie, gdzie
trzeba podac jeszcze nazwe stanu.

Bez związku piszesz. Mieszasz wersje a-b-c i w ten sposób się nie da
dyskutować.

Dlatego zeby w ogole bylo o czym dyskutowac, musisz zaproponowac cos
konkretnego. Dyskusja nie dziala tak, ze wystarczy napisac ze jest zle,
i liczyc ze ktos inny napisze co jest zle i jak powinno byc.

Tyle ze komunikaty trzeba nastepnie zaimportowac, i troche glupio bedzie
jesli najbardziej istotne elementy przekazu przy tym utracimy.

A czemu chcesz stracić?

Nie chce. Jak sobie to inaczej wyobrazasz, jesli pola z systemu
rozliczeniowego nie beda nijak nawet podobne do pol bazy danych banku?
--
Krzysztof Halasa

W dniu 2010-06-28 19:00, Krzysztof Halasa pisze:

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

Jakim cudem? Przelewam 100zł i w tej samej chwili ktoś z dużą ilością
kasy jest zmuszany do przelania 100zł do innego banku?

Trafiles w dziesiatke :-)

Myślałem, ze rozmawiamy poważnie.

A jak przepakujesz te 1000 znakow do systemu, ktory tyle nie obsluguje?

A którą wersję omawiam w związku z 1000 znaków?

A tego to ja juz nie wiem.

No to przykre, bo napisałem wyraźnie.

To teraz dodaj do tego listy "poste restante", albo np. takie, gdzie
trzeba podac jeszcze nazwe stanu.

Bez związku piszesz. Mieszasz wersje a-b-c i w ten sposób się nie da
dyskutować.

Dlatego zeby w ogole bylo o czym dyskutowac, musisz zaproponowac cos
konkretnego.

Zaproponowałem 3 wersje. Konkretne i jasne. Mieszasz cechy tych wersji i
twierdzisz, że ze sobą kolidują. Właśnie dlatego, że kolidują, to są 3
wersje oddzielne, a nie jedna z wszystkimi cechami.

Dyskusja nie dziala tak, ze wystarczy napisac ze jest zle,
i liczyc ze ktos inny napisze co jest zle i jak powinno byc.

Od kilkudziesięciu listów wyraźnie zaznaczam co jest źle oraz
przedstawiam różne wersje rozwiązań. Jako argument przeciw nim pojawiają
się kolizje pomiędzy wersjami, co jest po prostu bezsensowne.

Tyle ze komunikaty trzeba nastepnie zaimportowac, i troche glupio bedzie
jesli najbardziej istotne elementy przekazu przy tym utracimy.

A czemu chcesz stracić?

Nie chce. Jak sobie to inaczej wyobrazasz, jesli pola z systemu
rozliczeniowego nie beda nijak nawet podobne do pol bazy danych banku?

Ale o której wersji mówimy? Aczkolwiek ,,nijak podobne'' nie są w żadnej
z wersji, bo kaĹźda z nich nie daje gorszych wynikĂłw niĹź wersja obecna.
Więc możemy omawiać wady obiektywne, ale relatywnych względem obecnej
wersji nie ma.

--
Przemysław Adam Śmiejek

Chcesz nie głosować na Jarka?
Najpierw zobacz: http://hungry.w.of.pl/pro-life.htm

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3ocevfbwh.fsfintrepid.localdomain...

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

Podejrzewam, że formalnie te przelewy są jako przelewy zewnętrzne i
rozpakowują się przy przetwarzaniu eliksiru, nawet jak nie idą w KIR.

Moze nie w tym przypadku, ale ogolnie rzecz biorac powody, dla ktorych
przelewy nie sa wykonywane natychmiast sa rozne i nie wszystkie wynikaja
z techniki

Poprostu jedna komórka szykuje zbiory do transakcji międzybankowych i do odbiorców "wewnętrznych". Poprostu łatwiej to zrobić w jednym czasie.


Ciach

Nie wierzę, że mBank przyjmie dowolną informację i na jej podstawie mi
zwiększy stan konta. Przecież te numerki na koncie odpowiadają stanowi
finansowemu ,,sejfu'' banku.  Rozliczenie musi być przeprowadzone tak,
żeby banki między sobą rozliczyły stany posiadania (przesłały sobie
,,sztabki złota''). Np.
Ja sobie to skrĂłtowo wyobraĹźam tak:
Robimy rozliczenie, sesja 1:
Multi do mBanku => 1 miliard
mBank do multi ==> 0,5 miliarda
Wysyłamy ciężarówkę z 0,5 miliarda pomiędzy sejfami.

Bardzo smieszne, ale rzeczywistosc, zwlaszcza w kontekscie Eliksiru,
wyglada nieco inaczej. Nie ma zadnego wysylania "sztabek zlota", bo...
przeplywy eliksirowe kompensuja sie do zera :-)

No nie tak zupełnie. W rozliczeniach rzeczywiście to co zostało wysłane, musi do kogoś trafić. Nawet jeżeli to jest nadawca (np zwroty błędnie "zaadresowanych" przelewów).
Natomiast banki w praktyce nie mają "bilansu" na 0. Natomiast wzajemne zobowiązania banków dokonywane są na rachunkach banków w NBP.
Nikt nie wozi w tym celu ani stabek złota (jak podobno było w Rezerwie Federalnej), ani fizycznie kasy ciężarówkami ;-).
Zmieniają się tylko zapisy na kontach.

Prawda. Prowizje dla KIR to zupelnie inna sprawa, obciazaja zupelnie
inne konto i to cos takiego, jak np. MIF przy transakcjach karcianych.

No ale muszą być rozliczane. Od czegoś ten KIR jest.

Z rozliczeniami banki dały by sobie radę same. KIR w większej mierze jest w celu "wzajemnej kompensaty rozliczeń".


Ciach...


--
Pozdrawiam,
MacGregor

"MacGregor" <macgregor@smieci.poczta.onet.pl> writes:

Natomiast banki w praktyce nie mają "bilansu" na 0. Natomiast wzajemne
zobowiązania banków dokonywane są na rachunkach banków w NBP.
Nikt nie wozi w tym celu ani stabek złota (jak podobno było w Rezerwie
Federalnej), ani fizycznie kasy ciężarówkami ;-).
Zmieniają się tylko zapisy na kontach.

Wlasnie z powyzszego wynika, ze wszystko bilansuje sie do zera.
Jednym z elementow sa rozliczenia na rachunkach bankow w NBP :-)
--
Krzysztof Halasa

W dniu 2010-06-29 12:39, Krzysztof Halasa pisze:

"MacGregor" <macgregor@smieci.poczta.onet.pl> writes:

Natomiast banki w praktyce nie mają "bilansu" na 0. Natomiast wzajemne
zobowiązania banków dokonywane są na rachunkach banków w NBP.
Nikt nie wozi w tym celu ani stabek złota (jak podobno było w Rezerwie
Federalnej), ani fizycznie kasy ciężarówkami ;-).
Zmieniają się tylko zapisy na kontach.

Pisałem w cudzysłowie przecież, prezentując ideę.

Wlasnie z powyzszego wynika, ze wszystko bilansuje sie do zera.
Jednym z elementow sa rozliczenia na rachunkach bankow w NBP :-)

No więc przy przelewach natychmiastowych masz konieczność ciągłego
rozliczania, no nie?

--
Przemysław Adam Śmiejek

Chcesz nie głosować na Jarka?
Najpierw zobacz: http://hungry.w.of.pl/pro-life.htm

Przemysław Adam Śmiejek <niechce@spamu.pl> writes:

No więc przy przelewach natychmiastowych masz konieczność ciągłego
rozliczania, no nie?

No tak. Ale przyznaje ze juz sie zgubilem i nie mam bladego pojecia do
czego zmierzasz.
--
Krzysztof Halasa

W dniu 2010-06-29 22:35, Krzysztof Halasa pisze:

No tak. Ale przyznaje ze juz sie zgubilem i nie mam bladego pojecia do
czego zmierzasz.

Do niczego. Ta część dyskusji brzmiała ,,Czy przelewy natychmiastowe są
możliwe do wprowadzenia oraz czy problemy są wyłącznie techniczne czy
też prawne?''. Nie znam odpowiedzi, więc tylko zastanawiałem się nad
tymi aspektami sugerując ew. problemy w 1 i w 2 zakresie.

--
Przemysław Adam Śmiejek

Chcesz nie głosować na Jarka?
Najpierw zobacz: http://hungry.w.of.pl/pro-life.htm

Użytkownik "Przemysław Adam Śmiejek" <niechce@spamu.pl> napisał w wiadomości news:i0dlt0$hmb$2news.onet.pl...

W dniu 2010-06-29 22:35, Krzysztof Halasa pisze:

No tak. Ale przyznaje ze juz sie zgubilem i nie mam bladego pojecia do
czego zmierzasz.

Do niczego. Ta część dyskusji brzmiała ,,Czy przelewy natychmiastowe są
możliwe do wprowadzenia oraz czy problemy są wyłącznie techniczne czy
też prawne?''. Nie znam odpowiedzi, więc tylko zastanawiałem się nad
tymi aspektami sugerując ew. problemy w 1 i w 2 zakresie.

Przelewy natychmiastowe między bankami są możliwe do wprowadzenia.
Problemy są tylko techniczno-organizacyjne ;-).
Chodzi jak zwykle o kasę. ;-)

--
Pozdrawiam,
MacGregor

Dnia Thu, 24 Jun 2010 12:53:57 +0200, Przemysław Adam Śmiejek napisał(a):

>> Czyli powinni móc oddzielić dane nadawcy od tytułu przelewu. Podział danych
>> nadawcy na poszczególne składniki może być dość skomplikowane.
> Czyli już sam eliksir jest spierdolony.... Ale dlaczego spierdolony? Uproszczony po prostu.

> 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. Podejrzewam, ze zaprojektowano to
tak by jak najprościej było się dołaczyć do systemu.

Możliwe, były wolne łącza więc może oszczędzano na wielkości paczki
ale najczęściej takie oszczędności w dłuższym terminie przynoszą szkód niż pożytku

Z punktu widzenia
eliksiru tych danych mogłoby wogóle nie być.

AFAIR wg prawa są istotne, ostatnio chyba znowu był szum w gazetach że banki
powinny sprawdzać dane teleadresowe przy przelewach. Generowało by masę odrzutów
ale tym wypadku to byłaby katastrofa znalazłem taki opis elixiru http://tinyurl.com/27oqgu3. Nie wiem jak się ma do
międzybankowego ale jak widać pola opisu i danych nadawcy jednak oddzielone

PS wiecie że niebezpiecznie jest otwierać takie linki ;)


--

Dnia Mon, 28 Jun 2010 20:02:45 +0200, Ra napisał(a):

Ale dla elixiru te dane są nieistotne. Podejrzewam, ze zaprojektowano to
tak by jak najprościej było się dołaczyć do systemu.

Możliwe, były wolne łącza więc może oszczędzano na wielkości paczki

Powody mogły być różne.

ale najczęściej takie oszczędności w dłuższym terminie przynoszą szkód niż pożytku

Może i przynoszą, ale według starej zasady, jak działa to nie ruszamy.
 

Z punktu widzenia
eliksiru tych danych mogłoby wogóle nie być.

AFAIR wg prawa są istotne, ostatnio chyba znowu był szum w gazetach że banki
powinny sprawdzać dane teleadresowe przy przelewach. Generowało by masę odrzutów
ale tym wypadku to byłaby katastrofa

Szum akurat był o zgodność danych _odbiorcy_. Dane nadawcy mało kogo
obchodzą (no może US ;)).
 

znalazłem taki opis elixiru http://tinyurl.com/27oqgu3. Nie wiem jak się ma do
międzybankowego ale jak widać pola opisu i danych nadawcy jednak oddzielone

Ale to już w pierwszym moim poście w tym wątku podałem.

PS wiecie że niebezpiecznie jest otwierać takie linki ;)

Nie bardzo, ale tak czy tak skracacze linków są protezą na kulawe czytniki
(przynajmniej na newsach). Normalne czytniki sobie radzą.

--
Kojer

W dniu 2010-06-24 12:28, Robert Kois pisze:

Cóż, może być problem, szczególnie z tymi ludźmi z Zabrza bez przeszukania
całego pola. Z eliksiru dostają (z tego o co pytasz):

Tak se właśnie luknąłem w system mBanku i co widzę:

Rachunek nadawcy
81 1020 2401 0000 0602 0038 3414
Nazwa/imię i nazwisko nadawcy
STOWARZYSZENIE INŻYNIERÓW I TECHNIKÓW PRZEMYSŁU CHEMICZNEGO W W-WIE
Adres nadawcy (ulica)
UL. GÓRNYCH WAŁÓW 25
Kod pocztowy, miejscowość nadawcy
44-100 GLIWICE

Czyli mBank ma dane podzielone tak, jak mi trzeba i tylko generator CSV
jest skopany. Więc cała nasza długaśna dyskusja o eliksirze ma aspekt
edukacyjny dla młodych pokoleń i nic więcej, bo mBank dane wszelakie do
właściwego wygenerowania CSV posiada.

--
Przemysław Adam Śmiejek

Przemysław Adam Śmiejek wrote:

Czyli mBank ma dane podzielone tak, jak mi trzeba i tylko generator CSV
jest skopany.

ogolnie mBank jest skopany.
wyswietl sobie historie rachunku za jakis okres,  a potem zrob zrzut tego samego do pdfa i popatrz  na saldo poczatkowe, koncowe i saldo po kazdej operacji.
ogolnie, sieczka

Dnia Wed, 23 Jun 2010 15:17:42 +0200, Przemysław Adam Śmiejek napisał(a):

========
  uprzejmie informujďż˝, ďż˝e drogďż˝ mailowďż˝ mogďż˝ udzielaďż˝ jedynie ogďż˝lnych
informacji dotycz�cych produkt�w oferowanych przez mBank. W celu
z�o�enia dyspozycji na wyja�nienie prosz� o kontakt z mLini�
telefonicznie pod numerem 801300800 lub 426300800.
========

 Tradycyjna mBankowa technika odpowiedzi:
 Nie rozumiem maila -> wstaw szablon "Kontakt z mLinią"

Więc dałeś im niejako pretekst żeby cię spuścili na drzewo. Jakbyś
normalnie się pytał - to jest (niewielka) szansa że byś się dopytał.

Dobrze, jeszcze raz im napiszę.

 mBank przestaje wklejać formułki po trzecim liście w danej sprawie.
Przetestowane wielokrotnie.

--
Borys Pogoreło
borys(#)leszno,edu,pl

"mvoicem" news:4c2207c2$0$2598$65785112news.neostrada.pl

A swoją drogą - to jednak w pewnym sensie sam sobie jesteś winien.
Zamiast od adama i ewy wytłumaczyć co i jak, dałeś linka na grupę...
Więc dałeś im niejako pretekst żeby cię spuścili na drzewo. Jakbyś
normalnie się pytał - to jest (niewielka) szansa że byś się dopytał.

Po części masz rację, ale spuszczający na drzewo styl odpowiedzi na
elektroniczną korespondencję w mBanku nie jest niczym nowym.
Nie wiem kogo ani tam zatrudniają, ale jeżeli osoba odbierający mój mail
odpowiada mi "z dupy strony" i kompletnie nie na temat to sam juĹź nie wiem
czy mam się śmiać czy płakać.
W sumie na przestrzeni ostatniego roku wysłałem do nich bez mała 10 maili, w
których pokazywałem co działa nie tak jak należy w systemie bądź też
zadawałem pytanie związane z pewnymi procedurami w mBanku. Za każdym razem
dostawałem od nich papkę zdań bez ładu i składu i o zgroze ze złym
kodowaniem (krzaczki) co IMHO jest rzeczą mega śmieszną szczególnie w banku,
który podnieca się tym, że jest internetowy.
Doszedłem w końcu do wniosku, że nie warto się kopać z koniem i dałem sobie
na luz. Niech nadal żyją w złudnym przeświadczeniu, że wszystko działa u
nich cacy.

Dnia Wed, 23 Jun 2010 15:29:56 +0200, Valdi napisał(a):

Doszedłem w końcu do wniosku, że nie warto się kopać z koniem i dałem sobie
na luz. Niech nadal żyją w złudnym przeświadczeniu, że wszystko działa u
nich cacy.

 I właśnie o to im chodziło, byś się odwalił. :)

 Trzeba pisać do skutku, w końcu ktoś zaczyna odpisywać na temat.

--
Borys Pogoreło
borys(#)leszno,edu,pl

"Borys Pogoreło" news:kgiuj4xxy9gk$.1v2ftt1durc9p$.dlg40tude.net

 Trzeba pisać do skutku, w końcu ktoś zaczyna odpisywać na temat.

powstaje jednak jeszcze kwestia jakości tego odpisywania.
Bo jeżeli jakiś mądrala za odpowiedź uznaje wklejenie w ramach odpowiedzi na
moje pytanie gotowej formułki to dziękuję, postoję i najlepiej przeniosę się
tam gdzie przynajmniej nie mają problemów z czytaniem ze zrozumieniem i
sensownym odpowiadaniem na elektroniczną korespondencję.

Ogólnie mBank od kilku dobrych lat pikuje w dół pod względem oferty jak i
samego podejścia do klienta i nic nie wskazuje, że by coś miało się na tym
gruncie zmieniać. Szkoda, bo to fajny bank kiedyś był, no właśnie był.

Dnia Wed, 23 Jun 2010 15:54:39 +0200, Valdi napisał(a):

powstaje jednak jeszcze kwestia jakości tego odpisywania.
Bo jeżeli jakiś mądrala za odpowiedź uznaje wklejenie w ramach odpowiedzi na
moje pytanie gotowej formułki to dziękuję, postoję i najlepiej przeniosę się
tam gdzie przynajmniej nie mają problemów z czytaniem ze zrozumieniem i
sensownym odpowiadaniem na elektroniczną korespondencję.

 Formułki właśnie lecą na początku. Później temat jest w końcu przekazywany
tam gdzie należy.

 Ja regularnie im truję o niedziałające maile z wyciągami, bo co jakiś czas
im się wysypuje mechanizm cyfrowego podpisywania tych przesyłek. Po dwóch
odpowiedziach "aleossochodzi?" (mistrzostwem była odpowiedź w stylu "W
sprawach związanych z kodowaniem MIME prosimy o kontakt z mLinią") trafiają
one w końcu do kogo trzeba i na jakiś czas jest spokój.

--
Borys Pogoreło
borys(#)leszno,edu,pl

Valdi wrote:

powstaje jednak jeszcze kwestia jakości tego odpisywania.
Bo jeżeli jakiś mądrala za odpowiedź uznaje wklejenie w ramach odpowiedzi na
moje pytanie gotowej formułki to dziękuję, postoję i najlepiej przeniosę się
tam gdzie przynajmniej nie mają problemów z czytaniem ze zrozumieniem i
sensownym odpowiadaniem na elektroniczną korespondencję.

Widocznie zdecydowania wiekszosc korespondencji jaka do nich trafia
wymaga wlasnie wklejenia formulki, skad pracownik wyspecjalizowany
w obsludze takiej poczty ma od razu zauwazyc ze nalezysz do sladowej
czesci klientow piszacych w konkretnej sprawie?

Ogólnie mBank od kilku dobrych lat pikuje w dół pod względem oferty jak i
samego podejścia do klienta i nic nie wskazuje, że by coś miało się na tym
gruncie zmieniać. Szkoda, bo to fajny bank kiedyś był, no właśnie był.

To poprostu efekt skali :) Kiedys to byl maly bank.

Dnia Wed, 23 Jun 2010 15:54:39 +0200, Valdi napisał(a):

Ogólnie mBank od kilku dobrych lat pikuje w dół pod względem oferty

Ja tylko szybko w kwestii formalnej: Można pikować do góry? ;)



--
xbartx