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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

Przemysław Adam Śmiejek <n...@s...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

do góry

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

do góry

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

do góry

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

do góry