Hallo!

Wir spielen mit dem Gedanken in BaaN IV auf Lagerplatzverwaltung umzustellen. Aus diesem Grunde suchen wir eine Firma, die ähnlich
strukturiert ist und uns einige Tips zu dieser Unternehmung geben kann.

Geplanter Ablauf:
Einlagerung von Produktionsartikeln:

Produktionsauftrag + Etiketten mit Barcodeinfos erstellen ->produzierte Artikel auf Palette + Etikett -> Etikett (Barcode) wird gelesen ->
Einlagerungsvorschlag wird auf weiteres Etikett gedruckt (Lagerort) und auf Palette geklebt(?) -> Stapelfahrer lagert ein (Produzierte Menge wird dem Produktionsauftrag zugeordnet [in "Übergabetabelle" geschrieben]) ->
Weiterverarbeitung der "Übergabetabelle" über "Zeiten erfassen (Anpassung)"
Auslagerung:
Auf Kommissionierauftrag steht Lagerort der Ware - > Stapelfahrer lagert aus -> Etikett wird gelesen und Daten werden an "Übergabetabelle Auslagerung" übergeben -> Übergabetabelle wird über "Lieferungen verwalten+Anpassung" weiter verarbeitet.

...nur der grobe Ablauf.
Wir sind ein 3-Schichtbetrieb.Zur Zeit laufen die Verpackten Artikel gemischt über ein Rollenband ins Lager, werden dort je Auftrag gelagert wo Platz gerade
Platz ist (Stapelfahrer entscheidet). Bei der Auslagerung gibt's dann manchmal eine Sucherei....

Es wäre interessant zu hören, was man im Echtbetrieb noch alles beachten muss!

Ich freue mich auf jede Antwort.

Hallo,

wir betreiben unsere Lager mit ILC und automatischer LP-Findung bei der Einlagerung/Auslagerung. Die Steuerung/Verwaltung läuft vollständig in Baan (Baan4c4 SP 14 mit einigen Anpassungen in ILC).

Nur ein paar Anregungen:

Wichtig für eine automatische chaotische Einlagerung ist die Kenntnis über die Dimensionen jedes LP
(Höhe/Breite/Tiefe, Volumen des LP, belegtes Volumen, maximales Gewicht, belegtes Gewicht unter
Berücksichtigung von maximalen Feld- und Fachlasten).

Bei den Abmessungen sollte der Platz etwas kleiner angelegt werden als er tatsächlich ist (vor allem niedriger, der Staplerfahrer
braucht ja auch etwas "Manövrierfläche")

Bei den einzulagernden Einheiten müssen die Dimensionen der Umverpackung (!) bekannt sein. Sonst versucht das System überspitzt ausgedrückt schonmal einen Motorblock in ein Schraubenregal zu stellen (ähnliche Fälle sind uns passiert ;-) ). Mit den Abmessungen der Basiseinheiten kommt man nicht weit.

Ordentlich gepflegte Stammdaten sind elementar! Neue Artikel/Umverpackungen dürfen vom System erst eingelagert werden, wenn die Dimensionen bekannt sind (siehe oben...). Für solche Fälle müssen Fehlerplätze vorgesehen werden.

Was passiert wenn kein geeigneter LP mehr frei ist?

Immer beachten: so ein System hat (anders als der Staplerfahrer) kein Augenmaß. Es lagert einfach ein... .


Ich hoffe ich war nicht abschreckend.

Gruß
csecgn

Vielen Dank csecgn!

Die Wichtigkeit der Dimensionierung der LP und der einzulagernden Artikel mit ihrer jeweiligen Verpackung sehe ich auch als Grundvoraussetzung an.

Unsicher bin ich mir noch über den Zeitpunkt der Lagerplatzermittlung mit Reservierung des LP.

Beispiel: Heute ist der 5.10.04...
ein Produktionsauftrag über 10.000 Stück wird angelegt. Er benötigt 10 LP.
Der Beginn der Produktion ist für den 15.10.04 vorgesehen. Dauer 20 Tage.
(Planmäßiger Abgang duch VK-Auftrag ist für den 27.10.04 geplant.)

Wenn sofort 10 LP ab dem 15.10. resrviert würden, könnte ich im Voraus Etiketten mit dem "ermittelten LP" für jede Einheit drucken und sie während der Produktion anbringen lassen. Die Verpackungseinheiten werden dann gemischt mit 20 anderen Aufträgen über ein Rollenband ins Lager transportiert.

Der Lagerist sieht das Etikett mit dem LP drauf und kann ohne Zeitverlust
einlagern. Auf der Rollenbahn soll ein Barcode automatisch gelesen werden und die Daten für den Lagerzugang in eine "Übergabetabelle" geschrieben werden.
Damit wäre meiner Meinung die körperliche Einlagerung auch nachts um 2.30 Uhr und die Lagerbuchungen am nächsten Morgen per batch problemlos möglich.

Nachteil: Die 10 LP sind ab dem 15.10.komplett reserviert, obwohl der letzte LP erst am 24.10. benötigt würde, also 19 Tage "LEER" steht.

Muß man dies hinnehmen oder wird in der Praxis anders verfahren?

Solange die Lagerauslastung gering ist, ist das ja kein Problem aber wenn nicht, dann kostet es Geld...

Für's mitdenken vielen Dank im Voraus!


Gruß
Locher

...als steht der letzte LP nur 9 Tage leer. Tschudigung!

Gruß
Locher

Die Einlagerung bei der Lagerplatzverwaltung erfolgt über Einlagerungsvorschläge. Diese werden erstellt für die jeweils fertiggemeldete Menge. Eine Vorab-Reservierung für Produkte, die noch garnicht gefertigt sind, kann die Lagerplatzverwaltung leider nicht. Das heißt, Euer Produktionsauftrag muss erstmal (teil)fertig sein, bevor Ihr Einlagerungen generieren könnt. Auf die Produktionspapiere werdet ihr also die Lagerplätze vermutlich nicht draufbekommen. Ihr müsst die Generierung der Einlagerungsvorschläge (und damit die Ermittlung des Lagerplatzes) an die Fertigmeldung der Auftragsmenge koppeln. Kann das zeitlich klappen (weil Ihr bspw. mit BDE arbeitet) , oder meldet Ihr erst mit Tagen Verzug fertig?

Ulrich

Vielen Dank für die Info's!

Wenn die Ermittlung der LP an die Produktionsrückmeldung gebunden ist, dann hätten wir ein Problem.
Situation:
Die Paletten laufen nach Artikeln und Aufträgen bunt gemischt über 24 h über ein Rollenband in das Lager. Die Paletten müssen laufend vom Band entnommen und je VK-Auftrag/Lagerauftrag eingelagert werden.

Wenn ich mir vorstelle wir müssten je Palette einen Rückmeldung mit Einlagerungsvorschlag machen und dann erst einlagern, dann hätten wir ein zeitliches Problem, ganz abgesehen von den Mehrkosten für 3 EDV-Mitarbeiter (3-Schichten).

Andere Möglichkeit:
Wir sammeln die Artikel je Produktionsauftrag am WE-Platz und lagern mehrere Paletten gleichzeitig ein. Das wäre schön, dazu müssten wir aber ein größeres Lager bauen - kriege ich leider auch nicht durch.

Wie machen das andere Firmen mit LP-Verwaltung?

Gruß
Locher

Wenn Ihr einen gewissen Aufwand nicht scheut, würde ich fast eine Art "Schattenlagerbestand" mit eigenen Tabellen analog den Standard ILC Tabellen aufzubauen. In dieses Lager bzw. auf diese Lagerplätze können die Paletten eingebucht werden ohne Probleme mit dem Baan Standard zu bekommen. Die Synchronisation müsste dann paralell zu ALV freigeben bzw. ELV erstellen (dann aus den Schattenplätzen) und freigeben erfolgen.
Für diese Schattenplätze können auch zu beliebigen Zeitpunkten ELV erstellt werden (z.B: Bsp. bei oder vor dem aufsetzen der Paletten auf das Förderband/beim Druck der Etiketten). Dabei ist es dann egal ob ein Produktionsauftrag zurückgemeldet ist oder ob nicht. Es gibt keine oder zumindest weniger Probleme mit dem Standard (Korrektursessions wie tdilc0250m000) gibt.

Nur so eine Idee.


Gruß
csecgn

P.S.: Wie bzw. wann werden eigentlich zur Zeit die Produktionsaufträge und damit die Lagerbestände zurückgemeldet?

Hallo csecgn!

Der Gedanke mit der Schattenlagerplatzverwaltung nenne ich "Parallele LPV",
aber vom Gedanke her ist es das Gleiche!

Ich denke wir werden wie folgt verfahren:

IST-ZUSTAND
- Produktionsaufträge anlegen und Arbeitspapiere drucken

Zugang durch Produktion:
Produktionsrückmeldung jeweils morgens manuell für über
- Zeiten erfassen bzw.
- Prod.-Aufträge fertig melden

Abgang:
Hauptsächlich über Lieferungen verwalten.
--------------------------------------------------------------
Nachteile IST-Zustand:
- Beim Auslagern / Kommissionieren verlieren wir teilweise Zeit wegen
ärgerlicher Sucherei. (Lagergröße: 80m x 100 m)
- Es gibt keine schnelle Übersicht "Wo lagert was?"
- Lageroptimierung mangelhaft - keine durchgängige Einlagerung nach
Prioritäten z.B.: Kunde / Artikel-Nr. / Lieferdatum
- Lagerbestand und Auftragsfortschritt ist nur morgens aktuell.
(wird in Kauf genommen, weil BDE bzw. zusätzliche MA auf Grund der
Kosten-Nutzenrechnung nicht sinnvoll erscheinen)
==================================================
Bedachte Lösungsmöglichkeiten:
==================================================
a) Umstellung des Lagers auf die Standard-Lagerplatzverwaltung

Vorteil:
- Bessere Lagerübersicht u.
- teilweise Zeitersparnis bei der Auslagerung
Nachteil:
- Zeitverlust durch Einlagerungsvorschläge und Auslagerungsvorschläge
( evtl. Zusatzkosten für EDV und MA)
- Keine Lagerung nach Kunde, VK-Auftrag, Liefertermin möglich
( wir arbeiten ohne Projekt )
-----------------------------------------------------------------
b) Arbeiten wie bisher, jedoch schaffen einer möglichst automatischen
"Parallelen Lagerplatzverwaltung".

Geplanter Ablauf:

- P-Auftrag erstellen und Unterlagern drucken (ohne Etiketten)
(dabei VK-Auftragsnummer bzw. Kd-Nr. erfassen - ist bereits realisiert)
- Kurz vor Produktionsbeginn wird der Lagerplatz im Rahmen des
Etikettendruckes (mit LP) automatisch nach bestimmten Vorgaben
festgelegt
- und in eine eigene Lagerplatzbewegungstabelle als geplanter Zugang
mit Gesamtmenge und Menge je LP und ggf. VK-Abgangsdaten geschrieben
+ Reihenfolge der geplanten Einlagerung nach LP.
=> Aufgrund von geplantem Zugangs- und Abgangsdatum ergibt sich
eine "LP-Bewegungswarteschlange"! :)
- Während der Produktion werden die Verpackungseinheiten mit den Etiketten
versehen und über das Rollenband in das Lager transportiert.
Einlagerung
- Der Lagerist kann ohne Verzug sofort einlagern!
- *Am nächsten Morgen buchen wir die Produktionsrückmeldung mit den
Standardprogrammen + einer kleinen Anpassung (Die Rückmeldemenge wird
je Produktionsauftrag in der Reihenfolge der geplanten Einlagerung auf die
LP der eig. Lagerplatzbewegungstabelle in das Feld IST-Menge verteilt.)

Auslagerung

- Grundlage: Report Kommissionierauftrag
(Auf Grund der Keys in der "Parallelen LPV-Tabelle" kann man
die Auslagerungsplätze (in umgekehrter Reihenfolge der Einlagerung)
drucken.
- Beim Druck des Lieferscheines wird die Menge im LP entsprechend
vermindert. Falls die Menge = 0 ist wird der Satz gelöscht.

Sonstige Überlegungen

- Die Richtigkeit der Planungsdaten wie Produktionsbeginn u. Lieferdatum
sowie u. die sonst üblichen Rahmenbedingungen sind das A und O !
=>Änderungen dieser Daten muss ich wohl in den Sessions nachziehen!
- LP-Verwaltung muss auch manuell geändert werden können
- "RESTE" in den Lagerplätzen werden auf der LP-Ansicht farblich markiert
und sollten zum "RESTE"-LP umgelagert werden
- Um LP nicht unnötig lange zu reservieren müsste man den Etikettendruck
bei langen P-Aufträgen für Teilmengen durchführen.
- Die LP-Übersicht kann man nach verschiedenen Keys sortieren: z.B.:
- Kunde / VK-Auftrag / Artikel
- Artikel
- geplanter VK-Liefertermin
- P-Auftrag
- ...

Vorteile zum IST-Zustand

- Zeitgewinn bei der Einlagerung (keine Überlegung bezüglich LP nötig)
- Visuelle Transparenz der LP-Belegung für JEDEN!
-> Suche bestimmter Artikel über Keys möglich
- Zeitgewinn bei der Auslagerung (keine Suche notwendig)

Nachteile

- Falls die Ein- und Auslagerungen nicht wie geplant durchgeführt wird,
muss man manuell korrigieren.
- viel Arbeit für mich... :(
- Kosten für den Kauf einiger Sessions

Optimierungen

* Eine tolle Sache wäre das automatische Lesen der Barcodedaten je Palette
-> Übergabe der Daten an eine Baan-Tabelle und die Fortschreibung der
Lagerzugangsdaten für LP (oder auch P-Auftrag und Lager).
Leider habe ich keine Ahnung wie das Lesen des Barcodes und die
Übergabe an eine Baan-Tabelle zu realisieren ist)

Hat hier vielleicht jemand Erfahrungen?

Gruß und Danke für die bisherigen Hilfe

ES IST HALT DOCH EIN GUTES FORUM!

Hallo Locher,

der Begriff "Parallele LPV" beschreibt das was ihr wollt wirklich besser. Ihr solltet eventuell auf die Standard Lagerplatzverwaltung verzichten. Die Sortierungen/Funktionen die euch vorschweben, gehen damit nicht (zumindest nicht ohne Anpassungen die auf eine halbe Neuprogrammierung hinauslaufen. Da fahrt ihr mit einer kompletten Eigenentwicklung möglicherweise besser. Und ILC könnt ihr immer noch als Vorlage nehmen).

Zum Thema Barcodeleser:
Baan IV Sessions haben die Angewohnheit auf <Enter> den Standard-Continue Button auszulösen (aber nur den!). Und Barcodeleser (über Tastaturweiche) kann man so programmieren das sie an den String (= gelesene Barcodedaten) ein <Enter> anhängen. Nach meiner Meinung nehmt lieber Leser die nicht direkt auf den Barcode aufsetzen müssen (also z.B aus 20 cm Abstand noch lesen können). Das ist einfacher im Handling für die Lageristen. Wenn auch sicherlich teurer in der Anschaffung. Zumal bei Industriequalität.

Gruß
csecgn

Hallo zusammen,
interessante Diskussion. Haben wir vor zwei Jahren auch geführt. Ich bin der Meinung das man sich durch Standard Baan ILC mehr Nach- als Vorteile einhandelt, besonders in Eurem Fall.
Wir arbeiten ebenfalls im 3-Schicht-Betrieb, haben ein ähnlich großes Lager und haben uns für eine Schattenlagerwirtschaft zum vereinfachten Auffinden der Artikel entschieden. Simpel aber effektiv mit Baan Tools programmiert, so daß der Anwender nicht bemerkt das eigentlich gar kein ILC vorhanden ist. Auf eine Synchronisation der Bestände verzichten wir (die Praxis gibt uns recht ;) ). Barcodes zu lesen ist kein Hexenwerk und zum Glück kann man den Scannern auch etwas "Intelligenz" verpassen.

Martin

:)
Guten Tag Martin Jung,

vielen Dank für deine Antwort!
Ich war mir recht unsicher ob die Idee einer Schatten-Lagerplatzverwaltung in der Realität funktioniert. Auf Grund der returns bin ich heute aber sehr optimistisch die Idee erfolgreich in die Tat umzusetzen zu können!

Natürlich will ich die Sache noch weiter automatisieren und eventuell Barcodeleser einsetzen.

Ich sehe bei erfolgreichem Einsatz des Barcodelesers folgende Vorteile:

- automatische AG-Rückmeldung und Lagerzubuchung
(Die Abbuchung ist wohl zu aufwendig - da 10 Rampen zu bestücken wären)
=> dadurch gewinnen wir Zeit und der Auftragsfortschritt wäre sehr aktuell

Da ich hier aber noch recht unerfahren bin, bitte ich um Info's bezüglich

Etikett: ( ->es soll auf einem Rollenband am Lesegerät vorbeifahren )

- Welchen Code sollte man benutzen? (Code 128 habe ich mal auf
einem Etikett realisiert)
- Funktioniert das automatische Lesen auf ein "vorbeifahrendes" Etikett
problemlos? und wie weit darf das Etikett vom Lesegerät entfernt sein?

- Sind die Geräte funktionssicher, oder sollte man ein Reservegerät vorhalten?

- Gibt es Begrenzungen bezüglich der Länge des Barcodes?
( Für eine Rückmeldung braucht man doch relativ viele Daten...)

und das wichtigste:

- Welche Hardware und Software wird für solche Zwecke verwendet?

=> Wie funktioniert die Geschichte im Gesamtablauf?

Idealerweise stelle ich es mir wie folgt vor:

Barcodeleser liest gesammte Daten des Etiketts -> schreibt bei erkennen eines
"Satzendezeichens" den Satz in eine ASCII-Datei (auf ein Serverlaufwerk)

Baansession (zeitgesteuert) liest die Sätze -> erledigt die Rückmeldungen -> setzt Erledigtzeichen in die ASCII-Datei...usw.

Geht das so, oder denke ich hier zu einfach?

--------------------------

Viele Grüße

Hallo Locher,
zum Barcode-Druck und -Verarbeitung lässt sich aus meiner Sicht folgendes sagen:


Barcodes lassen sich aus Baan nur mit BW-Print drucken, es sein denn man steuert den Drucker speziell an. Der EAN-128 ist der einzig vernünftige aus der begrenzten Auswahl an Barcodetypen bei BW-Print. Der EAN-128 lässt sich zuverlässig und sicher lesen (Prüfziffer nicht vergessen!). Bezüglich Lesegeschwindigkeit und -abstand gibt es in der Regel Empfehlungen des Scanner Herstellers.

der Barcodeleser oder Scanner fungiert in der Regel nur als Ersatz für eine Tastatur und füttert dem entsprechend eine Session oder schreibt die Daten in eine Datei, die wiederum weiterverarbeitet wird. Zusätzliche Software ist nicht nötig. Barcodes haben je nach Typ eine endliche Länge, maximal die Länge, die der Scanner noch lesen kann. Eventuell mehrere Barcodes erzeugen.

Das Weiterverarbeiten der Daten kann entweder direkt in der jeweiligen Baan Session erfolgen oder offline mit einem AFS-Skript. Online hat naturgemäß einige Nachteile (Fehlerbehandlung, Verfügbarkeit etc.). AFS halte ich für das beste und "schonenste" Mittel die Daten in Baan zu bekommen.

Alles in allem halb so wild, vorausgesetzt das Konzept ist Baan-konform und in sich schlüssig.

Als Nachhilfe in Sachen Barcodes empfehle ich folgende Lektüre:

http://www.mikodata.de/download/dl_strichcodefibel.pdf (http://)

Gruss

Martin

:)
Vielen Dank an ALLE!

Die Infos waren für mich sehr hilfreich!

Grundsätzlich ist das geschilderte Verfahren (ASCII-Datensätze) möglich. Zu beachten ist aber das Datei-Handling zwischen Baan und dem externen Leser/Software-System. Insbesondere sollte man ausschließen, dass Baan und dieses System gleichzeitig auf die ASCII-Datei zugreifen, also beispielsweise mit einer zusätzlichen Kontrolldatei oder anderen locking-Mechanismen arbeiten.

Tatstatureingeschleifte Scanner, die eine Baan-Session direkt ansprechen würden, empfehlen sich in Eurem Fall nur, wenn Bann wirklich 100% stabil läuft, und man nicht davon ausgehen muss, dass ein temporärer Stillstand von Baan die phyische Einlagerung am Lager lahmlegt.

Ulrich