Von Tabelle2 "summe" in Tabelle1 "summe" abziehen

[Andi_Aston_Martin]

Hi, mal eine frage: möchte von 2 Tabellen die die gleichen Spalten " Menge " haben die Summe abziehen. Sprich von Tabelle 2 die " Menge " von Tabelle1 " Menge " abziehen ohne eine neue Spalte hinzufügen zu müssen. Wie geht das ?? . Gruß Andi

 

[andyfau]

Hallo,
deine Frage zeigt, dass Du eher in "Excel" denkst, als in "Access". Access ist eine Datenbank bei der es nicht um "Spalten" von Tabellen, sondern um Datensätze geht. Diese werden in Tabellen abgelegt und so miteinander in Beziehung gesetzt, dass Redundanzen vermieden werden (Stichwort: Normalform). Wenn Du so möchtest, wird also eher "zeilenweise" und in Feldern gedacht. D.h. Du musst zuerst sicherstellen, dass die beiden Tabellen synchron behandelt werden können. Dies geschieht i.d.R. durch ein Schlüsselfeld in Tabelle1 und den korrespondierenden Fremdschlüssel in Tabelle2. Duch eine solche Beziehung der Tabellen zueinander lassen sich dann entsprechende Auswahlabfragen mit den relevanten Feldern erstellen. In einer solchen Abfrage kannst Du dann sehr einfach z.B. die Differenz zwischen zwei Feldern ermitteln.
Um Dich näher mit Access vertraut zu machen empfehle ich www.access-tutorial.de . Dort ist absolutes Grundwissen kompakt und einfach leicht zu lernen.
Beste Grüße
Andreas

 

[ukulele]

Der Wert in der Spalte Menge bezieht sich auf den Datensatz. Wenn du zwei Tabellen hast in der die Datensätze zusammen gehören, dann ist das ganz einfach, wenn man die Datensätze joint. Allerdings redest du dann noch von Summen, Summen sind Aggregate aller Datensätze. Wir können nicht wirklich erraten, was du von was abziehen willst, ob wirklich ein Aggregat gebildet werden soll. Vielleicht gibst du mal ein konkreteres Beispiel mit einem oder mehreren Datensätzen in beiden Tabellen.

 

[Andi_Aston_Martin]

Hi ukulele,
hast recht das mit der Summe war falsch definiert von mir.
Es geht im Prinzip darum die Bestell-Menge pro Teil des Kunden vom Lagerbestand abzuziehen.
Sprich, die Bestell-Menge " Kunde wünscht 10 Stück " gebe ich in der Tabelle "KDBestellungen", Spalte "Menge" ein.
Nun würde ich gerne das mir die Bestell-Menge vom Lagerbestand Tabelle "AstonMartinTeile", Spalte "Menge" abgezogen wird.
Lagerbestand "60" Stück minus Bestell-Menge "10" Stück = 50 Stück.
Beide Tabellen haben eine eindeutige Teile ID "OSPNNR" und stehen in Beziehung "1:n".

Gruß Andi

 

[andyfau]

Hallo Andi,

mit deiner Vorgehensweise erzeugst Du dann ein Problem, was Dir früher oder später wieder vor die Füße fällt. Früher, als die Rechner noch nicht so schnell und die Datenbanken noch nicht so leistungsfähig waren, wurden Lagerbestände bei der Verarbeitung von Bewegungsdaten "mit kontiert" und dann im Artikelstammsatz (ganz schlecht) oder einem Lagerortsegment abgelegt. Das erfordert dann aber bei jedem Zu oder Abgang, das man den Bestandssatz mit anfasst. Besser ist es einfach Bewegungssätze zu erzeugen und nur diese in eine Tabelle "Bewegungen" zu schreiben. Das verhindert Inkonsistenzen in den Daten. Ein Bestand lässt sich dann leicht immer dynamisch über entsprechende (Summen)Abfragen, die von Ukulele angesprochenen Aggregate, ermitteln.

Gruß
Andreas

 

[ukulele]

Vereinfacht betrachtet hast du

SELECT AstonMartinTeile.OSPNNR,
AstonMartinTeile.Menge - isnull(sum(KDBestellungen.Menge),0) AS Bestand
FROM AstonMartinTeile
LEFT JOIN KDBestellungen
ON AstonMartinTeile.OSPNNR = KDBestellungen.OSPNNR
GROUP BY AstonMartinTeile.OSPNNR,AstonMartinTeile.Menge

Du joinst, bildest ein Aggregat von den Bestellungen und ziehst das vom Bestand ab. Aber ganz ehrlich gefällt mir das auch nicht. Du wirst Probleme bekommen weil der Ansatz einfach zu kurz gedacht wurde.

1) Du verwendest Access. Entweder, dein Durchsatz von Artikeln ist überschaubar, dann kann man es fast schon mit Excel führen. Oder dein System wird früher oder Später nicht skalieren - Access ist im Prinzip eine Einzelplatzlösung und auch kein echtes DBMS. Ich weiß nicht, wie fortgeschritten oder alt deine Lösung ist aber ich bin allgemein erstmal skeptisch, was die Verwendung von Access angeht. Das klingt so nach einem Schulprojekt, das kann man machen. Aber für ein System, was man produktiv nutzen will oder bereits nutzt, sollte man sich das gut überlegen.

2) Der Tabellenname AstonMartinTeile verrät mir, das dein Datenmodell Grütze ist. Eine Teile-Tabelle macht Sinn, eine Teile-Tabelle pro Hersteller ist immer Quatsch.

3) Eine Teile-Tabelle sollte eher keine Mengen-Spalte haben. Teile und ihr Bestand sind zwei unterschiedliche Dinge. Ob man den Bestand jetzt in einer Bestandstabelle führt oder nur Zu- und Abgänge transaktionsbasiert betrachtet ist sicherlich ein wenig Geschmackssache. Wenn du aber einen Bestand in einer Tabelle führst, dann kannst du nicht Abgänge transaktionsbasiert abziehen. Dann muss dieser Wert ja irgendwann neu gesetzt werden, im Idealfall sofort wenn eine Bestellung ausgeführt wurde, also der Bestand kleiner geworden ist. Du vermischt zwei sehr grundlegende Prinzipien, das kann eigentlich nicht gut gehen.

4) Nur Transaktionen zu betrachten ist erstmal gedanklich charmant aber an irgendeinem Punkt muss man Transaktionen auch in "feste" Informationen umwandeln um nicht jedes Mal alle historischen Transaktionen zu aggregieren. Ab einer gewissen Menge an Daten (sicherlich sehr vielen Daten) bremst das das System aus.

5) In der Realität wirst du auch andere Bestandsveränderungen haben als (ausgeführte) Bestellungen, also z.B. Rückläufer, beschädigte Artikel, falsche Liefermengen, Diebstahl oder Abweichungen in der Inventur.

6) KDBestellungen sollten auch keine Menge enthalten. Bestellungen sollten mehrere Positionen verschiedener Artikel umfassen können, und die Positionstabelle sollte die Bestellmenge enthalten.

 

[andyfau]

Ich würde vorschlagen Andi gibt mal ein etwas ausführlicheres Mengengerüst und beantwortet die Frage ob es sich um ein Schulprojekt, eine kleine Einzelplatzlösung oder die Bestandsführung für den Otto-Versand handelt.

Für die beiden ersten Varianten ist Access ein wunderbares Tool, was Millionen von Anwendungen und Installationen zeigen.
Für Nutzerzahlen im einstelligen Bereich ist mit einer Aufteilung in Frontend und Backend auch eine prktikable Lösung machbar, ohne dass man Informatik studiert haben muss.
Und wenn es dann wirklich größer sein muss, ist die Migration auf eine SQL-DB im Netzwerk auch kein Hexenwerk, wobei die Nutzer erstmal weiter auf ihrem gewohnten Frontend arbeiten können.
Einzig als reine Webanwendung und wenn Hochskalierbarkeit gefordert ist, ist Access ein Krampf, bzw. kein Thema.
Es bleiben also die oben gestellten Fragen, was man eigentlich benötigt, was der, ich will ihn mal Entwickler nennen, selbst in der Lage ist zu tun und wieviel Aufwand er in Lern- und Installationsaufwand stecken möchte. Nicht zuletzt was es kosten darf.

Da dies ein Access-Forum ist und kein Access-bloß-nicht!-Forum würde ich Andi gern im Rahmen seiner Möglichkeiten helfen.
Die oben genannte SQL-Anweisung funktioniert in Access tadellos, die richtige Tabellenstruktur vorausgesetzt.

Frage an @Andi_Aston_Martin:
Reicht das als Hilfestellung? Als Access- und/ oder Datenbankanfänger täte ich mich damit schwer, weil man bei Access nicht gerade mit dem Studium von SQL anfängt. Eher nutzt man doch die umfangreichen Hilfestellungen, die Access als Entwicklungsumgebung bietet.

Wir müssen also mehr als die Eingangsfrage wissen um zu helfen.

Viele Grüße
Andreas

 

[Andi_Aston_Martin]

Hi andyfau,
erstmal vielen Dank für deine Hilfsbereitschaft.
Folgendes:
Vor 4 Wochen verstarb unser Mitinhaber unserer Firma, er schrieb vor ca.30 Jahren das Lagerprogramm " leider aber was damals noch toll war in DOS "mit Angebot und Rechnungsstellung, läuft eigentlich noch gut ist aber nicht mehr Zeitnah.
Im Dos sind Tabellen enthalten die wir eigentlich nicht brauchen, vielleicht war es damals von Nöten.
Haben uns entschlossen ein neues zu schreiben was Anwenderfreundlicher ist.

Im DOS Programm läuft es momentan so ab:
1) Kunden auswählen "der zuerst ein Angebot erhalten soll was die Reparatur seines Aston Martin Kosten würde" .
2) Teile zusammen suchen die wir zur Reparatur brauchen " sind über 7.000 Teile die wir momentan in der Tabelle haben ".
3) Sind alle Teile gesammelt stellen wir dem Kunden ein Angebot zusammen " Export zu Word " die Teile dürfen in diesem Moment vom Lagerbestand
noch nicht abgezogen werden " .
4) Es kann sein das der Kunde nachdem er das Angebot erhalten hat sich entscheidet, ein Teil vom Angebot können wir auf später
verlegen.
5) Müssen nun das Angebot korrigieren und ihm ein neues zusenden.
6) Erst nach erhalt, Bestätigung des neuen Angebotes kommt es zur Rechnungserstellung.
7) Jetzt erst nach Rechnungserstellung " und Export zu Word " werden die Teile vom Lagerbestand abgezogen werden.
8) Angebot und Rechnung werden in Word Datei gespeichert.

Hoffe das dient zum besseren Verständnis
Gruß Andi

 

[andyfau]

Ok. Softwaretechnisch ist das Thema Softwarelösungen für Kfz-Werkstätten in allen Größen und Varianten viele Male gelöst und im Einsatz.
Natürlich kostet das Geld, ist aber für die Werkstatt dann sicher die einfachere Lösung, als sich etwas selbst zusammen zu stricken.
Unter folgendem Link werden ein paar gängige Programme verglichen: (Nur einmal gegoogelt, man findet sicher noch viel mehr.)
Die 10 besten Rechnungsprogramme für KFZ Werkstatt (2024)

Es gibt in Eurem Fall nur wenige Gründe etwas selbst zu bauen:

-Ich habe so besondere Anforderungen, dass ich sie in keinem Standardprogramm wiederfinde. (Das sehe ich in Eurem Fall nicht.)
-Ich möchte kein oder nur wenig Geld für eine Lösung ausgeben. (Wenn man Deinen Stundenlohn dagegen hält, ist das in Summe am Ende sicher viel teuerer, als die meisten Standardlösungen. )
-Ich möchte mich intensiv mit einer selbst gebauten Lösung auseinandersetzen, weil mich das Thema Datenbank und Anwendungsentwicklung sehr interessiert, ich dafür (viel) Zeit habe und so nur das baue, was ich wirklich selbst brauche. (Standards erscheinen zuerst umfangreich und kompliziert, sind aber in der Regel ausgereift und benutzerfreundlich und sie haben Funktionen, an die Du jetzt noch nicht gedacht hast, die Du später aber villeicht benötigst. Gesetzliche Änderungen etc. werden zumeist in Updates geliefert.)

Wenn Du also nun immer noch der Meinung bist es selbst zu machen, dann fang an!
Befasse dich ausführlich mit Access als Tool (siehe Link weiter oben).
Erstelle Dir ein Lastenheft das die Funktionen und Arbeitsabläufe, die Du benötigst, möglichst genau beschreibt. (Der Anfang ist ja mit der ersten Beschreibung schon gemacht)
Erstelle ein vernünftiges Datenmodell. Definiere also die notwendigen Tabellen und ihre Beziehungen zueinander. (Stichworte: Normalisierung, Redundanzen vermeiden)
Wenn Du soweit bist kannst Du es gern mal hier zeigen/hochladen. (In Access im Beziehungsfenster ganz gut nachvollziebar)

Wenn das Backend steht kann es ans Frontend gehen. (Eingabe- und Anzeigemasken(In Access Formulare genannt), sowie Ausdrucke (Angebot, Auftrag, Rechnung)(Berichte genannt).

Die eigentlichen, benötigten Funktionen sind meistens recht schnell gebaut. Zu Bedenken ist aber, dass, wenn auch andere Mitarbeiter "Dein Werk" benutzen sollen, meistens der Aufwand stark steigt die Anwendung benutzerfreundlich und sicher in der Verarbeitung zu machen.

Viel Grüße
Andreas

 

[ukulele]

Also wer Spaß dran hat kann an so einer Software "schrauben", wer es nur aus Kostengründen macht tut sich vermutlich keinen Gefallen.

In dem Zusammenhang würde ich noch auf die geplante E-Rechnung verweisen. Ab 01.01.2027 müssen Rechnungen an Unternehmer dem E-Rechnungsstandard entsprechen. Du musst dann entweder ZUGFeRD-PDFs mit XML Datensatz oder nur XML-Datensätze nach X-Rechnung-Standard ausgeben können und archivieren können. Ist nicht wild aber einfach nur drucken und abheften ist halt nicht mehr.

 

[andyfau]

Wenn er sich bis Anfang 2027 intensiv mit der Materie auseinander setzt wird das sicher kein Problem sein. ;-)
Es wird dann auch für Access Module geben, die sich einfach anflanschen lassen. XML ist ja schließlich auch nur eine Textdatei, die man ausgeben muss. Die Ausgabe eines Reports als PDF ist auch nur ein Befehl. Man muss halt nur wissen, was draufstehen muß.

 

[Andi_Aston_Martin]

Hi ukulele und andyfau,

verstehe eure bedenken irgendwie schon, keine frage aber es besteht keine Eile oder alles auf schnell schnell zu machen.
wie gesagt das DOS läuft einwandfrei und wir haben nie Drucken und Abheften gemacht sondern alles immer in Datei gespeichert
und können es in fast jedes Format speichern u. umwandeln, es gibt ja soviel Möglichkeiten heut zu tage.
Wir wollen einfach das Programm schlanker und einfacher machen da wir einige Datensätze " sprich in einer Tabelle sind 20 Datensätze, Spalten
vorhanden auf die hälfte kürzen wollen " nicht mehr benötigen die vielleicht vor 20-30 Jahren nötig waren.
Alle alten Datensätze die wir nicht mehr brauchen bleiben natürlich vorhanden im Archiv .
Da wir, durch das unverhoffte Ableben des Mitinhaber und Programmierer keinen eingriff in dieses Dos Programm haben um eventuell Änderungen vorzunehmen die mal anstehen würden haben wir uns zu diesen schritt entschieden.

ukulele,

habe dein :

SELECT AstonMartinTeile.OSPNNR,
AstonMartinTeile.Menge - isnull(sum(KDBestellungen.Menge),0) AS Bestand
FROM AstonMartinTeile
LEFT JOIN KDBestellungen
ON AstonMartinTeile.OSPNNR = KDBestellungen.OSPNNR
GROUP BY AstonMartinTeile.OSPNNR,AstonMartinTeile.Menge

versucht, leider kam immer Fehlermeldung :

"Falsche Anzahl an Argumenten für Funktion angegeben in Abfrageausdruck AstonMartinTeile.Menge : isnull(sum(KDBestellungen.Menge),0)"

weiß noch nicht wo der Fehler liegt, bin noch am suchen.

Gruß Andi

 

[andyfau]

Die Funktion isnull(....) funktioniert in Access so nicht.

Ändere die Zeile in:

AstonMartinTeile.Menge - nz(sum(KDBestellungen.Menge),0) AS Bestand

Beste Grüße
Andreas

 

[ukulele]

Ja sry ich nehme MSSQL, das ist in vielen Dingen ähnlich aber bei isnull() scheinbar nicht. Versteht auch keiner ;-)

 

[andyfau]

SQL-Dialekte halt. Die isnull-Funktion gibt es in Access/VBA natürlich auch. Sie prüft auf NULL gibt aber keinen Ersatzwert aus, wie Nz.
Schönes Wochenende.