An und Verkauf Programm

  • Hallo ihr Lieben.

    Ich habe eine frage ,wie erstelle ich eine Datenbank für mein Programm das beim Ankauf in die Datenbank Schreibt und Später abgerufen werden kann beim Verkauf usw.

    Gerne bin ich bereit was zu bezahlen wenn wir es einer soweit Fertigstellen kann. Bitte PN wenn es mir einer gegen Bezahlung Schreibt.

    Mit freundlichen Grüßen

    Roberto.

    Vielen Lieben dank ich freue mich auf eure antworten.

    Hier mein Code

    4 Mal editiert, zuletzt von heyhey83 (21. Juni 2022 um 19:08)

  • Du meinst eine Art Lizenzprüfung?

    Falls ja, dann schaue Dir mal XProtec an.

  • Nein sowas meine ich nicht. Also ich meine das so, wenn ich ein Kühlschrank Ankaufe möchte ich das die Daten gespeichert werden und ich die daten Später im Reiter (Artikel Datenbank) Abrufen kann in einer Liste und beim Anklicken Bearbeiten - Löschen kann usw.


    LG

    Roberto

  • Solange du nicht Unmengen von Artikeln handelst, würde ich die einfachste Lösung wählen: Excel.

    Eine Tabelle mit Ankauf, eine mit Verkauf. Mit VBA eine minimale Oberfläche erstellen zum Daten Erfassen und Verschieben bei Verkauf.

    Ist funktionell und übersichtlich.

    Ansonsten gibt es sogar für Kleinstunternehmen Freeware Produkte für eine minimalistische Warenwirtschaft, die all das beinhaltet.

    EDIT: z.B. gratis bis 5000 Belege pro Kalenderjahr: Vario

  • Hallo BugFix danke für deine Antwort. Aber mit SQL also einer DLL würde es doch auch gehen. Wir haben sehr viele Artikel und da bringt uns Excel nicht viel.

    Die Freeware ist nicht das was wir gerne hätten, deswegen bin ich hier auf der suche für mein Problem.


    LG

    Roberto

  • Nein da greift nur ein User zu und das ist der Chef ;) . Also wenn ich beim Ankauf des Artikels ,die Artikel Bezeichnung so wie den Name und Vorname von der Person von den ich als Händler kaufe Speichere sollte die Datensätze später in der Artikel Datenbank abrufbar sein und auch änderbar sein usw. Des weiteren sollte es ein Dokument erstellen was man dann ausdrucken kann beim Ankauf und Verkauf. Ach ja und beim Speichern des Artikels sollte auch ein EAN oder QR Code Generiert werden denn man gesondert Ausdrucken kann mit der Artikelbeschreibung und den Verkaufspreis usw.

    LG

    Roberto

  • OK, das wäre dann schon eine kleine Warenwirtschaft, die auf SQLite aufsetzt.

    Das zu Programmieren ist recht umfangreich. QR-Code Generator existiert als UDF von mir, könnte man also integrieren.

    Das ist alles nicht schwer umzusetzen und auch kein Hexenwerk, aber eine Menge Arbeit. Da brauchst du jemanden mit ausreichend Zeit.

    Für mich zur Zeit nicht drin.

  • Hallo Roberto,

    wie BugFix schon schrieb ist das alles viel Arbeit, aber machbar.

    Was du brauchst ist eine Datenbank, die Installiert und mit den Daten befüllt werden muss.

    Dies könnte eine SQL Lite, MySQL/ MariaDB, Microsoft SQL oder Microsoft Access sein. Dafür gibt es zumindest bei AutoIT einige Beispiele.

    Ich selbst habe im Unternehmen Access und MySQL in verschiedenen Projekten im Einsatz.

    Gruß gmmg

  • Hab das gerade eben zufällig gesehen und würde vorschlagen, das Thema vor Beginn der Umsetzung gut zu überdenken.

    Nicht nur, dass eine Wawi, selbst eine kleine, nicht innerhalb weniger Monate programmiert ist und eine Eigenentwicklung ergibt angesichts der bereits verfügbaren freien oder niedrigpreisigen Produkte am Markt auch keinerlei geschäftlichen Sinn ergibt, es handelt sich um eine Software, die im Rahmen einer Geschäftstätigkeit eingesetzt wird. Dadurch ergeben sich automatisch weitreichende Verpflichtungen, die erfüllt werden wollen, wenn bei der nächsten Betriebsprüfung oder Kassennachschau keine fünfstelligen Strafzahlungen an das Finanzamt anfallen sollen (hinzu kommen zwangsweise noch weitere hohe Beträge, die sich durch Schätzungen aufgrund Möglichkeit zum Verwurf der Buchhaltung und Sicherheitsbehalte ergeben oder noch ein nettes Steuerstrafverfahren als Sahnehäubchen).

    Falls das Programm in Deutschland eingesetzt werden soll, sind mindestens die GoBD zu beachten. Dient das Programm auch zur Vereinnahmung von Bargeldzahlungen, handelt es sich um eine Kassenfunktion, was gem. § 146a Abs. 1 Satz 1 AO i.V.m. § 1 Satz 1 der KassSichV die Implementation einer gem. der technischen Richtlinie TR-03153 des BSI zertifizierten technischen Sicherheitseinrichtung, sowie der DSFinV-K nach sich zieht. Die ändert sich auch immer mal, gerade zum 01.07.2022 gab es wieder eine Anpassung. Die Belegausgabepflicht nach § 146a Abs. 2 AO muss natürlich mit allen erforderlichen Angaben ebenso umgesetzt werden.

    Hast Du, aus welchem Grund auch immer, nicht alles beachtet, stehen für Dich als Inverkehrbringer der Software gem. § 379 Abs. 1 Satz 6 AO (Steuergefährdung) Geldbußen bis zu € 25.000 im Raum. Wird das Ganze nach § 378 AO (Leichtfertige Steuerverkürzung) abgehandelt, sind wir bei bis zu € 50.000.

    In allen anderen deutschsprachigen Ländern oder Ländern mit deutschsprachigem Bevölkerungsanteil existieren ähnliche Regelungen. Ich glaube, lediglich die Schweiz ist da noch relativ entspannt. Allerdings muss auch hier durch technische Maßnahmen eine Manipulation der Daten ausgeschlossen sein.

    Erfahrene Softwarehäuser, die ausschließlich solche Branchensoftware entwickeln, haben Jahre gebraucht, um das alles haarklein und annähernd fehlerfrei umzusetzen und dabei literweise Blut, Schweiß und Tränen vergossen. Wenn hier also momentan schon der grundsätzliche Zugriffsweg auf eine Datenbank im Raum steht, würde ich – nix für ungut – empfehlen, den Hammer nicht nur sofort fallen zu lassen, sondern in einer alten Mine zu vergraben und alles mit Beton volllaufen zu lassen, denn die technische Umsetzung der reinen Programmfunktionen ist noch ziemlich banal im Verhältnis zur Erfüllung aller rechtlichen Anforderungen.

    Ich hatte mit dem Kram während dem abenteuerlichen Werdegang von der Gesetzgebung bis zur Realisation zu tun und auch heute ist das Thema noch mein Tagesgeschäft. Glaub mir, allein die enormen Kosten für Kopfschmerztabletten und Antipsychotika machen eine Eigenentwicklung aus dem Stegreif 100 % sinnlos.

    Also ganz im Ernst, nimm einen Fuffi in die Hand und spende den an Lexware oder lade Dir doch einfach die JTL-Wawi für lau runter, wenn es unbedingt kostenlos sein muss.

    Als nettes Softwareprojekt zum Herumbasteln würde ich mir irgendwas anderes suchen.

  • Moin zusammen.

    Ich habe die ersten Beiträge verfolgt und gemerkt, das ich da nicht helfen kann. Aber nun bin ich nochmal auf den Beitrag gegangen und ich habe den Beitrag von Dexter durchgelesen.

    Ich kann nur sagen, das Du da, was das Strafmaß betrifft noch locker geblieben bist. Deine Info hast Du aus der veröffentlichten Gesetzgebung (Gesetzestexte / -bücher), oder? Real gehe ich mal davon aus, das die § 379 Abs. 1 Satz 6 AO (Steuergefährdung) und § 378 AO (Leichtfertige Steuerverkürzung) schon mal zusammen legen werden. Dazu würden aber auch noch weitere Restverstöße vorliege. Alleine das wir jetzt hier das Ganze in Frage stellen, werde man ihn auslegen, das er wissentlich weiter gearbeitet hat. Nur solange die klagende Seite nichts von diesem Beitrag weiß, kann es nicht gegen ihn verwendet werden. Aber ehrlich? Da setzen die kurz mal einen Polizisten der IT Abt. an das Programm und der weiß sofort wo er weiter suchen muss. Jede Au3-2-Exe-Datei hat im Inneren einen klaren Hinweis.

    Und es geht hier ja auch nicht "nur" um Rechtsverstöße in Deutschland, sondern auch in anderen Ländern. Und die Schweizer sind da nicht zu unterschätzen. Die erlauben viel, aber die sind noch "blondiert". ;)

    Roberto? Ich kann Dir nur empfehlen, das ganze mit einem Anwalt für Steuerrecht zu besprechen. Kann sein das wir das alle falsch verstehen oder sonst etwas. Aber aus meiner Sicht ist eine anwaltliche Beratung zu Deinem Schutz (!) ratsam / sinnvoll

    Lieben Gruß,
    Alina

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Geheime Information: ;)
    OuBVU5ebLhHu5QvlnAyQB4A7SzBrvWulwL7RLl2BdH5tI6sIYspeMKeXMSXl

  • Hallo!

    Dexter: Ich bin zwar aus Österreich aber ich denke die gesätzlichen Vorgaben sind sehr ähnlich. Allerdings, solange Du keine Verrechnung machst ist es egal mit welchen Programm Du Deine Waren verwaltest. Nur die Rechnungsstellung muss mit einen Programm gemacht werden das (in Ö) beim Finanzamt gelistet ist. Auch ich habe das Kassenbuch (in Autoit geschrieben) von meiner Frau und die Registierungskassa (gekaufte Software) getrennt. Das ist kein Problem, außer in D sind die Gesätze strenger!

    Aber ich gebe Dir schon recht, hier ein bisschen Geld zu investieren ist sicher der bessere Weg um nicht in Teufels(Finanzamt)-Küche zu kommen.

    lg

    Racer

  • Ich kann nur sagen, das Du da, was das Strafmaß betrifft noch locker geblieben bist. Deine Info hast Du aus der veröffentlichten Gesetzgebung (Gesetzestexte / -bücher), oder? Real gehe ich mal davon aus, das die § 379 Abs. 1 Satz 6 AO (Steuergefährdung) und § 378 AO (Leichtfertige Steuerverkürzung) schon mal zusammen legen werden.

    Hallo Alina!

    Genau, das kann man momentan lediglich der veröffentlichten Gesetzgebung entnehmen, da noch keine Erfahrungen aus der Rechtsprechung vorliegen. Das ist auch ein großes Problem bei der Umsetzung der DSFinV-K, denn vieles ist schwammig definiert und damit Auslegungssache. Da muss dann der Hersteller der Software entscheiden, ob er konservativ vorgeht oder gewisse Risiken eingeht. Ob die Prüfer der Auslegung folgen, steht in den Sternen. Genau wissen wird man das erst, wenn sich Erfahrungen aus der Bewertung bei Prüfungen vor Ort ergeben. Aber wie Du richtig sagst, wird man da eher geneigt sein, bei erkannten Verstößen großzügig einzuschenken. Deswegen rate ich eher zu einem konservativen Ansatz.

  • Dexter: Ich bin zwar aus Österreich aber ich denke die gesätzlichen Vorgaben sind sehr ähnlich. Allerdings, solange Du keine Verrechnung machst ist es egal mit welchen Programm Du Deine Waren verwaltest. Nur die Rechnungsstellung muss mit einen Programm gemacht werden das (in Ö) beim Finanzamt gelistet ist. Auch ich habe das Kassenbuch (in Autoit geschrieben) von meiner Frau und die Registierungskassa (gekaufte Software) getrennt. Das ist kein Problem, außer in D sind die Gesätze strenger!

    Generell ähneln sich viele Bereiche der Gesetzgebung in Deutschland und Österreich, das ist richtig. Was die Kassengesetzgebung angeht, handelt es sich allerdings um eine recht neue Entwicklung, und die ging verschiedene Wege. Bei Dir gilt statt der KassenSichV die RKSV. Da passt im Prinzip die komplette Umsetzung mit in den Gesetzestext. Bei uns hat alleine die DSFinV-K 122 Seiten (Stand März 2022).

    Wie so oft war die Umsetzung in Österreich zielführend und pragmatisch. Das können wir nicht. Kassen an die RKSV anzupassen, war eine Sache von Monaten. Das hätte man in Deutschland übernehmen können. Ich bin mir sicher, dass Österreich das gerne in irgendeiner Form an uns lizensiert hätte, dazu hätten wir aber fragen müssen. Aber wir sind ja das größere Land, viel schlauer und können deswegen alles besser. Daher mussten wir das auch selbst machen und dabei das Rad wieder neu erfinden. Das Ergebnis sieht man an unseren Straßen und der Netzabdeckung bei Mobiltelefonen. Und an der Umsetzung der Kassensicherheit.

    Bei uns gibt es im ganzen Vorschriftenwesen kaum einen Bereich, der so abstrus und undurchschaubar ist wie die Kassengesetzgebung. Über Jahre und Jahrzehnte hinweg hat der Gesetzgeber einen Wust ineinander eingreifender Gesetze, Verordnungen, Richtlinien und Ausführungsbestimmungen mit so vielen Fristen, Ausnahmen und Übergangsregelungen erlassen, dass mittlerweile die meisten Steuerberater keinen Durchblick mehr haben. Nur eine generelle Kassenpflicht gibt es immer noch nicht. Man könnte wirklich ein Buch darüber schreiben.

    Als Schmankerl sollte nicht unerwähnt bleiben, dass die Inbetriebnahme oder Außerbetriebnahme von Kassensystemen bei uns per Gesetz seit dem 01.01.2020 innerhalb von vier Wochen dem zuständigen Finanzamt gemeldet werden muss. Dazu ist ein Online-Portal vorgesehen, das bis heute nicht existiert. 😶

    Aber zu Deinen persönlichen Umständen: Meinst Du mit „Verrechnung“ die Vereinnahmung von Barentgelten? Also ich kann mir gut vorstellen, dass auch in Österreich alles manipulationssicher gespeichert werden muss, was zur Buchhaltung gehört und letztlich im Erstellen von Rechnungen mündet, insbesondere Kassenbücher. Auch, wenn es nicht besonders zertifiziert oder gelistet sein muss. Eintragungen müssten dann wenigstens irgendwie serialisiert werden und Änderungen nur möglich sein, wenn sie im Nachgang einsehbar sind. Ich weiß zwar nicht, ob Ihr ein Analog zur GoBD habt, aber in westlichen Ländern ist das normalerweise Usus. Ob das mit AutoIT so umsetzbar ist?

    Zitat

    Aber ich gebe Dir schon recht, hier ein bisschen Geld zu investieren ist sicher der bessere Weg um nicht in Teufels(Finanzamt)-Küche zu kommen.

    Absolut; da gibt's gar keinen Grund, mit dem Feuer zu spielen.

  • Hallo,

    hmm. Ich könnte mir vorstellen, dass die Diskussion ein wenig aus dem Ruder läuft. Zum einen sehe ich in der Anforderung "lediglich" eine Lagerverwaltung, in der man den "Lieferanten" mit ablegt, um die Herkunft später dokumentiert zu haben. Der Ausdruck eines EAN oder QRCodes für einen, wie auch immer gearteten, Laufzettel sehe ich auch nicht als problematisch an. Da aus der Anwendung kein Verkauf erfolgt, ist es auch kein Kassenprogramm und damit fallen auch die rechtlichen Grundlagen weg, die hier erwähnt wurden. Natürlich muss der finale Verkauf über eine GoBD konforme Kasse erfolgen und die Bücher müssen entsprechend gepflegt sein, das ist keine Frage.

    Meine Empfehlung wäre einen internen Online Shop zu nutzen. WooCommerce zum Beispiel. Das kann man auf einem schlanken Rechner im Laden betreiben und sowohl Front-Desk Mitarbeiter als auch Chef können die ihren Berechtigung entsprechenden Änderungen und Eingaben durchführen. Zudem entfällt der Stress mit eigenem Datenbankmodell und die Abhängigkeit vom Windows Rechner am Front Desk. Und wenn der Chef im Urlaub vom Strand seinen Datenbestand pflegen will, dann könnte man das per VPN oder so auch ermöglichen.

    Ähnliche Systeme gibt es auch in kostenpflichtig (Open3A, Lexware, Buhl) und wenn man noch Support und Updates haben möchte, wäre das ganz sicher der Weg, den ich gehen würde.

    Aber ich denke nicht, dass wir hier mit Rechtsberatungen anfangen sollten. Das Projekt ist in AutoIt umsetzbar, aber sicher kein kleines Projekt. Hier wäre definitiv jemand mit Programmiererfahrung notwendig und vielleicht ist es dann schon fast besser, einen Entwickler freiberuflich zu beauftragen und das ganze in C# oder was auch immer zu entwickeln.

    Grüße