Ich möchte hier gerne noch einmal die FAKTURAMA-2-Kopfzeile öffentlich zur Diskussion stellen, deren Begrifflichkeiten und Fülle m.E. zu Irritationen führen könnten, klarer benannt und gestrafft werden sollten - es geht mir genauer gesagt um folgenden Bereich:

Dazu muss ich zunächst noch einmal die allgemeinen Abläufe in einem Produktions-, Handwerks-, Dienstleistungs- und/oder Handelsbetrieb in Erinnerung rufen:

Zur Erläuterung:
Ein Interessent oder Kunde kann sich ein Angebot (1) unterbreiten lassen oder gleich einen Auftrag (2) erteilen. Das, was man bisher als (Eingangs-) "Bestellung" betrachtet hat, ist an sich bereits ein Auftrag (2) - wozu also die redundanten Programmteile "Auftrag" und "Auftragsbestätigung" ... ?
Kann der erteilte Lieferungs-/Leistungs-Auftrag ohne externe Unterstützung nicht vollständig erfüllt werden, so müssen rechtzeitig oder spätestens während der Abarbeitung entsprechende Aufträge an das "Hinterland" herausgegeben werden - darunter verstehen wir also Bestellungen (3) an Subunternehmen für Material-Lieferungen und Leistungen ... !
Wurden die vom Kunden beauftragten Lieferungen und Leistungen ohne oder mit externer Unterstützung vollständig erbracht, erfolgen die (letzte) Auslieferung und/oder Abnahme. Zur beiderseitigen Dokumentation wird ein Liefer-/Abnahmeschein (4) vorbereitet.
Auf Basis der vorliegenden Liefer-/Abnahmescheine kann nun die abschließende Rechnung (5) erstellt werden.
Im Fazit also sollte geklärt werden, welcher Programmteil nun künftig alleine für die AB's (2) genutzt werden soll und welcher für Bestellungen (3) an Hersteller/Lieferanten/Subunternehmen zur Verfügung steht. Das ist auch deshalb wichtig, weil sich später hieran einmal die Wareneingangserfassung und Bestellrückstandskontrolle anbinden lässt ...
_ _ _ _ _
Die Programmteile "Rg.-Korr." und "Proforma" halte ich in der Kopfzeile für völlig überflüssig:
Wenn eine Rechnung später noch einmal zu korrigieren ist, so kann das über Teil-Gutschriften oder über eine komplette Gutschrift mit darauf folgender Neuschrift oder sogar in der ursprünglichen Rechnung selber erfolgen - FAKTURAMA lässt das alles problemlos zu, man darf dabei nur nicht die Übersicht verlieren und muss sich etwas geschickt anstellen. Mit anderen Worten lassen sich diese Notwendigkeiten alleine im Rechnungswesen schon vereinen. Ich schlage also vor, beide Programmpunkte aus der Kopfzeile zu entfernen und nur zum Bestandteil der Dokumentenbearbeitung im Rechnungswesen zu machen - der Begriff "Rg.-Korr." könnte vorzugsweise noch in "Gutschrift" umbenannt werden:

Anmerkung: Ich hatte von 1991 bis 2006 das sehr leistungsfähige BC>FAKTURA aus dem Hause W.Biller GmbH Wittmund vertrieben, eingeführt und mit weiterentwickelt (Entwicklung und Vertrieb wurde ca. 2007 eingestellt). Hier konnte man mit jeweils neuer Belegnummer ...
1) Rechnungen alleine duplizieren
2) aus Rechnungen komplette Gutschriften (negative Duplikate) erzeugen
3) zugleich zu den GS neue gleichartige Rechnungen für die Überarbeitung generieren
4) Proforma-Rechnungen generieren
... alles unter der gleichen Dokumentenbearbeitung (im Rechnungswesen). Ich denke, eine solche Optimierung wäre auch für FAKTURAMA sinnvoll, damit die Übersichtlichkeit nicht verlorengeht ...
JöLi.
kurze Anmerkung von mir: "Kopfzeile" ist hier etwas irreführend, das Ding nennt sich "Buttonleiste", korrekt: "Coolbar" 😉
Ich werde die Rechnungskorrektur definitiv nicht wieder in "Gutschrift" umändern. So hieß das früher schon mal und es hat sich nach einer langen und sehr zähen Diskussion herausgestellt, daß das falsch ist. Möglicherweise werde ich zusätzlich noch die Dokumentart "Gutschrift" einführen, das kommt aber dann erst später.
Die Icons in der Coolbar kann man übrigens ausblenden (über die Einstellungen -> Werkzeugleiste).
Die anderen Anmerkungen werde ich mal so aufgreifen. Evtl. mache ich dafür noch ein eigenes Subforum auf, da das hier sonst etwas untergeht, glaube ich.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Wenn es erlaubt ist, möchte ich hier auch mal meine Senf dazu beitragen...
Die Ausführungen @dr.listemann sind in einigen Punkten m.E. nicht ganz zutreffen. Dazu muss aber auch ich einleitend ebenfalls etwas ausschweifen:
Bekanntlich führen viele Wege nach Rom und so kann ein rechtsverbindlicher Kaufvertrag (auch Werk-, Liefer- oder Leistungsvertrag) ebenfalls auf unterschiedliche weise zustande kommen. Dazu muss man verstehen, dass ein Angebot entweder bindend oder unverbindlich (freibleibend) seien kann (je nach dessen Ausgestaltung). Dementsprechend kann beispielsweise auch eine Werbung bereits den rechtlichen Charakter eines Angebot haben. Beispielsweise wenn man ein konkretes Produkt zu einem bestimmten Preis bewirbt. Daher handelt es sich bei einem Webshop rechtlich gesehen um ein Angebot. Und dies kann, etwa durch entsprechende Regelung in den AGB, bindend oder unverbindlich sein. Diese Unterscheidung ist wichtig, kommt dadurch schließlich ein Vertrag auf unterschiedliche Weise zustande:
- Verbindliches Angebot -> Auftrag des Käufer = Vertragsabschluss durch Angebotsannahme
- Unverbindliches Angebot -> Auftrag des Käufer = verbindliches Angebot -> Auftragsbestätigung des Verkäufer = Vertragsabschluss durch Angebotsannahme
- Auftrag des Käufer = verbindliches Angebot -> Auftragsbestätigung des Verkäufer = Vertragsabschluss durch Angebotsannahme
(Schließlich kann es auch sein, das ein Kundenauftrag ohne vorheriges Angebot eingeht)
Um dies in Fakturama entsprechend abbilden zu können, ist der Belegtyp Auftrag neben der Auftragsbestätigung also Wichtig! Beispielsweise für den elektronischen Datenaustausch durch den Import von Bestellungen / Aufträgen... Etwa Webshop- Bestellungen oder auch mittels openTrans oder GAEB.
Übrigens kommt ein Vertrag De Facto erst durch zwei übereinstimmende Willensbekundungen zustande. Bis dahin hat eigentlich alles den Charakter eines Angebot. Selbst eine Auftragsbestätigung, sofern diese beispielsweise abweichende Preise oder zusätzliche Positionen enthält.
Es wäre daher folgendes Wichtig:
- Im Angebot sollte man eine Bindefrist eingeben können. Ist diese Identisch mit dem Angebotsdatum (oder leer) handelt es sich um ein unverbindliches Angebot. In den Einstellungen sollte man einen Standard Zeitraum definieren können (vergleichbar mit dem Zahlungsziel).
- Der Belegstatus sollte dies zum jeweiligen Zeitpunkt abbilden können. Bei Angeboten beispielsweise: Datum Bindefrist = abgelaufen oder eben "weitergeführt", "bearbeitet" usw.
Zum Thema Korrekturrechnung hat @rheydenr übrigens vollkommen recht. Auch wenn dies frührer evtl. anders gehandhabt wurde, ist eine fehlerhafte Rechnung nicht durch eine Gutschrift (ggf. mit anschließender neuer Rechnung) zu korrigieren, sondern eben mittels einer Korrekturrechnung zu berichtigen. Eine Korrekturrechnung bedarf zwangsläufig einer vorhergehenden Rechnung. Sie kann sowohl zu einem Guthaben als auch einer Nachforderung führen. Schließlich kann man sich ja in beide Richtungen verrechnet haben. Eine Gutschrift ist hingegen ein eigenständiger Beleg und führt wie der Name schon vermuten lässt zwangsläufig zu einem Guthaben. Wenn auch selten benötigt, ist die Belegart Gutschrift dennoch erforderlich (z.B. für Provisionen) und sollte kurzfristig wieder integriert werden.
Abschließend möchte ich noch kurz auf folgende themenrelevante Tickets hinweisen:
- #713
- #674
- #621
- #622
- [url= https://bugs.fakturama.info/view.php?id=580 ]#580[/url]
Gruß
Matthew
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
Gut - das mit den "Aufträgen" und "Auftragsbestätigungen" sowie "Gutschriften" und "Rechnungskorrekturen" lasse ich mir mal durch den Kopf gehen, obgleich ich bereits seit 1990 in verschiedenen Branchen selbständig bin und mir diese Problematik noch nie auf den Tisch gekommen ist 8-). Am wichtigsten erscheint mir jedoch, das Programm optisch nicht zu überladen, wenn mehr Funktionen dazukommen - man kann diese Funktionen dann systematischer in den entsprechenden Arbeitsbereichen unterbringen ...
Doch auf welche Weise lösen wir mit FAKTURAMA Bestellungen bei unseren Lieferanten aus und halten den Wareneingang unter Kontrolle, wenn wir in FAKTURAMA schon erste Ansätze für eine Bestandsführung haben ? Man sieht - es gibt noch so Einiges tiefgründiger zu durchleuchten ... :)o
JöLi.
dr.listemann schrieb:
-------------------------------------------------------
> Doch auf welche Weise lösen wir mit FAKTURAMA
> Bestellungen bei unseren Lieferanten aus ...
Überhaupt nicht! >:D<
Entschuldigt meine "Benzin-in-Feuer-Antwort", aber man muss das Kind schon beim Namen nennen ... 😉
Allerdings sehe ich da noch ein generelles Problem: Die unterschiedlichen "Sprachen" ...
Warnung: Viel Text (hoffentlich recht "amüsant" oder informativ - wenn auch eher wenig Fakturama-lastig), viel Blabla, aber dennoch vielleicht nicht soooo verkehrt. 🙂
Beispiel Handelsbetrieb (aber auch andere Betriebsformen):
Hier werden teilweise recht unterschiedliche "Sprachen gesprochen":
a) zw. Händler und Endverbraucher
b) zw. Händler und Produzent
c) regionale Unterschiede
d) Ausland (packe hier einfach mal alle rein, wobei Punkt a-c hier auch noch gelten können)
Beispiel: "Gully(deckel)" (das Ding, wo auf der Straße das Wasser abläuft)
Ein Gully ist (eigentlich) das quadratische Ding mit den Schlitzen - an so gut wie jeder Straße alle paar Meter zu finden. Viele sagen das aber auch zu den "runden Dingern", deren Leistung Wasser aufzunehmen jedoch als eher bescheiden einzuordnen ist, denn deren 16 Löcher (oder 12 schmaleren "halbrunden" Langlöcher) stinken gegen die 7 Schlitze des "echten Gullys ab. Ich habe keine Unterlagen darüber, aber ich denke, dass 2 Schlitze (vielleicht auch nur einer) schon die oder mehr Ablaufleistung als die 16 Löcher haben. Deshalb sind auch die runden eher in der Straßenmitte zu finden, da diese "nach links und rechts" abschüssig ist, da sonst das Wasser einfach "stehen bleiben würde".
Um auf den Punkt zu kommen, der Gully nimmt ALLES auf, Wassermassen, Laub, Dreck etc. - der "runde Gully" eben nicht und ist eine s.g. Mannlochplatte, manhole cover (Mannloch Abdeckung, englisch) und in America heissen die soweit ich weiss "thermische Abdeckungen" (oder von mir aus thermische Gullydeckel). Die Funktion der Löcher ist (soweit ich weiss) also nicht das einlassen von etwas (z.B. Regenwasser), sondern vielmehr das herauslassen von etwas. (z.B. Gasen oder allgemein Druck/-luft).
In Deutschland sagt man auch "Straßenablauf" und laut Wikipedia sagt der Schweizer Dole(ndeckel), aber das ist dann eher wieder die "Mannlochplatte", die wie gesagt nicht die Funktion hat etwas "hereinzulassen", sondern vielmehr etwas herauszulassen - eine Ausnahme: der "Mann" (Angesteller der Stadt oder so), der dort unten Arbeiten zu verrichten hat.
Sorry, für das weite ausholen, aber habe mich gerade erst in die Materie eingelesen und will damit ja nur veranschaulichen, wieso "mehrere Sprachen für ein und den selben Artikel" notwendig sind.
Es sollte also über einen "kundenfreundlichen" und einen "alternativen Namen" (herstellerspezifischen Namen) nachgedacht werden - wobei, wenn man es ganz genau nimmt, sind Artikelbeschreibungen auch 2 Paar Schuhe - nämlich das was der Hersteller machen soll und was der Käufer haben möchte ...
Wieder ein Beispiel:
Dem Kunden ist wichtig, dass alles an seiner Wandhalterung (für den TV), gut verschweisst ist (wenn überhaupt), bzw. alles egal Hauptsache da kann sein 50kg-Trümmer dran aufgehängt werden - für den Lieferant (oder eher Ingenieur) ist wichtig, "welche Schweissnaht (I-, U-, V-, Y-Naht .....) zum Einsatz kommt, damit ich da mind. 70 kg dranhängen und somit 50 kg garantieren kann ...
Jetzt bestellt man beim Hersteller natürlich keine "50 kg-Halterung", sondern eine mit "V- und Kehlnaht" ... denn der Hersteller hat auch eine Billigvariante die 50 kg kann, aber nur punktgeschweißt ... und "unser Laden steht für Qualität" also bestellen wir auch die entspr. Schweißnahtausführung mit ... naja, wie gesagt nur ein fiktives Beispiel, wie es vielleicht sein könnte.
Fakt ist aber, dass viel verschiedene "Sprachen" gesprochen werden ... Stellt euch mal an eine Verkaufstheke im Heizungs-/Sanitärbereich eines Fachhändlers ... wenn das auf der Rechnung stehen würde, was die Jungs dort bestellen, würde vermutlich keiner die Rechnung für voll nehmen (oder nicht verstehen) und unbezahlt wegwerfen (oder sich jedes Wort erklären lassen müssen) ... Anders herum kann ich wohl kaum beim Hersteller der "Gully" einen "Gullydeckel" bestellen ... vermutlich eher "gusseiserne Schachtabdeckung wasserführender Kanalsysteme, eckig, geschlitzt" (haha, so ein Schmarn) 😀
Worauf wollte ich hinaus? Ach ja, also m.M.n. müsste jeder Artikel eine "alternative" Artikelbezeichnung, wie auch eine weitere Artikelbeschreibung verpasst bekommen können.
Ich hätte mir die viele Schreiberei bezügl. der Sprachen (=Ausdrücke) auch sparen können ... (siehe oben)
- Kopfzeile
- Coolbar
- Toolbar (würde ich vllt. sagen) oder
- Icon-Leiste
- Horizontalleiste
- Funktionsleiste
oder oder oder ... 😀
Also, habt einen schönen Feierabend!
Viele Grüße!
:eek: 😮
Zitat eek6smxf: "Ich hätte mir die viele Schreiberei bezügl. der Sprachen (= Ausdrücke) auch sparen können ..."
Richtig erkannt - ich (persönlich) bitte doch darum, dass wir gerade in dieser Themengruppe auf große Polemik verzichten und uns auf das Wesentliche beschränken ... :)o
Nun nochmals zum eigentlichen Thema selber: Bei direkten Arbeitskontakten mit Ralf wurde seinerseits u.a. SAP erwähnt und auch ich selber habe bereits mit verschiedenen mehr oder weniger bekannten und leistungsfähigen Fakturierungs- und Warenwirtschaftssystemen gearbeitet (u.a. mit LEXWARE), andere für einige Zeit getestet (siehe hier). Dort sind mir verschiedene Begriffe für eigentlich die gleichen Funktionen aufgefallen - ein grundsätzliches Problem also. Daher sollte man sich an einschlägig anerkannte Standards halten oder solche noch schaffen ...
Woran können wir uns hierbei halten ? FAKTURAMA wurde ursprünglich für die Warenwirtschaft entwickelt und ist aber u.a. auch für kleinere Handwerks- und Dienstleistungsbetriebe geeignet. Ich habe es sogar (als preiswerte Alternative bzw. Interimslösung) in einem kleinen (10 Zimmer-) Hotel eingeführt. Und FAKTURAMA ist mittlerweile mehrplatzfähig, so dass die o.a. allgemeine Ablauforganisation sachgebietsbezogen von verschiedenen Mitarbeitern realisiert werden kann - dazu gehört ganz klar auch ein Bestellwesen, und der Einwand von eek6smxf "überhaupt nicht" ist realitätsfremd, d.h. man kann ihn nicht gelten lassen ...
Ich schlage also vor, dass wir uns bei der FAKTURAMA-Weiterentwicklung und Vervollkommnung an die Begriffswelt und die Funktionalitäten von SAP und LEXWARE halten. Dort wird das Auftragswesen ganz klar der Bearbeitung eingegangener Liefer- und Leistungs-Aufträge zugeordnet - die Betonung liegt auf "eingegangen", d.h. es sind Aufträge von Kunden ...
Können gewisse Positionen der eingegangenen Aufträge nicht vom Auftragnehmer selber erfüllt werden, weil diese z.B. nicht auf Lager sind oder Fremdleistungen beansprucht werden müssen, so sind zur Erfüllung dieser Positionen Aufträge an Hersteller, Lieferanten, Subunternehmen und dergleichen weiterzuleiten. Dabei handelt es sich um Auftrags-Ausgänge bzw. Bestellungen (an Lieferanten) ...
Und jetzt nochmals meine ganz klare Frage: Mit welchem FAKTURAMA-Baustein kann man das lösen ? Macht es wirklich Sinn, dafür anstatt FAKTURAMA ein anderes Programm zu nutzen - mit einer redundanten Datenverwaltung, einem eigenständigen Kontrollsystem ? Und wie soll man auftragsbezogen den Bearbeitungsstatus bzw. Liefer- und Leistungs-Rückstände des eigenen "Hinterlandes" im Blick behalten ?
Im Fazit halte ich es schon für sinnvoll, einen größeren Weitblick bei der FAKTURAMA-Gestaltung und seinem Ausbau einzunehmen - diese dringlichste Empfehlung gebe ich mit meiner wirklich langjährigen beruflichen Erfahrung seit Mitte der 1980-er Jahre gerade auf diesem Gebiet (siehe hier), aus der hier jeder Mitwirkende gerne etwas mitnehmen kann ... :)o
JöLi.
Powas, Powo? Polemik kann dort anfangen, wo ein @-Zeichen gesetzt wird. Aber bestimmt nicht in meinem Text.
Ui, da hat dr.listemann mich aber missverstanden ...
Sprachen & Ausdrücke ...
a) Um über eine Sache sprechen zu können, muss man die selbe Sprache sprechen können, dass das nicht ganz hingehauen hat, wurde bereits am 19.02. mit erster Antwort aufgezeigt. Aber das ist ja kein Beinbruch und ich wollte niemand an den Pranger stellen oder so (am besten "ätschbätsch, der weiss nicht wie das heisst", oder wie?). Mir ging es darum das "Sprachproblem" im Allgemeinen (''Gullybeispiel'') aufzuzeigen, denn ...
b) dr.listemann schrieb:
-------------------------------------------------------
> Doch auf welche Weise lösen wir mit FAKTURAMA
> Bestellungen bei unseren Lieferanten aus ...
... für mich sieht es nunmal so aus, dass man (aufgrund der Sprachbarriere) nämlich "Überhaupt nicht!" beim Hersteller bestellen könnte ... Außerdem; ist das Tool (oder ''Cool'') "Bestellung (beim Hersteller)" an mir vorbeigegangen? Hab Fakturama gerade nicht zur Hand, aber das werde ich noch prüfen.
Frage: Über was regen sich "die Leute" (Endverbraucher) nach ersehntem "Fernseherkauf" am meisten auf? (mal davon abgesehen, dass die meisten nicht wussten, dass ihr Gerät "4k" kann, oder wissen was das nicht, geschweige denn, dass sie das für ihre "Nachmittagssendungen" auch in weiter Zukunft gar nicht ausnutzen können).
Also, was stört den Verbraucher am meisten? "Kauderwelsch" in der Anleitung! Dass man nichts von dem darin versteht, weil der Hersteller eine "ganz andere Sprache" spricht (und damit meine ich nicht englisch oder chinesisch, eher ''fachchinesisch'').
Daher war mein Vorschlag Artikel "zweisprachig" (oder sogar 4-sprachig, DE_EK, DE_VK, EN_EK, EN_VK) einpflegen zu können, sodass es der Hersteller (Einkäufer-Seite) versteht und auf der anderen Seite der Kunde (im Verkauf/Shop/Angebot oder wie auch immer).
Ich kann nun mal nicht beim Hersteller einen "Wasserhahn (oder ...kran) für eine Badewanne mit Dusche" bestellen. Das Ding heisst nun mal bspw. "Wannenfüllarmatur mit Brausehalter" (Brauseschlauch und Duschkopf sind übrigens i.d.R. im Fachhandel nicht inkludiert). Die Fach- und Umgangssprache liegen zu weit auseinander, sodass man meiner Meinung für Shop und/oder Angebot und Fachhändler und/oder Hersteller etc. mehrere "Sprachen" (Fach- und Normalsprache ... ein Umgangssprachen-Shop wäre allerdings auch mal etwas neues) verwenden können muss.
Viele Grüße!
:eek: 😮
dr.listemann schrieb:
-------------------------------------------------------
> Doch auf welche Weise lösen wir mit FAKTURAMA
> Bestellungen bei unseren Lieferanten aus ...Überhaupt nicht! >:D<
Entschuldigt meine "Benzin-in-Feuer-Antwort", aber man muss das Kind schon beim Namen nennen ... 😉
Ich finde diesen Beitrag auch etwas daneben... insbesondere wegen des m.E. völlig unangebrachten Finger- Smiley. Und während der Lektüre des restlichen Geschwafel über Gullydeckel bla bla bla... wäre ich dann auch fast weggenickt *gähn*
Mit Fakturama auch Geschäftsvorfälle zu Lieferanten abbilden zu können ist übrigens ein absolut berechtigter Entwicklungsvorschlag! Schließlich kann man ja bereits Kreditoren in Fakturama verwalten, nur diese Daten bis dato nicht produktiv nutzen. Dabei dürfte die Mehrzahl an Lieferantenbestellungen übrigens mit eindeutigen Artikelnummern erfolgen, Texte sind dabei häufig zweitrangig und haben eher Informativen Charakter.
Mehrerer Artikeltexte für jede Zielgruppe... am besten wohl auch noch für jede Region oder jeden Dialekt ne eigene - Ernsthaft!? Wer will derartige Daten denn bitte Einpflegen? Für jemanden der evtl. mit um die 100 selbst angelegten Artikeln auskommt mag das ja ggf. noch machbar sein, aber wenn man von mehreren Herstellern ein paar Hundert oder gar Tausend Artikel importiert ist so etwas m.E. völlig Realitätsfremd.
Selbst bei kommerziellen Programmen stehen häufig nur zwei Textfelder je Artikel zur Verfügung. Bei Lexware beispielsweise ein Kurz- und ein Langtext... was bei Fakturama Name und Beschreibung entspricht (um die Übersetzung gleich mal mit zu liefern). Damit könnte man bereits aktuell eines für die Kurzbezeichnung des Hersteller / Liferanten und das andere zur ausführlicheren Produktbeschreibung für einen eher Kunden orientierten Text verwenden.
Gruß
Matthew
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
Mit Fakturama auch Geschäftsvorfälle zu Lieferanten abbilden zu können ist übrigens ein absolut berechtigter Entwicklungsvorschlag! Schließlich kann man ja bereits Kreditoren in Fakturama verwalten, nur diese Daten bis dato nicht produktiv nutzen.
Doch, das geht 🙂 Indem man nämlich bei der Adreßauswahl die STRG-Taste drückt und das entsprechende Icon anklickt...
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Doch, das geht smiling smiley Indem man nämlich bei der Adreßauswahl die STRG-Taste drückt und das entsprechende Icon anklickt...
Das ist richtig, aber damit kann man zwar in Verkaufsdokumenten Lieferantendaten übernehmen, Einkaufsdokumente sind damit jedoch noch nicht umgesetzt.
Grüße
Matthew
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
Zum Beitrag von eek6smxf am 07. März 2019/15:17 Uhr: Ich glaube Dich jetzt mit Deiner "Polemik" verstanden zu haben, d.h. Deinem Versuch, uns zu erklären, dass Kunden, Händler, Dienstleister, Lieferanten, Hersteller usw. bezüglich des selben Objektes in verschiedenen Begriffswelten leben - ist das korrekt ?
Dazu vertrete ich folgende Auffassung: Dem "Erfinder" (Hersteller) des Objektes steht auch das primäre Recht zu, das Objekt so zu benennen, wie er selber es für richtig hält. Mit anderen Worten weiß er am besten, worum es sich hierbei handelt, aber alle Nachfolgenden entstellen oftmals die Bezeichnung des gleichen Objektes nach eigenem Verständnis bzw. Gutdünken ...
Wie bei der "stillen Post" kommt am Schluss etwas ganz Anderes an, als ursprünglich gemeint. Und wer ist für die Missverständnisse dann verantwortlich ? Ganz offensichtlich Diejenigen, die den vom "Erfinder" (Hersteller) gesetzten Standardbegriff entstellt haben, also die Zwischenhändler und dergleichen ...
Was nun die Begriffe für die Funktionen in einem Anwenderprogramm betrifft, so ist zunächst gewissenhaft (darauf liegt die Betonung) zu prüfen, ob es dafür bereits passende Begriffe gibt, die sich allgemein anerkannt etabliert haben. Und wenn dem nicht so ist, darf sich der Hersteller (hier Software-Entwickler) "herausnehmen", seinen neuartigen Begriff in die Welt zu setzen. Er kann eine öffentliche Begriffs-Diskussion großzügig gestatten oder aber auch seinen neuen Begriff einfach festlegen (Urheberrecht) ...
Was nun FAKTURAMA betrifft, so gibt es ähnliche Programme bereits seit vielen Jahren wie Sand am Meer, d.h. es ist an sich keine neue Erfindung. ABER unser FAKTURAMA hat viele sehr angenehme Besonderheiten, die hier Jedem recht gut bekannt sind und uns Anlass waren, es auch einzuführen und weiterzuentwickeln. Da macht es schon Sinn, sich an den älteren und etablierteren Programmen zu orientieren, deren Begriffe und Funtionen aber angenehm in FAKTURAMA einzubinden. Und gerade deshalb sollte man u.a. auch mal darauf schauen, was z.B. SAP und LEXWARE, HANDICRAFT & Co. so alles können ... und FAKTURAMA im Moment noch nicht ...
Nachsatz an LastBoyScout: Ich habe den Eindruck, dass auch Du an einem Bestellwesen (an Lieferanten) innerhalb FAKTURAMA interessiert bist. Deshalb sollte man hierzu mal ein weiteres Thema aufmachen und das werde ich in den nächsten Tagen mal tun. Wir alle können dann dort ja gemeinsam diskutieren, wie man das dann weiter angeht ... bis dahin beste Grüße 🙂
JöLi.
Nachsatz an LastBoyScout: Ich habe den Eindruck, dass auch Du an einem Bestellwesen (an Lieferanten) innerhalb FAKTURAMA interessiert bist. Deshalb sollte man hierzu mal ein weiteres Thema aufmachen und das werde ich in den nächsten Tagen mal tun.
Ich habe noch an so manchen Funktionen Interesse, weshalb ich bis dato leider noch immer auf Lexware Angewiesen bin. Das meiste habe ich aber im Bug Tracker bereits selbst formuliert!
Bez. Bestllwesen bedarf es in einem ersten Schritt ja egentlich nur zusätzlicher Dokumente (Angebotsanforderung, Bestellung, Liefereingangsbestätigung, Eingangsrechnung usw.) zur Interaktion mit den Kreditoren (Debitoren per STRG ;))
Der zweite und wichtige Schritt wäre dann die Umsetzung eines System zu System Datenaustausch mittels etablierter Standards wie openTrans und BMEcat! Lexware unterstützt übrigens beide Standards schon seit Jahren, auch als Standard- Shop- Schnittstelle.
Gruß
Matthew
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
Einen gesegneten Abend!
@dr.listemann: Und schon sind wir d'accord ... sorry wg. evtl. Misstimmung/-verständnisse. :)-D
Ich wollte es nun dabei belassen, aber da der Falsch-Versteher-Zug nun doch wieder im Bahnhof einläuft und ja, diesmal spare ich mir/uns die netten (Bösewicht-)Smilies.
@LustBoyScout:
Auch wenn mir gerade nicht der Sinn danach steht mich oder es zu erklären:
Zitat: "... Geschäftsvorfälle zu Lieferanten abbilden ... ist übrigens ein absolut berechtigter Entwicklungsvorschlag!"
[Sarkasmus an] Ach soooooo ... [Sarkasmus aus] und die "offene Frage" ...
dr.listemann schrieb:
-------------------------------------------------------
> Doch auf welche Weise lösen wir mit FAKTURAMA
> Bestellungen bei unseren Lieferanten aus ...
wollte lediglich durch "Überhaupt nicht! >:D<" untermauert worden sein.
Und wer es nun immer noch nicht auf dem Schirm hat ... eine "echte Schnittstelle" zwischen
Hersteller/Vorlieferant und weiter verarbeitender Industrie/Handwerk und Kunde/Endverbraucher
wäre wünschenswert ... Funktion/Button "Bestellung (an ...)" ja bitte, her damit, toll. Jetzt klar?
[size=2] Wat bin ich froh, dass der Smiley wenigstens grinst und ich mir keine Vorwürfe machen muss ...
Tor 1: Benutzer (mich) sperren wegen unverschämtem Verhalten (den Smiley zu nutzen)
Tor 2: Smiley aus dem Forum löschen / zensieren (das würde sich mit der Politik Deutschlands decken)
Tor 3: ZONK! "Vergessen was war", ran ans Werk und gemeinsam in die richtige Richtung ziehen!
Mehrerer Artikeltexte für jede Zielgruppe... am besten wohl auch noch für jede Region oder jeden Dialekt ne eigene - Ernsthaft!?
Du weisst schon was eine "Zielgruppe" ist?
Ich rede generell von 2 (zwei!) "Sprachen" innerhalb von Fakturama - die "Endverbraucher-freundliche" und des "Herstellers/Fachhandels" (und ggf. von einer Zweitsprache bzw. Fremdsprache)
Statt (m)einer "realitätsfremden" Rechnung, AB etc. mit kundenfreundlichem/er Artikelnamen/Beschreibung stelle man sich doch mal diese AB oder Rechnung vor ...
[quote="Ein "Traum" für jeden Kunden ..."]
ELKO
聚脂膜電容器 电解电容的作 25V 2000 uF 100°C
聚丙烯膜電容器 夸夸其谈 都是一样的 你错了我
重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺
重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺 重复填补空缺
Ein "Traum" für jeden Kunden ... und auch wenn es "nur" englisch gewesen wäre, so hat das für eine für den deutschen Markt vorgesehene Lieferung auf (m)einer Rechnung nichts verloren)
Durch eine bestätigte Lieferung erlangt der Kunde trotz der vielen Details und des BlaBlas leider keine Kenntnis darüber, ob radiale oder axiale Bauteile (übrigens hier ELKO = "Aluminium-Elektrolytkondensatoren") zur Lieferung bestätigt wurden.
Na, wenn das nicht gut beim Kunden ankommt. Hatte ich eigentlich schon ... ? Vorsichtshalber: [Sarkasmus aus]
Nebenbei...
[quote=HK Hamburg]
Die Rechnung ist nach § 239 HGB ... in einer lebenden Sprache vorzunehmen.
Hier verlangt die Finanzverwaltung regelmäßig Übersetzungen, falls eine andere als die deutsche oder englische Sprache verwendet wird.
Aber das geht jetzt zu weit und spätestens bei der ("realistischen", kundenfeindlichen) "Muster-Rechnung" sollte einem einleuchten, dass das die "2 Welten" (Hersteller Verbraucher) eine sprachliche Schnittstelle (durch Handel) erfahren müssen.
Oder mal anders gefragt:
Wieso kann der Endverbraucher (üblicherweise) nicht beim Hersteller direkt kaufen? Tipp: Es geht nicht immer um Stückzahlen ...
Der Hersteller hat einfach keinen Bock auf "malen nach Zahlen" (und keine Kapazitäten das Rätsel zu lösen / Kundenwünsche in ein passendes Produkt zu "übersetzen'') - der will wissen, was er bauen muss, welche DIN das Teil zu erfüllen hat und nicht auf welcher Rue de la Schlagmichtot sein Gully (um dabei zu bleiben) liegen wird und welcher Fahrbahnbelag dort vornehmlich verlegt wurde oder welche Bäume das Straßenbild dort prägen ...
Auch will kein Hersteller wissen, ob man einen Reizdarm hat oder nicht und warum es unbedingt ein "Falchspüler" (= WC = water closet, english) sein soll (Ein wenig Randwissen: das Gegenteil ist der "Tiefspüler" oder liebevoll "Plumpsklo" genannt).
Viele Grüße!
:eek: 😮
"eek6smxf" - könntest Du Dich nicht besser etwas kürzer fassen ? Und was nun die verschiedenen Begrifflichkeiten für Produkte aus "Endverbraucher-" (hässlicher Begriff) und Hersteller- bzw. Lieferanten-Sicht betrifft, so hat das mit dem hiesigen Thema "Überarbeitung der FAKTURAMA-2-Kopfzeile" nichts mehr zu tun. Dieses neue Forum befasst sich zwar mit FAKTURAMA-Konzepten", sollte aber dennoch übersichtlich bleiben, d.h. für das von Dir Angesprochene bedarf es eigentlich eines neuen Themas oder eines Erweiterungswunsches unter "Fehler & Verbesserungsvorschläge" ... B)-
Dennoch: Auch ich halte es für nicht ganz so abwegig, wenn in FAKTURAMA Produkte (Artikel, Leistungen) gegebenenfalls zweifach beschrieben werden könnten, d.h. 1x für den Kunden und 1x für den Lieferanten. Im seit ca. 2007/08 nicht mehr entwickelten BC>FAKTURA, an dessen Einsatzvorbereitung, Einführung und Betreuung ich ca. 15 Jahre lang mitbeteiligt war, gab es dafür u.a. auch verschiedene Artikel-Nummern (1x für den Händler/Dienstleister, 1x für den Lieferanten/Hersteller) ... in diesem Sinne also ...
Sei also so gut, und mach' dafür selber mal ein neues Thema auf - beste Grüße :)-D
JöLi.