Dnia Sat, 26 Jun 2010 11:11:57 +0200, Przemysław Adam Śmiejek napisał(a):

>> Jeszcze raz ci napiszę, celem eliksiru jest wymiana komunikatów
>> rozliczeniowych. I to zadanie wypełnia
> Ale jakość przekazywanych komunikatów jest niska.

Wystarczająca do tego by rozliczyć płatnosci.

>> Ależ kto ci broni wprowadzić sobie dane klientów do bazy i identyfikować
>> ich po numerze rachunku
> Czyli muszę zaprogramować bazę i import do niej danych. A to jest mało
> dostępne dla większości.

No patrz, masz beznadziejnie zorganizowane rozliczenia. Powinieneś coś z
tym zrobić. no ale w tym momencie wygenerowałoby ci to koszty (albo
oprogramowania, albo czasu poświęconego na wklepywanie).

>> i powiedzmy nazwie (ja nadal uważam, że dane
>> adresowe są w tym przypadku zbędne i nadmiarowe).
> No nie są priorytetowe, owszem. Ale nie zaszkodzi jak są.

Nie zaszkodziłoby jakby był regon, nip, pesel i parę innych rzeczy. Tylko
po co?

>>> Po drugie: powiązanie 1:1 konta z kontrahentem to duże uproszczenie. To
>>> relacja często 1:n, a czasami wręcz n:n.
>> Zaczynasz powoli rozumieć, że prosto nie jest.
> Ja? Ja od początku mówiłem, że nie jest prosto i gdyby całość była
> zaprojektowana zgodnie z teorią baz danych, to by było prosto.

Teorie są zawsze śliczne, i jeszcze raz, elixir to nie baza danych, służy
do rozliczeń między bankami. Po to powstał. Prawdopodobnie miał być jak
najprostszy by łatwo było się do niego dostosować.

>>>> Nie. Ale nie widzę powodu by bank (odbiorca przelewu) przechowywał dane
>>>> nadawcy w takiej samej formie jak dane swoich klientów.
>>> A ja widzę. Choćby po to, żeby dać potrzebne narzędzie klientom.
>> Dla mnie potrzebnym narzędziem byłby natychmiastowy "eliksir" do wszystkich
>> banków. Jakoś nie ma.
> Ale to jest utopia, w przeciwieństwie do zaprojektowania protokołu
> wymiany tak, żeby dzielił dane sensownie.

Dlaczego, to wcale nie tak bardzo skomplikowane. Za to koszt po stronie
banków byłby spory a zysk (dla banku) niewielki. Pewnie kiedyś zrobią.

>> Tak btw to ciekawe czy bank ma prawo przetwarzać
>> takie dane kogoś kto nie jest jego klientem (ciekawe czy ustawodawca o tym
>> pamiętał).
> Ależ jest klientem. Wysyła do tamtego banku pieniądze. Jak Ty wysyłasz
> do mnie list, to oskarżysz mnie o przetwarzanie danych, choć nie jestem
> twoim klientem?

Błedna analogia. Ja nie wysyłam pieniędzy bankowi, bank jest tylko
pośrednikiem. Jakby poczta skanowała sobie wszystkie adresy z kopert i
trzymała w bazie to by było bliższe temu co mamy przy przelewach

>> Jakich zestawień?
> Opisałem je w wyjściowym liście.

Ale rozdzielenie nazwy nadawcy od adresu nadal ci nie da tego co byś
chciał.

>> Skoro nie masz pewności co w danej nazwie jest i po czym
>> ją sortować. Nie ma standardów.
> No i powinny być. Powinno być:
[ciach]

No to jeszcze teraz grzecznie ustal rozmiary pól i ich wymagalność. I nagle
zobaczysz, że są dane które pasować nie będą. Albo ich w danym momencie nie
będzie. A potem dostosuj wszystkie systemy bankowe do twojej wizji.
to da się zrobić jak zmienisz ustawę i zmusisz banki do tego. Jak myślisz,
kto za to zapłaci?

> Aczkolwiek samo oddzielenie numeru
> konta w osobne pole byłoby krokiem naprzód.

Pretensje do mbanku.

> Nie rozumiesz zagadnienia. Obecny format też można uznać za fajny, bo
> odpowiednio wykwalifikowany pracownik przeklepie to do bazy i już.
>
> Sęk w tym, że jak muszę dokonać zestawienia: MOJE WPŁATY NA PRĄD ZA
> OSTATNIE 5 LAT na przykład, albo MOJE PRZYCHODY OD xyz OD 2003, to
> obecny format mBankowy nie pozwala tego uczynić szybko i wygodnie, tylko
> wymaga żmudnej, wielogodzinnej analizy.

Jakbyś od 5 lat wpisywał sobie wszystkie płatności tak jak chcsz do własnej
bazy danych to nie miałbyś problemu. Nie robiłeś tego a przeciez eksport do
cvsa od początku chyba był taki. A teraz mirmiłujesz.

> Albo chciałbym automatycznie wczytywać to do systemu rozliczeń.

Niestety nikt nie obiecywał ci, że historia transakcji na coś takiego
pozwoli

--
Kojer