- historia przelewów wysyłanych do konkretnego odbiorcy z listy zdefiniowanych odbiorców lub płatności.
- Ustanowienie doładowania telefonu komórkowego jako płatność.
- Przesyłanie wyciągów przez bank na maila pierwszego każdego miesiąca

- NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESIĄCA!!!!

Kurde, gdy ktoś nie zrobi przelewu pierwszego dnia bo była przerwa, to zrobi drugiego. A jak nie zrobi ostatniego dnia miesiąca, to po ptokach - faktura nie wejdzie w koszty w tym miesiącu.

$tipa

- NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

On 2010-04-01 14:26, Jan Kowalski wrote:

- NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale można je zacząć o północy...

witrak()

--

witrak()

On 1 Kwi, 17:46, "witrak()" <wit...@hotmail.com> wrote:

On 2010-04-01 14:26, Jan Kowalski wrote:>> - NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

>> Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
>> zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
>> - faktura nie wejdzie w koszty w tym miesi cu.

> przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale mo na je zacz o p nocy...

Nie, nie mozna jesli chcesz nastepnego dnia rano normalnie miec dostep
do systemu.
Albo rybki albo akwarium.

On 2010-04-01 21:35, Jan Kowalski wrote:

On 1 Kwi, 17:46, "witrak()" <wit...@hotmail.com> wrote:

On 2010-04-01 14:26, Jan Kowalski wrote:>> - NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale mo na je zacz o p nocy...

Nie, nie mozna jesli chcesz nastepnego dnia rano normalnie miec dostep
do systemu.
Albo rybki albo akwarium.

Jakieś techniczne uzasadnienie ?

witrak()

W dniu 02.04.10 17:46, witrak() pisze:

On 2010-04-01 21:35, Jan Kowalski wrote:

On 1 Kwi, 17:46, "witrak()" <wit...@hotmail.com> wrote:

On 2010-04-01 14:26, Jan Kowalski wrote:>> - NIE ROBIENIE PRZERW
KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po
ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale mo na je zacz o p nocy...

Nie, nie mozna jesli chcesz nastepnego dnia rano normalnie miec dostep
do systemu.
Albo rybki albo akwarium.

Jakieś techniczne uzasadnienie ?

Od północy do 6.oo jest 6 godzin. Od 21.oo do 6.oo - 9.
I to jest uzasadnienie.

--
Pete

On 2010-04-01 21:35, Jan Kowalski wrote:

On 1 Kwi, 17:46, "witrak()" <wit...@hotmail.com> wrote:

On 2010-04-01 14:26, Jan Kowalski wrote:>> - NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale mo na je zacz o p nocy...

Nie, nie mozna jesli chcesz nastepnego dnia rano normalnie miec dostep
do systemu.
Albo rybki albo akwarium.

Więc jak z tymi rybkami ? Czym różni się standardowe przetwarzanie dla normalnych kont na koniec dnia od przetwarzania na koniec miesiąca, oprócz naliczania oprocentowania ? Nie widzę żadnego powodu do specjalnego rozróżniania - wszak wszystkie statystyki i inne operacje związane z działaniem banku, ale nie związane z saldami kont klienckich mogą być robione później.

Oczywiście trzeba zakładać, że system działa na odpowiednio wydolnym sprzęcie :-) ale w przypadku tego banku akurat to nie ulega wątpliwości...

witrak()

witrak() pisze:

On 2010-04-01 21:35, Jan Kowalski wrote:

On 1 Kwi, 17:46, "witrak()" <wit...@hotmail.com> wrote:

On 2010-04-01 14:26, Jan Kowalski wrote:>> - NIE ROBIENIE PRZERW KONSERWACYJNYCH W NOCY OSTATNIEGO DNIA MIESI CA!!!!

Kurde, gdy kto nie zrobi przelewu pierwszego dnia bo by a przerwa, to
zrobi drugiego. A jak nie zrobi ostatniego dnia miesi ca, to po ptokach
- faktura nie wejdzie w koszty w tym miesi cu.

przetwarzanie konca miesiaca - raczej nie do przeskoczenia.

Ale mo na je zacz o p nocy...

Nie, nie mozna jesli chcesz nastepnego dnia rano normalnie miec dostep
do systemu.
Albo rybki albo akwarium.

Więc jak z tymi rybkami ? Czym różni się standardowe przetwarzanie dla normalnych kont na koniec dnia od przetwarzania na koniec miesiąca, oprócz naliczania oprocentowania ? Nie widzę żadnego powodu do specjalnego rozróżniania - wszak wszystkie statystyki i inne operacje związane z działaniem banku, ale nie związane z saldami kont klienckich mogą być robione później.

Oczywiście trzeba zakładać, że system działa na odpowiednio wydolnym sprzęcie :-) ale w przypadku tego banku akurat to nie ulega wątpliwości...

witrak()

A w PKO BP przypadkiem na kontach nie jest kapitalizacja miesięczna?
W każdym razie tak wynika z opisu np. dla superkonta "Należne odsetki dopisywane są do salda na koniec każdego miesiąca (kapitalizacja miesięczna odsetek)".

Czyli za uzasadnienie techniczne można przyjąć naliczanie i dopisywanie odsetek.

Poza tym są pewnie przeprowadzane przez system operacje czysto księgowe, jak utworzenie bilansu na nowy miesiąc i etc.

Czyli za uzasadnienie techniczne można przyjąć naliczanie i dopisywanie
odsetek.

Poza tym są pewnie przeprowadzane przez system operacje czysto księgowe,
jak utworzenie bilansu na nowy miesiąc i etc.

Ano wlasnie. Plus kwestia czasowa wspomniana wczesniej.

A co do sprzetu - tia, na brak mocy nie narzekamy.

V.

On 2010-04-06 16:04, Jan Kowalski wrote:

Czyli za uzasadnienie techniczne można przyjąć naliczanie i dopisywanie
odsetek.

To jest raczej kiepskie uzasadnienie. I nie zamierzam tego specjalnie uzasadniać - od "usprawiedliwiaczy" banków i tak nie uzyskam potwierdzenia a innym nie potrzeba argumentów :-)

Poza tym są pewnie przeprowadzane przez system operacje czysto księgowe,
jak utworzenie bilansu na nowy miesiąc i etc.

A to można liczyć i następnego dnia i jeszcze później.

Ano wlasnie. Plus kwestia czasowa wspomniana wczesniej.

A co do sprzetu - tia, na brak mocy nie narzekamy.

No właśnie :-)

witrak

witrak() pisze:

On 2010-04-06 16:04, Jan Kowalski wrote:

Czyli za uzasadnienie techniczne można przyjąć naliczanie i dopisywanie
odsetek.

To jest raczej kiepskie uzasadnienie. I nie zamierzam tego specjalnie uzasadniać - od "usprawiedliwiaczy" banków i tak nie uzyskam potwierdzenia a innym nie potrzeba argumentów :-)

A ja bardzo chętnie poznam dlaczego to nie jest uzasadnienie techniczne uwzględniając wydajność db i macierzy dyskowych.
Kiedyś na stronie Asseco było, który bank jaki system ma dany bank.
Z tego co pamiętam najnowsze wywodzą się z lat 90 i początku rocznika 2000. Oczywiście pewne modyfikacje na bank zaszły. Na podstawie tego jaki system ma dany bank można było zauważyć pewne zależności.
Na przykład
System bankowy: Profile
Banki: Alior Bank i Lukas
Co: Brak księgowanej 3 sesji eliksirowej.

Szperając po internecie, można znaleźć również jakie serwery mają banki.
Swego czasu GetinBank chwalił się, że ich system działa na serwerach HP.
Tutaj przykładowy link:
http://www.integrity.com.pl/upload_module/u_doc/getinbank%20yellow1.pdf
http://www.integrity.com.pl/upload_module/u_doc/getin_pop.pdf

Mam nadzieje, że odpowiedz poprzesz faktami.


Poza tym mam propozycje, aby zrobić listę porównawczą jaki System bankowy, w którym banku i jego plusy i minusy.
Co ułatwi stwierdzenie, że nie dany bank tylko dana platforma działa tak a siak.

Poza tym są pewnie przeprowadzane przez system operacje czysto księgowe,
jak utworzenie bilansu na nowy miesiąc i etc.

A to można liczyć i następnego dnia i jeszcze później.

Ano wlasnie. Plus kwestia czasowa wspomniana wczesniej.

A co do sprzetu - tia, na brak mocy nie narzekamy.

No właśnie :-)

witrak

On 2010-04-07 13:57, Gosc wrote:

witrak() pisze:

On 2010-04-06 16:04, Jan Kowalski wrote:

Czyli za uzasadnienie techniczne można przyjąć naliczanie i dopisywanie
odsetek.

To jest raczej kiepskie uzasadnienie. I nie zamierzam tego specjalnie uzasadniać - od "usprawiedliwiaczy" banków i tak nie uzyskam potwierdzenia a innym nie potrzeba argumentów :-)

A ja bardzo chętnie poznam dlaczego to nie jest uzasadnienie techniczne uwzględniając wydajność db i macierzy dyskowych.

Już miałem nie odpowiadać - powody jak wyżej - ale mi się przypomniało, jak prowadziłem kiedyś spór nt. tego, który bank jaki system ma. Więc niech będzie - ostatni raz ;-)

Kiedyś na stronie Asseco było, który bank jaki system ma dany bank.
Z tego co pamiętam najnowsze wywodzą się z lat 90 i początku rocznika 2000. Oczywiście pewne modyfikacje na bank zaszły. Na podstawie tego jaki system ma dany bank można było zauważyć pewne zależności.
Na przykład
System bankowy: Profile
Banki: Alior Bank i Lukas
Co: Brak księgowanej 3 sesji eliksirowej.

Lukas: przychodzące: 12:00-13:00  16:00-17:00  18:00-19:00
Może zresztą coś się zmieniło - pożegnałem się z nimi prawie rok temu...
Może myślałeś o BPH, który faktycznie nie ma trzeciej przychodzącej? Tyle, że jest to (a na pewno była) największa instalacja profile'a na świecie :-)

Szperając po internecie, można znaleźć również jakie serwery mają banki.
Swego czasu GetinBank chwalił się, że ich system działa na serwerach HP.
Tutaj przykładowy link:
http://www.integrity.com.pl/upload_module/u_doc/getinbank%20yellow1.pdf
http://www.integrity.com.pl/upload_module/u_doc/getin_pop.pdf

Mam nadzieje, że odpowiedz poprzesz faktami.

Takich "faktów", jakie raczyłeś wskazać, poszukiwać nie zamierzam bo do marketolenia mam wstręt :-) [kiedyś M$ chwalił się udanym i szybkim wdrożeniem systemu mBanku na ich sofcie, i to w istocie akurat było wyjątkowo blisko prawdy, ale po co się tym zaczytywać?]


Ale do rzeczy. Otóż problem platformy jest w jakimś stopniu problemem technicznym, ale *znacznie* bardziej organizacyjnym. Sprzęt można wymieniać w miarę narastania potrzeb, pod warunkiem oczywiście, że jest na co :-)
Natomiast wybór platformy jest skutkiem podjęcia decyzji co do sposobu zapewnienia sobie *skalowalności* systemu (w bankach - na wiele, wiele lat).
Że potrzeby każdego banku zawsze rosną to rzecz oczywista i dlatego jeżeli kierownictwo banku wybiera platformę, której możliwości silnie ograniczają skalowanie systemu w górę, to jest to błąd z uwarunkowaniami technicznymi mający tyle wspólnego, co każda inna błędna decyzja *biznesowa*.
Niestety akurat takie decyzje mają bardzo poważne skutki eksploatacyjne i choć na początku bywa, że wydają się zupełnie trafne - z punktu widzenia bezpośrednich rezultatów - ich wady ujawniają się stopniowo, w miarę jak uzależnienie od przyjętych rozwiązań stopniowo wprowadza organizację w pułapkę.

W takiej pułapce technologiczno-organizacyjnej tkwi PKO BP (o ile wiem ZORBA jest nowo wdrożonym, wiekowym systemem). Objaw, który daje się obserwować, jest zapewne wynikiem budowania systemu on-line'owego dla bardzo dużej liczby klientów na bazie niewydolnego oprogramowania back-endowego. To nie jest sprawa techniki. To jest błąd w decyzji organizacyjnej. W każdym banku niewydolny system back-endowy *zawsze* prędzej czy później doprowadzi do spiętrzenia przetwarzania ponad wytrzymałość klientów w dniach zejścia się wielu końców okresów (że przypomnę wielką wpadkę - dwa dni postoju - pewnego znanego i skądinąd nowoczesnego banku na przełomie czerwca i lipca przed laty...). I nie ma to nic (prawie...) wspólnego z techniką jako taką, a jest skutkiem błędów organizacyjnych (czasem z przyczyn bliskich głupocie).

Poza tym mam propozycje, aby zrobić listę porównawczą jaki System bankowy, w którym banku i jego plusy i minusy.
Co ułatwi stwierdzenie, że nie dany bank tylko dana platforma działa tak a siak.

Ale i tak nie da to odpowiedzi na pytanie, które nas (mnie przynajmniej interesuje): jakie czynniki w konkretnym banku decydują o tym, że system nie działa jak trzeba ?
Czasem (rzadko) można to odgadnąć. Np. ostatnio system EB zaczął systematycznie robić bokami (pierwsze sygnały były, gdy po wprowadzeniu kapitalizacji dziennej i dużej liczby kont oszczędnościowych zaczęły się problemy z dostępem). I co zrobili ?
Przerabiają system.
Niedawno ograniczyli możliwość składania zleceń na dzień następny - aktualnie system przestaje je przyjmować "po uważaniu", nawet już około 21:30, choć w dokumentacji piszą, że może to się zdarzyć po 22. Właśnie *to* jest problem techniczny - mają za słabe serwery, więc poprawiają naprędce system, aby nie był zależny od nadmiaru wydajności obliczeniowej. Idzie im to kiepsko, co widać np. w opóźnieniach w aktualizacji stanu kont. Tylko, że tutaj efekt jest potencjalnie do zniwelowania, bo kont z kapitalizacją miesięczną jest znacznie mniej niż z dzienną, a *system jednak się wyrabia* w codziennym przetwarzaniu (przypuszczalnie bo jest *nowy*, więc zapewne łatwo skalowalny). Poprawią go jeszcze trochę, odżałują wreszcie trochę kasy na serwery i będzie dobrze.

Pozdr.

witrak()

W takiej pu apce technologiczno-organizacyjnej tkwi PKO BP (o ile
wiem ZORBA jest nowo wdro onym, wiekowym systemem). Objaw, kt ry
daje si obserwowa , jest zapewne wynikiem budowania systemu
on-line'owego dla bardzo du ej liczby klient w na bazie niewydolnego
oprogramowania back-endowego. To nie jest sprawa techniki. To jest
b d w decyzji organizacyjnej. W ka dym banku niewydolny system
back-endowy *zawsze* pr dzej czy p niej doprowadzi do spi trzenia
przetwarzania ponad wytrzyma o klient w w dniach zej cia si wielu

Jak na bywalca grupy bankowej twoja wiedza na temat - bylo nie bylo -
najwiekszego bankowego wdrozenia ostatnich lat - jest zenujaco niska.

Zorba to system z ktorego zostal maly ogryzek, zastapiony w calosci
przez Alnove. Jesli ci sie wydaje ze onlinowe iPKO to li tylko
naklada
na stary system centralny - jestes w grubym bledzie. Za bledne decyzje
dotyczace wdrozen (daleko mniej waznych niz architektura systemu)
placi sie glowa.
Sprzet i oprogramowanie ktore za tym stoja kosztuja ciezkie pieniadze
- nie masz pojecia jak bardzo ciezkie . Jesli ci sie wydaje ze ktos
podjalby
decyzje powodujace niewydolnosc systemu z przyczynami poza
infrastruktura
-mylisz sie kolejny raz.

Skoro tak dobrze znasz problematyke - zaloz jakis bank, z dostepem 24
h przez 365
dni w roku. Klienci beda walic drzwiam i oknami.

On 2010-04-07 22:02, Jan Kowalski wrote:

W takiej pu apce technologiczno-organizacyjnej tkwi PKO BP (o ile
wiem ZORBA jest nowo wdro onym, wiekowym systemem). Objaw, kt ry
daje si obserwowa , jest zapewne wynikiem budowania systemu
on-line'owego dla bardzo du ej liczby klient w na bazie niewydolnego
oprogramowania back-endowego. To nie jest sprawa techniki. To jest
b d w decyzji organizacyjnej. W ka dym banku niewydolny system
back-endowy *zawsze* pr dzej czy p niej doprowadzi do spi trzenia
przetwarzania ponad wytrzyma o klient w w dniach zej cia si wielu

Jak na bywalca grupy bankowej twoja wiedza na temat - bylo nie bylo -
najwiekszego bankowego wdrozenia ostatnich lat - jest zenujaco niska.

Zorba to system z ktorego zostal maly ogryzek, zastapiony w calosci
przez Alnove. Jesli ci sie wydaje ze onlinowe iPKO to li tylko
naklada
na stary system centralny - jestes w grubym bledzie. Za bledne decyzje
dotyczace wdrozen (daleko mniej waznych niz architektura systemu)
placi sie glowa.
Sprzet i oprogramowanie ktore za tym stoja kosztuja ciezkie pieniadze
- nie masz pojecia jak bardzo ciezkie . Jesli ci sie wydaje ze ktos
podjalby
decyzje powodujace niewydolnosc systemu z przyczynami poza
infrastruktura
-mylisz sie kolejny raz.

Nie wiem, z kim polemizujesz, bo nie ze mną. Co do przyczyn, dla których tyle lat trwało doprowadzenie systemów PKO do stanu zintegrowania, nie mnie się wypowiadać, ale ocena skutków jest jednoznaczna - ludzie, którzy kiedyś (dawno temu) podejmowali decyzje mające poważne konsekwencje techniczne nie mieli pojęcia czym się bawią.  Gdyby system miał właściwą architekturę (software'ową - sprzętowa musi być zadowalająca, bo inaczej system wytrzyma do pierwszej awarii) to problemy, o których rozmawialiśmy można byłoby zlikwidować w parę miesięcy.
Pozostałe Twoje uwagi sprowadzają się do niczym nie popartych supozycji.

Skoro tak dobrze znasz problematyke - zaloz jakis bank, z dostepem 24
h przez 365
dni w roku. Klienci beda walic drzwiam i oknami.

Napisanie - nawet gdyby tylko dla żartu - czegoś co tylko sugerowałoby, że aby założyc bank wystarczy mieć system informatyczny, może być, powiedzmy, "mocno kompromitujące".

witrak()
PS. Naprawdę, chyba nie warto Ci było niezbyt trafnej uwagi, rzuconej mimochodem, bronić jak Jasnej Góry ;-)