Artikel mit verschiedenen Kunden-Artikelnummern anlegen

[ZweiInEins]

Hallo,

ich möchte für unserere Artikel mehrere Kunden-Artikelnummern anlegen. Es gibt unsere (Haupt-) Artikelnummer und mind. 3 unserer Kunden benötigen auf AB, LS und RG ihre eigenen (internen) Artikelnummern.
Über welches Feld kann ich diese einpflegen?

Z. B: Unsere Art.-Nr. xy600:
Kunde 1: Art.-Nr. GLA1
Kunde 2: Art.-Nr. 98765
Kunde 3: Art.-Nr. RES-TP100

Vielen Dank für eure Hilfe & LG

 

[smtrnc]

Hallo,

ich möchte für unserere Artikel mehrere Kunden-Artikelnummern anlegen. Es gibt unsere (Haupt-) Artikelnummer und mind. 3 unserer Kunden benötigen auf AB, LS und RG ihre eigenen (internen) Artikelnummern.
Über welches Feld kann ich diese einpflegen?

Z. B: Unsere Art.-Nr. xy600:
Kunde 1: Art.-Nr. GLA1
Kunde 2: Art.-Nr. 98765
Kunde 3: Art.-Nr. RES-TP100

Vielen Dank für eure Hilfe & LG

Wir sind auch sehr daran interessiert. Arbeiten derzeit mit eigenen Feldern.

 

[Tacticaltrim]

Hi,
wir haben die Thematik auch, benötigen es sogar auf dem Artikeletikett.

 

[Jürgen Jester]

Hallo,
hier kommen wir mit unserem neuen Shopprojekt auch gerade an. Ich hoffe, man nimmt es mir nicht übel,
das Thema nochmal anzuschieben, da wir auch dafür eine Lösung suchen
Ich lese mich bei den eigenen Feldern trotzdem mal ein.
Viele Grüße,
Jürgen

 

[JordanHealy]

Wir sind auch sehr daran interessiert. Arbeiten derzeit mit eigenen Feldern.

Wir sind aktuell auch auf der Suche einer Lösung. Könnt ihr mir vielleicht mitteilen wie ihr es mit den eigenen Feldern gelöst habt? Wir müssten diese Nummern ebenfalls auf Rechnungen usw. Drucken.

 

[frankell]

Wir sind aktuell auch auf der Suche einer Lösung. Könnt ihr mir vielleicht mitteilen wie ihr es mit den eigenen Feldern gelöst habt? Wir müssten diese Nummern ebenfalls auf Rechnungen usw. Drucken.

Sehr pauschale Antwort für die sehr pauschale Frage:

Lege in der Wawi je Kunde, der eine eigene Artikelnr. benötigt, ein Eigenes Feld an, bspw. "ArtNr Kunde X", "ArtNr Kunde Y", "ArtNr Kunde Z" etc. Das ist ggf. noch simpel.

Etwas anspruchsvoller wird es, wenn in den verschiedenen Dokumentvorlagen die eigentliche Artikelnummer durch die kundenspezifische ersetzt werden soll. Dort muss dann die Angabe der Artikelnummer durch eine Wenn-Dann-Formel (oder besser 'case') ersetzt werden. Alles möglich.

 

[FOC Solutions]

Sehr pauschale Antwort für die sehr pauschale Frage:

Lege in der Wawi je Kunde, der eine eigene Artikelnr. benötigt, ein Eigenes Feld an, bspw. "ArtNr Kunde X", "ArtNr Kunde Y", "ArtNr Kunde Z" etc. Das ist ggf. noch simpel.

Etwas anspruchsvoller wird es, wenn in den verschiedenen Dokumentvorlagen die eigentliche Artikelnummer durch die kundenspezifische ersetzt werden soll. Dort muss dann die Angabe der Artikelnummer durch eine Wenn-Dann-Formel (oder besser 'case') ersetzt werden. Alles möglich.

Genau so setzen wir es bei unseren Kunden um. Bei einem Kunden sind es mehr als 10 kundeneigene Artikelnummern, da ist die mehrfach ineinanderverschachtelte cond Abfrage schon etwas unübersichtlich, sprich nichts für Anfänger aber machbar. Wenn ein neuer Kunde mit einer Kundeneigenen Artikelnummer dazukommt, muss die Druckvorlage entsprechend erweitert werden.

 

[frankell]

Genau so setzen wir es bei unseren Kunden um. Bei einem Kunden sind es mehr als 10 kundeneigene Artikelnummern, da ist die mehrfach ineinanderverschachtelte cond Abfrage schon etwas unübersichtlich, sprich nichts für Anfänger aber machbar. Wenn ein neuer Kunde mit einer Kundeneigenen Artikelnummer dazukommt, muss die Druckvorlage entsprechend erweitert werden.

Deswegen ein "case", zumindest in DotLiquid.

Schon mal drüber nachgedacht, in die Bezeichnung des Eigenen Feldes einen Wert mit einzubauen, den man extrahieren und in der SQL verwenden kann? Bspw. "ArtNr Kunde [ABC] ([cKundenNr])". Dann würde man sich a) das Editieren sparen, wenn was dazukommt, und b) die Verschachtelung verschlanken. Dafür wäre die Abfrage ein wenig komplexer, aber das dürfte wenig ins Gewicht fallen.

 

[FOC Solutions]

Deswegen ein "case", zumindest in DotLiquid.

Schon mal drüber nachgedacht, in die Bezeichnung des Eigenen Feldes einen Wert mit einzubauen, den man extrahieren und in der SQL verwenden kann? Bspw. "ArtNr Kunde [ABC] ([cKundenNr])". Dann würde man sich a) das Editieren sparen, wenn was dazukommt, und b) die Verschachtelung verschlanken. Dafür wäre die Abfrage ein wenig komplexer, aber das dürfte wenig ins Gewicht fallen.

Gute Idee, danke.

 

[merres]

Ich finde die bisherigen Vorschläge nicht ganz optimal. Wie wär's stattdessen mit folgendem Ansatz:

1. Wir richten eine externe Datenbank ein, zum Beispiel mit Airtable oder Baserow. Da kommen drei Tabellen rein: Artikel, Kunden und Kundennummern/KD-Artikelnummern.
2. In der Kundennummern-Tabelle verknüpfen wir dann Kunde und Artikel und tragen die kundenspezifische Artikelnummern ein
3. Wenn ein Auftrag angelegt wird, schicken wir per Webhook die Details an einen selbstprogrammierten Prozess. Der prüft, ob's für den Kunden eine spezielle Nummer gibt und passt die Artikelnummer in der Auftragsposition an - entweder per REST-API oder direkt in der Datenbank.

Das Gute daran: Man muss den Prozess nur einmal programmieren und kann danach einfach neue Kunden und Artikel in die Tabelle eintragen, ohne jedes Mal am Code was zu ändern.

Ich find's eine praktische Lösung, die sich auch gut anpassen lässt. Wenn die Beziehungen zwischen Kunden und Artikeln nicht zu kompliziert sind, könnten sogar zwei Tabellen ausreichen.
Zudem bräuchte man keine komplexen "Wenn-Dann"-Formeln.

 

[frankell]

Ich finde die bisherigen Vorschläge nicht ganz optimal. Wie wär's stattdessen mit folgendem Ansatz:

1. Wir richten eine externe Datenbank ein, zum Beispiel mit Airtable oder Baserow. Da kommen drei Tabellen rein: Artikel, Kunden und Kundennummern/KD-Artikelnummern.
2. In der Kundennummern-Tabelle verknüpfen wir dann Kunde und Artikel und tragen die kundenspezifische Artikelnummern ein
3. Wenn ein Auftrag angelegt wird, schicken wir per Webhook die Details an einen selbstprogrammierten Prozess. Der prüft, ob's für den Kunden eine spezielle Nummer gibt und passt die Artikelnummer in der Auftragsposition an - entweder per REST-API oder direkt in der Datenbank.

Das Gute daran: Man muss den Prozess nur einmal programmieren und kann danach einfach neue Kunden und Artikel in die Tabelle eintragen, ohne jedes Mal am Code was zu ändern.

Ich find's eine praktische Lösung, die sich auch gut anpassen lässt. Wenn die Beziehungen zwischen Kunden und Artikeln nicht zu kompliziert sind, könnten sogar zwei Tabellen ausreichen.
Zudem bräuchte man keine komplexen "Wenn-Dann"-Formeln.

Sich eigene Hilfstabelle(n) anzulegen, ist sehr oft der einfachere Weg. Oder eigene Views, die ja dynamisch sind.
Wenn man das aber beherrscht, dann benötigt man keine externe Datenbank, sondern macht alles in der einen, die man hat. Da benötigt man dann ja auch keinen Workflow, sondern kann einen eigenen Trigger einrichten.

Für reine Anwender dürfte jedoch der Weg über die Eigenen Felder der passende sein.

Auch für Servicepartner könnte eine Kombination aus beidem adäquat sein. Eigenes Feld für die Anwender und dann entweder direkt in den Vorlagen vollständig coden oder aber eine eigene View anzapfen (ggf. unter Benutzung einer Benutzervariable).

 

[John]

Man könnte die Kunden Artikelnummern auch in nur einem Eigenen Feld vom Typ Text pflegen und dabei einen Inhalt vom Typ
Kundennummer=Artikelnummer für Kunden
nehmen
Bsp.
Kunde mit KundenNr A mit ArtNr = aaa
Kunde mit KundenNr B mit ArtNr = bbb
Kunde mit KundenNr C mit ArtNr = ccc

Eigenes Feld:
A=aaa|B=bbb|C=ccc
Mit Alias$ kann man dann den Wert der Kundenartikelnummer in Abhängigkeit der Kundennummer rausholen.

 

[frankell]

Man könnte die Kunden Artikelnummern auch in nur einem Eigenen Feld vom Typ Text pflegen und dabei einen Inhalt vom Typ
Kundennummer=Artikelnummer für Kunden
nehmen
Bsp.
Kunde mit KundenNr A mit ArtNr = aaa
Kunde mit KundenNr B mit ArtNr = bbb
Kunde mit KundenNr C mit ArtNr = ccc

Eigenes Feld:
A=aaa|B=bbb|C=ccc
Mit Alias$ kann man dann den Wert der Kundenartikelnummer in Abhängigkeit der Kundennummer rausholen.

Das funktioniert nur, wenn in der Vorlage auch die entsprechenden Eigenen Felder entweder direkt oder als EigeneFelderAlsText verfügbar sind. Das ist je nach Vorlage nicht immer gegeben, und - wenn ich nichts übersehen habe - bei den neuen Vorlagen gar nicht der Fall.
Wenn aber vorhanden, ist das natürlich eine womöglich noch charmantere Variante.

 

[John]

Das funktioniert nur, wenn in der Vorlage auch die entsprechenden Eigenen Felder entweder direkt oder als EigeneFelderAlsText verfügbar sind. Das ist je nach Vorlage nicht immer gegeben, und - wenn ich nichts übersehen habe - bei den neuen Vorlagen gar nicht der Fall.
Wenn aber vorhanden, ist das natürlich eine womöglich noch charmantere Variante.

Naja, wenn nicht vorhanden den Wert des Eigenen Feldes eben per SQL holen. Kein Hexenwerk, 42 mal hier im Forum erklärt...

 

[frankell]

Naja, wenn nicht vorhanden den Wert des Eigenen Feldes eben per SQL holen. Kein Hexenwerk, 42 mal hier im Forum erklärt...

Sag ich ja.

 

[JordanHealy]

Wie löst ihr die Suchfunktion der eigenen Artikelnummern? Mit Filtern zu arbeiten ist etwas umständlich für den Anwender. Er würde gerne direkt in der Suchleiste arbeiten.

 

[John]

Hier bietet sich z.B. an, einen Pseudo-Shop anzulegen und dann im Artikel einen neuen Ausgabeweg für diesen Pseudo-Shop der Beschreibung zu erzeugen.
In den Artikelnamen des Pseudo-Shops kommen dann die Kunden-Artikelnummern.

Die JTL Artikelsuche sucht über die Artikelnamen in allen Ausgabewegen und so werden sie gefunden.

 

[JordanHealy]

Hier bietet sich z.B. an, einen Pseudo-Shop anzulegen und dann im Artikel einen neuen Ausgabeweg für diesen Pseudo-Shop der Beschreibung zu erzeugen.
In den Artikelnamen des Pseudo-Shops kommen dann die Kunden-Artikelnummern.

Die JTL Artikelsuche sucht über die Artikelnamen in allen Ausgabewegen und so werden sie gefunden.

ah, sehr gute idee danke schön!