Beiträge von itsmeJAY

  • VieCode Lexikon 7.2.0 erschienen

    Danke auch von mir.

    Noch ein kleiner Einwand: Der Fehler, den ich hier noch zusätzlich gemeldet habe, wurde in ein separates Thema verschoben. Du hast mir dort geantwortet, allerdings habe ich mit dem Account hier keinen Zugriff auf das Lexikon. Hanashi und meine Wenigkeit können Fehler in der Regel sicherlich gut einordnen und ggf. direkt mit einem Hinweis "beheben" und Dir so ggf. Arbeit abnehmen. Ich betreue zudem einige Installationen. Deshalb wäre es sinnvoll, uns oder mir ggf. Zugriff auf den Support-Bereich zu geben - auch weil ich nicht immer über Kunden- oder Unternehmenskonten schreiben kann bzw. darf.

    Liebe Grüße,
    Jonas

  • VieCode Lexikon 7.2.0 erschienen

    Ich habe rating nun einen Ordner höher gelegt, das passt jetzt.

    Folgenden Fehler kann ich nicht reproduzieren. Hanashi hast du auch wirklich in V 7.2.1 geprüft?

    Zitat von Hanashi

    Zusätzlich habe ich noch einen Fehler gefunden in der Klasse lexicon\data\entry\Entry. Im Konstruktor steht als Parameter ?$row = null müsste aber $row = null oder ?array $row = null heißen, führt sonst zu einer Fehlermeldung.

  • VieCode Shop 8.1.3 erschienen

    Hallo,


    ich hatte dazu neulich eine externe Schulung im Betrieb. Korrekt ist, dass der Empfang ab 2025 verpflichtend ist bzw. man in der Lage sein muss diese empfangen zu können und ab 2027 der Versand. Das Problem ist, dass viele große Unternehmen freiwillig bereits ab 2025 ausschließlich eine E-Rechnung akzeptieren und ab 2027 eine Nicht-E-Rechnung nicht mehr zum Vorsteuerabzug berechtigt - bzw.. nur noch in Ausnahmen. Und jetzt kommt es: Der Empfänger muss eine X-Rechnung nicht akzeptieren, sondern kann auch eine ZUGFeRD Rechnung anfordern, die der Leistende ebenfalls generieren können muss. Das Format ist leider noch nicht einheitlich geklärt.


    BTW gilt dies auch für Kleinunternehmen.

  • Varianten / unterschiedliche Artikelnummern

    Hallo

    Zitat von Peter

    Nein, beim Shop kann man generell keine Artikelnummern pflegen.

    das wundert mich doch sehr. Versandware hat, es sei denn man strickt selber paar T-Shirts, immer Artikelnummern. :)

    Schade, aber Danke! Möglicherweise sollte in dem Rahmen das Versandwaren-Modul noch einmal überdacht werden. Wofür genau ist das denn da? Wirklich nur für „eigene“ Ware, die man produziert? Aber selbst die hat oft eine Artikelnummer.

  • Varianten / unterschiedliche Artikelnummern

    Hallo,

    für Versandware ist es oftmals üblich, dass es für unterschiedliche Ausführungen, unterschiedliche Artikelnummern zur Verfügung stehen.

    Beispiel:

    T-Shirt, Rot, Größe M = TS-RM1

    T-Shirt, Rot, Größe S = TS-RS1

    T-Shirt, Blau, Größe M = TS-BM1

    Das ist natürlich ein einfaches Beispiel. Oft bezieht es sich auf Ware des Großhändlers, wo es für jegliche Variante eines Produkts unterschiedliche Artikelnummern und/oder Eigenschaften gibt. Theoretisch kann ein Artikel (Produkt) x verschiedene Varianten haben in Abhängigkeit von allen möglichen Eigenschaften wie Länge, Breite, Farbe, usw.

    Grundsätzlich geht es aber nicht um Preise, sondern eher um die Artikelnummern, die der Großhändler mitgeteilt bekommen muss.

    Die Frage wäre hier: Sind Varianten pro Artikel abbildbar für Versandware? Kann ein Benutzer also das T-Shirt wählen und dann Zusätze wie „Blau“ oder „Rot“, für die eigene Preise gelten und eigene Artikelnummern?

    Das ist relativ Standard bei Großhändlern, egal in welcher Branche. Oder ist der Shop dafür eher nicht ausgelegt?

    Grüße

  • Ansicht des Warenkorbs

    Hallo,

    Zitat von MysteryCode

    Wie unschwer zu erkennen ist, beziehen sich die Daten, die im Formular des Shops abgefragt werden, auf ein existierendes Benutzerkonto. Es handelt sich hier um ein simples Login-Formular.

    wieso funktioniert dann ein Klick auf „Registrieren“ nicht, wenn das Formular nicht ausgefüllt ist? Wenn ein Benutzer sich registrieren möchte und den Button „Registrieren“ betätigt, sollte er vorher nicht die Daten in das von Dir eingegebene „Formular für ein existierendes Benutzerkonto“ eingeben müssen. Wenn er keins hat, und auf registrieren klickt, dann müsste er sich eins erstellen können und zum Formular weitergeleitet werden. Davon mal abgesehen, dass die Daten, die dort eingegeben werden, sowieso inkonsistent übernommen werden. Die Mail wird in den Benutzernamen übernommen und das Kennwort wird gar nicht übernommen.

    Faktisch ist es so: Man suggeriert dem Kunden sich einzuloggen, er sagt aber „nö, ich möchte mich registrieren, weil ich kein Account habe“, aber muss vorher das Formular, welches eigentlich zur Anmeldung dient, ausfüllen.

    tl;dr: Der Registrieren-Button sollte die Form nicht absenden. Möglicherweise handelt es sich in Version für WSC 6 auch um einen Fehler, da deine Aussagen gegen den Prozess sprechen, den ich gestern gesehen habe.

  • Ansicht des Warenkorbs

    Hallo,

    besteht standardmäßig die Möglichkeit die Ansicht zu ändern? Der Ablauf des Prozesses ist für "normale Gäste" sehr irreführend:

    Nach einem Klick auf Zur Kasse gehen:

    pasted-from-clipboard.png

    Wenn ich Als Gast bestellen = Ja auswähle, bleiben die Buttons Registrieren und Anmeldung weiterhin vorhanden, wieso? Wäre es nicht sinnvoll, das Boolean-Feld generell weg zu lassen und Als Gast bestellen als Button einzufügen?

    Derzeit erwartet zusätzlich der Button "Registrieren" ebenfalls ein Benutzernamen oder eine E-Mail und ein Kennwort im Formular, wieso?

    1. Die E-Mail wird in das Feld "Benutzername" übernommen, auch, wenn es sich gar nicht um einen Benutzernamen, sondern um eine E-Mail handelt.
    2. Das "Kennwort" wird überhaupt nicht übernommen, muss aber zwangsläufig angegeben werden.

    pasted-from-clipboard.png

    Grundsätzlich finde ich den gesamten Ablauf sehr irreführend, gerade für einen "normalen Benutzer".