[gelöst] Speditionsauftrag als Ressource?

Wir beauftragen eine Spedition, uns einen leeren LKW bereitzustellen. Der LKW wird beladen und an den Zielort geschickt. Was transportiert wird, ist also egal - es geht jetzt um die Bestellung des LKW.

Momentan dient als Bestellposition leider ein (nicht lagerbestandsgeführter) Artikel. Ich würde gern auf Artikel verzichten und wieder den Standard nutzen.
Da wir für die Bestellzeile Preise und Textbausteine abrufen müssen, bietet sich eine Ressource als Lösung an (eine kleine Anpassung vorausgesetzt).

Leider bin ich mit Ressourcen kaum in Berührung gekommen.
Gibt es gute Gründe, beim Artikel zu bleiben? Was spricht gegen eine Ressource, was vielleicht doch eher für ein Sachkonto?
Wenn Ressource: Würdet ihr Person, Maschine, oder bessere eine neue Art verwenden?

(Mit Projekten und dem Service-Modul arbeiten wir übrigens nicht.)

Das Preisfíndungssystem bei den Artikeln ist wesentlich leistungsfähiger als bei den Ressourcen, wenn man das nicht benötigt, würde ich eher die Ressourcen für den Einkauf aufbohren und den LKW als Maschine führen. Sauberer ist das . Sachkonto geht zwar auch, ist aber von der Geschäftsleitung nicht immer gern gesehen, weil dann der Zugriff auf den Kontenplan damit einhergeht.

Das Preisfíndungssystem bei den Artikeln ist wesentlich leistungsfähiger als bei den Resourcen, wenn man das nicht benötigt...

(Aus aktuellem Anlass:) jedenfalls bei Speditionen ist die Preisfindung beliebig komplex. Man ist versucht als einen Parameter Tagesform des Disponenten anzunehmen

(Aus aktuellem Anlass:) jedenfalls bei Speditionen ist die Preisfindung beliebig komplex. Man ist versucht als einen Parameter Tagesform des Disponenten anzunehmen

Oje.
Also bei uns scheint das entspannt zu sein. Es gibt feste Preise für bestimmte Strecken, für welche der LKW bestellt werden wird. Darum führen wir zur Zeit für jede Strecke einen eigenen Artikel (und hoffentlich bald eine eigene Ressource).

Die Ressourcen verfügen über Preistabellen, wenn auch ohne Startdatum. Aber das ließe sich ja auch noch ergänzen ....

Es gibt feste Preise für bestimmte Strecken, für welche der LKW bestellt werden wird. Darum führen wir zur Zeit für jede Strecke einen eigenen Artikel (und hoffentlich bald eine eigene Ressource).

=:-)
Das wird, je mehr Strecken angeboten werden gaanz schnell 'interessant'. Ich tät eher zu km-Preis-Artikel/Ressource tendieren.

Das wird, je mehr Strecken angeboten werden gaanz schnell 'interessant'.

In der Tat, bei uns aber unausweichlich. Zur Zeit gibt es 65 dieser "Transportartikel". Tendenz ist natürlich steigend, hält sich aber noch im Rahmen. Meistens werden die gleichen Strecken immer wieder befahren.

Ich tät eher zu km-Preis-Artikel/Ressource tendieren.

Das funktioniert in der Praxis nicht. Der Preis hängt nämlich von viel mehr Variablen als der bloßen Entfernung ab. Da spielt z.B. mit, ob und in welches Ausland es geht, welcher Kreditor mit welchen Konditionen im Boot ist, was transportiert werden soll, welcher Papierkram zusätzlich anfällt usw.
Bei neuen Strecken wird der Preis also individuell erfragt und verhandelt.
Ein weiterer Nachteil der km-Lösung: In jeder Bestellzeile müsste die Beschreibung händisch korrigiert werden. Da soll nämlich nicht nur "Transport", sondern auch "von-bis" drin stehen.

Eine Schwachstelle sehe ich jedoch jetzt bei den Ressourcen:
Die EK-Preistabelle enthält keinen Kreditor als Teil des Schlüssels. Es ist aber sinnvoll, alle eingeholten Preise der verschiedenen Kreditoren zu pflegen, um sie beim Ausfall eines Kreditoren sofort nachhalten zu können.
Und hierfür den Arbeitstypencode missbrauchen ...? Nee ...
Mal schauen, ob das Hinzufügen der Kreditorennr. (+ Start-/Enddatum) mir woanders Probleme bereiten würde ....

Der Weg über den Ressourcen-Einkauf erscheint mir hier der richtige zu sein.
Aus meiner Sicht wäre der sauberste Weg folgender:

• Möglichst wenig Ressourcen anlegen
  (Eine je benötigter (MwSt.-)/Produktbuchungsgruppe für die Kontenfindung.)
• Strecken als Arbeitstypen hinterlegen.
  (Beschreibung in der EK-Zeile wird dann von der Beschreibung des Arbeitstypen überschrieben. [Muss programmiert werden.])
• Ressourcen-Preis-/Rabattfindung EK (ggfls. auch VK) an die Logik der Artikelpreise anpassen.

Es gibt sicherlich auch Lösungswege, die weniger Programmanpassung erfordern, jedoch dürfte sich der Aufwand in Zukunft schnell auszahlen, da

1. Die Ressourcen-Preis-/Rabattfindung genauso wie bei den Artikeln funktioniert (Stichwort: Einheitlichkeit)
2. Die Übersichtlichkeit gewahrt bleibt. (Ihr werdet nicht von unzähligen Ressourcen "erschlagen".)
3. Evtl. Erweiterungen in der Preisfindung in der Zukunft mit relativ geringem Aufwand eingebaut werden können.

• Strecken als Arbeitstypen hinterlegen.
  (Beschreibung in der EK-Zeile wird dann von der Beschreibung des Arbeitstypen überschrieben. [Muss programmiert werden.])

DANKE, den Schritt hatte ich noch übersehen.
Heißt allerdings, dass ich das Feld Work Type Code noch in die EK-Zeilen integrieren muss.

Und aufgrund der Vielzahl der Strecken = Arbeitstypen muss ich noch (wie bei den Artikelpeisen) einfache Filtermöglichkeiten schaffen, um die Übersichtlichkeit bei der Pflege zu wahren.
Naja, wenigstens gibts hierzu eine Vorlage im Standard

Viel "Erstimplementierungsaufwand", soviel ist klar ...!

Edit: Ein großer Nachteil der Arbeitstypenlösung: Die Textbausteine müssen am Arbeitstypencode hängen .... Der Arbeitstypencode muss verpflichtend sein.

Dann noch eine Frage:
Lässt sich die Ressourcenplanung so verwenden, dass dem Anwender ein Bedarf gemeldet werden kann, ähnlich wie ein Bestellvorschlag bei Artikeln ...?

ich muss mal frage, warum entweder Resource oder Artikel. Warum nicht beides?

Mein Gedanke wäre es die einzelnen Bestandteile eines Speditionsauftrags als Resource anzulegen, z. B. Abholung, Ladevolumen, Sendungsgewicht, Strecke, Verzollung, Dokumenterstellung, Intrastat,...

Aus diesen Resourcen dann Stücklisten erstellt und diese im Auftrag automatische entfalten lassen, ggf. zzgl. Textbausteine. Hätte den Nebeneffekt, dass man einzelne Positionen ändern könnte, also z. B. ausnahmsweise keine Verzollung.

Ist aber nur so eine Idee eines Amateurs.

Volker

In NAV 2013 R2 gibt es ein Feld Art. Dieses Feld gibt an, ob der Artikel lagerbestandsgeführt ist oder eine Dienstleistung ist. Vielleicht hilft das?

Was hältst du davon, die Artikelzuschläge für die Speditionsbestellungen zu verwenden?

Edit: Kann natürlich keine Meldungen per Planungsvorschlag erzeugen. Also bleiben wohl nur Artikel.

In NAV 2013 R2 gibt es ein Feld Art. Dieses Feld gibt an, ob der Artikel lagerbestandsgeführt ist oder eine Dienstleistung ist. Vielleicht hilft das?

Das hilft mir für 2009 R2 leider nur bedingt. Dass es das Feld "später" gibt, ist mir durchaus bewusst. Ich möchte dennoch in unserer jetzigen Version vom Artikel runter, um wieder zum Standard zurückzukehren. Dass wir aktuell überhaupt mit Artikeln arbeiten, liegt an einer Anpassung unseres früheren Partners. Und diese Anpassung ist leider nicht sauber, und hat auch nichts mit der Lösung in 2013 R2 zu tun.

Was hältst du davon, die Artikelzuschläge für die Speditionsbestellungen zu verwenden?

Vielleicht verstehe ich noch immer etwas falsch , aber meiner bescheidenen Information nach ist das der falsche Ansatz. Uns wird ja nicht damit unsere Ware angeliefert. Zum Zeitpunkt der Bestellung des LKWs gibt es noch keine gebuchte Verkaufslieferung, welche wir dem Zuschlag zuweisen können.

In den Verkaufsaufträgen ist das was anderes. Da arbeiten wir bereuts heute mit Artikelzuschlägen.

In NAV 2013 R2 gibt es ein Feld Art. Dieses Feld gibt an, ob der Artikel lagerbestandsgeführt ist oder eine Dienstleistung ist. Vielleicht hilft das?

Das hilft mir für 2009 R2 leider nur bedingt. Dass es das Feld "später" gibt, ist mir durchaus bewusst. Ich möchte dennoch in unserer jetzigen Version vom Artikel runter, um wieder zum Standard zurückzukehren. Dass wir aktuell überhaupt mit Artikeln arbeiten, liegt an einer Anpassung unseres früheren Partners. Und diese Anpassung ist leider nicht sauber, und hat auch nichts mit der Lösung in 2013 R2 zu tun.

Ich dachte man könnte die Lösung eventuell aus 2013 übernehmen.

Was hältst du davon, die Artikelzuschläge für die Speditionsbestellungen zu verwenden?

Vielleicht verstehe ich noch immer etwas falsch , aber meiner bescheidenen Information nach ist das der falsche Ansatz. Uns wird ja nicht damit unsere Ware angeliefert. Zum Zeitpunkt der Bestellung des LKWs gibt es noch keine gebuchte Verkaufslieferung, welche wir dem Zuschlag zuweisen können.

In den Verkaufsaufträgen ist das was anderes. Da arbeiten wir bereuts heute mit Artikelzuschlägen.

Wird die Bestellung zu diesem Zeitpunkt bereits gebucht? ansonsten könnte man die Bestellung über einen Zuschlag erfassen und bei Eingang der Speditionsrechnung dann zuweisen und buchen.

Ich dachte man könnte die Lösung eventuell aus 2013 übernehmen.

Das habe ich auch so verstanden
Ich gehe lediglich pessimistisch davon aus, dass der Weg zu umständlich wird (trotz der schönen Kopiervorlage). Kann auch eine totale Fehleinschätzung meinerseits sein (Hat das schon mal jemand von euch probiert...?).
Bräuchten wir hierzu eigentlich eine Lizenzerweiterung durch neue Tabellen? Kann mich an keine erinnern.

Wird die Bestellung zu diesem Zeitpunkt bereits gebucht? ansonsten könnte man die Bestellung über einen Zuschlag erfassen und bei Eingang der Speditionsrechnung dann zuweisen und buchen.

Buchungstechnisch geht das problemlos. Allerdings fordern unsere Anwender dann für diese Zuschläge eine streckenspezifische Beschreibung + EK-Preistabelle + Textbausteine (--> erscheint schließlich alles im gedruckten Beleg):

Da wir für die Bestellzeile Preise und Textbausteine abrufen müssen, bietet sich eine Ressource als Lösung an (eine kleine Anpassung vorausgesetzt).

Ich frage mich halt, welche Lösung am wenigsten Anpassungen erfordert, und trotzdem die Anforderung der Einkäufer abdeckt.

Hallo Natalie,

wir haben kürzlich bei einem Kunden die Ressourcen einkaufbar gemacht. Aus ähnlichen Gründen wie bei Dir.

Die Resourcen haben eine Produktbuchungsgruppe. Zusammen mit der Geschäftsbuchungsgruppe kannst du in der Buchungsmatrix die Einkaufskonten für die Transporte hinterlegen. Das Füllen der Ressourenposten aus dem Einkauf ist relativ einfach. Knifflig ist aber die FiBu_Buchung. Wir sind daher einen anderen Weg gegangen.

Wir haben eine Art-Alias für die Belegzeilen erfunden. In dem Feld ist neben den Werten des Standard-Art-Feld auch noch der Wert "Ressource" enthalten. Die Standard-Art und Nr. haben wir ausgeblendet. Wenn der Nutzer z.B "Art-Alias" = "Artikel" wählt, dann wird auch "Art" = "Artikel" gesetzt. Wenn der Benutzer "Art-Alias" = "Ressource" wählt, dann wird die Art "Sachkonto" gesetzt. Als "Nr-Alias" kann man dann auch Ressourcen auswählen. Ist die Ressource gewählt kann aus der Buchungsmatrix das entsprechende Sachkonto geholt werden und in das echte Feld "Nr." übertragen werden. Beim Buchen füllen wir die Ressourcenposten per Anpassung. Die kniffligen Sachbuchungen werden aber mit den Standard-Routinen ausgeführt.

Unser Kunde hat sehr viele unterschiedliche Ressourcen (Z.B. Transport, Palettisierung, Containerbeladung, ...) und die Buchen das auf viele verschiedene Sachkonten. Wir haben dazu eine Ressourcen-Buchungsmatrix erfunden. Dadurch bläht man die Produktbuchungsgruppe und die Buchungsmatrix nicht so auf. Das muss man aber nicht so machen.

Meld Dich gern, wenn Du Dir das mal näher anschauen möchtest.

Herzlichen Gruß

Andreas Koblischke