Banking 4W v5.2 BETA

 
hanni
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Hamburg
Beiträge: 297
Dabei seit: 06 / 2011
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 31.03.2014 - 18:40 Uhr  ·  #101
@msa
danke, du sprichst mir aus dem Herzen!
infoman
Benutzer
Avatar
Geschlecht:
Beiträge: 7357
Dabei seit: 06 / 2008
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 31.03.2014 - 19:30 Uhr  ·  #102
@msa
es ist die Rede von 100% SEPA und daher sollte man bspw. bei der Einrichtung eines Kontos oä. auch die BIC "mit verarbeiten" - sprich man kann entweder die BIC oder BLZ eingeben. (siehe glaub 1. Seite in diesem T. wo ich es erwähnt hatte)
des weiteren ist bei Bankzugängen nur die BLZ vermerkt und ebenfalls nicht die BIC
zumal einige Anbieter nur noch BIC abfragen, sollte man sich auch hieran gewöhnen.

das Produkt ist meines Erachtens nicht nur für hardcore-online-banking entwickelt, sondern auch für die "breite Masse", hier sollte man Sicherheitsinformationen nicht unberücksichtigt lassen, zumal phishing usw. immer mehr zunimmt und viele garnicht wissen, dass es eine zentrale Rufnummer zur Sperrung usw. gibt.
ein kleines icon, wird das Produkt nicht unbedingt aufblähen.
In diesem Zusammenhang könntest du mir ja mal mitteilen, wo man bspw. Phishing-Mails oder entsprechende Homepage prüfen/melden kann - für die R-Volksbanken bzw. Sparkassen - so einfach ist das nicht, weil auf den Banken pages steht hierzu wenig bis nichts.
hier mal ein Erfahrungsbericht eines bloggers: http://www.borncity.com/blog/2…en-kunden/

bzgl. den Banken-URLs bin ich deshalb ua. drauf gekommen, da die Banken die Domain mit Sicherheit nicht ändern werden
anderweitige URLs und Pflege könnte man evtl. über Schwarmintelligenz (auf Hersteller-Homepage) umsetzen
dies würde zwei Punkte abdecken: falsche URLs/Banken-Pages durch Buchstabendreher vermeiden + bei Auslandsüberweisungen kann man evtl. schneller Adressen ermitteln.
(zumal die Produkt-Basis ja immer parallel auf Desktop und App "entwickelt" wird und bestimmt nicht viele die URLs bei letzterem als Lesezeichen im mobile-Browser haben)

und um abschließend auf deinen Punkt "Kern Online-Banking-Prog." einzugehen, dann hat Auswertung/Kategorie nichts darin zu suchen bzw. wäre grenzwertig, da dies schon im Finanzmanagement Bereich/Buchhaltung oä. zu sehen ist.

wobei der Cheffe ja entscheidet was reinkommt und weder du noch ich, war ja nur ein Vorschlag. (verbunden mit einem "Datenpaket an URLs")
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 31.03.2014 - 20:21 Uhr  ·  #103
Hallo Andreas, wieso wurde im Ausgangskorb das "Gesendete Aufträge löschen" entfernt? So muß man jetzt immer aufpassen, dass man nicht doch noch etwas ungesendetes löscht, nicht schlimm, aber eindeutig ein Rückschritt!
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 31.03.2014 - 20:39 Uhr  ·  #104
Zitat geschrieben von infoman
es ist die Rede von 100% SEPA und daher sollte man bspw. bei der Einrichtung eines Kontos oä. auch die BIC "mit verarbeiten" - sprich man kann entweder die BIC oder BLZ eingeben. (siehe glaub 1. Seite in diesem T. wo ich es erwähnt hatte) des weiteren ist bei Bankzugängen nur die BLZ vermerkt und ebenfalls nicht die BIC
zumal einige Anbieter nur noch BIC abfragen, sollte man sich auch hieran gewöhnen.

Wie Andreas an anderer Stelle schon mal ausgeführt hat, ist bei HBCI/FinTS ausschließlich die BLZ für die Einrichtung und die Übertragung maßgeblich, für BICs gibts bei HBCI noch nicht mal Felder! BICs werden bei HBCI nur innerhalb der XML-Datei übertragen und diese wird als Binary eingestellt. Insofern muß bei der Einrichtung die BLZ abgefragt werden und nicht die BIC. Zumal eine Umsetztabelle auch nichts bringen würde, da div. Banken eine ganz bestimmte BLZ für HBCI brauchen, die nichts mit der BLZ des Kontos zu tun hat und somit aus der BIC des Kontos auch nicht abgeleitet werden kann! Hier mit BICs zu arbeiten wäre also eine unendliche Quelle von Fehlern, solange nicht HBCI komplett neu erfunden wurde (wovon ich ausgehe, dass es niemals passieren wird...).

Zitat geschrieben von infoman
das Produkt ist meines Erachtens nicht nur für hardcore-online-banking entwickelt, sondern auch für die "breite Masse", hier sollte man Sicherheitsinformationen nicht unberücksichtigt lassen, zumal phishing usw. immer mehr zunimmt und viele garnicht wissen, dass es eine zentrale Rufnummer zur Sperrung usw. gibt.
ein kleines icon, wird das Produkt nicht unbedingt aufblähen.

Ich find schon, dass das aufbläht. Schuster bleib bei Deinen Leisten. Es ist ein ONLINEBANKING-Programm und kein rundumseligmachendes Allgemeintool für alles was mit Geld zu tun hat. Sorry, ist halt meine Meinung. Wenn Andreas anderer Meinung ist, dann wird er die Zusätze vielleicht einbauen. Ich hoffe nicht, weil er dann so aufgeblähten Dingern wie Starmoney ähnlicher wird - und damit uninteressant.

Zitat geschrieben von infoman
In diesem Zusammenhang könntest du mir ja mal mitteilen, wo man bspw. Phishing-Mails oder entsprechende Homepage prüfen/melden kann - für die R-Volksbanken bzw. Sparkassen - so einfach ist das nicht, weil auf den Banken pages steht hierzu wenig bis nichts.
hier mal ein Erfahrungsbericht eines bloggers: http://www.borncity.com/blog/2…en-kunden/

Hm. Melden - und was bringt das? Das ist doch alles ganz einfach: JEDE Mail von meiner *Bank, die irgendwas von mir WILL ist von vorneherein Phishing, denn keine vernünftige Bank wird sowas tun. Und wenn ich mir nicht sicher bin, dann kann ich meinen Berater anrufen und fragen, wie er dazu kommt, von mir per Mail irgendwelche Daten zu wollen - es sei denn ich bin gerade mitten in einer Transaktion mit ihm. Aber dann werde ich anhand der Mailinhalte sofort sehen, dass es darum geht und nicht um "Einen Uberprufung von die Sicherheit von Ihre Sparkassen-Account-Konto". Nur ein geringstes Maß an Hirn einschalten hilft da ungemein weiter :-)

Zitat geschrieben von infoman
bzgl. den Banken-URLs bin ich deshalb ua. drauf gekommen, da die Banken die Domain mit Sicherheit nicht ändern werden anderweitige URLs und Pflege könnte man evtl. über Schwarmintelligenz (auf Hersteller-Homepage) umsetzen
dies würde zwei Punkte abdecken: falsche URLs/Banken-Pages durch Buchstabendreher vermeiden + bei Auslandsüberweisungen kann man evtl. schneller Adressen ermitteln.
(zumal die Produkt-Basis ja immer parallel auf Desktop und App "entwickelt" wird und bestimmt nicht viele die URLs bei letzterem als Lesezeichen im mobile-Browser haben)

Und ob Banken ihre URLs ändern! Gerade heutzutage, wo ständig irgendwer mit irgendwem fusioniert bzw. geschluckt wird! Die DiBa hatte vom Start des Internetauftrittes bis heute ich glaube 4 oder gar 5 Domains, die HypoVereinsbank ich glaube 4 - mit Unicreditoübernahme usw. Die Sache mit der Schwarmintelligenz hört sich gut an, ist aber wohl bei einem kommerziellen Produkt nicht verwendbar - der Produkthersteller haftet für sein Produkt, und dass aus dem Schwarm von bösen Schwärmern mal Übles ins Produkt gelangt, das ist einfach zu gefährlich. Wir hatten so eine Diskussion schon mal im Zusammenhang mit externen Screen-Scraping-Modulen, von irgendwelchen Nutzern entwickelt und in B4* eingebunden...

Zitat geschrieben von infoman
und um abschließend auf deinen Punkt "Kern Online-Banking-Prog." einzugehen, dann hat Auswertung/Kategorie nichts darin zu suchen bzw. wäre grenzwertig, da dies schon im Finanzmanagement Bereich/Buchhaltung oä. zu sehen ist.


Richtig!! Genau deswegen ist die ganze Kategorisierung/Auswertung mir auch irgendwo ein Dorn im Auge. Aber es gibt wohl genügend Leute, für die sowas wichtig zu sein scheint. Wenn ich solche Auswertungen brauche, mache ich die in Excel, da kann ich wenigstens so auswerten, wie ich es will, und nicht so, wie es gerade mal geht. Aber nachdem nicht jeder gut in Excel zurecht kommt, mag es nötig sein, sowas einzubauen bzw. eingebaut zu haben.

Zitat geschrieben von infoman
wobei der Cheffe ja entscheidet was reinkommt und weder du noch ich, war ja nur ein Vorschlag. (verbunden mit einem "Datenpaket an URLs")

Genau! Und ich bin auch echt froh, dass ich das nicht entscheiden muß! Dass das von Dir nur Vorschläge waren ist mir schon klar gewesen. Das was ich dazu geschrieben habe war auch nur meine Meinung dazu, keinesfalls eine Verdammnis der Vorschläge oder so :-)
subsembly
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: München
Homepage: subsembly.com/
Beiträge: 4582
Dabei seit: 11 / 2004
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 10:24 Uhr  ·  #105
Zitat geschrieben von msa

Zitat geschrieben von infoman
es ist die Rede von 100% SEPA und daher sollte man bspw. bei der Einrichtung eines Kontos oä. auch die BIC "mit verarbeiten" - sprich man kann entweder die BIC oder BLZ eingeben. (siehe glaub 1. Seite in diesem T. wo ich es erwähnt hatte) des weiteren ist bei Bankzugängen nur die BLZ vermerkt und ebenfalls nicht die BIC
zumal einige Anbieter nur noch BIC abfragen, sollte man sich auch hieran gewöhnen.

Wie Andreas an anderer Stelle schon mal ausgeführt hat, ist bei HBCI/FinTS ausschließlich die BLZ für die Einrichtung und die Übertragung maßgeblich, für BICs gibts bei HBCI noch nicht mal Felder! BICs werden bei HBCI nur innerhalb der XML-Datei übertragen und diese wird als Binary eingestellt. Insofern muß bei der Einrichtung die BLZ abgefragt werden und nicht die BIC. Zumal eine Umsetztabelle auch nichts bringen würde, da div. Banken eine ganz bestimmte BLZ für HBCI brauchen, die nichts mit der BLZ des Kontos zu tun hat und somit aus der BIC des Kontos auch nicht abgeleitet werden kann! Hier mit BICs zu arbeiten wäre also eine unendliche Quelle von Fehlern, solange nicht HBCI komplett neu erfunden wurde (wovon ich ausgehe, dass es niemals passieren wird...).



Hallo,

es gibt leider keine eindeutige Abbildung von BIC -> BLZ. Die Postbank verwendet z.B. nur eine BIC, hat aber mehrere verschiedene BLZ. Und wie @msa schon richtig erkannt hat, ist für HBCI zwingend die BLZ erforderlich. Spannend ist übrigens auch die Konvertierung von BLZ zu BIC, hier hängt das Ergebnis nämlich vom Kontext ab und ist auch nicht eindeutig.
subsembly
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: München
Homepage: subsembly.com/
Beiträge: 4582
Dabei seit: 11 / 2004
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 10:28 Uhr  ·  #106
Zitat geschrieben von msa

Hallo Andreas, wieso wurde im Ausgangskorb das "Gesendete Aufträge löschen" entfernt? So muß man jetzt immer aufpassen, dass man nicht doch noch etwas ungesendetes löscht, nicht schlimm, aber eindeutig ein Rückschritt!


Hallo,

ja, dieser Punkt ist entfallen und muss nun per Mehrfachselektion nachgebildet werden. Grund dafür war die neue, erweiterte Löschfunktion, welche nun auch zugehörige Zahlungen löschen kann.
onlbanker
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 10:37 Uhr  ·  #107
Zitat geschrieben von subsembly
es gibt leider keine eindeutige Abbildung von BIC -> BLZ. Die Postbank verwendet z.B. nur eine BIC, hat aber mehrere verschiedene BLZ. Und wie @msa schon richtig erkannt hat, ist für HBCI zwingend die BLZ erforderlich. Spannend ist übrigens auch die Konvertierung von BLZ zu BIC, hier hängt das Ergebnis nämlich vom Kontext ab und ist auch nicht eindeutig.

Daher empfehle ich immer gern http://www.iban-rechner.de weil der alle Sonderregeln der BuBa kennt, eine Richtigkeitsgarantie für die Umwandlung in Euro und Cent übernimmt und eine SOAP/REST Schnittstelle für automatisierte Anfragen besitzt.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 10:47 Uhr  ·  #108
Zitat geschrieben von subsembly
ja, dieser Punkt ist entfallen und muss nun per Mehrfachselektion nachgebildet werden. Grund dafür war die neue, erweiterte Löschfunktion, welche nun auch zugehörige Zahlungen löschen kann.

Mmmh, ja OK, dass die Löschfunktion etwas mehr kann habe ich bemerkt. Aber was hat nun das Eine mit dem Anderen zu tun? Die ausgeführten Zahlungen sind nach wie vor an dem grünen Haken problemlos erkennbar, wieso muß ich diese dann jetzt extra mit dem Auge suchen und mit der Maus anzittern und einzeln markieren, wenn das Programm doch eine eindeutiges Selektionskriterium hätte? Warum wird hier eine täglich verwendte und fundamental praktische vorhandene Funktion eliminiert? Ich würd es halt nur gern verstehen...
subsembly
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: München
Homepage: subsembly.com/
Beiträge: 4582
Dabei seit: 11 / 2004
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 12:39 Uhr  ·  #109
Zitat geschrieben von onlbanker

Zitat geschrieben von subsembly
es gibt leider keine eindeutige Abbildung von BIC -> BLZ. Die Postbank verwendet z.B. nur eine BIC, hat aber mehrere verschiedene BLZ. Und wie @msa schon richtig erkannt hat, ist für HBCI zwingend die BLZ erforderlich. Spannend ist übrigens auch die Konvertierung von BLZ zu BIC, hier hängt das Ergebnis nämlich vom Kontext ab und ist auch nicht eindeutig.

Daher empfehle ich immer gern http://www.iban-rechner.de weil der alle Sonderregeln der BuBa kennt, eine Richtigkeitsgarantie für die Umwandlung in Euro und Cent übernimmt und eine SOAP/REST Schnittstelle für automatisierte Anfragen besitzt.


Nur damit kein Mißverständnis entsteht: Die IBAN-Hilfe in Banking 4W (und auch in Banking 4A oder 4i) berücksichtigt natürlich auch alle IBAN Sonderregeln der Bundesbank.
onlbanker
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 13:15 Uhr  ·  #110
Zitat geschrieben von msa
Hmm, was hat der KARTEN-Sperrnotruf in einem HBCI-Onlinebanking-Programm zu suchen?

Ich glaube, damit kann man auch sein Onlinebankingzugang sperren lassen, wenn was unerwartetes auftritt.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 13:20 Uhr  ·  #111
Zitat geschrieben von onlbanker

Zitat geschrieben von msa
Hmm, was hat der KARTEN-Sperrnotruf in einem HBCI-Onlinebanking-Programm zu suchen?

Ich glaube, damit kann man auch sein Onlinebankingzugang sperren lassen, wenn was unerwartetes auftritt.

Das wäre mir neu. Das heißt, ich ruf da an und lasse allen Leuten, denen ich mal was überwiesen habe und deren Kontonummer ich deswegen kenne (und meinetwegen noch ein paar persönliche Daten zur Überprüfung) das Onlinebanking sperren? Cool :-)
onlbanker
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 01.04.2014 - 13:26 Uhr  ·  #112
Du kennst ja deren Zugangsdaten garnicht. Und wenn der Anmeldename nicht zufällig die Kontonummer ist bringt dich das nicht weiter.
http://www.sperr-notruf.de/
Zitat
Die Notrufnummer ist weltweit die erste zentrale und einheitliche Rufnummer zum Sperren von unterschiedlichen elektronischen Berechtigungen wie Kreditkarten, Online-Banking-Zugänge, Handykarten oder auch die elektronischen Identitätsfunktion des neuen Personalausweises.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

SUPA-Import funktioniert nicht völlig korrekt

 · 
Gepostet: 08.04.2014 - 11:29 Uhr  ·  #113
Ich habe gerade SEPA-Basislastschriften per SUPA-Datei importiert, soweit funktioniert das. Allerdings ist jede importierte LA mit dem "!" markiert. Es wird angemeckert, dass man eine korrekte Gläubiger-ID, Lastschriftart und Ausführungsdatum angeben soll - OBWOHL das alles korrekt gesetzt ist!

Um weiterarbeiten zu können muß man jede LA zum Bearbeiten öffnen und wieder Speichern bzw. mit OK schließen, dann ist das "!" weg und alles normal. Ich gebe in meinen SUPA-Datensätzen nur die unbedingt nötigen Felder an, Gl-ID wird beim Import aus den Kontostammdaten beigesteuert, Lastschriftart von alleine auf B2B gesetzt wenn nichts anderes in SUPA angegeben ist und Ausführungsdatum wird auf "heute" gesetzt - kann man dann ja noch nach Wunsch über die Massenänderung setzen.

Bisher hat das prima geklappt, jetzt werden wohl die Vollständigkeitsprüfungen beim Import zu früh gemacht wird und zwar, bevor die automatisch zugesteuerten Werte eingetragen sind. Somit werden korrekte Datensätze als unvollständig markiert, obwohl sie die nötigen Daten längst enthalten.

Bitte um Korrektur dieses Verhaltens in der End-Version!!
subsembly
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: München
Homepage: subsembly.com/
Beiträge: 4582
Dabei seit: 11 / 2004
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 08.04.2014 - 13:07 Uhr  ·  #114
Die importierten SEPA-LA sind unvollständig und wurden auch in früheren Versionen so importiert und unvollständig gespeichert. Es wurden niemals Werte automatisch zugesteuert. Solche unvollständigen Zahlungen werden jetzt mit dem Ausrufezeichen markiert damit man diese unvollständigen Zahlungen sofort erkennen kann. Am besten siehst Du das, wenn Du die entsprechenden Spalten (Gläubiger-ID, usw.) einblendest.

Erst wenn Du die SEPA-LA zum Bearbeiten öffnest, wird:

1. Von der im Formular eingebauten Logik die fehlende Gläubiger-ID mit dem Wert aus den Kontostammdaten ergänzt.

2. Eine Lastschriftart wohl eher zufällig ausgewählt (bei mir in diesem Fall eigentlich immer Basislastschrift und nicht Firmenlastschrift).

3. Da der Date-Picker für das Ausführungsdatum keinen Null-Wert anzeigen kann steht dort halt das heutige Datum drin. Bei SEPA-LS ist dies aber eigentlich nicht möglich, so dass der Wert auch hier erst geändert werden muss, bevor das Formular mit OK geschlossen werden kann.

Die neue Markierung mit dem Ausrufezeichen ist wichtig, da man eine unvollständige Zahlung nicht automatisch zu einem sortenreinen Sammler zusammenfassen kann und auch nicht mit dem neuen Menüpunkt "Senden" einfach senden kann.

Eine direkte SEPA-Sammellastschrift mag möglich sein, da hier das Datum sowieso noch mal explizit gesetzt wird. Die Subsembly SEPA API verwendet als Default-Wert für die Lastschriftart auch CORE, so dass auch diese Hürde genommen wird. Die Gläubiger-ID müsste aber auch in diesem Fall zu einem Problem führen.

Alles in allem war das bisherige Verhalten eher zufällig und nicht sauber. In der neuen Version habe ich die Validierung von SEPA-Aufträgen deshalb komplett überarbeitet. Funktional sollte sich abgesehen von dem Warnsymbol aber nichts geändert haben, oder?
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 08.04.2014 - 14:10 Uhr  ·  #115
Dass meine SUPA unvollständig war, ist mir schon klar. Inzwischen habe ich die Werte nachprogrammiert und dann klappt es. Aber:

Gläubiger-ID hatte ich vorher NICHT drin. Die wurde (und wird!) beim Import aus dem Kontostamm von B4W dazugesteuert. Jedenfalls steht die im Zahlungsdatensatz schon drin, auch wenn man ihn noch NICHT bearbeitet hat. Find ich eigentlich auch korrekt so. Denn wenn ich diese im Kontostamm hinterlegt habe, dann paßt die ja wohl für Importe auf dieses Konto. Würde einem ersparen, sie in dem Fremdsystem das die SUPA erzeugt auch wieder pflegen zu müssen... Andererseits könnte man wieder sagen, die Mandatsreferenz macht nur zusammen mit der Gl-ID Sinn. Wobei ich mich gerade frage, ob auf einem Konto verschiedene Gl-IDs vorkommen können und was passiert, wenn ich der Bank eine Datei sende, die eine andere Gl-ID beinhaltet als bei der Bank hinterlegt ist. Wird wohl zu einem Fehler führen? Somit kann eine in der SUPA gelieferte Gl-ID nur entweder identisch zur in den Stammdaten hinterlegten sein oder einfach falsch. Also kann man sie wohl aus den Stammdaten zusteuern? Ist wohl eine Ansichtssache...

Lastschriftart wurde zufällig ausgewählt beim Import - OK. Ich verstehe, wenn Du da beim Import explizit eine vorgegeben haben willst. Allerdings kann man die dann hinterher ja auch wieder ändern (auch für den gesamten Sammler), so dass es zur Vereinfachung auch wieder Sinn machen würde, wenn "die üblichste" gesetzt würde, wenn keine geliefert wird. Und das wäre (wie bisher zufällig) die CORE. Würde auch wieder die SUPA möglichst universell halten, aber wenn Dir das widerstrebt versteh ich's auch...

Bei nicht vorgegebenem Datum wäre es meines Erachtens am sinnvollsten, das nächst mögliche vom Importzeitraum aus für die Lastschriftart zu setzen. Ändern kann man's dann ja auch immer noch.

Meine Überlegungen gehen dahin, dass das System was die SUPA erzeugt so wenig wie möglich eigene Stammdaten verwalten muß. Es erzeugt nur das absolut notwendige. Alles was beim Import nicht belegt ist, wird mit Standardvorbelegungen vom am meisten vorkommenden vorbelegt. Also Gl-ID aus dem Kontostamm (das Konto muß ja beim Import eh angegeben werden), Lastschriftart CORE und nächstmögliches Belastungsdatum vom Importzeitpunkt aus. Alles was von den Vorbelegungen nicht stimmt kann man dann in B4W ändern und man muß nicht im liefernden System Klimmzüge machen. Gerade z.B. was das Belastungsdatum betrifft. Gerade auch wenn eine SUPA vom Fremdsystem erzeugt und nicht sofort importiert wird. In dem Fall dürfte das ereugte Belastungsdatum in der SUPA in den seltensten Fällen stimmen...

Prinzipiell ist das Verhalten wie vorher, bis auf das Ausrufezeichen. Allerdings konnte man vorher einfach weiter arbeiten (also z.B. Sammler erstellen bzw. der Sammler wurde gleich belassen). Jetzt verhindert das Ausrufezeichen ja das Weiterarbeiten. Die markierten Zahlungen werden als Einzelzahlungen importiert, nicht als Sammler, und können auch nicht zu einem Sammler gemacht werden, weil der Punkt ausgegraut ist. Somit kann man auch die Sachen wie Gl-ID und Lastschriftart nicht auf einmal für den ganzen Sammler setzen sondern eben erst mal nur für jede Zahlung einzeln durch Bearbeiten und Speichern. Erst dann kann man weiterarbeiten. Und jede einzeln aufrufen und ohne Änderung abspeichern um das Rufzeichen zu entfernen ist bei größeren Mengen von Zahlungen etwas lästig... eben vor dem Hintergrund das Fremdsystem so dumm wie möglich zu halten und div. "klare" Einzelwerte vom Fremdsystem nicht zu liefern.
fujisan
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 54
Dabei seit: 10 / 2013
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 10.04.2014 - 15:56 Uhr  ·  #116
Zitat geschrieben von subsembly

Zitat geschrieben von uno23

Hallo, bei den Auswertungen fehlen auf jeden Fall die Varianten Quartal, Jahr und "alle Umsätze". Und besonders komfortabel finde ich den 'Zeitstrahl' nun nicht grade, es fehlt irgendwie ein schnelles vor/zurück mit der Tastatur...


Du kannst ein Quartal einfach auswählen wenn Du auf dem Zeitstrahl auf den Quartalsbeginn klickst, gedrückt hältst, zum Quartalsende ziehst und dann auslässt. genauso kannst Du ein Jahr oder einen anderen beliebigen Monatsbereich auswählen. Mit den Links/Rechts-Pfeilen kannst Du dann zurück/vorschalten. Die Variante "alle Umsätze" fehlt tatsächlich. Muss ich evtl. noch irgendwie reinklemmen.


Bin jetzt auch bei B4W und B4A gelandet ;) Beim Beta-Test finde ich es schon einmal sehr gelungen, die Umbuchungen ausschließen zu können. Dies müsste allerdings bei den Apps noch angepasst werden. Da kann ich die neue Kategorie Umbuchungen nicht ausschließen (Arbeite da mit synchronisierten Datenbanken).
Bei der Kritik am Zeitstrahl muss ich mich allerdings anschließen. Die Standardzeiträume Monat/Quartal/Jahr sollten schon mit einer Schaltfläche erreichbar sein und auch als Voreinstellung gespeichert bleiben. Auf dem Laptop ohne Maus ist der Strahl ganz schön fummelig. Und auf dem Smartphone kann ich ihn mir gar nicht als sinnvoll vorstellen.Eine zusätzliche Schaltfläche "Freier Zeitraum" und von/bis auf der Tastatur fände ich besser. Der Strahl sieht zwar auf den ersten Blick ganz gut aus. Da er aber die anderen Schaltflächen nicht ersetzen kann ist er für die eine Funktion eigentlich zu viel Aufwand.
Ansonsten ein sehr schönes Programm.
Schön wäre es auch noch, wenn bei den Vorlagen eine bereits angelegte nicht wieder angelegt würde (gleicher Empfänger als Kriterium) und wenn man diese Empfänger noch zusammenführen könnte. Bsp. Geldautomat X wird mit Geldautomat Y zu Geldautomat zusammengeführt. Oder der Empfänger "Danke, ihr Supermarkt" in "Supermarkt XY" umbenannt werden könnte und die nächsten Buchungen erkannt würden und dem neuen Empfänger zugeordnet werden könnten. Auch vermisse ich bei den Vorlagen eine Gruppe "eigene Konten" oder "Favoriten". Das lässt sich zur Not ja über die Kommentare sortieren aber die Vorlagen in Gruppen zusammenfassen zu können hätte etwas.
Grüße
fujisan
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 54
Dabei seit: 10 / 2013
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 10.04.2014 - 16:20 Uhr  ·  #117
Zitat geschrieben von msa

Zitat geschrieben von infoman
und um abschließend auf deinen Punkt "Kern Online-Banking-Prog." einzugehen, dann hat Auswertung/Kategorie nichts darin zu suchen bzw. wäre grenzwertig, da dies schon im Finanzmanagement Bereich/Buchhaltung oä. zu sehen ist.

Richtig!! Genau deswegen ist die ganze Kategorisierung/Auswertung mir auch irgendwo ein Dorn im Auge. Aber es gibt wohl genügend Leute, für die sowas wichtig zu sein scheint. Wenn ich solche Auswertungen brauche, mache ich die in Excel, da kann ich wenigstens so auswerten, wie ich es will, und nicht so, wie es gerade mal geht. Aber nachdem nicht jeder gut in Excel zurecht kommt, mag es nötig sein, sowas einzubauen bzw. eingebaut zu haben.

Grundsätzlich ja, aber ein einfacher Einnahmen/Ausgaben-Vergleich ist schon praktisch. Und wenn man da die Umbuchungen untereinander (eigene Konten) als solche kennzeichnen und damit ausschließen kann finde ich das schon praktisch. Und das geht am einfachsten mit Kategorien. Wer es gar nicht will löscht einfach den Kategorienbaum und gut. Deswegen muss man ja noch lange nicht Gegenbuchungen zuordnen können. Auch für Auswertungen in Excel sind die Kategorien doch ganz praktisch. Aber ansonsten habt ihr schon recht, großartig ausgebaut (Grafiken usw.) sollte der Bereich nicht. Schneller Überblick z.B. Auwertung als Starseite und "hoppla da fehlt was" gibt es doch kaum etwas dagegen.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 25.04.2014 - 12:08 Uhr  ·  #118
Ich habe gerade noch eine - in meinen Augen - Merkwürdigkeit in der BETA entdeckt!

Was macht es für einen Sinn, dass Aufträge, deren Fälligkeitstermin ÜBERSCHRITTEN ist, nicht gesendet werden können, ohne vorher den Ausführungstermin hochzusetzen?

Fall: Ich habe gestern Zahlungen abgesendet, drei davon konnten wegen Limitüberschreitung nicht ausgeführt werden. Soweit kein Problem, die Leichen im Ausgangskorb gelöscht, die zugehörigen Zahlungen im Zahlunsverkehr nicht gelöscht, dann kann man sie mit "Senden" nochmal senden. Gestern standen die da ganz normal drin, mit Fälligkeit 24.4. (welche ich nicht angegeben hatte, die wurde wohl beim mißglückten Senden reingeschriben). Heute hatten diese Zahlungen dann das (!) dran stehen, beim Drüberfahren kam "Fälligkeit überschritten" oder sowas. Absenden ging nicht, da kam dann eine Fehlermeldung, dass man das Ausführungsdatum korrigieren soll. OK, das geht mit der Sammelfunktion problemlos. Nur der Sinn erschließt sich mir nicht. Das kommt doch laufend vor, dass man nicht AM Tag der Fälligkeit zum Absenden kommt sondern erst danach? Kann es sein, dass da eine Abfrage falsch sitzt mit = statt mit <= ??
elvis61
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 4
Dabei seit: 04 / 2014
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 26.04.2014 - 08:21 Uhr  ·  #119
OK..
Ich habe Bete 5.2 installiert. B4W-Umbuchung scheint wieder zu gehen.
Hoffentlich habe ich keine andere Fehler.

Mit einer Banksoftware darf man keine Experimente machen.
Wer steht für einen Schaden gerade ??

Was soll ich mit B4A machen, damit es auch funktioniert ??
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7561
Dabei seit: 03 / 2007
Betreff:

Re: Banking 4W v5.2 BETA

 · 
Gepostet: 26.04.2014 - 15:43 Uhr  ·  #120
Zitat geschrieben von elvis61
OK..
Ich habe Bete 5.2 installiert. B4W-Umbuchung scheint wieder zu gehen.
Hoffentlich habe ich keine andere Fehler.

Es ist und bleibt eine BETA Software, um neue Funktionen zu testen und weiterzuentwickeln. Allerdings sind die Betas von Subsembly, die sie zum allgemeinen Test freigeben, keine wackeligen Ungetümer, sondern stabile Versionen eben mit neuen aber noch nicht endgültig aus-überlegten und aus-gedachten Funktionen und mitunter eben Bug-Fixes für Banken, die mal wieder was geändert haben und eben mal wieder nicht den Standard erfüllen. Es ist keinesfalls so, dass die Funktionalität der Software unzuverlässig ist und sie deswegen mal aus Versehen irgendwas in fremde Länder oder so überweist...

Zitat geschrieben von elvis61
Mit einer Banksoftware darf man keine Experimente machen.
Wer steht für einen Schaden gerade ??

Das, mein lieber Elvis61, ist allein Deine Entscheidung. Es steht Beta drauf und es ist Beta drin. Wer eine solche Version einsetzt weiss - oder sollte zumindest wissen - was er da tut und ist selbstverständlich SELBST dafür verantwortlich. Wenn niemand irgendwelche Experimente machen würde, dann würde es nie irgendwelche Neuerungen geben bzw. es würde niemals Fehlerbereinigungen ect. geben bzw. es würde die ganze Software nicht geben. Es gibt nämlich von den Banken KEINE Testserver oder Testzugänge. Fast Alles in diesem Bereich wird von Herstellern und im Rahmen von Betatests eben auch von testwilligen Kunden mit echten Konten und echten Transaktionen getestet, bis es klappt. Ob man da mitmachen will oder nicht ist die eigene Entscheidung.

Zitat geschrieben von elvis61
Was soll ich mit B4A machen, damit es auch funktioniert ??

Das Gleiche, was Du auch mit B4W machen mußt, wenn Du keine Beta mit aktuellen Veränderungen (die es für B4A derzeit nicht gibt) einsetzen willst:
Warten, bis ein neues Release rauskommt.
Gewählte Zitate für Mehrfachzitierung:   0