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