Hier möchte ich dafür plädieren, dass wir weg von diesem starren Schubladendenken hin zu wesentlich mehr Flexibilität kommen! Übrigens wie bei anderen Themenbereichen auch: z.B. beliebig viele Adressen zu einem Kunden / Lieferanten.

Was ich damit meine ist, dass wir nicht alles in starre Eingabefelder packen, sondern das Potential einer relationalen Datenbank auch nutzen sollten!
Sprich einmalige Werte (Artikelnummer, Bezeichnung usw.) gehören unmittelbar zum Produkt und können so abgelegt werden. Ein Produkt kann aber von mehreren Lieferanten (Kreditoren) und damit auch zu unterschiedlichen EK bezogen werden. Somit müsste eine Möglichkeit geschaffen werden, einem Produkt auch mehrere Lieferanten mit den jeweiligen Preisen zuordnen zu können.

Überdies setzt sich ein VK oftmals eben nicht nur aus EK und nur einem Zuschlag zusammen, sondern es können etwa weitere Bestandteile von Bedeutung sein... Beispielsweise: EK + Nebenkosten + Zuschlag.

Das wichtige dabei sind ja in erster Linie nicht die Eingabefelder welche der Benutzer zu Gesicht bekommt, sondern viel mehr die Datenbankstruktur im Hintergrund. Hier gilt es eben bereits vorab ein entsprechendes Grundgerüst aus Tabellen und ihren wechselseitigen Bezügen zu entwickeln um nicht erneut Inkonsistenzen zu Riskieren (siehe etwa Ticket #686).

Gruß
Matthew

Moin zusammen,
die Diskussion ist ganz nach meinem Geschmack 🙂 Großes Lob erst mal dafür.
Ich glaube, das Problem ist, die Software so zu gestalten, daß sie einen möglichst breiten Nutzerkreis bedient. SAP hat das ja schon versucht, und was dabei herausgekommen ist, kann man in größeren Unternehmen beobachten.
Natürlich kann man alles mögliche konfigurierbar machen, aber ich habe so bißchen die Befürchtung, daß wir das Programm dann überfrachten und der Otto Normalkleinunternehmer keinen Durchblick mehr hat. Es ist halt ein ziemlich breites Spektrum von Anwendern, das geht von Tischlern über eBay-Händler bis hin zu Physiotherapeuten. Jeder hat da unterschiedliche Anforderungen und Vorstellungen. Das ist irre kompliziert, aber sehr spannend 😉
Ich möchte, daß wir hier weiter diskutieren und werde mir mal Gedanken machen, wie man das alles unter einen Hut bekommt. Zunächst wird aber wohl das nächste Thema tatsächlich die Umstellung der Adressen sein. Mir gefällt der derzeitige Zustand da auch nicht, und ich glaube, wir sind da durch die anderen Diskussionen hier schon auf einem ganz guten Weg.

Nur als kleine Begriffs-Korrektur: Hersteller und Lieferanten sind keine "Debitoren", sondern "Kreditoren", weil sie ihre Lieferungen und Leistungen bis zu dem Zeitpunkt als "Kredite" abgeben, bis sie vom Bezieher auch vollständig bezahlt sind. "Debitoren" hingegen sind die Auftraggeber bzw. Kunden, die diese Lieferungen und Leistungen empfangen ... :)-D

Ansonsten bezieht sich das Thema "Artikelpreis-Kalkulation" ausschließlich auf Einzelartikel und -Leistungen. Das von LastBoyScout angeschnittene Thema zur Kalkulation von Artikel-Sets (o.ä.) befindet sich bei mir auch schon in Vorbereitung (bitte um etwas Geduld), und es wäre dann sinnvoller, die entsprechenden Vorschläge und Hinweise dann dort mit unterzubringen :)o

@rheydenr
Das ist natürlich die Schwierigkeit, einerseits ein möglichst breites Spektrum an Geschäftsvorfällen sicher abbilden zu können und dies andererseits möglichst einfach und intuitiv zu gestalten.
Fakturama sollte m.E. nicht anstreben ein Maßanzug für spezielle Branchen (z.B. den Onlinehandel) zu werden und das erstrebenswerte Ziel der Eierlegenden Wollmilchsau wird sich wohl nie vollständig erreichen lassen.
Stadtessen kann Faktuarama aber mit Sicherheit das dicke Schweizer Offiziersmesser in Sachen Faktura werden! Dieses Bild gefällt mir irgendwie, schließlich nutzt man da auch meist nur das Messer und den Flaschenöffner, ist aber gelegentlich sehr froh auch eine kleine Säge, Schere, Pinzette und der gleichen mehr verfügbar zu haben. B)

Bezogen auf das hiesige Thema würde dies bedeuten, dass man zwar mehrere Lieferanten mit unterschiedlich kalkulierten Preisen zu einem Artikel hinterlegen kann, es aber eben nicht zwingend muss. Und wenn man es nicht machen möchte, die entsprechenden Dialoge auch nicht durchlaufen braucht. Der Vorteil liegt ja schließlich darin, dass man von Null über Einem bis hin zu theoretisch unendlich vielen Bezügen alles abbilden kann. Zudem könnte künftig nicht nur der EK (inkl. Kalkulation), sondern auch die Bestandsführung in den relationalen teil verschoben werden: Artikel 1 = 5 Stück von Lieferant A, 2 Stück von Lieferant B und 10 Stück von Lieferant C.

@dr.listemann
Das war natürlich ein kleiner Fehler meinerseits (passiert halt wenn man den Text vor der Veröffentlichung nochmal umbaut), gemeint waren jedoch von Beginn an die Kreditoren... hab ja überwiegend auch den Begriff Lieferanten gebraucht.

Mein obiger Vorschlag bezieht sich ebenfalls auf Einzelartikel, nicht auf eine Gruppenkalkulation! Diese wären über entsprechende Relationen natürlich ebenfalls möglich... Ich denke Ralf hat es bereits Verstanden, möchte es aber gern nochmal Verdeutlichen:
Aktuell hat man eine Tabelle mit den Artikel in welche alle Artikeldaten abgelegt werden. Daneben gibt es eine Tabelle mit Kontakten in welchen neben den Kunden auch die Lieferanten liegen. Beide haben momentan keinen Bezug zueinander. Nun könnte man natürlich in der Tabelle für die Produkte weitere Spalten für Lieferant, Einkaufspreis, Kalkulation usw. einfügen. Nachteil: Man kann je Produkt nur einen Lieferanten abbilden. Besser wäre es eine dritte Tabelle zu erstellen, welche die wechselseitigen Bezüge zu den beiden ersten Tabellen herstellt und über dies die aus dieser Beziehung resultierenden Werte (Einkaufspreis, Kalkulation, Lagermenge usw.) enthält. So kann man zu einem Produkt mehrere Lieferanten mit den jeweiligen Preisen und bezogenen Mengen hinterlegen.

Gruß
Matthew

P.S.
Übrigens muss es nicht bei der Beziehung Produkt Kreditor bleiben... Damit wäre dann genauso gut auch Produkt Debitor möglich, wodurch jedem Kunden zu bestimmten Produkten eigene Preise hinterlegt werden können (Sonderpreisvereinbarungen).

Ebenfalls würde ich mir wünschen, dass die Kalkulation nicht nur für Bestandsartikel, sondern auch für manuelle Artikel möglich wird. Schließlich hat man ja auch bei Sonderanfertigungen einen Einkaufspreis (oder eben Rohstoffpreis), Nebenkosten und Zuschläge welche es zu Kalkulieren gilt. So müsste diese nicht mehr extern erfolgen und wäre in Fakturama mit dem Auftrag verknüpft / archiviert. Zu guter Letzt könnte man dadurch auch zu jedem Auftrag eine Gesamtkalkulation sehen und wüsste ob man noch im grünen Bereich ist.
Diese Kalkulation ist Lexware Financial Office übrigens seit langem bereits möglich.

Guten Morgen zusammen!

Ich möchte mich auch an diesem Thema beteiligen.
Es gibt verschiedene Ansätze der Kalkulation / Nachkalkulation.

Mal ist es notwendig die Preise am Markt auszurichten.
Bei anderen Produkten wie Arbeitswerten etc.. nicht.
Bei nicht bestandsgeführten Artikeln, wie Ersatzteilen, kalkuliere ich bei der Auftragserfassung.

Jede der 3 Arten kann anders kalkuliert werden.
Aus diesem Grund benutze ich schon lange die nicht benötigte MWST Steuerfunktion.
So kann ich im Artikelstamm mit den "Steuersätzen" kalkulieren.
Und bei Anlage von Aufträgen direkt im Auftrag einen Zuschlag auswählen.

Eine Zusatztabelle mit verschiedenen zuschlagssätzen die im Artikel und in der Erfassung auswählbar sind, wäre für mich
das optimum.

Ähnlich wie bei der Rabatt Auswahl....

Viele Grüße