rcpt_c.riegger
Gut bekanntes Mitglied
Hi Leute,
wir sind ein österreichisches Unternehmen und haben seit 2014 einen Standort in Deutschland.
Damals mussten wir hierfür einen eigenen Mandanten anlegen und unabhängig verwalten.
Vor einigen Jahren wollten wir Aufgrund des großen Aufwandes der doppelten Artikelpflege sowie des nur teilweise funktionierenden Ameisen-Artikel-Abgleichs anstelle des eigenen Deutschland Mandaten eine Firma im Mandanten Österreich anlegen und dort gemeinsam verwalten. Leider war es damals Aufgrund der nicht vorhandenen Steuerverwaltung und anderer fehlender Funktionen nicht möglich.
Jetzt nach erscheinen der JTL-WAWI 1.7 haben wir das Thema wieder aufgegriffen und die Möglichkeiten nochmals geprüft.
Ich habe mir nun den Funktionsumfang für Firmen in JTL-WAWI 1.7 angesehen und muss sagen, dass die Umstellung nun bis auf ein paar wenigen aber tiefgründigen Problemen möglich wäre.
Um das Thema abzukürzen würde ich gerne wissen wie ihr mit folgenden Themen umgeht:
1. Nach einer Finanzprüfung der Niederlassung Deutschland wurde uns vorgeschrieben, dass wir zwingend einen Aufschlag beim Warenkauf von Firma AT -> Firma DE verrechnen müssen.
Bis Dato haben wir das mit einer eigenen Kundengruppe EK+5% im Mandanten AT gelöst.
Zur Info:
Firma Deutschland bezieht die Waren wie folgt:
a) per Dropshipping direkt zum Kunden (Rechnung geht direkt an Firma Deutschland), Deutschland erstellt eine eigene Rechnung an den Kunden (inkl. Warenlieferung)
b) per Bestellung zum Speditionslager für den Wiederverkauf direkt aus dem deutschen Mandaten
c) per Bestellung zum Warenlager der Niederlassung (dort gibt es zusätzlich auch einen Ausstellungsraum)
Das heißt die Artikel vom Mandant Deutschland werden mit einem höheren Durchschnittseinkaufspreis geführt.
Uns ist hier keine Funktion in JTL-WAWI bekannt und es würde nur die Option bleiben, dass bei Bedarf oder am Ende des Jahres zur Lagerbewertung aller Artikel mit EK Preisen exportiert und dort bsp. 5% aufgeschlagen werden.
Wie kann das vielleicht doch in JTL-WAWI mit nur einem Artikelstamm (aber zwei oder mehreren Firmen mit unterschiedlichen EK-Preisen) umgesetzt werden?
2. Bis Dato wurden beim Mandant Deutschland die Bestellungen mit einem selbst programmierten Workflow nach Österreich übertragen und dort als Dropshipping ausgeliefert.
Rechnungsempfänger war immer Mandant Deutschland.
Mit der geplanten Mandantenzusammenführung können die Artikel ja direkt vom Mandant Deutschland von einem österreichischen Lager ausgeliefert werden ohne an den Mandanten Deutschland verrechnet zu werden.
Mein Ansatz wäre eventuell mit einem Script alle Lieferungen die später (wenn Mandant Deutschland als Firma beim Mandant Österreich geführt wird) von Firma DE aus Lager Österreich ausliefert, auszulesen und auf eine Art
Monatsauftrag zu schreiben und nach Kontrolle an die Firma Deutschland zu verrechnen.
Wie würdet ihr das machen ?
3.Ein weiteres mögliches Problem könnte das versehentliche Waren ausliefern aus den Lägern der jeweils anderen Firmen entstehen.
Wir würdet ihr das unterbinden?
Hier ein paar Probleme warum wir die Mandaten zusammenfassen und getrennt nach Firma arbeiten möchten:
- Einheitlicher Artikelstamm ohne verzögerte aktualisiertung - derzeit nur 1x wöschentlich (Preise, ...)
- Artikelstammdaten 1:1 (derzeit kein 100% Abgleich möglich nur mit händischer Nacharbeit)
- Kategorien können nur manuell abgeglichen werden
- Artikelzustände und Zustandsartikel können nur manuell bearbeitet werden
- Tote Artikel - Risiko von vergessenen Waren sinkt auf quasi 0% (vieles in AT bereits gelöscht aber in DE noch mit Lagerstand vorhanden somit wird die Ware nie verkauft)
- Artikelverfügbarkeit sofort ersichtlich, ohne die Mandanten wechseln zu müssen
- Druckvorlagen werden nur 1x bearbeitet
- gemeinsamer Kundenstamm (für bsp. Newsletter) - Klarheit bei Kunden die 1x in AT und 1x in DE mit unterschiedlichen Zahlungsbedingungen angelegt sind.
- viele Vorgänge mit Bestellung etc. könnten wegfallen (Dropshippingprozess, JTL-Workflows für Bestellungen, ...)
- doppelte Workflowverwaltung
- Reservierungen von Waren
wir sind ein österreichisches Unternehmen und haben seit 2014 einen Standort in Deutschland.
Damals mussten wir hierfür einen eigenen Mandanten anlegen und unabhängig verwalten.
Vor einigen Jahren wollten wir Aufgrund des großen Aufwandes der doppelten Artikelpflege sowie des nur teilweise funktionierenden Ameisen-Artikel-Abgleichs anstelle des eigenen Deutschland Mandaten eine Firma im Mandanten Österreich anlegen und dort gemeinsam verwalten. Leider war es damals Aufgrund der nicht vorhandenen Steuerverwaltung und anderer fehlender Funktionen nicht möglich.
Jetzt nach erscheinen der JTL-WAWI 1.7 haben wir das Thema wieder aufgegriffen und die Möglichkeiten nochmals geprüft.
Ich habe mir nun den Funktionsumfang für Firmen in JTL-WAWI 1.7 angesehen und muss sagen, dass die Umstellung nun bis auf ein paar wenigen aber tiefgründigen Problemen möglich wäre.
Um das Thema abzukürzen würde ich gerne wissen wie ihr mit folgenden Themen umgeht:
1. Nach einer Finanzprüfung der Niederlassung Deutschland wurde uns vorgeschrieben, dass wir zwingend einen Aufschlag beim Warenkauf von Firma AT -> Firma DE verrechnen müssen.
Bis Dato haben wir das mit einer eigenen Kundengruppe EK+5% im Mandanten AT gelöst.
Zur Info:
Firma Deutschland bezieht die Waren wie folgt:
a) per Dropshipping direkt zum Kunden (Rechnung geht direkt an Firma Deutschland), Deutschland erstellt eine eigene Rechnung an den Kunden (inkl. Warenlieferung)
b) per Bestellung zum Speditionslager für den Wiederverkauf direkt aus dem deutschen Mandaten
c) per Bestellung zum Warenlager der Niederlassung (dort gibt es zusätzlich auch einen Ausstellungsraum)
Das heißt die Artikel vom Mandant Deutschland werden mit einem höheren Durchschnittseinkaufspreis geführt.
Uns ist hier keine Funktion in JTL-WAWI bekannt und es würde nur die Option bleiben, dass bei Bedarf oder am Ende des Jahres zur Lagerbewertung aller Artikel mit EK Preisen exportiert und dort bsp. 5% aufgeschlagen werden.
Wie kann das vielleicht doch in JTL-WAWI mit nur einem Artikelstamm (aber zwei oder mehreren Firmen mit unterschiedlichen EK-Preisen) umgesetzt werden?
2. Bis Dato wurden beim Mandant Deutschland die Bestellungen mit einem selbst programmierten Workflow nach Österreich übertragen und dort als Dropshipping ausgeliefert.
Rechnungsempfänger war immer Mandant Deutschland.
Mit der geplanten Mandantenzusammenführung können die Artikel ja direkt vom Mandant Deutschland von einem österreichischen Lager ausgeliefert werden ohne an den Mandanten Deutschland verrechnet zu werden.
Mein Ansatz wäre eventuell mit einem Script alle Lieferungen die später (wenn Mandant Deutschland als Firma beim Mandant Österreich geführt wird) von Firma DE aus Lager Österreich ausliefert, auszulesen und auf eine Art
Monatsauftrag zu schreiben und nach Kontrolle an die Firma Deutschland zu verrechnen.
Wie würdet ihr das machen ?
3.Ein weiteres mögliches Problem könnte das versehentliche Waren ausliefern aus den Lägern der jeweils anderen Firmen entstehen.
Wir würdet ihr das unterbinden?
Hier ein paar Probleme warum wir die Mandaten zusammenfassen und getrennt nach Firma arbeiten möchten:
- Einheitlicher Artikelstamm ohne verzögerte aktualisiertung - derzeit nur 1x wöschentlich (Preise, ...)
- Artikelstammdaten 1:1 (derzeit kein 100% Abgleich möglich nur mit händischer Nacharbeit)
- Kategorien können nur manuell abgeglichen werden
- Artikelzustände und Zustandsartikel können nur manuell bearbeitet werden
- Tote Artikel - Risiko von vergessenen Waren sinkt auf quasi 0% (vieles in AT bereits gelöscht aber in DE noch mit Lagerstand vorhanden somit wird die Ware nie verkauft)
- Artikelverfügbarkeit sofort ersichtlich, ohne die Mandanten wechseln zu müssen
- Druckvorlagen werden nur 1x bearbeitet
- gemeinsamer Kundenstamm (für bsp. Newsletter) - Klarheit bei Kunden die 1x in AT und 1x in DE mit unterschiedlichen Zahlungsbedingungen angelegt sind.
- viele Vorgänge mit Bestellung etc. könnten wegfallen (Dropshippingprozess, JTL-Workflows für Bestellungen, ...)
- doppelte Workflowverwaltung
- Reservierungen von Waren
Zuletzt bearbeitet: