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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry