eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankimBank żondzi
Ilość wypowiedzi w tym wątku: 73

  • 51. Data: 2010-06-28 11:17:27
    Temat: Re: mBank żondzi
    Od: Krzysztof Halasa <k...@p...waw.pl>

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


  • 52. Data: 2010-06-28 11:58:54
    Temat: Re: mBank żondzi
    Od: "MacGregor" <m...@s...poczta.onet.pl>

    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



  • 53. Data: 2010-06-28 12:30:40
    Temat: Re: mBank żondzi
    Od: Robert Kois <k...@h...pl>

    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


  • 54. Data: 2010-06-28 12:39:02
    Temat: Re: mBank żondzi
    Od: Przemysław Adam Śmiejek <n...@s...pl>

    W dniu 2010-06-28 13:17, Krzysztof Halasa pisze:
    > Przemysław Adam Śmiejek <n...@s...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.



    --
    Przemysław Adam Śmiejek



    W dniu 2010-06-28 13:58, MacGregor pisze:
    > Ciach....
    >
    >
    > 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...
    >
    > 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.
    >
    >
    >


    --
    Przemysław Adam Śmiejek


  • 55. Data: 2010-06-28 12:44:35
    Temat: Re: mBank ?ondzi
    Od: Przemysław Adam Śmiejek <n...@s...pl>

    W dniu 2010-06-28 13:17, Krzysztof Halasa pisze:
    > > Przemysław Adam Śmiejek <n...@s...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


  • 56. Data: 2010-06-28 13:14:57
    Temat: Re: mBank żondzi
    Od: Przemysław Adam Śmiejek <n...@s...pl>

    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


  • 57. Data: 2010-06-28 13:57:37
    Temat: Re: mBank żondzi
    Od: Robert Kois <k...@h...pl>

    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


  • 58. Data: 2010-06-28 14:30:09
    Temat: Re: mBank żondzi
    Od: Przemysław Adam Śmiejek <n...@s...pl>

    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


  • 59. Data: 2010-06-28 14:51:42
    Temat: Re: mBank ?ondzi
    Od: Krzysztof Halasa <k...@p...waw.pl>

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


  • 60. Data: 2010-06-28 15:58:32
    Temat: Re: mBank ?ondzi
    Od: Przemysław Adam Śmiejek <n...@s...pl>

    W dniu 2010-06-28 16:51, Krzysztof Halasa pisze:
    > Przemysław Adam Śmiejek <n...@s...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

strony : 1 ... 5 . [ 6 ] . 7 . 8


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1