Neu Entity Relationship Model für Abfragen und Änderungsabfragen

[sebo-gmbh]

Ich denke, dass die Darstellung der Datenbank als ERM (Entity Relationship Model) sinnvoll wäre für eine eigene Vorbereitung von Abfragen und Änderungsabfragen. Die Doku (https://wawi-db.jtl-software.de/ ) lässt sich nicht so durchsuchen, um durch die Suche nach einer Feldbezeichnung beispielsweise in Erfahrung zu bringen in welcher Tabellenspalte welcher Tabelle der Verkaufspreis (VK) für einen Artikel steht oder in welcher Tabellenspalte die Namen (Name) der Kunden stehen. Wie gehen andere User eigene Abfragen und Änderungsabfragen betreffend vor? Man braucht für eine SQL-Abfrage schon mal den Tabellennamen und den Feldbezeichner. GGf. Dank für einen Austausch (siehe Umfrage) oder Fachdiskussion, wie wer was wo in der Datenbank abfragt, der nicht selbst bisher die Datenbank entwickelt hat. DL

 

[zwitsch]

Trial and Error bis es passt. Aber keine Aktualisierungen über diesen Weg, sondern nur Abfragen.

Aktualisierungen erfolgen immer über die Ameise. Lässt sich auch in eigene Programme einbauen mit Aufruf über verschiedene Parameter.

 

[Mitarbeiter]

Guten Tag!

Ich suche beispielsweise in der Datenbank die Tabelle mit dem oder den Feldern für die Abfrage von einem Deckungsbeitrag oder die Stored Procedure (https://wawi-db.jtl-software.de/)

Das ganze sollte sich beispielsweise so zusammensetzen, siehe https://ebakery.de/renner-und-penner-mit-jtl-wawi-1-0/

Jetzt möchte ich mit einem SQL-Query (einer Abfrage mit SQL) gerne mit einer Drittanbieter-Anwendung (beispielsweise Microsoft Office etc.) genau diese beiden Felder auslesen und darstellen.

In welcher Tabelle und welcher Spalte finde ich beispielsweise das Feld "GW-Netto", oder bin ich hier zu "old-school" oder der "DAU" (Dümmerster anzunehmender User), wenn ich dann wieder daran denke das aus einem Entity-Relationship-Modell (als Dokumentation) so etwas eigentlich problemlos abzulesen bzw. herauszufinden seien sollte?!

Ggf. Dank

DL

 

[marcelj]

Hallo,

Sinn der Deckungsbeitragsrechnung als Stückrechnung ist die Ermittlung des Selbstkostenpreis. Das ist niedrigste Preis, zu dem ein Produkt verkauft werden sollte. Die Formel dafür ist simpel:
Umsatzerlöse – variable Kosten = Bruttoerfolg = Deckungsbeitrag

In JTL-Wawi heißt diese Spalte GW-Netto in der Listenansicht der Produktverwaltung und hier wird die Differenz zwischen Verkaufspreis Netto und Ø-Einkaufspreis Netto angezeigt.

Auf den Ersten Blick konnte ich kein Attribut "GW-Netto" in der DB finden, jedoch wenn die obige Info korrekt ist, dann brauchst du nur aus tArtikel die Attribute fVKNetto und fEKNetto von einander abziehen.

Im Allgemeinen ist es hilfreich zu überlegen zu welcher Entität wohl ein gesuchtes Attribut gehört und dann dementsprechend im SQL Server Browser in Frage kommende Tabellen durchsehen.

Disclaimer: Von Kostenrechnung habe ich nicht allzu viel Ahnung.
Die Berechnung ist meiner Ansicht nach nicht vollständig. Es werden hier z.B. keine Gemeinkosten in die Selbstkosten eingerechnet. Da wir aber Ausgaben für WaWi Hosting, etvl Gebühren für eazyAuction, gebühren für Ebay Account usw. haben, werden hier relevante Kosten nicht berücksichtigt. Brutto-VK abhängige "Kosten" wie z.B. 9 % Provision zu zahlen an Ebay auf den Brutto VK eines Artikels schlägt sich auch ganz schön nieder.

 

[Mitarbeiter]

Danke, soweit ist das: Das man aus der Tabelle tArtikel die Attribute fVKNetto und fEKNetto abfragt (SQL SELECT STATEMENT beispielsweise SELECT fEKNetto FROM tArtikel) und dann in Microsoft Office (also beispielsweise Excel) oder Microsoft Power-BI manuell voneinander abziehe um den Stückdeckungsbeitrag zu ermitteln.

Zum "Haftungsausschluss", vollkommen richtig: Die Kostenarten Gemeinkosten und VVK (Verwaltungs- und Vertriebskosten) werden bei einer Kostenträger-Auswertung (beispielsweise Produkten) außen vor gelassen: Es handelt sich nicht um Deckungsbeiträge1, Deckungsbeiträge2 und Deckungsbeiträge3 sondern um Stückdeckungsbeiträge gemäß folgender betriebswirtschaftlichen Definition: Stückerlös - Stückkosten = Stückdeckungsbeitrag.

Zitat: "Im Allgemeinen ist es hilfreich zu überlegen zu welcher Entität wohl ein gesuchtes Attribut gehört und dann dementsprechend im SQL Server Browser in Frage kommende Tabellen durchsehen."

Ich finde, wenn ein ERM dokumentiert wäre, siehe ERM-Notation, dann müsste ich nicht überlegen in welcher Entität ein gesuchtes Attribut gehören sollte, sondern könnte das "auf einen Blick" ablesen, wenn das ERM nicht entsprechend umfangreich wäre. Danke.

DL