[Gelöst] Paketverfolgungsnummer

Guten Morgen,

ich bräuchte mal eine Rat aus der Praxis. Man kann ja im Auftrag die Paketverfolgungsnummer eingeben. Bei uns ist der Ablauf eigentlich Lieferschein und Rechnung erstellen => Paket packen, LS und RG in Paket => Versand.

Nun lässt mich NAV aber die Paketnummer nicht mehr nachtragen, da ja die Belege schon gebucht sind. Wie macht Ihr das denn?

Das ich direkt auf die SQL-Tabellen gehen kann ist mir klar, aber ich wollte eigentlich einen sauberen Weg.

Volker

Zuletzt geändert von vsnase am 29. November 2012 11:38, insgesamt 1-mal geändert.

Hallo volker,

also ich kann die sagen wie wir das machen.

Ein Auftrag ist bei uns im Haus wird gefertigt, die Rechnung/Lieferschein gedruckt und dann nach dem Packen kommt der Paketaufkleber auf das Päckchen und dieses wird dann für den Postausgang gescant. Danach erhält der Auftrag bei uns die Pakelverfolgungsnummer und wird gebucht.

P.S.: Bei uns gibt es allerdings keine Vorkasse oder Teillieferung

Ihr bräuchtet evtl. eine Anpassung, bei der die Paketverfolgungsnummer nach dem Paketscan in die gebuchten Rechnungen übernommen wird.

Das sollte euer Partner erledigen können.
z.B. Property Permissions: TableData Sales Invoice Header=rimd

mfg,
winfy

Zuletzt geändert von winfy am 29. November 2012 10:39, insgesamt 1-mal geändert.

Ein Auftrag ist bei uns im Haus wird gefertigt, die Rechnung/Lieferschein gedruckt und dann nach dem Packen kommt der Paketaufkleber auf das Päckchen und dieses wird dann für den Postausgang gescant. Danach erhält der Auftrag bei uns die Pakelverfolgungsnummer und wird gebucht.

Wie kannst du Lieferschein und Rechnung drucken, und danach erst den Auftrag buchen?

Ein Auftrag ist bei uns im Haus wird gefertigt, die Rechnung/Lieferschein gedruckt und dann nach dem Packen kommt der Paketaufkleber auf das Päckchen und dieses wird dann für den Postausgang gescant. Danach erhält der Auftrag bei uns die Pakelverfolgungsnummer und wird gebucht.

Wie kannst du Lieferschein und Rechnung drucken, und danach erst den Auftrag buchen?

Bei uns werden die Aufträge nicht manipuliert sondern kommen aus einem Shopsystem.
Dort werden schon die Rechnungen gedruckt. Navision ist hier nur nachgelagert.

Das mit dem Lieferscheinen war allerdings von mir wirklich falsch dargestellt, diese kommen aus dem Navision und werden erst nach dem Buchen erzeugt. Diese werden allerdings auch in kein Paket getan, da wir das nur für unsere Filialbelieferungen benötigen.

mfg,
winfy

Zuletzt geändert von winfy am 29. November 2012 10:45, insgesamt 1-mal geändert.

Ein Auftrag ist bei uns im Haus wird gefertigt, die Rechnung/Lieferschein gedruckt und dann nach dem Packen kommt der Paketaufkleber auf das Päckchen und dieses wird dann für den Postausgang gescant. Danach erhält der Auftrag bei uns die Pakelverfolgungsnummer und wird gebucht.

Wie kannst du Lieferschein und Rechnung drucken, und danach erst den Auftrag buchen?

Bei uns werden die Aufträge nicht manipuliert sondern kommen aus einem Shopsystem.
Dort werden schon die Rechnungen gedruckt. Navision ist hier nur nachgelagert.

mfg,
winfy

Das ist natürlich schon eine wichtige Info

Das ist natürlich schon eine wichtige Info

Ja, das ist richtig.

Zurück zum Thema,
Bei Volker müsste man meiner Meinung nach, nach dem Paketscan die Verfolgungsnummer in die gebuchten Lieferungen übernehmen.

z.B. Property Permissions: TableData Sales Shipment Header=rimd

mfg,
winfy

Hi Winfy,

was meinst Du mit "Property Permissions: TableData Sales Shipment Header=rimd"?

Wo soll man das denn setzen?

Volker

Also wenn du im Navision scanst oder den Scan importierst, dann musst du bzw. dein Partner die Rechte so vergeben, das die Paketverfolgungsnummer in die gebuchte Lieferungen geschrieben werden kann.

Schau mal unter der Permissions Property in der Hilfe.

Sets whether a database object has additional permission required to perform some operations on one or more tables. The operations can be to read, insert, modify, and delete data.

Applies To
Codeunits
Dataports
Forms
Pages
Reports
Tables
XMLports

After you set the Permissions property of an object, only users with direct permission to perform all the extra operations that the object has been given can modify this object.

Do not use the Permissions property to give extra permissions to an object that you would like your users to be able to modify. These users might not have direct permission to perform these operations. This is why you should be careful when you use the Permissions property for tables and forms.

mfg,
winfy

Zuletzt geändert von winfy am 29. November 2012 11:24, insgesamt 1-mal geändert.

Hallo,

Prinzipiell hast du eigentlich drei saubere Möglichkeiten:
1. Wenn du nur ein Paket pro Lieferung hast, kannst du im Anschluss die Paketverfolgungsnummer in den gebuchten Lieferschein (unter Lieferung im Kopf) eintragen (oder besser scannen), das Feld ist editierbar.
2. Wenn du ohne Logistik arbeitest, dann packst du den Auftrag, erfasst die Paketdaten, und buchst die Lieferung (dabei könntest du dann Frachtkosten, Anzahl Pakete, Gewichte noch erfassen, bevor der Beleg gebucht wird) während des Buchens der Lieferung (egal ob mit oder ohne Rechnung) werden dann u.U. die Paketdaten eine Software eine Paketdienstes übergeben. (Wenn alle Informationen bekannt sind, dann kannst du Rechnung und Lieferung schon vor dem packen buchen, der Ablauf bleibt aber der gleiche). Nach dem Tagesabschluss des Paketdienstes oder sofort (je nach Software) kannst du die Paketnummer dann wieder einlesen und dem Lieferschein zuordnen.
2. Du produzierst mit jeder Lieferung ein Sendung, oder führst mehrere Lieferungen später zu einer Sendung zusammen, bevor diese dann gebucht wird, gibst du die Paketdaten der Sendung ein, und buchst das ganze.(Ablauf ähnlich wie 2. aber mit zusätzlicher Ebene)

was meinst Du mit "Property Permissions: TableData Sales Shipment Header=rimd"?

muss er nicht machen, die Tabelle ist editierbar, die gesperrten Felder in der Form verhindern die Eingabe/Änderung

Gruß, Fiddi

was meinst Du mit "Property Permissions: TableData Sales Shipment Header=rimd"?

Wo soll man das denn setzen?

In Endkunden-Lizenzen ist der Zugriff auf die Tabellen gebuchter Belege eingeschränkt (sofern er nicht das Granule 7300 Solution Developer besitzt).
Für die Geb. Verkaufslieferungen gibt es bereits die Codeunit 391 "Shipment Header - Edit", welche dem Endanwender die "zweite Hälfte" der indirekten Schreibberechtigung erteilt.
Dort ist auch schon berücksichtigt, dass folgende Felder durch den Endanwender geändert werden können:
- "Shipping Agent Code"
- "Shipping Agent Service Code"
- "Package Tracking No."

Sollten auch gewisse Felder in Geb. Verkaufsrechnungen und/oder Geb. Verkaufsgutschriften nachträglich geändert werden können, so müssten hierfür entsprechende Codeunits angelegt werden, welche nach demselben Prinzip wie die Codeunit 391 agieren.

Ein Endanwender (ohne Granule 7300) kann selber jedoch keine Permissions auf die geschützten Tabellen vergeben, das müsste dann der zuständige Microsoft Partner erledigen.

Permissions auf Form-Ebene zu setzen widerspricht dem Sinn der indirekten Berechtigungen, da der Anwender dann alle Felder der Tabelle ändern dürfte.
Dies kann bei gebuchten Belegen mächtig in die Hose gehen.

Ich betrachte das mal von meiner Seite aus als gelöst. CU391 war mir bis jetzt nicht bekannt. Das eröffnet ja zur Anbindung externer Paketscheinprogramme ganz neue Möglichkeiten.

Danke

Volker

Ich betrachte das mal von meiner Seite aus als gelöst. CU391 war mir bis jetzt nicht bekannt. Das eröffnet ja zur Anbindung externer Paketscheinprogramme ganz neue Möglichkeiten.

Danke

Volker

Ja, so kann man auch gleich aus Navison heraus einen Link setzen und das Tracking des jeweiligen Versandanbieters verwenden.
Das ist eine super Sache.

mfg,
winfy

Permissions auf Form-Ebene zu setzen widerspricht dem Sinn der indirekten Berechtigungen, da der Anwender dann alle Felder der Tabelle ändern dürfte.
Dies kann bei gebuchten Belegen mächtig in die Hose gehen.

Hallo Timo,

eine Frage dazu:
Angenommen man möchte das auch im Standardfeld 106 in den gebuchten Rechnungen.

Das mit einer neuen Codeunit wäre natürlich die feinere Variante, aber wenn er beispielsweise in einem neuen Report das Property Permissions zum editieren gesetzt bekommt und nach einem Import der Scans nur in das Feld Paketverfolgungsnummer schreiben würde, hätte er innerhalb des Reports die Rechte in alle Tabellenfelder zu schreiben - richtig.

Mit einer normalen Kundenlizenz könnte er aber ohnehin den Report nicht weiter manipulieren, da sich der Report mit den Permissions bei erneuten Änderungen im Report nicht kompilieren lassen würde - oder?

Wo würde da etwas in die Hose gehen?

mfg,
winfy

was meinst Du mit "Property Permissions: TableData Sales Shipment Header=rimd"?

Wo soll man das denn setzen?

In Endkunden-Lizenzen ist der Zugriff auf die Tabellen gebuchter Belege eingeschränkt (sofern er nicht das Granule 7300 Solution Developer besitzt).
Für die Geb. Verkaufslieferungen gibt es bereits die Codeunit 391 "Shipment Header - Edit", welche dem Endanwender die "zweite Hälfte" der indirekten Schreibberechtigung erteilt.
Dort ist auch schon berücksichtigt, dass folgende Felder durch den Endanwender geändert werden können:
- "Shipping Agent Code"
- "Shipping Agent Service Code"
- "Package Tracking No."

Sollten auch gewisse Felder in Geb. Verkaufsrechnungen und/oder Geb. Verkaufsgutschriften nachträglich geändert werden können, so müssten hierfür entsprechende Codeunits angelegt werden, welche nach demselben Prinzip wie die Codeunit 391 agieren.

Ein Endanwender (ohne Granule 7300) kann selber jedoch keine Permissions auf die geschützten Tabellen vergeben, das müsste dann der zuständige Microsoft Partner erledigen.

Permissions auf Form-Ebene zu setzen widerspricht dem Sinn der indirekten Berechtigungen, da der Anwender dann alle Felder der Tabelle ändern dürfte.
Dies kann bei gebuchten Belegen mächtig in die Hose gehen.

Als Zusatzinfo: Für Unternehmen ohne Granule 7300 lassen sich auch nicht modifizierte Objekte abspeichern, wo vorher schon permissions drauf waren. Also CU391 selbst anpassen ist nicht möglich. Das muss dann der Partner vornehmen, sofern man nicht Granule 7300 hat.

Ja, so kann man auch gleich aus Navison heraus einen Link setzen und das Tracking des jeweiligen Versandanbieters verwenden.
Das ist eine super Sache.

Ich dachte das andersrum:

- Auftrag erstellen
- Lieferschein/Rechnung buchen und drucken
- Lieferschein-Daten an Paketscheinprogramm automatisch übergeben (Datei, Webservice-Aufruf, SQL-Trigger, ...)
- Paketschein erstellt Aufkleber
- und dann über die CU als NAV-Webservice die Daten automatisch an NAV zurückschreiben.

Das ist dann ja richtig rund.

Volker

Permissions auf Form-Ebene zu setzen widerspricht dem Sinn der indirekten Berechtigungen, da der Anwender dann alle Felder der Tabelle ändern dürfte.
Dies kann bei gebuchten Belegen mächtig in die Hose gehen.

Hallo Timo,

eine Frage dazu:
Angenommen man möchte das auch im Standardfeld 106 in den gebuchten Rechnungen.

Das mit einer neuen Codeunit wäre natürlich die feinere Variante, aber wenn er beispielsweise in einem neuen Report das Property Permissions zum editieren gesetzt bekommt und nach einem Import der Scans nur in das Feld Paketverfolgungsnummer schreiben würde, hätte er innerhalb des Reports die Rechte in alle Tabellenfelder zu schreiben - richtig.

Mit einer normalen Kundenlizenz könnte er aber ohnehin den Report nicht weiter manipulieren, da sich der Report mit den Permissions bei erneuten Änderungen im Report nicht kompilieren lassen würde - oder?

Wo würde da etwas in die Hose gehen?

mfg,
winfy

Ich sprach ja auch von Forms
Wie Jan kurz nach dir schrieb, ist es Kunden ohne Granule 7300 nicht möglich, Objekte zu verändern, in denen Permissions auf Tabellen enthalten sind, auf welche der Kunde nur eingeschränkte Rechte hat.
Somit kann man auch einen Report mit den entsprechenden Permissions ausstatten, da dieser ja nur über C/AL Code bestimmte Feldwerte ändert.

Permissions auf einer Form würden es dem Anwender gestatten, alle (auf der Form enthaltenen) Felder in der jeweiligen Tabelle zu ändern.
Und das kann zu einem Daten-Chaos führen.

Ich dachte das andersrum:

- Auftrag erstellen
- Lieferschein/Rechnung buchen und drucken
- Lieferschein-Daten an Paketscheinprogramm automatisch übergeben (Datei, Webservice-Aufruf, SQL-Trigger, ...)
- Paketschein erstellt Aufkleber
- und dann über die CU als NAV-Webservice die Daten automatisch an NAV zurückschreiben.

Das ist dann ja richtig rund.

Volker

Okay, das klingt auch gut.

Bei uns ist das nicht so einfach automatisch möglich, da wir viele verschiedene Versandfirmen haben.
Bei uns werden neben dem Paketschein die Versandaufkleber (mit der Pakettrackingnummer) noch extra aufgeklebt.

mfg,
winfy

Ich sprach ja auch von Forms
Wie Jan kurz nach dir schrieb, ist es Kunden ohne Granule 7300 nicht möglich, Objekte zu verändern, in denen Permissions auf Tabellen enthalten sind, auf welche der Kunde nur eingeschränkte Rechte hat.
Somit kann man auch einen Report mit den entsprechenden Permissions ausstatten, da dieser ja nur über C/AL Code bestimmte Feldwerte ändert.

Permissions auf einer Form würden es dem Anwender gestatten, alle (auf der Form enthaltenen) Felder in der jeweiligen Tabelle zu ändern.
Und das kann zu einem Daten-Chaos führen.

Okay, dann ist gut.
Es hätte ja auch sein können, das ich da bei meiner dargestellten Logik etwas übersehen hatte.

mfg,
winfy

Bei uns ist das nicht so einfach automatisch möglich, da wir viele verschiedene Versandfirmen haben.
Bei uns werden neben dem Paketschein die Versandaufkleber (mit der Pakettrackingnummer) noch extra aufgeklebt.

mfg,
winfy

Warum nicht? Es gibt doch noch die Felder Zustellercode und Zustellertransportart. Je nach Zustellercode werden die Daten an das jeweilige Paketprogramm übergeben. Nix dramatisches.

Volker

Warum nicht? Es gibt doch noch die Felder Zustellercode und Zustellertransportart. Je nach Zustellercode werden die Daten an das jeweilige Paketprogramm übergeben. Nix dramatisches.

Volker

Mag sein, das nutzen wir auch, aber wir wissen nicht immer im vorraus wie ein Paket versendet wird.
Das richtet sich nach der Menge der im Auftrag befindlichen Artikel, Gewicht, Größe und Ankunft der Versandfahrzeuge.
Theoretisch könnte man hier auch Regeln hinterlegen, aber das entscheidet bei uns der Verantwortliche im Versand.

Der hat da seine 5 Rollen mit verschiedenen fertigen Versandaufklebern und klebt die dann dementsprechend auf.

mfg,
winfy

Warum nicht? Es gibt doch noch die Felder Zustellercode und Zustellertransportart. Je nach Zustellercode werden die Daten an das jeweilige Paketprogramm übergeben. Nix dramatisches.

Volker

Mag sein, das nutzen wir auch, aber wir wissen nicht immer im vorraus wie ein Paket versendet wird.
Das richtet sich nach der Menge der im Auftrag befindlichen Artikel, Gewicht, Größe und Ankunft der Versandfahrzeuge.
Theoretisch könnte man hier auch Regeln hinterlegen, aber das entscheidet bei uns der Verantwortliche im Versand.

Der hat da seine 5 Rollen mit verschiedenen fertigen Versandaufklebern und klebt die dann dementsprechend auf.

mfg,
winfy

Verantwortlicher Rollenabroller? Im Endeffekt musst Du ja sein "Kopfregelwerk" ins NAV gießen Aber dann wäre er nur noch Rollenabroller ohne verantwortung, da es dann NAV vorgibt.

Mag sein, das nutzen wir auch, aber wir wissen nicht immer im vorraus wie ein Paket versendet wird.
Das richtet sich nach der Menge der im Auftrag befindlichen Artikel, Gewicht, Größe und Ankunft der Versandfahrzeuge.
Theoretisch könnte man hier auch Regeln hinterlegen, aber das entscheidet bei uns der Verantwortliche im Versand.

Der hat da seine 5 Rollen mit verschiedenen fertigen Versandaufklebern und klebt die dann dementsprechend auf.

mfg,
winfy

Aber zum einen muss der doch auch irgendwie die Paketschein erstellen und zum anderen heißt das doch, dass euer Kunde gar keine Versandart vorgeben kann, wenn der liebe Gott in der Versandabteilung nach einem imaginären Regelwerk entscheidet, oder?

Volker

Verantwortlicher Rollenabroller? Im Endeffekt musst Du ja sein "Kopfregelwerk" ins NAV gießen Aber dann wäre er nur noch Rollenabroller ohne verantwortung, da es dann NAV vorgibt.

Hehe, ja man könnte das sicherlich auch ins Navision bringen, aber dann nehme ich ihm auch noch diesen Freiheitsgrad.

Der Versand muss bei uns auch auf die täglichen Gegebenheiten reagieren. Falls es mal Probleme mit einem Versandunternehmen gibt oder eins zu teuer wird, nimmt er dann fix ein anderes auf.

Aber zum einen muss der doch auch irgendwie die Paketschein erstellen und zum anderen heißt das doch, dass euer Kunde gar keine Versandart vorgeben kann, wenn der liebe Gott in der Versandabteilung nach einem imaginären Regelwerk entscheidet, oder?

Volker

Wäre sicherlich denkbar, aber momentan kann bei uns der Kunde nur entscheiden das er das Paket bekommt oder Selbstabholer ist.

Das Versandunternehmen wählen wir.
Versandkosten sind bei uns ohnehin pauschal, daher ergeben sich hier keine Unterschiede.

Wir haben allerdings mehrere Pauschalen abhängig von der Auftragsgröße.
Hat sich bis jetzt auch in der Praxis schon jahrelang so bewährt.

Das einzigste Problem ist gelegentlich nur die Angabe der Lieferadresse mit Packstation, die ja nur ein Versandunternehmen beliefern kann.

mfg,
winfy

Das wird der Rollenabroller wohl ohne Probleme hinbekommen. If Packstation then immer rolle D(HL)

Das wird der Rollenabroller wohl ohne Probleme hinbekommen. If Packstation then immer rolle D(HL)

Richtig, ich plädiere ja auch nicht dafür alle Regelwerke oder menschlichen Entscheidungen im Unternehmen in ein ERP-System zu gießen.

If Packstation then immer rolle D(HL)

Ja, so läuft das momentan auch.

P.S.: Der Versandleiter ist im übrigen nicht nur ein Rollenabroller...

mfg,
winfy