ERD - Aufbau

Hallo allerseits

Ich bin ein blutiger Anfänger und habe mir sozusagen PostgreSQL eben geladen weil ich merke, dass sich mein Vorhaben mit Filemaker nicht umsetzen lässt. Ich möchte Postgres verwenden und voraussichtlich Servoy. Meine Frage bezieht sich aber weniger auf PostgreSQL sondern grundsätzlich auf das DB Modell.

Ich plane Rechnungsnummerneinträge zu generieren (es sollte also später eine Auftragsverwaltung draus werden).

Momentan gliedern sich Rechnungen bei uns folgendermassen:

700000 ff
für Geschäftsbereich 1

und

720000 ff
für Geschäftsbereich 2

Evtl. wäre es wohl intelligent das Jahr z.B. “07” noch vorne anzufügen wenn man schon auf eine DB umstellen möchte und eine Filialnummer ans Jahr anschliessen.

Im Moment bestehen unterschiedliche Nummernbereiche um die Filialen besser unterscheiden zu können (Eine andere hat 500000 und 520000).

Also grundsätzlich sieht es so aus… 3 Filialen à 2 Geschäftsbereiche mit eigenen Nummernbereichen. Wie baut man sowas jetzt am besten auf? Ich nehme fast mal an man bräuchte wohl sowas wie eine Verwaltungstabelle. Aber mir erschliesst sich nicht wie ich das anstellen könnte.

Vielleicht hat ja auch jemand einen guten Link auf ERD Tutorials, obwohl die sich meist auch eher auf sehr grundsätzliche Konzepte erschöpfen und nicht so stark ins Detail gehen.

Ich sehe nix, exakt gar nix, was das mit PostgreSQL zu tun haben könnte.

Andreas.

Eigentlich hat akretschmer Recht, das dies kein Datenbankspezifisches Problem ist. Du kannst keine Mittel der Datenbank verwenden, um die Vollständigkeit deiner Rechnungsnummern sicherzustellen.

Allerdings könnten dir verschiedene Ansätze weiterhelfen:

  • einfacher Ansatz: Tabelle locken, höchste passende ID/Rechnungsnummer suchen, eins erhöhen, Eintrag schreiben, Tabelle freigeben

  • etwas großzügigerer Ansatz: Rechnungsnummern in einer extra Tabelle hinterlegen und von dort die nächste passende abrufen.

  • aufgetrennter Ansatz: jede Filiale fängt bei 1 an zu zählen, die Filialnummern oder was du sonst unterscheidest, werden an einer anderen Stelle mitgeführt und nur bei der Ausgabe davor gesetzt.

Wie genau du das nun löst, bleibt deiner Implementierung überlassen. Grundsätzlich sei jedoch gesagt, das dir die verschiedenen Rechnungsnummern irgendwann Probleme in der Datenbank bereiten dürften.

Tja, aber trotzdem muss ich sie ja in der Datenbank abspeichern.

Den letzten übergeordneten Ansatz werde ich sicher verfolgen. Also brauche ich bei dem grosszügigeren Ansatz für jeden Geschäftsbereich pro Filiale eine Tabelle? D.H. 2 Tabellen pro Filiale?

Kannst du näher darauf eingehen? Wie machen es andere?

Ja, musst du. Bzw. sollte in der DB irgendwo eine Referenz liegen.


Dein erstes Problem ist, das du lückenlose fortlaufende Rechnungsnummern für das Finanzamt liefern musst. Das zweite, das du hast, ist die Belegbarkeit deiner Rechnungen. Es genügt eigentlich nicht, das du nur die Daten der Rechnung irgendwo speicherst. Wenn du diese zu einem Zeitpunkt X irgendwann einmal generiert hast, musst du diese dann auch in Kopie vorhalten, sonst kannst du später nicht nachweisen, das du genau so eine Rechnung verschickt hast.

Das erste Problem lässt sich noch mit einem der Verfahren lösen, die ich weiter vorn beschrieben hatte. Für das zweite Problem brauchst du ein Verfahren, das revisionssicher ausgelegt ist.

So ein Problem löst man eigentlich nicht aus dem Stehgreif sondern das wird passend für und um eure Probleme modelliert. Aber das geht auch nur, wenn man viel mehr um das drumherum bei euch weiss. Also wie z.B. Rechnungen erstellt werden, wer das wie alles erstellen kann ect.

Dies könnte man z.B. so lösen, daß man ein PDF generiert und dieses druckt&speichert.

Andreas

Japp, aber je nachdem, wer wo Rechnungen generiert, müssten die PDFs dort generiert und dann trotzdem zentral irgendwo abgelegt werden …
Wenn das verschiedene Filialen sind, braucht man dann halt auch ein Verfahren, die Dateien zentral einzusammeln.

Sage ja, so etwas muss man zuschneidern :wink:

Hallo aguafiestas,

da das Finanzamt seit dem 1.4.2004 sehr streng bei den Pflichtangaben in einer Rechnung ist, solltest Du dich mit der aktuellen Steuergesetzgebung beschäftigen oder einen Fachmann hinzuziehen. Bei unvollständiger oder ungenauen Angaben hat dies weitreichende Konsequenzen bezüglich des Vorsteuerabzugs beim Rechnungsempfänger. Die Rechnunsnummer muß eine fortlaufende Nummer sein. Bei einer Steuerprüfung überprüft das Finanzamt auch den kontinuierlichen Verlauf der Rechnungsnummer. Um Probleme mit dem Finanzamt zu vermeiden sollte es daher auch einen Nachweis über fehlende Rechnungsnummer im kontinuierlichen Verlauf geben.



mfg

fristo

Es bleibt alles in einer zentralen Datenbank, die Betriebe greifen darauf zu. Die Rechnungen sollten aus einer Offerte generiert werden können. Aber ich stelle mir das schon als wiederkehrendes Problem in Datenbanken vor. Gibt es keine Tutorials wie man sowas Gesetzeskonform umsetzt? Wahrscheinlich würde es sogar dann noch Probleme machen bei Mutationen.

Digital reicht neu, zumindest hier in der Schweiz. Bei uns gibt es aber zusätzlich sowieso auch noch einen Ausdruck, der in die Buchhaltung kommt.

Ok, die Schweizer Gesetzeslage kenne ich nicht, ich bin von den bürokratischen Deutschen ausgegangen. Keine Ahnung, ob ihr es da besser oder schlimmer habt :slight_smile:

Es kann schon darum kein Standard-Howto geben, weil die Lage in jeder Firma anders ist. Also muss man entweder Software nehmen und die Firma darum modellieren (SAP macht das wohl so g) oder man schreibt die Software um die Firma herum und passt sie entsprechend an.

Sag Bescheid, wenn man euch dabei konkret helfen kann.