Posts by Alexander Nowak

Kann irgendwie unterstützt werden, um das Thema des Auslagerns aus belibigen Lagerplätzen voran zu bringen?

Zum Schluss hier noch das finale Feedback… Der Weg war tatsächlich der richtige. Nur ist der TC56 ja auch schon ein wenig in die Jahre gekommen… Nach einem Update auf die auch schon etwas antiquiertere Version 8.1 des Android Betriebssystems auf dem Ding ist auch Chrome als Browser verfügbar und das ganze funktioniert.

Vielen Dank!

ok... hab das einfach mal auf dem Rechner getestet... da läuft das.

Da scheint Android 6 und der Browser dahinter wohl das Problem zu sein. schade. Ich versuche dann mal so ein Softwareupdate zu bekommen. Aber das scheint nicht ernsthaft in der Philosophie von Zebra zu liegen die Updates frei raus zu geben.

Wareneingang

Auch eine Möglichkeit mit den Links als QR Code.

Klar macht das alles nur im Browser Sinn.

War nur eine kleine Idee, Ich kann den Aufwand nicht einschätzen. Aber den Lieferschein habe ich ja tendenziell immer dabei. Oder wenn man das Paket vom Zulieferer öffnet eben die EAN ... Oder wenn ich einen Artikel in der Hand habe und.... Daher mein Gedankengang. Vielleicht kommen mir da noch mehr Ideen, wenn ich erstmal mit dem Scanner losarbeite ;), Auf der anderen Seite sind das eventuell auch sehr spezielle Optimierungsspielereien -_-

Guter Tipp, dies erklärt einiges.

(In den DataWedge Einstellungen unter dem entsprechenden Profil muss 'keystroke output' aktiviert sein. Etwas weiter unten unter 'Basic Data formatting' kann man dann ganz unten 'Send ENTER key' auswählen.)

Nur zählt bei mir die Zahl nicht einfach hoch. Nach dem ersten scan trägt er eine 1 ein und nach dem zweiten scan bucht er den einen Artikel unten in der Paket-inhaltserfassung

Ist das so gewollt?

Hi,

ich habe hier jetzt so einen Zebra TC56 und das funktioniert im hauseigenen Browser schon alles ganz gut. (bis auf die Hardwaregrenze ;))

wie funktioniert denn die

• Scaneingabe für Artikelerfassung mit Schnellscanfunktion (Wiederholtes Scannen für Artikelzählung)

... bei mir trägt der den gescannten Code ein und das wars (Ich bin im Testsystem gerade hier: OpenXE 1.12 (87d1fb2e))

eventuell ist ja aber auch mein Ansatz falsch.-_-

Das klingt tatsächlich nach dem, was für mich auch passt. Zum Lagerplatzvorschlag wäre dann eventuell eine komplette Liste aller Lagerplätze interessant. Falls der Lager-Vorschlag weiter weg ist, als der Lagerplatz neben mir. (warum auch immer das passieren sollte)

... Für den Scanner muss es ja offensichtlich auch nicht gleich eine App sein, aber als Idee würde ich eine Scanner Seite vorschlagen. Hier könnte dann egal, was gescannt wird entsprechend reagiert werden (Das kann natürlich auch ausarten, aber es muss ja nicht sofort übertrieben werden....)

Scanne ich einen Lieferschein (hoffentlich gibts die Nummer nicht nochmal irgendwo), bekomme ich den Vorschlag diesen auszulagern und kann dann so weitermachen, wie du beschrieben hast.

Scanne ich eine EAN, könnte mir ein Wareneingang vorgeschlagen werden. (abhängig von den Projekteinstellungen halt ggf auch nur die eigene Nummer)

Scanne ich einen Produktionsauftrag..... usw.

.... über diesen Weg gekommen ggf dann auch automatisch im 'Einzelscan zum Zählen' Modus (Wiederholtes Scannen für Artikelzählung) Aber damit verlassen wir das Thema hier gerade.

Moin,

ich weiß, das Thema ist schon eine Weile her, aber ich habe aufgrund einer Lagerumstellung jetzt auch das Produktionsmodul für mich neu entdeckt. Die Herausforderung stellt sich ähnlich. Aktuell kann man lediglich einen Lagerplatz auswählen, aus dem die Produktion kommen soll... Das sind bei mir die Regalfächer. Das geht also noch nicht.

Meine Lager sind dazu auch noch auf einem Gelände. Das heißt ich verstecke in einem teilweise Chaotischen Lager in Gebäude eins und zwei alle teile für eine Produktion.

Auf Basis eines akuten Platzmangels habe ich nun ein teilweise chaotisches Lager, was bis dahin ja auch recht gut unterstützt wird. Jetzt entsteht sozusagen die Notwendigkeit, dass ich auch einen chaotischen Zugriff auf das Lager benötige. Ich müsste also dem System sagen, wo ich etwas für die Produktion entnehme und nicht umgekehrt. Manche Lagerplätze sind nämlich 'schwerer erreichbar (;))' als andere.

Ich weiß nicht, wie weit die Planung für Anpassungen aktuell ist. In meinem Kopf wäre das eine Liste vom System, wo ich überall an meine Einzelteile komme. Ich suche den Artikel, (Scanne den zur Not nochmal... oder wie zum einlagern mehrfach) und scanne das Lager, aus dem ich die Teile entnommen habe. Sollte nicht die gesamte Anzahl an diesem Lagerplatz verfügbar gewesen sein, muss ich entsprechend noch weitere Plätze ansteuern.

Ein reines Produktionslager müsste ggf. auch für Ersatzteile erreichbar sein, die direkt an einen Kunden gehen.

(

Aktuell lief das ganze aus damaligen Gründen als Auftrag an uns selbst. Den Lieferschein konnte man dann in die Produktion werfen und auf 'jetzt auslagern' klicken. ... Hier steht jetzt allerdings auch meine Lagerproblematik im weg. Ich habe an dieser stelle keine Chance (die ich kenne) dem System zu sagen, aus welchen Regalen ich wie viele Artikel entnommen habe.

... Unabhängig von einer Produktion bleibt die gleiche Herausforderung (nach meinem Wissensstand) auch für Lieferungen an Kunden, bei denen ich gern festlegen würde, wo die Artikel entnommen werden. (bzw. dem System einfach sage, wo ich sie entnommen habe).

)

Also bleibt nach meinem vielen Input die Frage, was ich übersehen habe bzw. wie die aktuelle Planung aussieht.

nun gut... aufräumen hilft ja. ;)... Manchmal muss man ja nicht um die Software rundrum arbeiten, nur, weil das damals is dBase so war, sondern kann sich dafür entscheiden sinnvoll mit der Software zu arbeiten um es einfacher zu haben.

Ja. Die PDF Vorschau habe ich aus ähnlichen Gründen sehr oft genutzt. Jetzt lege ich mir die PDF auch zur Übersicht parallel mit dem Hinweis ab, dass es ja eine XML gab.

Inhaltlich müsste korrekter Weise nun eine Vorschau generiert werden die aus dem Inhalt der XML erstellt wird. Das würde bedeuten, dass quasi ein kompletter E-Rechnungs-Reader implementiert wird, der zur Vorschau zu Rate gezogen wird. Nur dann könnte man als Mensch wieder versuchen die Arbeit der Maschine sinnvoll zu kontrollieren. Aber das wird schwer... wenn man eine Rechnung zum Beispiel bei ELSTER rein wirft, ist das auch nicht viel übersichtlicher als eine XML :D. Das Ziel ist es ja nur das ganze etwas weniger sperrig lesbar zu machen.

So sehr ich mir auch eine Lösung wünsche fehlt mir wahrscheinlich der Weitblick um mir eine sinnvolle Lösung auszudenken -_-

Hi,

Ich habe gerade einen etwas älteren Stücklistenartikel betrachtet und unter Einkauf-Kalkulation wurde mir gesagt: "Quantity must be greater than 0. Actual: 0

/var/www/html/OpenXE-V.1.11/classes/Modules/Article/Service/PurchasePriceService.php:41"

... Den Grund verstehe ich ein wenig. Kann das geändert werden? In meinem Fall ist das ein Alternativartikel, weil ich damals unter Xentral ein wenig um das System rundrum gearbeitet habe. (Das mach ich auch immer noch viel zu viel aber ich hoffe das ändert sich). Der Alternativartikel ist mit Anzahl Null noch in der Stückliste enthalten und wird je nach bedarf wieder aktiviert. In der Kalkulation kann ja einfach die Null genutzt werden. Oder übersehe ich was?

Nun, wo ich näher nachlese, hätte ich für meine Kunden gern noch den Preis je Position näher aufgeschlüsselt... hab das hier als Beispiel auf https://docs.peppol.eu/poacc/billing/3.0/bis/ unter "§9.2. Calculation on line level" gefunden. Je länger man gräbt, desto mehr findet man auch -_-.

<cac:Price>
    <cbc:PriceAmount currencyID="EUR">410</cbc:PriceAmount>
    <cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="EUR">40</cbc:Amount>
        <cbc:BaseAmount currencyID="EUR">450</cbc:BaseAmount>
    </cac:AllowanceCharge>
</cac:Price>

Die Info des Listenpreises wäre damit dann auch übergeben.

Ich tue mich nur schwer damit herauszufinden, wie ich an die Werte komme, die da rein müssen

:D... wenn man doch alles verstehen würde, was da steht.... Ja. Das geht und das macht auch Sinn... nun kann die nächste Nachkommastelle nachrutschen und die Summe stimmt wieder ... Ich versuche damit mal noch eine Weile zu spielen.

^{Das kommt bei mir raus... hatte alles gerade vorher auf den neuesten Stand gezogen. Anpassungen habe ich fürs Template weggelassen... daher kommt beim Validieren noch eine Warnung mit dazu.}

hab endlich wieder mal Zeit gefunden. In meinem Test bleibt der Fehler (PEPPOL-EN16931-R120) der gleiche. ausgegeben werden allerdings auch die selben Werte, wie in der alten Version und unter PayableRoundingAmount steht 0.00...

        <cbc:PriceAmount currencyID="EUR">15.94</cbc:PriceAmount>

        <cbc:InvoicedQuantity unitCode="XPP">10.0000</cbc:InvoicedQuantity>
        <cbc:LineExtensionAmount currencyID="EUR">159.43</cbc:LineExtensionAmount>


        <cbc:LineExtensionAmount currencyID="EUR">193.43</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="EUR">193.43</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="EUR">230.18</cbc:TaxInclusiveAmount>
        <cbc:PayableRoundingAmount currencyID="EUR">0.00</cbc:PayableRoundingAmount>
        <cbc:PayableAmount currencyID="EUR">230.18</cbc:PayableAmount>

Meine Recherche endete hier. Aber vielleicht sollte das jemand lesen der es gewöhnt ist nummerierte Zeilen zu haben ;):

GitHub - itplr-kosit/xrechnung-testsuite: Test instances for the XRechnung Standard, the German Core Invoice Usage Specification of CEN EN16931 [MIRROR of GitLab]

Test instances for the XRechnung Standard, the German Core Invoice Usage Specification of CEN EN16931 [MIRROR of GitLab] - itplr-kosit/xrechnung-testsuite

github.com

Quote from Alex

Code

val-sch.2.2    PEPPOL-EN16931-R120    error    Pfad: /ubl:Invoice/cac:InvoiceLine[1]

Das weist auf Rundungsdifferenzen hin, müsste ich mir genauer ansehen.

Genau. Das mit den Rundungsdifferenzen Liegt an dem, was ich versucht hatte am 13.12.2024 im Post 108 zu beschreiben.

hier https://docs.peppol.eu/poacc/b…ppol/PEPPOL-EN16931-R120/ steht dann:„Der Nettobetrag der Rechnungszeile MUSS gleich sein (Rechnungsmenge * (Nettopreis des Artikels/Preisbasismenge des Artikels) + Summe der Gebühren der Rechnungszeile - Summe der Freibeträge der Rechnungszeile“

Ich habe das gerade erneut mit der aktuellen Version getestet und hier https://erechnungsvalidator.service-bw.de versucht zu validieren.

Vielleicht habe ich das nicht genau ausgedrückt.

Artikelkosten: 37,96

Rabatt 58% ^{(ist natürlich fiktiv)}

Ergebnis: 15,9432 ^{... hier entstehen die 4 Nachkommastellen zum Rechnen.}

Einzelpreis ausgegeben: 15,94 ^{... mit dem wird aber nicht gerechnet}

10* Ergebnis ist dann: 159,43 ^{und das ist ungleich zu 10* [Einzelpreis ausgegeben]....}

Der Validator rechnet damit, dass in der Summe der Zeile 159,40 stehen muss und daran schlägt die Validierung fehl.

Ich kann es nur nicht programmieren -_-.

Wenn ich die Zeilen entsprechend korrigiere, ergibt das ein Valides Dokument.

Ich habe hier auch noch so ein Schöne "übersichtliches" Dokument entdeckt... Eventuell verschwindet das Problem, wenn der Rabattierte Preis mit ausgegeben wird. ... so ein Feld scheint es wohl zu geben: http://www.xoev.de/sixcms/medi…-XRechnung-2022-01-27.pdf auf Seite 27.

Selbstredend wäre eine Lösung als PDF mit eingebauter XML (das müsste dann ein ZUGFeRD sein) ziemlich praktisch, weil es doch sicher genügend Personen gibt, die mal schnell in die Datei schauen wollen... aber Alex sagte das glaub ich schon... Erst den ersten Schritt. Dann kann es weiter gehen.

Das ist ja jetzt auch schon fest hinterlegt. Denke ich mal ;).

Der Fehler entsteht dadurch, dass der Stückpreis (<cbc:PriceAmount currencyID="EUR">15.94</cbc:PriceAmount>) nur zwei Nachkommastellen hat, die Summe der 10 Stück in OpenXE aber mit aber mit dem vierstelligen Nachkommawert errechnet wird und in der Rechnung eingetragen wird (<cbc:LineExtensionAmount currencyID="EUR">159.43</cbc:LineExtensionAmount>).

Wenn in der Prüfung nun 15,94*10 gerechnet wird, kommt da unweigerlich 159,40 raus und folglich 3 cent weniger als in der XML eingetragen.

Es wird weniger der richtige Weg sein als der nachvollziehbare Weg.

(( ob ich die 15,9432 vorher abrunde oder aufrunde ist nicht das Problem des Finanzbeamten. Das müssen wir zwischen Unternehmer und Unternehmer klären. Der Finanzbeamte will aber in seinem Dokument schlüssig nachvollziehbare Zahlen haben.))

nachdem ich nun bei schreiben nachgedacht und alles wieder gelöscht habe liegt dieser Fehler darunter begraben, dass bis jetzt niemals ein rabattierter Einzelpreisausgegeben wurde... daher ist dieser noch vierstellig nach dem Komma. Es darf aber nur mit dem ausgegebenen Wert mit zwei Nachkommastellen weitergerechnet werden. (Global angepasst würde dies zu einem anderen Ergebnis führen. Die XML geht dann durch den TÜV und auf der PDF ist es weiterhin nicht zu 100% nachvollziehbar, wie gerechnet wurde.)

Auf dieser Basis würde ich vermuten, dass das Berechnungsproblem im Umsatzsteuerbereich behoben werden kann. Dies gab es bis jetzt nicht, da alle Artikel 19% drauf bekamen... Die XRechnung scheint es zu ermöglichen unterschiedliche Steuersätze für unterschiedliche Artikel zu haben.

Auf Basis der Erfahrung bei den Artikel-Rabatten tippe ich darauf, dass die zeilenweise Berechnung inkl. Rundung auf zwei Nachkommastellen und das dann folgende Summieren der Einzelwerte zu validierbaren Ergebnissen führt.

... die zwei Nachkommastellen in einer Rechnung sind natürlich auch nachvollziehbar korrekt. Alles andere würde Fragen aufwerfen.

Quote from Alex

Das Thema hatten wir schonmal bei den Verbindlichkeiten. Da ist es so gelöst das mehrere Wege gerechnet werden für die Summe. Evtl. würde es helfen wenn man im XML verschieden berechnete Summen zur Auswahl hätte?

Mit Bruttopreisen kenne ich mich nicht aus, ich meine irgendwo mal elesen zu haben dass XRechnung nur mit Nettopreisen funktioniert.

Hi,

ich bin neu hier und komme gerade erfolgreich aus Version 18.xx.... Vielen Dank für die Viele Arbeit.

Der Grund liegt auf der Hand: die X-Rechnung.

Daher nun auch direkt der erste erfolgreiche Fehlschlag. Hier allerdings nicht mit dem Thema Steuern, sondern mit dem Thema Rabatt. Offensichtlich interessiert das Thema der Rabatte nicht und ist daher in der Rechnung nicht enthalten.

Rechnerisch wird in OpenXE aktuell der Netto Listenpreis rabattiert. Dabei kommt etwas krummes raus mit 4 Stellen nach dem Komma. Dies wird dann beispielhaft mit 10 Stück multipliziert und und die dritte Stelle wander eins nach vorn. Damit hat der genannte erechnungsvalidator.service-bw.de ein Problem. Ändere ich die Werte, Geht die Rechnung durch.

Möglicherweise denken wir alle viel zu genau und der Schlüssel ist einfach zwischendurch zu runden und einfach nur mit zwei Nachkommastellen weiter zu machen. Dies wäre dann natürlich global sinnvoll, damit alle Rechnungen gleich berechnet werden. Ich denke die Auswahl verschiedener berechneter Summen stiftet Unruhe.

Es bleibt zu testen, ob zwischendurch runden oder einfach abhacken die angenehmere Lösung für Validierungsprogramme ist. Gibt es denn auch noch andere Seiten Validieren? Die hier (https://www.epoconsulting.com/…g-sap/xrechnung-validator) verhält sich im genannten Fall auf jeden Fall gleich zu der aus BW