Verbindlichkeiten

    Danke erst mal, ich habe die "klärende" Stelle in der Funktion erpAPI::MenuEintrag() gefunden. Da durchläuft der optionale Parameter mark einen Filter über verschiedene Sets möglicher Strukturen für den 1. Prameter link. Ich hatte durch C&P irgendwie zusätzlich "&smodule=verbindlichkeit" mit drin und darauf reagiert die Filterung mit einem Aussetzen der Automatik mark=1 zu setzen.

  • Alex

    Hat das Label Bestätigt hinzugefügt.

    Vielleicht guckt sich mal einer meinen letzten Experimentierstand an, ob dieser als Rumpf f. weitere Entwicklungen taugt. Leider bleibe ich immer in der class.yui hängen, wenn es zum Beispiel darum geht, javascript-Sequenzen so zu editieren und mit "firefox-Werkzeugen" zu debuggen.


    Persönliches Ziel f. die Verarbeitung v. Verbindlichkeiten besteht für mich darin, diese in einzelne Positionen aufzuteilen, die Kostenstellen zuordenbar sind, Dabei soll zum Beispiel der Gesamtbetrag per javascript rot werden, wenn die Summe der Positionen den Gesamtbetrag übersteigt usw. Deshalb der Versuch die Positionszeilen "editable", wie zum Beispiel in Aufträgen zu verwenden.

    Da sollten wir uns absprechen, ich bin gerade dabei für die Zahlungen ein Buchungsmodul zu schreiben. Allerdings ohne Kostenstellen. Was willst Du mit der Kostenstellenbuchung erreichen?


    Um Javascript mache ich immer wenn es geht einen Bogen und versuche möglichst viel mit HTML-Formularen abzudecken. Die dynamischen Editiertabellen sind allerdings schicker, das stimmt schon.


    Ich versuche das mal anzusehen. Ist das auf dem letzten OpenXE-Stand aufgesetzt? Ansonsten kann ich auch wirklich empfehlen mit Github zu arbeiten, da kannst Du dann z.B. einen Pull-Request erstellen und ich ziehe mir den dann...

    Mir fehlt leider aktuell ein zweiter Experimentier-Server und Zeit, mein "ausgelaufenes" Debian-Stretch zu erneuern. Deshalb ist es einfach aus dem "pages"-Verzeichnis meiner 20_1-OS-Version kopiert.


    Vielleicht mal gleich die Frage, hat man als Testumgebung eine Chance auf einem Laptop mit nur 2 echten Kernen und 2 "im Schatten"? Der wäre vorhanden.


    Kostenstellen-Zuordnung ist nur so eine private Aussicht von mir, die bei uns in der Überzahl vorkommenden Papier- u. Barzahlungs-Rechnungen auf der Kostenseiten dazurstellen ohne einzelne Artikel zu buchen, z.B. kommt jede Woche ein Rechnung des Blumenhändlers rein mit ab 30 Positionen aufwärts verschiedener Artikel. Die werden vereinfacht praktisch gegen die Warengruppentaste Schnittblumen unserer 0815-Registrierkasse gerechnet und so ist in etwa eine Darsellung d. "Material-Einkauf gegen Umsatz"-Verhältnises analog zur BWA in diesem Teilbereich möglich. Das ist aber Experimentierstatus!


    Ja klar! Sobald ein Rechner frei ist, natürlich github bzw. git.

    Musst Du mal ausprobieren, ich glaube wenn die Datenbank nur ein paar Testdaten enthält ist das System recht sparsam.


    Am Besten ziehst Du auf die neue OpenXE-Version um, ich glaube sonst bekomme ich Dein Modul nicht gut getestet.


    Könnte man die Kostensicht-Anforderung auch über Sachkontenbuchungen lösen? Das wäre mit dem neuen Modul bereits abgedeckt.

    Ja - klassisch macht man das wohl über Sachkonten. Das wurde für unsere "Mikro-Firma" seitens des Steuerbüros aber nie umgesetzt, weil es den realen Arbeitskraftstundenaufwand wohl gesprengt hätte(im Vergleich zum Nutzen). Aber das stimmt schon, Sachkonten reichen. Der Hintergrund lag, so glaube ich darin, dass Sachkonten generell verschieden sind, wenn sie sich im MwSt-Satz unterscheiden, wahrscheinlich damit automatisch eine Aufteilung in Nettowert und Steuerbetrag erfolgen kann. Die Logik, die hinter Kostenstellen steckt, ist glaube ich die, dass hier immer Betriebskosten gesehen werden und damit immer der Nettobetrag. Also genau eine Kostenstelle, während mehrere Sackkonten auf eine Kostenstelle abbilden können. Ich bin aber kein Experte und reime mir das nur so zusammen.


    Ich denke, ich bekomme über die Feiertage mal einen Rechner startklar, um mit ein paar Datensätzen anzufangen.

    Habe meine drei Experimentierdateien in OXE1.8 ergänzt und sie funktionieren da, so wie in Xentral.OS20.1. Ist ja auch erstmal nur ein Schema, allerdings mit den editable-Feldern.

    Sollte ich jetzt tatsächlich einen Pull-Request wagen. Ich kann mir ja nicht sicher sein, ob dieser Ansatz von allen Benutzern getragen wird. Kann der dann auch wieder verworfen werden. Diese Art des Umgangs mit git ist leider noch nie meine Praxis gewesen. Gibt es einen Tipp?

    Ich habe mir Deinen Code jetzt mal angesehen. Ich bin mir nicht sicher ob wir die "$this->app->YUI->AARLGPositionen()" dort verwenden sollten. Verbindlichkeiten sollten ja in der Masse aus der Bestellung abgeleitet werden bzw. bei anderen Rechnungen (z.B. Büromaterial) benötigt man ja die Positionen nicht.


    Ich verwende für die Positionsansichten immer "Tablesearch", kannst Du Dir z.B. im Produktionsmodul mal ansehen.

    Ist schon klar! Tablesearch() folgt ja dem dokumentierten Programmierbeispiel. Mir ging es hier ja auch nur darum, der Funktionalität d. editierbaren Felder auf den Grund zu gehen. Und mit der Ableitung aus Bestellungen hast du natürlich auch Recht.

    Wir haben Xentral noch nie auf der Ebene genutzt bzw. nutzen können, als dass wir alle bestellten Artikel einzeln elektronisch pflegen konnten bzw. könnten. Wir bekommen immer Wochenangebote zusätzl. als XLSX, da tragen wir die Stückzahl ein und schicken das als Anhang einer Bestellung zurück. Nur so als Hintergrund. Wobei ich das Ziel noch nicht aufgegeben habe, dass sich auch für uns ein Warenwirtschaften auf Artikelebene mit vertretbaren Aufwand umsetzen lässt. Es handelt sich bloß leider um sehr viele und insbesonder variable Artikel usw. egal.

    Wie geht's weiter, soll ich mich mit dem Umbau "Positionen per Tablesearch" beschäftigen? Oder ist da schon weiter in der Entwicklung?

    Bis jetzt haben wir das Thema noch nicht angefangen. Evtl. ergibt es Sinn wenn wir hier in der Community die Funktionalität nochmal gemeinsam zusammenschreiben. Bei den buchhaltungsrelevanten Themen müssen wir auf jeden Fall darauf achten dass es mit dem Buchungen-Modul zusammenpasst. Ausserdem haben wir einen Altbestand aus Xentral den wir benötigen, deshalb muss die DB-Struktur unangetastet bleiben.


    Schau Dir doch bitte mal den Wareneingang noch an, dort ist auch mit Tablesearch die Erfassung von Positionen mit oder ohne Bestellung umgesetzt, das ist ja eigentlich der gleiche Vorgang. Es gab da auch noch den Wunsch eines schnellen Wareneingangs. Evtl. ergibt es Sinn, erst den Wareneingang auf "schnell" umzubauen und dann diese Funktionen für die Verbindlichkeiten auch einzusetzen. Wann Du Dich dort einbringen willst würde das auf jeden Fall helfen.


    Beitrag
    RE: Schneller Wareneingang
    Also bis auf die Etikettenfunktion liese sich das in den bestehenden Wareneingang integrieren.

    Lieferant wählen -> Liste mit offenen Posten, Mengen je Position eintragen, Lager pro Position wählen und mit einmal Klicken alles buchen. Zusätzlich könnte man noch Knöpfe machen für ein Lager setzen für alle.

    Wäre das ausreichend?
    Alex

    Ich habe mir den Wareneingang angeschaut und versucht etwas in Richtung "schnell", heisst mit einem Knopf/Button die Mengen für alle "dropnbox-gecheckten" Artikel zu übernehmen(im Bild "alle Artikel erfassen" unter dem vorhandenen "Artikel manuell erfassen") Das Schema bis dahin stammt aus dem Bestellvorschlag.


    Der Bestellvorschlag hat ja keine einzelnen "zuordnen"-Button und die Inhalte der Mengenfelder sind per GetPostArray() auslesbar. Das funktioniert beim Wareneingang so nicht. Ich vermute bis hierher, dass es daran liegt, das im Wareneingang in der Action/Menü-Spalte per Artikel ein eigenes Form-Element mit POST-Methode verwendet wird und deshalb nur beim Click("Zuordnen") der Inhalt des Mengenfeldes an den Server gesendet wird.


    Dann ist mir aufgefallen, dass es noch eine "Menge"-Spalte hinter der "Auftrag"-Spalte gibt, die meiner Meinung nach in der entsprechenden $sql-Zuweisung nicht gefüllt wird. Dafür aber im "Aktion"-Feld die oben erwähnte Form bzw. folgender Kode

    Code
    $menu = "<table cellpadding=0 cellspacing=0><tr><td nowrap><form style=\"padding: 0px; margin: 0px;\" action=\"\" method=\"post\" name=\"eprooform\">Menge:&nbsp;<input type=\"number\" size=\"5\" name=\"pos[%value%]\">&nbsp;<input type=\"submit\" value=\"zuordnen\" name=\"submit\"></form></td></tr></table>";

    Wäre es eine Alternative, dass <input .. name=\"pos[%value%]\"> in die Spalte "Menge" davor zu setzen und unter Aktion nur den "Zuordnen"-Button mit <input .. name=\"submit_pos[%value%]\"> einzufügen?

    Ja genau, im Wareneingang ist momentan jede Zeile ein Formular, besser ist es wenn die gesamte Tabelle das Formular ist und alle Eingabefelder mit einem Knopf abgesendet werden können.


    Schau bitte auch in der fibu_buchungen, die ist ganz neu. Da habe ich das so umgesetzt im tablesearch "fibu_buchungen_einzelzuordnen".


    Ich habe extra die Helferfunktion $this->app->erp->ConcatSQL() erstellt, mit der kann man relativ komfortabel das HTML zusammensetzen welches ja dann durch das SQL-Statement durchgewurstet werden muss. Eventuell könnte man da sogar auch die Templates verwenden, sprich es gibt eine .tpl für das HTML... Bin für Vorschläge offen ;)


    Das Menü ist besonders, dort kann man immer nur einen Wert hinterlegen per %value%, normalerweise ist das "id" für z.B. editieren. Ich würde es nicht über das Menü machen, ggf. will man ja auch später das Menü noch benutzen aber dann ist die Funktion belegt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden