Heart-Profit ERP
June 26, 2024, 10:26:05 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 ... 273
361  Heart-Profit Boards / Heart-Profit ERP Support / Re: INVECO-Gids 2016 on: May 11, 2016, 04:45:30 pm
Goed. Dan houden we het even op 2 uur en dan in de context van wat we hier hebben besproken. Dus 1 positie erbij voor de ZBK die je bij het Artikel ziet en ook 1 positie bij dat LOZBKRA gebeuren. Als je zelf denkt dat dit alles is, dan gaan we daar voor nu vanuit. Als er later ergens alsnog iets moet worden aangepast dan horen we dat wel.

Voor de zekerheid nog even dit : ik vind het raar dat 1 zo'n positie ineens 2 characters kan bevatten. Maar goed, de VVVF zal wel raar zijn (of niet soms ? haha). Ik verwacht dus meer "ellende".
362  Heart-Profit Boards / Heart-Profit ERP Support / Re: INVECO-Gids 2016 on: May 11, 2016, 04:13:24 pm
Kijk, naar zoiets zochten we. Super !

Ik heb nog een klein beetje hulp nodig :

Wij zien in de programmatuur kontroles op 000N. Ik heb het niet echt erop nagekeken, maar heb in mijn hoofd "met 000N helemaal niets aan de knikker !". En juist omdat ik dat zie en het vermoeden al had dat zo'n kontrole wellicht niet meer op gaat *en* dat ik nu geen N in het lijstje meer aantref ... hoe moet dat dan, nu ?
Is de N soms M geworden ?

En hoe moeten we omgaan met klanten die de oude codering nog erin hebben staan ? Dus kijk naar jullie zelf ... stel je verandert niets, wat betekenen de (oude !) codes dan vanaf heden ?

Moraal (denk ik) : Er is een nieuw veld nodig. En waar dat dan gebruikt moet worden ...
Ofwel, leuke moraal maar niet handig.
Verder denk ik ook dat er wellicht hier en daar iets op printjes of weet ik veel moet worden aangepast.

Het toeval wil dan ook nog dat ooit in een grijs verleden speciaal voor jullie iets met Toevoegen / Wijzigen / Verwijderen ZBK codes is gemaakt, en ook al kan ik zo snel niet vinden waar die funktie uithangt (in hangt), hij heet LOZBKRA. Die kan dus 1 letterige codes toevoegen enz. en wat overigens in tabel LOZB terecht komt.

Ik zei al, dit gaat ons net even te snel (lees : er komt vast meer bij kijken, wil je het goed doen).

Help ! smile smile


363  Heart-Profit Boards / Heart-Profit ERP Support / Re: INVECO-Gids 2016 on: May 11, 2016, 03:24:11 pm
Dit gaat ons net even te snel ... Maar dit ook onder het motto dat Google niet van ZBK en SIRE lijkt te houden. En Inveco ? nou, die (VVVF site) vertelt ons ook niet veel (met wel voorzichtig de opmerking dat dit VVVF-dedicated lijkt te zijn?)

Als we naar de oude SIRE code kijken (zie helptekst van de ZBK rubriek) - en dus ook met de wetenschap dat de ZBK eigenlijk de oude SIRE is, dan zie je dat e.e.a. positiegebonden is; het is niet zo maar een willekeurige code.
En was/is SIRE/ZBK ook wel VVVF-dedicated ?

Samengevat : leid ons eens naar een pagina of dokument enz. waaruit wij kunnen leren hoe dit tegenwoordig in elkaar zit ? Dat ik er helemaal niets over vind, vind ik al raar (kan zeker niet Googlen).

Dank !
364  Heart-Profit Boards / Heart-Profit ERP Support / Re: retouren naar leverancier on: April 28, 2016, 08:56:13 am
Quote
leg eerst maar eens uit waarom je dat niet kunt gebruiken

Kan je uitleggen waarom je dat niet kan gebruiken ?
Wink
Ja, ik ben er ook niet zo goed in hoor, maar ...
365  Heart-Profit Boards / Heart-Profit ERP Support / Re: Help-functie niet bereikbaar on: April 21, 2016, 01:27:42 pm
Ik heb het zojuist weer opgezocht, maar waar ik hetzelfde ervaar als eerder (te weinig uitleg) ben ik nu "gefocused" en zie ik dat er weliswaar Help is, maar domweg onvoldoende.
Ik heb even niets gezegd. Wink
366  Heart-Profit Boards / Heart-Profit ERP Support / Re: Help-functie niet bereikbaar on: April 20, 2016, 02:30:08 pm
Richard, domme vraag misschien, maar kan het zijn dat wij daar zelf ook last van hadden (vorige week - twee weken terug) ?
Ik weet dat we niet overàl helptekst bij maken, maar ik trof nu toch wel redelijk essentiële dingen aan zonder Helptekst waarvan je ook nooit kan raden hoe het werkt zonder die Helptekst. Dat was in AD trouwens.
367  Heart-Profit Boards / Heart-Profit ERP Support / Re: Scanterminal Ophalen Grondstoffen voor Produktiekaart (LOTSSTPK) on: April 20, 2016, 02:06:57 pm

Dit betreft een aangepaste versie van de uiteenzetting in de eerste post;
Het deel wat in de eerste post was genoemd :
Afboeken Grondstoffen Produktieorder
heet nu :
Afboeken Grondstoffen Produktieorder - Aangepaste versie
(met Ctrl-F te vinden)
Het aangepaste deel eindigt bij :
Einde Aangepaste versie

In het algemeen kan over de aanpassing worden opgemerkt dat het Afboek gedeelte oorspronkelijk middels de Scanterminal was voorgesteld, waar dit nu is veranderd naar "normaal Profit". De reden van de aanpssing ligt in het (nog) niet onderkend zijn van een deel in de procedure als geheel, en het uiteindelijk alleen maar ONhandiger zou zijn om dit ontbrekende deel via de scanner te doen (denk in het algemeen aan Bijstellingen).


Met ingang van heden is er een nieuw Scanterminal scherm ontwikkeld t.b.v. het ophalen van voorraad voor een Produktieorder.


In het kort:

We hebben een Produktieorder waarbij diverse grondstoffen in een Produktiekuip moeten worden gemengd.

Deze grondstoffen worden opgesplitst in drie categoriën:

a. Zakgoed (welke alvorens te kunnen produceren eerst opgehaald moet worden uit het Grondstoffenmagazijn)

b. Silo produkten (worden afgehandeld met een separaat Scanterminalscherm, zie http://ha1.heartprofit.nl/profit/index.php?topic=27327.0)

c. Vloeibare produkten (zoals additieven, welke buiten beschouwing worden gelaten en worden geacht aanwezig te zijn op de Produktievloer).

Het hier beschreven Scanterminalscherm focust zich op de eerste categorie: het ophalen van "zakgoed".

Hierbij treden vervolgens weer drie situatie's op:

1. Ophalen van volle zakken uit het Grondstoffenmagazijn die rechtstreeks in de P.O. kunnen worden gebruikt.

2. Ophalen van volle zakken uit het Grondstoffenmagazijn ter aanvulling van de voorraad op de weeglokatie.

3. Het afwegen van de resthoeveelheid op deze weeglokatie.


Een medewerker gaat het magazijn in, raapt de goederen die nodig zijn voor deze Produktieorder (en weegt ze zonodig af). Deze goederen worden overgeboekt naar een 'Verplaatsbare Lokatie'; een zgn. (rode) Produktieorderkaart. Als alle grondstoffen voor de Produktieorder opgehaald zijn, kontroleert iemand de opgehaalde grondstoffen, en wordt het geheel overgeboekt naar de Produktievloer. De voorraad wordt dan overgeboekt naar een (gele) Produktieorderkaart.  De goederen die op de Produktieorderkaart gescand zijn kunnen vervolgens in de P.O. worden afgeboekt.

Het initiële ontwerp bevat nog meer onderwerpen zoals 'vaten-orders' en 'rapen voor een Produktiestap'; vooralsnog is dit deel niet ontwikkeld (zie verderop).



Uitgangspunten:
* Geen Kenmerken
* Alleen ophalen van "Zakgoed"
* Als een grondstof meerdere malen in een Produktieorder-Recept voorkomt, betreft dit alleen "vloeibaar" (hetgeen anders wordt afgehandeld).



Disclaimer
Voor de klant voor wie dit maatwerk ontwikkeld is, geldt dat Profit niet zo is ingericht zoals wij dit normaliter zouden doen. Omdat dit niet logisch is ingericht geldt dat sommige werkwijzen die door Profit standaard gehanteerd worden niet ingezet kunnen worden, en waardoor we tegen problemen aanlopen die anders standaard niet aan de orde zijn. Dit alles zorgt er ook voor dat er slecht nagedacht kan worden over hoe e.e.a. nu eigenlijk echt moet. Mogelijk blijkt later nog dat een bepaalde inrichting alsnog anders moet...

Om iets konkreter te zijn noem ik de Produktiemagazijnen, die bij deze klant beginnen met G2, G6 of G8.

G2 = Malerij
G6 = Mengerij
G8 = Bulk

Binnen Profit geldt als hoofdregel dat een Produktiemagazijn met een "P" dient te beginnen; P2, P6 en P8 zou wat dat betreft geen probleem zijn geweest. Een "Produktiestation" binnen een Produktiemagazijn begint volgens Profit-termen met dat Produktiemagazijn, vervolgens een "S" van ProduktieStation, en gevolgd door nog twee letters, bijvoorbeeld een volgnummer. P6S01 zou een eerste menger kunnen zijn in het Magazijn P6.

Standaard geldt dat bij het Gereedmelden van een Produktieorder Profit voorraad kan afboeken die "in het Produktiemagazijn ligt"; ofwel, iedere Lokatie die kwa eerste twee posities overeenkomt met die van het Produktiestation. Een Produktieorder op P6S01 mag derhalve standaard alle voorraad afboeken van P6-Lokaties. Stel dat we nog drie mengers in Produktiemagazijn P6 hebben (P6S02, P6S03 en P6S04) dan mogen zeze alle 4 putten uit de voorraad die op deze P6-Lokaties ligt. Op die manier zouden we bijv. "Additieven", die in kleine hoeveelheden benodigd zijn op de Produktievloer, op P6000 (of P6ALG) neer kunnen leggen en kan iedere P6Sxx order als vanzelf uit die voorraad afboeken.
Indien gewenst is het ook mogelijk om Profit zodanig in te richten dat ieder Produktiestation alleen uit haar eigen voorraad mag afboeken. Dit kunnen we inrichten bij het Produktiestation, en zorgt ervoor dat als we een vat met additieven naar P6S01 hebben verplaatst, alleen een order op dát station uit dat vat kan afboeken. Zou een order op P6S02 hetzelfde produkt nodig hebben, dan zal ze zelf een vat moeten gaan ophalen.

Een Produktieorder op P6S01 kan dus standaard voorraad afboeken van iedere P6-Lokatie... maar NIET van de G6 lokatie (zoals het in deze praktijk situatie is ingericht). Om toch voorraad van andere lokaties af te kunnen boeken wordt een parameter 'misbruikt' die we ooit  voor een klant ontwikkeld hebben die helemaal geen Lokaties wilde onderhouden, maar slechts de totale voorraadhoeveelheid bij wilde houden, ongeacht Charges en ongeacht waar deze in het systeem lag. Voor die situatie hebben we een parameter "Grondstoffen Afboeken van iedere Lokatie toegestaan J/N" ontwikkeld, en welke de standaard Lokatie kontrole op "moet voldoen aan Produktiemagazijn" uitschakelt. Ja, dit zal er ook voor zorgen dat de grondstof rechtstreeks vanaf de G6 Lokatie kan worden afgeboekt. Helaas kunnen we ook ongewenst:

* voorraad kunnen afboeken uit het G2/G8 magazijn
* voorraad kunnen afboeken uit een Expeditiemagazijn (goederen die zijn klaargezet voor verzending naar klanten)
* voorraad kunnen afboeken van klantlokaties
* voorraad kunnen afboeken uit een Externe Magazijnen (bijv. een magazijn in het buitenland)
* voorraad kunnen afboeken van de RaperLokaties of Ophaalkaarten die met dit maatwerk gevuld worden

Her en der zijn in de loop der jaren al wat aanpassingen gedaan om dit niet te snel te fout te laten gaan, maar toch... "Afboeken van alle Lokaties" leidt tot ongewenste situaties !!

Nb: Als er een specifieke noodzaak was geweest om e.e.a. op deze manier te gebruiken, dan was het beter geweest als hiervoor een parameter was ontwikkeld waarmee we hadden kunnen aangeven uit welke magazijnen er ongestrafd mag worden afgeboekt. Dat zou tot minder ongewenste problemen leiden.

Merk hierbij ook op dat als we Profit klakkeloos de oudste charge laten afboeken, ongeacht vanaf welke lokatie we dit doen, er nooit iets zal kloppen van een traceability. Ook al zouden we iets expliciet naar de Produktievloer verplaatsen, Profit boekt toch wel de oudste partij af. Deze werkwijze zal dan ook altijd gepaard moeten gaan met handmatig de juiste partij af te boeken, willen we nog wat aan de traceability hebben.

Naast Goederen af te boeken van de Produktievloer is het ook mogelijk om per Produktieorderregel expliciet aan te geven vanaf welke Lokatie de voorraad afgeboekt moet worden. Deze methode (oorspronkelijk ontwikkeld om een tanklokatie in te kunnen vullen) gaan we nu gebruiken om deze met de juiste G2/G6/G8 lokatie te vullen; de lokatie die representatief is met alle voorraad die voor de Produktieorder is opgehaald. Ondanks dat het pakket dan niet is ingericht zoals wij dat voor ogen hebben, kan het nieuw ontwikkelde Scanterminalscherm toch werken zonder dat daarvoor het pakket anders ingericht hoeft te worden.

Let op:
Daarmee is niet gesteld dat een formelere manier van inrichten helemaal van de baan is ! Immers, ook in dit ontwerp is gesproken over bijv. "additieven". Vloeibare produkten die in kleine hoeveelheden in orders worden afgeboekt. Produkten die al "op de Produktievloer aanwezig horen te zijn". Maar, wil Profit hierin sturend kunnen zijn, zal Profit moeten weten hoeveel liter er op de Produktievloer ligt, hoeveel er nodig is, en hoeveel er nog moet worden opgehaald. Profit zou kunnen weten hoeveel we 'te kort' komen en daarin sturend kunnen optreden. Omdat we deze additieven voor nu buiten beschouwing laten, is de noodzaak voor het anders inrichten van de Produktiestations en Produktiemagazijnen nog even niet aan de orde, maar toch... het zou wel beter zijn. Merk op dat als we een vat met een bepaald additief van Charge B naar de Produktievloer P6-000 zouden hebben geboekt, en we dat additief willen afboeken, Profit zelf al kan weten dat dit Charge B betreft, immers een ander vat ligt er niet. Laten we dit vat op G6 staan, dan zullen we handmatig het juiste vat moeten gaan selekteren, hetgeen fouten in de hand werkt.
Merk ook op dat een Profit consultant slecht kan meedenken over werkwijzen als e.e.a. niet wordt ingericht zoals we dit in Profit voor ogen hebben liggen. Zolang de Produktiemagazijnen niet formeel "P-Lokaties" zijn, zal de parameter "Afboeken Grondstoffen van alle Lokaties J/N" op "Ja" gezet moeten worden (om die additieven die op een niet P-Lokatie liggen überhaupt af te kunnen boeken), met de (even terug) beschreven problemen tot gevolg.



Voordat we aan de slag gaan : Begrippen / Inrichten

Klaarzet-/Produktieorderkaarten
Klaarzet- en Produktieorderkaarten zijn in Profit niet veel meer dan een normale Lokatie; een Lokatie die representatief is voor een Produktieorder. De voorraad op die Lokatie omvat alle grondstoffen die we voor een specifieke Produktieorder hebben opgehaald uit het magazijn (danwel hebben afgewogen op de weeglokatie). Waar deze voorraad zich in werkelijkheid bevindt weten we niet; dat is "waar we de pallet met die voorraad hebben neergezet". Dit zal op zich een vaste plek in het Magazijn zijn, daar waar de opgehaalde goederen worden verzameld (lees: klaargezet) voor produktie. Maar, het kan net zo goed zijn dat er ergens een chauffeur met een palletwagen rondrijdt die de kaart aan het vullen is.

Om dit soort Lokaties duidelijk te kunnen herkennen begint iedere soort kaart met zijn eigen 2 letters-/cijfers (het Magazijn) en zijn de fysieke kaarten gekleurd.

Voor de klant voor wie e.e.a. ontwikkeld is geldt:

Rode kaarten zijn klaarzetkaarten. Dit zijn lokaties die beginnen met "G5". Middels een rode klaarzetkaart worden goederen opgehaald voor een Produktieorder, ongeacht of deze op G2, G6 of G8 wordt geproduceerd). De klant zelf gebruikt één rode klaarzetkaart per Produktieorder, maar wij hebben bedacht dat ook meerdere kaarten inzetbaar moeten kunnen zijn; bijvoorbeeld één per verzamelde pallet.

Nadat alle goederen zijn opgehaald en zijn (gewogen en) gekontroleerd, gaan de goederen door naar een "produktielokatie": het betreffende "G2/G6/G8 magazijn".
De goederen worden dan overgeboekt naar een Produktiekaart die voor ieder magazijn een eigen kleur heeft:
G2 = Zwarte kaart (Malerij)
G6 = Groene kaart (Mengerij)
G8 = Gele kaart (Bulk)


Vloeibare produkten
Vloeibare produkten worden in dit scherm uitgesloten. Het zou handig zijn geweest als we dit konden herkennen op basis van de Voorraadeenheid van het Artikel, bijvooreeld 'alles wat in zakgoed op voorraad ligt betreft KG' en 'alles wat vloeibaar is heeft een Voorraadeenheid "Liters"'. Helaas is dit niet het geval. Derhalve is bij een Artikel een rubriek "Vloeibaar J/N" opgenomen.

Tijdens de Upgrade waarmee deze aanpassingen op uw systeem zijn geplaatst zal er een konversie draaien die alle Artikelen in de Voorraadeenheid "Liters" automatisch als "Vloeibaar = Ja" opneemt. Aanvullend (doch alleen voor de klant voor wie dit maatwerk ontwikkeld is) geldt dat ook alle Artikelen die in Drums op voorraad geregistreerd worden als vloeibaar opgenomen zullen worden.



Nb: In een later stadium zal een "Vaten Order" hierin nog uitgezonderd worden; zie ook verderop.

Rapers en Raper-Lokaties
Een Raper is een medewerker die met behulp van een Scanterminalscherm goederen gaat rapen, in dit geval voor een Produktieorder. Voorraad die hij 'ophaalt' wordt administratief overgeboekt naar een zgn. Raper-Lokatie, zijnde een Lokatie die begint met bijv. de letters "RP" (instelbaar met een parameter) en verder gevolgd door zijn Userid (waarmee hij inlogt op de Scanterminal).




Voordat we aan de slag gaan : Parameters

T.b.v. deze funktionaliteit is TouchScreen-/Scanterminal Parameters uitgebreid met een aantal parameters:



Grondstoffen ophalen met P.O. kaart J/N
Middels deze parameter kan het alhier beschreven maatwerk worden geaktiveerd. Hoewel we in Profit praktisch nergens met "Dynamische Menu's" werken, doen we dat in dit geval wel. Op die manier zal het Scanterminalmenu alleen anders worden ingedeeld bij de klanten die dit maatwerk aktiveren. Voor de overige klanten blijft het menu zijn oude volgorde hanteren. Deze parameter staat u toe om dit maatwerk eerst in de Testbestanden uitvoerig te testen alvorens dit in de Produktiebestanden in gebruik wordt genomen. Ook zal de wetenschap dat dit scherm gebruikt wordt in andere Touchscreen-/Scanterminal schermen gebruikt kunnen worden om net even wat meer-/minder kontroles uit te voeren.



Grondstoffenmagazijnen
Middels deze parameter kunnen we formeel aangeven welke Magazijnen onze "Grondstoffenmagazijnen" betreffen. Meerdere Magazijnen dienen met komma's te worden gescheiden. De opname van deze parameter is om eenduidiger aan te kunnen geven waar onze grondstoffen opgehaald moeten worden, in plaats van "nog een nieuwe uitzondering" te introduceren op de reeds bestaande, maar niet voor dit doel bestemde parameter "Grondstoffen afboeken van alle Lokaties toegestaan J/N".

Magazijn met Weeglokaties
Middels deze parameter kan worden aangegeven in welk Magazijn zakgoed afgewogen moet worden. Uitgangspunt is dat deze weeglokatie als separaat Magazijn wordt gedefinieerd, en waarbij de Lokaties in dit Magazijn "Baknummers" zijn die representatief zijn voor alle grondstoffen die in produktie afgewogen moeten worden. Iedere Lokatie in dit Magazijn zou een "Baknummer" moeten zijn, en dient slechts voorraad van één Artikel te bevatten.

Prefix Raper Lokatie
Middels Hmenu-F5-F5-R dient op Tabblad #1 de Raper-Prefix te worden ingevuld.
Om hier "RP" in te kunnen vullen zal er eerst een Magazijn "RP" moeten worden toegevoegd, en daarna zal er per Raper (Userid) een Lokatie moeten worden toegevoegd. Zou user "WR" dit scherm gaan gebruiken, dan moet er een lokatie "RPWR " zijn gedefinieerd.





Tabblad #1 - Produktiekaart

Op het eerste Tabbblad van het nieuwe Scanterminalscherm Scannen we een (rode) Produktiekaart. Indien dit een "nieuwe" kaart is, waarop nog geen grondstoffen zijn geraapt voor een Produktieorder, kan middels de tweede textbox de Produktieorder voor welke we de goederen gaan ophalen gescand worden (is feitelijk verplicht op dat moment). Zodra het eerste produkt op deze kaart geboekt is, zal deze kaart formeel aan die Produktieorder worden gekoppeld. Wordt de kaart dan voor een tweede keer gescand, dan hoeft de Produktieorder niet nogmaals te worden gescand immers van de Produktiekaart is dan al bekend voor welke Produktieorder deze bestemd is.
De detailgegevens van de Produktieorder worden getoond op het scherm.



Onder de gegevens van de Produktieorder wordt middels buttons aangegeven wat we voor deze Produktieorder gaan doen.

* Vaten order
* Volle zakken ophalen
* Wegen

Omdat het scherm zelf "de volgorde" afdwingt waarin we het ophalen van grondstoffen moeten afhandelen, valt er eigenlijk niets te kiezen hier. Hooguit wordt de button "groen" van de keuze die het systeem bepaalt, waarmee het scherm aan de gebruiker aangeeft: we gaan nu volle zakken ophalen uit het grondstoffenmagazijn.
De buttons staan overigens ook op volgorde waarin we te werk gaan. Zouden er vaten op te halen zijn in een vaten order, dan zullen we die niet bovenop het zakgoed gaan leggen; die doen we dus altijd als eerste. Daarna gaan we volle zakken ophalen, en als laatste stap gaan we de produkten ophalen-/afwegen voor de weeglokatie.

Nb:
* Omdat "Vaten-orders" nog even zijn uitgesloten, zal deze button vooralsnog disabled blijven.
* Merk op dat we hier de Produktieorder scannen en niet een Produktieorderregel.

Middels F1 kan de Gebruiker verder naar het volgende scherm.



Tabblad #2 - Regels Produktiekaart

Dit Tabblad wordt enabled nadat Tabblad #1 is verwerkt, maar dit tabblad is in dit stadium nog niet aan de orde (ook al is ze nu enabled) en wordt aldus verderop uitgelegd (waar het wel aan de orde is).


Tabblad #3 - Op te halen Artikelen

Na F1 (op het 1e Tabblad) weet het systeem voor welke Produktieorder we de grondstoffen moeten gaan ophalen, immers deze worden bepaald door de grondstoffen die zijn opgenomen in de regels van de betreffende Produktieorder. Artikelen die als 'Vloeibaar = Ja' zijn gedefinieerd, en Artikelen die op voorraad liggen in een 'Silo Verschijning' worden uit deze behoeftelijst verwijderd, immers die zullen op een andere wijze dienen te worden afgeboekt. Van de resterende Artikelen (het zakgoed) bepaalt het systeem of er 'volle zakken' opgehaald kunnen worden (d.w.z. grondstof die niet behoeft te worden afgewogen - zie ook verderop). Zo ja, dan worden die Artikelen hier op het scherm gepresenteerd. De raper mag zelf bepalen in welke volgorde die volle zakken opgehaald gaan worden; misschien vindt hij/zij het wel handig om de grondstoffen die als laatste nodig zijn als eerste te rapen (immers, dan komen die onderop de pallet te liggen).



Nb: Om geen informatie prijs te geven over het konkrete Recept zijn Artikelomschrijvingen deels geblurd, en zijn ook hoeveelheden gewijzigd.

N.b.: Met het ophalen van "volle zakken" bedoelen we redelijk expliciet dat dit niét af te wegen produkt betreft (dit is een aparte stap, die verderop wordt behandeld). Het mag dan zo zijn dat in het grondstoffenmagazijn geen aangebroken zakken behoren te liggen (voor de klant voor zie dit maatwerk is ontwikkeld) maar evengoed kan het systeem hier best mee omgaan.

Op dit Tabblad wordt een overzicht opgebouwd van die Artikelen waarvoor "volle" Verschijningen kunnen worden opgehaald in het Grondstoffenmagazijn. Een Artikel (en zo ook een grondstof) kan meerdere Verschijningsvormen hebben. Als we naar het 1e produkt op het scherm kijken, de PC150, dan ligt deze in zakken van 25 Kg op voorraad (25.00ZG) maar ook in BigBags van 400 Kg (BB400). De raper moet kunnen bepalen wát hij gaat ophalen, en derhalve kunnen we op dit scherm nog niet tonen "hoeveel" (Verschijningen) er opgehaald moet worden. Wél geldt dat als hier de Verschijningsvorm 'Big Bag 400 Kg' vermeldt wordt, dit impliceert dat er in het Magazijn een "volle" Big Bag staat die in zijn geheel in de Produktieorder kan worden verwerkt. Stel dat we slechts 50 Kg nodig zouden hebben dan zou een Big Bag van 400 Kg nooit vermeldd worden, immers die bevat teveel voorraad om in zijn geheel in de kuip te kunnen worden gegooid. Echter, betreft het een te wegen produkt omdat er niets anders is dan de Big Bag dan verschijnt deze uiteraard wel (wederom, zie verderop).

Het kan ook voorkomen dat we een grondstof bij verschillende Leveranciers inkopen en dat de één zakken van 20 Kg levert en de ander zakken van 25 Kg. Om die reden kunnen we nooit eerst beginnen met de "weegartikelen", immers de af te wegen hoeveelheid zal afhangen van de hoeveelheid volle zakken die we opgehaald hebben. Stel dat we 30 Kg nodig zouden hebben en we pakken een zak van 25 Kg, dan zal er nog 5 Kg moeten worden afgewogen uit een tweede zak (of in elk geval "uit" de weeglokatie). Hebben we een zak geraapt met 20 Kg erin, dan zal er nog 10 kg moeten worden afgewogen uit een tweede zak. Resumer: we zullen eerst "volle" zakken gaan rapen, en daarna, in een volgende stap de "weegprodukten" gaan afwegen.

Als het produkt maar in 1 Verschijningsvorm op voorraad ligt in de Grondstoffenmagazijnen, dan zal het scherm al meteen tonen hoeveel zakken van welke inhoud er opgehaald moeten worden (zie 6 x 25 Kg bij FC004 danwel 2 x 25 Kg bij FS001).

Nb: Op het scherm worden alleen die grondstoffen getoond die ook daadwerkelijk geraapt kúnnen worden. Als er géén voorraad is zal het produkt niet in de lijst worden opgenomen.



Tabblad #4 - Voorraaditems

Nadat op Tabblad #3 is aangegeven welk Artikel opgehaald moet gaan worden (in dit voorbeeld de PC150) volgt Tabblad #4.



Dit scherm toont hoeveel voorraad we hebben van welk Chargenummer, en waar deze voorraad zich bevindt. Het overzicht respekteert de eerder genoemde parameter "Grondstoffenmagazijn" en toont dus alleen die voorraad waarvan bekend is dat ze opgehaald mag worden (en waarbij we dus ook niet uit een "kaart lokatie" van een andere order kunnen rapen, of zouden kunnen rapen van een lokatie waar we niet bij kunnen (het magazijn in het buitenland)). Het overzicht presenteert altijd het Chargenummer, maar, het overzicht is daar niet noodzakelijk op gesorteerd. Kwa sortering respekteert het overzicht de setting van de Systeemparameter voor "FIFO Afboeken". Die kan bijv. op "Datum Charge" zijn ingesteld, opdat de oudste charge altijd als eerste moet worden vermeld. Het is dus zaak dat de raper probeert de eerst-genoemde Charge op het scherm te rapen, opdat de FiFo Parameter zoals (niet voor niets) ingesteld wordt gerespekteerd. Voor nood kan weliswaar een eerste regel (of meer) worden overgeslagen, maar "procedure" mag het niet zijn.

Per batch toont Profit waar deze voorraad ligt, en hoeveel er van die partij ligt. Indien er meer Voorraaditems zijn dan op het scherm passen, zal er automatisch een scrollbar ontstaan waarmee de overige Voorraaditems kunnen worden bekeken. In dit voorbeeld ligt alle voorraad op 1 Lokatie, maar indien Lokaties zijn ingericht als Magazijnstelling, laag, vaknummer dan kan de raper direkt zien waar naar toe moet worden gelopen om de partij op te halen. Op basis van de wetenschap dat in het voorliggende scherm meerdere Verschijningsvormen werden getoond (25.00ZG + BB400) weet de gebruiker dat er meerdere Verschijningen aan de orde kunnen zijn die voldoen. Welke partij de raper ophaalt wordt uiteindelijk bepaald door de betreffende batch te scannen. In dit voorbeeld scant de Gebruiker als eerste "de big bag" op Lokatie G4AA1.


Tabblad #5 - Rapen (voor Produktie)

Nu eenmaal bekend is welke batch de Gebruiker gaat ophalen, is de Verschijningsvorm en de inhoud bepaald, en kan het systeem bepalen hoeveel er van deze partij geraapt moet worden. In het geval van het scannen van de Big Bag van 400 Kg geldt dat we 1 Verschijning moeten rapen.
Informatief wordt ook in het scherm getoond dat we in totaal nog 462.817 Kg nodig hebben van dit produkt; halen we daar de 400 Kg van de Big Bag af, dan blijft er nog een behoefte van 62.817 Kg over.



Met F1 wordt de Big Bag 'geraapt' en op de Produktiekaart geboekt; dit door de Voorraad over te boeken van de Voorraadlokatie (G4AA1) naar de Ophaal-/P.O. Kaart Lokatie (G5AC3).  Omdat er nog meer "volle" Verschijningen te rapen zijn, keert het scherm terug naar Tabblad #4 en kan een volgend item worden gescand.



Ik scan vervolgens een partij waarvan er 40 zakken van 25 Kg op een pallet liggen.
Het scherm geeft aan dat ik 2 Verschijningen moet rapen voor deze Produktieorder.



"Onder water" wordt deze partij formeel "gesplitst" en zal voor het afgesplitste deel een nieuw Subchargenummer worden gegenereerd. Omdat de gesplitste partij straks rechtstreeks in de Produktiekuip zal worden gegooid, zal niemand zitten te wachten op het printen van een formeel etiket voor deze gesplitste partij. Hoewel het mogelijk is dat er een etiket geprint wordt (op basis van de inrichting van Koppelingen Queue-/Funktie voor Funktie LOTSSTPK geacht Bedrijf & Gebruiker), zal, indien deze koppeling wordt ingesteld als "Printen naar een File" er geen etiket worden afgedrukt !

Als we op Voorraad kijken, zien we wel dat de 2 items een nieuwe Subcharge (26290310803) toegekend hebben gekregen (de gescande partij betrof 26290310802).



Merk op dat het enerzijds handig is dat we geen etiket hoeven te printen, immers, we hoeven dan ook niet naar een printer te lopen om het etiket op te halen en op de gesplitste partij te plakken. Het niet printen van een etiket impliceert echter ook dat als iemand zou besluiten om de Produktieorder alsnog niet uit te voeren, we geen etiket hebben die we kunnen scannen om de voor de Produktiekaart geraapte goederen weer terug te leggen in het Magazijn. Mocht dat alsnog nodig zijn, dan kunnen we altijd nog vanuit Profit een etiket printen voor een Voorraaditem. Uiteraard kunnen we ook besluiten om gewoon standaard een etiket te printen, maar deze alleen op te halen in de situatie dat we de goederen willen terug gaan leggen in het magazijn.

Zodra er geen "volle" zakken meer te rapen zijn in het Grondstoffenmagazijn, verdwijnt dit Artikel uit de lijst op Tabblad #3.



De procedure met "selekteren Artikel, scannen batch, rapen aantal Verschijningen" herhalen we tot het hele scherm met Artikelen waarvoor we volle Verschijningen kunnen ophalen leeg is. Daarna keert het hoofdscherm terug.



De raper rijdt nu met de palletwagen naar de klaarzetlokatie en laat de (laatst volgestapelde) pallet daar achter.
Vervolgens begint de raper met een nieuwe doorloop: het ophalen van goederen voor de weeglokatie + het afwegen van de goederen.

Let op :
Op dit moment is het systeem niet goed in staat om te gaan met de situatie dat er weliswaar is begonnen met rapen voor de betreffende Produktieorder, maar "nog (!) niet" alle voorraad aanwezig is. Dus, bovenstaande procedure volgend, zie je dat het systeem automatisch overgaat van het rapen van "volle" zakken naar het afwegen (hieronder); zou er intussen nieuwe voorraad ontstaan (Goederen Ontvangst) dan moeten we dus weer terug naar het deel '"volle" zakken rapen' en kan het zelfs zo zijn dat op te halen zakken voor het wegen (zie hierna) nog een volgende doorloop kent, en/of in elk geval als procedure expliciet moet kunnen worden gekozen. Op dit moment kan dit dus niet !


Tabblad #1 - Scan P.O. Kaart / Wegen

Als de gebruiker de volle zakken heeft opgehaald dan laat ze deze pallet achter bij de klaarzetlokatie.

In de praktijksituatie van de klant neemt de raper vervolgens de (rode) Produktiekaart weer mee, en begint met een nieuwe doorloop: het ophalen en wegen van de weegartikelen.

In onze optiek zou je eigenlijk niet de pallet zonder kaart achter mogen laten, immers, als iemand de pallet ziet staan in het magazijn, ligt er geen kaart op, en weten we dus ook niet welke voorraad er op ligt, en voor welke P.O. ze is opgehaald. Op zich mág dit zo werken met één rode kaart, maar we hebben erin voorzien dat het ook mogelijk is dat de raper nu met een tweede (rode) kaart aan zijn vervolgopdracht begint.
N.b.: Hetzelfde fenomeen treedt op wanneer de raper meerdere keren heen en weer rijdt van klaarzetlokatie naar grondstoffenmagazijn, omdat de raper ook dan de rode kaart meeneemt.

Het "weegtrajekt" begint op precies dezelfde manier. De raper scant de (rode) Produktiekaart. Gaat de raper met dezelfde kaart op pad als waarmee de volle zakken zijn opgehaald, dan is van die kaart al bekend dat ze bij deze Produktieorder hoort en hoeft de P.O. niet nogmaals gescand te worden. Pakt ze een nieuwe kaart, dan zal ook de P.O. nog een keer gescand moeten worden.



Het scherm weet dat alle te rapen volle zakken zijn opgehaald, en triggert de volgende doorloop: Wegen.

Net als bij het ophalen van de volle zakken zal na F1 Tabblad #2 enabled worden, maar worden overgelagen omdat ze nog niet aan de orde is (zie uitleg verderop).
Tabblad #3 zal aldus aktief worden.



Tabblad #3 - Op te halen Artikel voor weeglokatie

Nog steeds is bekend voor welke Produktieorder we grondstoffen aan het ophalen zijn; Nu de volle zakken opgehaald zijn, kan Profit ook bepalen welke resthoeveelheden er nog moeten worden afgewogen. Maar... alvorens we naar de Weeglokatie gaan om aldaar grondstoffen af te wegen, vindt er eerst nog een andere stap plaats: het ophalen ten behoeve van de weeglokatie !

Het Scanterminalscherm weet niet alleen welke produkten er afgewogen moeten worden, maar ze weet ook hoeveel voorraad er van welk produkt aanwezig is op de weeglokatie. Daarmee weet ze ook op voorhand of er voldoende voorraad aanwezig is op de weeglokatie om hetgeen wat we willen afwegen af te kunnen wegen. Niets is lastiger dan dat we eerst naar de weeglokatie lopen, vervolgens konstateren dat de bak waarin het produkt wat we nodig hebben leeg is, om vervolgens naar het magazijn te moeten lopen, een nieuwe zak op te halen, daarna ons produkt kunnen afwegen, om vervolgens bij het volgende produkt te konstateren dat we daar ook te weinig voorrraad van hebben, en weer terug moeten naar het magazijn. De raper zou dan continue op- en neer aan het lopen zijn tussen de weeglokatie en het magazijn. Dit moet dus anders !

Nèt als dat we volle zakken gingen ophalen voor onze Produktieorder, bouwt Profit nu eerst een lijst op met de grondstoffen die we in onze Produktieorder nodig hebben, en waarvan niet voldoende voorraad aanwezig is op de weeglokatie. Eerst zullen we voor al deze Artikelen één zak uit het magazijn moeten gaan ophalen.



Op dezelfde manier als het ophalen van de volle zakken zullen we nu de produkten in dit scherm moeten doorlopen. Onder de Artikelomschrijving geeft het Scanterminal scherm nog aan hoeveel eenheden we nodig hebben (voor AT111 7.781), hoeveel er op voorraad ligt op de weeglokatie (1.438), en hoeveel we vervolgens tekort komen (6.343) en waarvoor we dus eerst een volle zak moet gaan ophalen uit het grondstoffenmagazijn.



Tabblad #4 - Ophalen voor de weeglokatie

Nadat we op Tabblad #3 een Artikel hebben geselekteerd, verschijnt ook nu weer Tabblad #4 welke ons toont waar we voorraad hebben liggen.
We gaan op zoek naar de partij en scannen deze.



Merk op dat onder in het scherm wordt vermeld dat we dit produkt aan het ophalen zijn voor de weeglokatie, en niet voor onze Produktiekaart.



Tabblad #5 - Rapen voor de weeglokatie

Op eenzelfde wijze als dat we volle zakken ophaalden, halen we ook hier de zak op voor de weeglokatie. Merk op dat we van één produkt altijd 1 zak mee zullen nemen. Nemen we niets mee, dan komen we te kort, en nemen we meer dan 1 zak mee, dan mag het uitgangspunt zijn dat we deze niet kwijtraken op de weeglokatie (omdat de bak zal overlopen). Aan 1 zak hebben we overigens ook altijd voldoende, want we zullen nooit meer dan 1 zak hoeven af te wegen; dan hadden we nl. in een eerdere fase nog wel een volle zak te rapen gehad.



De volle zakken die we aan het ophalen zijn voor de weeglokatie, zijn puur ter aanvulling van de voorraad in de bakken op die lokatie. Deze (volle) zakken mogen we niet op onze Produktiekaart boeken, immers als de raper zijn proces zou afbreken, zou er teveel voorraad op zijn pallet liggen. De voorraad die we rapen ter aanvulling van de voorraad op de weeglokatie wordt derhalve (administratief) op de Raperlokatie geboekt: RPWR in dit geval.



Wederom op dezelfde manier als het ophalen van volle zakken, herhaalt de procedure van het selekteren van Artikelen, Scannen van de Batch, en Rapen van de zakken zich totdat alle Artikelen waarvan niet voldoende voorraad aanwezig is op de weeglokatie geraapt zijn. Daarna verschijnt het scherm:



We zijn klaar met het rapen ("ophalen") van de grondstoffen voor de weeglokatie, en kunnen nu met alle voor die weeglokatie geraapte zakken naar de weeglokatie gaan. Ook als we nu het scherm zouden verlaten, en daarna opnieuw het ophaalscherm opstarten, dan weet het systeem dat we nog volle zakken bij ons hebben, en dat we daarmee naar de weeglokatie moeten.


Wegen (Algemeen)

In dit voorbeeld hebben we voor twee produkten een zak opgehaald uit het magazijn, omdat we op de weeglokatie niet voldoende voorraad hadden.

Op de weeglokatie kunnen er nu in praktijk verschillende situaties ontstaan. We kunnen altijd eerst de bak leegmaken, we kunnen de opgehaalde zak in de bak gooien, en dan uit de bak scheppen (waarbij we als eerste het verbruiken wat we als laatste erin gegooid hebben), maar, als we 18 Kg nodig hebben en 20 Kg in de opgehaalde zak hebben, kan het ook voorkomen dat we juist 2 Kg uit de zak halen, die in de bak gooien, en de rest van de zak (de 18 Kg) meenemen. Al dit soort situaties willen we niet expliciet gaan aansturen; de magazijnmedewerker zou eigenlijk alleen maar het netto resultaat moeten bevestigen; in de meeste gevallen maakt het nog niet eens uit ook.

Als een bak bijvoorbeeld Subcharge A.01 bevat (ofwel de 1e Subcharge van Hoofdcharge A) en de opgehaalde zak betreft Charge A.02, dan is dit feitelijk dezelfde partij als die al in de bak lag; hooguit is er een nieuw Subcharge toegekend om technische redenen (het splitsen). Of we nu uit de bak scheppen, of uit de zak, of uit beide, het is om het even immers de hoofdcharge impliceert dezelfde batch.

Zodra de nieuw opgehaalde zak echter een andere Hoofdcharge betreft (bijv. partij B.01) dan geldt dat die andere Hoofdcharge ook andere specifikaties kan hebben; misschien is de partij zelfs wel van een hele andere Leverancier afkomstig. Dit moeten we wel weten in onze traceability. In dit geval zullen we éérst de voorraad die nu in de bak ligt (A.01) eruit moeten scheppen, en pas daarna zullen we mogen afwegen uit de opgehaalde partij (B.01).
Op het Scanterminal scherm sturen we hier separate opdrachten voor aan.

Niet uitschepbare hoeveelheid

We hebben daarbij ook gedacht aan opdrachten als "maak eerst de bak leeg" bij de overgang naar een nieuwe Hoofdcharge, maar dat kan niet altijd. Immers, wie zegt dat we de bak uit het schap kunnen nemen en hem helemaal leeg kunnen maken? Wie zegt dat de hoeveelheid die het systeem zegt dat er nog in de bak ligt, ook daadwerkelijk uit de bak gehaald kan worden? Misschien zegt Profit wel dat er nog 3 Kg in de bak ligt, terwijl er fysiek nog maar 2,5 Kg in ligt. En, misschien ligt er dus wel 3 Kg in, maar kunnen we met de schep maar maximaal 2 Kg uit de bak scheppen, en we dus de laatste kilo er nooit uitkrijgen.

Uiteindelijk hebben we ervoor gekozen om bij een Lokatie een veld "Niet uitschepbare hoeveelheid" op te nemen. Per "Lokatie" impliceert hier per "Bak", en dus mag de ene bak een andere "schep" hebben dan een andere bak, waarmee in grotere danwel kleinere hoeveelheden geschept kan worden; bij een grotere handschep blijft er misschien 1 Kg achter, zouden we met een theelepel scheppen dan kunnen we meer uit de bak halen. Kunnen we de bak helemaal op zijn kop zetten, dan krijgen we alles eruit.

Niet te vergeten : deze meer moeilijk ogende procedure treedt alleen op wanneer (zo af en toe) de Hoofdcharge verandert.



Overigens zal er altijd FIFO uit de bak worden geboekt. Stel dat we 1 Kg er nooit uit kunnen scheppen, dan zal de Kg die achterblijft van de oude hoofdcharge, bij de eerst volgende boeking alsnog worden afgeboekt (anders blijft deze voor eeuwig in de bak liggen, en blijft het systeem melden dat er een nieuwe hoofdcharge opgehaald is).




Tabblad #6 - Wegen

Voor het wegen geldt dat we 1 of meerdere produkten moeten gaan afwegen. De volgorde waarin dit gebeurt is niet van belang; het is niet zo dat we (zoals bij het ophalen van volle zakken) een pallet moeten stapelen, en we het laatst benodigde produkt onderaan willen leggen opdat het eerst benodigde produkt bovenaan ligt. De gewogen produkten zitten allemaal in emmertjes bovenop de pallet. Desnoods worden (als het toegestaan is) meerdere grondstoffen in dezelfde emmer geworpen; voor het weegscherm maakt dit niet uit.

Profit bepaalt hoeveel artikelen er gewogen moeten worden, en maakt hier 'opdrachten' van die uitgevoerd moeten worden. De opdrachten die nu onderkend worden, zijn:

1. Schep uit de Bak
Treedt op indien:
a. er voldoende voorraad in de bak ligt, en er geen zak hoefde te worden opgehaald;
b. er onvoldoende voorraad in de bak ligt, maar de opgehaalde zak een andere Hoofdcharge impliceert.

2. Schep uit Bak of Zak
Treedt op indien er onvoldoende voorraad in de bak ligt, er weliswaar een nieuwe zak zojuist werd opgehaald, maar deze zak dezelfde Hoofdcharge impliceert als hetgeen nu in de bak ligt, en daarmee maakt het niet uit of we eerst uit de bak scheppen, eerst uit de zak, of wat dan ook, als we maar de gevraagde hoeveelheid afwegen, en (het restant van) de opgehaalde zak uiteindelijk maar in de bak gegooid wordt.

3. Schep uit Zak
Treedt op indien er helemaal geen voorraad in de bak ligt, en we zojuist een nieuwe zak hebben opgehaald. Of we nu eerst de zak in de bak gooien en daarna uit de bak scheppen, of dat we eerst uit de zak scheppen en daarna de rest in de bak gooien is om het even.


In onderstaande schermprint een voorbeeld van het Tabblad wegen. Links bovenin wordt het produkt genoemd welke we moeten afwegen. Daaronder staat het Baknummer (G9WB4) waaruit het produkt geschept moet worden (omdat dit produkt in die bak ligt). Rechts op het scherm zien we een grote 7. Deze geeft aan dat we in totaal 7 weegopdrachten hebben.



In dit geval (Hoofdcharge is veranderd) moeten we nu 1.438 Kg uit de bak met nummer G9WB4 halen. Omdat we geen "Charges" kunnen scannen, verplicht het scherm dat we het Baknummer scannen, opdat Profit kan bevestigen dat het juiste produkt geraapt is (gaat worden).

Als bovenstaande verwerkt is (F1) volgt automatisch de volgende opdracht; nu moet er nog eens 6.343 Kg uit de zak worden gehaald (die zojuist is opgehaald).
De 7 is nu gewijzigd in een 6, omdat we (met deze erbij) nog 6 weegopdrachten zijn.



Nb: Er is voor gekozen om het aantal opdrachten niet als 1/7, 2/7 t/m 7/7 te tonen, omdat we hiervoor zouden moeten weten hoeveel opdrachten we initieel hebben. En, omdat de data steeds opnieuw berekend wordt (iemand anders kan inmiddels de bak leeggegooid hebben waardoor u rechtstreeks uit de door u opgehaalde zak moet scheppen) kan het aantal opdrachten gedurende het proces wijzigen.

Dan nog een voorbeeld van ongeacht zak of bak. Merk op dat als we een onjuiste lokatie scannen, Profit een foutmelding geeft. Als we uit deze (verkeerde) bak rapen dan zullen we een andere (verkeerde) grondstof gaan afwegen.



De afgewogen hoeveelheden (in emmertjes?) leggen we vervolgens bij-/op de pallet met volle zakken die we voor deze Produktieorder hebben opgehaald.

N.b.: Merk op dat het proces van afwegen en tegen het systeem vertellen (per grondstof) dat dit is gebeurd middels het scannen zoals zojuist beschreven, twee zaken bewerkstelligt die we niet kunnen zien (maar dus wel plaatsvinden) :
1. De grondstof wordt op de rode kaart (t.b.v. de klaarzetlokatie) geboekt;
2. De raperlokatie wordt afgeboekt voor wat betreft de volledige zak.
Dat het voor de Produktieorder niet benodigde restant achterblijft in de bak(lokatie), is evident. Dus ook dat is "geboekt".

Als we helemaal klaar zijn met het ophalen van de grondstoffen, dan verschijnt de melding:





Tabblad #2 - Wat is er geraapt ?

Dan is er nog één Tabblad die we al 2x hebben overgeslagen: Tabblad #2.

Vanaf het moment dat Tabblad #1 bevestigd is, is dit Tabblad beschikbaar. Op dit Tabblad wordt getoond wat er in totaal voor deze Produktieorder aan grondstoffen is opgehaald. Dit hoeft dus niet enkel te zijn wat de raper bij zich heeft, maar dit betreft het totaal van alles wat op rode kaarten voor deze P.O. is opgehaald. Het scherm kan gebruikt worden als kontrole middel om te zien of we de juiste hoeveelheden hebben, maar ook of er bijvoorbeeld regels zijn die niet geraapt zijn omdat er helemaal geen voorraad van was.





Naar Produktielokatie

Alle opgehaalde grondstoffen (de volle zakken en het afgewogen produkt) liggen nu op één (of desgewenst meerdere) rode Produktiekaart(en) op de klaarzetlokatie. Alhier worden ze nog een keer door iemand gekontroleerd. Daarna worden de goederen verplaatst naar de Produktievloer. Dit gebeurt met behulp van Scanterminalscherm "Verplaatsen Voorraad v/e Lokatie".



Hebben we alles op één kaart geboekt, dan boeken we die ene kaart over naar een kaart met de kleur van de betreffende Produktieafdeling; hebben we meerdere rode kaarten, dan zal iedere kaart naar dezelfde P.O. kaart moeten worden geboekt. Het scanterminalscherm 'Verplaatsen voorraad Lokatie' weet dat de gescande lokatie voor een Produktieorder is, en toont informatief dat Produktieordernummer.

Na F1 zijn de goederen administratief overgeboekt naar de ingevulde (Produktie) Lokatie. Tevens zorgt dit overboeken ervoor dat in de Produktieorder v.w.b. de opgehaalde Grondstoffen, de Lokatie waarnaar wordt overgeboekt (de gekleurde P.O. Kaart) wordt opgenomen als zijnde de Lokatie waar de grondstoffen (later) van moeten worden afgeboekt.



Aanvullend stellen we nu ook binnen dit maatwerk dat:
* als een P.O. regel een produkt bevat die in een Silo op voorraad ligt, ze ook uit die Silo zal worden afgeboekt
* er altijd maar één Silo per produkt is (er hoeft dus nooit tussen 2 Silo Lokaties gekozen te worden)

Het overboeken van de goederen van de (rode) ophaalkaart naar de (gekleurde) Produktieorderkaart zal de 'Silo produkten' herkennen, en zal de Lokatie van deze Silo opnemen in de P.O. regels, opdat deze regels verderop in het proces via 5-2-2-1 kunnen worden afgeboekt, zonder dat daar moet worden aangegeven welk Voorraaditem moet worden afgeboekt.





Afboeken Grondstoffen Produktieorder - Aangepaste versie

Al het "zakgoed" is nu opgehaald en op een P.O. Kaart geboekt, en de P.O. weet dat deze regels van die kaart moeten worden afgeboekt.
V.w.b. "silo produkten" is bekend uit welke silo het produkt moet worden afgeboekt, en ook dat is nu opgenomen in de Produktieorderregel.
Resteert nog één categorie, en dat zijn de vloeibare produkten die niet vooraf worden opgehaald, maar tijdens het produktproces uit een vat worden geboekt die naar de Produktievloer is gehaald.

Helemaal in het begin van het topic is al genoemd dat de huidige inrichting niet conform de methode is zoals wij dat normaliter voor ogen hebben.  Als G2/G6/G8 geen "G" had geheten maar "P" (dus P2/P6/P8), dan werkte het standaard zo in Profit dat iedere Produktieorder die op een P6Sxx Lokatie werd geproduceerd als vanzelf Voorraad mocht afboeken van een P6 Lokatie. Het overboeken van een vat vloeibaar produkt naar de Produktievloer zou dus voldoende zijn om een Produktieorder op die Produktievloer uit dát vat (en de charge die naar die Produktievloer verplaatst is) af te laten boeken. Helaas is e.e.a. nu niet zo ingericht, en in dit voorbeeld zijn we ook niet voornemens die inrichting nu op zijn kop te zetten!

In deze specifieke situatie zal het zo zijn dat G6 het Produktiemagazijn wordt genoemd. De vaten zullen dus naar een G6 Lokatie worden verplaatst en Profit zal vanaf die G6 Lokatie moeten afboeken. Tot nu toe was de enige mogelijkheid hiervoor om de bedrijfsparameter "Afboeken Grondstoffen van alle Lokaties toegestaan" op "Ja" te zetten, met alle eerder genoemde problemen vandien. Met onderstaande oplossing gaan we dit nu iets formeler oplossen.

Let op: De parameter "Afboeken Grondstoffen van alle Lokaties toegestaan" zal nu uitgeschakeld moeten worden!

Nb: deze bedrijfsparameter vindt u bij Hoofdmenu, F5, F5, G (Produktie) op Tabblad #1.



Als die parameter uit staat, vervalt Profit in haar standaard werkwijze. Onze Produktieorder, die voor Produktiestation PAS03 was gemaakt, mag daarmee normaliter alleen voorraad afboeken van de PA Lokaties. Maar, omdat we in deze situatie geen voorraad hebben op P-Lokaties kunnen we (als we verder niet zouden ingrijpen) geen voorraad afboeken. Handmatig afboeken (F4 vanuit Hmenu-5-2-2-1-F1) zal geen geschikt Voorraaditem vinden die voldoet.



Aan het afboekproces is derhalve ook wat veranderd!

Het (met de Scanterminal!) verplaatsen van de voorraad van de ophaalkaart (G5AC3) naar de P.O.-Kaart (G6AA2) zal er nu tevens voor zorgen dat deze P.O.-Kaart formeel wordt opgenomen bij de Produktieorderheader. Raadplegen Produktieorders is uitgebreid met een kolom 'POKrt' waarin deze P.O. Kaart wordt weergeven:



Een aantal Afboeken Grondstoffen Funkties, te weten Regel Afboeken (5-2-2-1-F1-F4), Hoeveelheid Afboeken (5-2-2-1-F1-Sh+F5) en Automatisch Afboeken (5-2-2-1-F1-F5) zijn vervolgens zodanig aangepast dat er ook Voorraad mag worden afgeboekt van iedere Lokatie die kwa eerste twee posities overeenkomt met de Produktiekaart. Dit dan alléén indien er bij de Produktieorderregel niet reeds een Lokatie is ingevuld. Dus: als de Produktieorderregel zegt dat het produkt van Lokatie T1A02 moet worden afgeboekt, dan zal de voorraad op T1A002 worden gelokaliseerd; staat er bij de Produktieorderregel geen Lokatie ingevuld, dan zal naar voorraad worden gezocht op G6-Lokaties (bij de gratie dat de PO-Kaart met G6 begint), en als we te maken hebben met een Produktieorder waar geen PO-Kaart bij zou horen, dan zal alsnog naar de voorraad op PA (van Produktiestation PAS03) worden gekeken.

Bij 5-2-2-1-(F1) hebben we 3 manieren om af te boeken:

F5 - Automatisch Afboeken Grondstoffen
Deze optie gaat er vanuit dat alle grondstoffen volgens norm zijn verbruikt. Als de print van de Produktieorder zegt dat u 321 Liter in de kuip moet gooien, gaat ze er vanuit dat u dat ook gedaan heeft; F5 zal derhalve precies afboeken wat er volgens de norm in had gemoeten. F5 boekt "automatisch" en vraagt niet om verdere gegevens (zoals invulling Charge e.d.).

F4 - Handmatig Regel Afboeken Grondstoffen
Deze optie staat de Gebruiker toe om zélf op te geven hoeveel eenheden er van welk Voorraaditem moet worden afgeboekt. Met deze optie bent u dus in staat om zowel méér als mínder grondstoffen te verbruiken dan door de Produktieorder werd aangegeven.

Shift+F5 - Hoeveelheid Afboeken Grondstoffen
Betreft een kombinatie van bovenstaande twee methoden. Met Hoeveelheid Afboeken kunnen we een afwijkende hoeveelheid (zowel méér als mínder) opgeven, maar worden we niet vermoeid met het moeten opgeven van de af te boeken Charges; dit gebeurt FIFO t.o.v. de partijen die 'beschikbaar' zijn.

Welke "Grondstoffen Afboeken" Funktie moet ik nu gebruiken ?

In eerste instantie is toets F4 de bekendste toets om te gebruiken als we bijv. in geval van een Bijstelling méér of mínder willen afboeken. Toch zal het gebruik van deze toets hier niet wenselijk zijn. Kijk maar eens naar wat er van produkt AT111 op onze P.O.-Kaart is geboekt :



Er liggen 3 Voorraaditems op deze kaart. Deze 3 items zijn in dit voorbeeld ontstaan door afwegen. Eerst hebben we 1,438 Kg moeten afwegen uit de bak. Administratief lag er 2,438 Kg in de bak, maar omdat we hadden ingesteld dat er een niet uitschepbare hoeveelheid was van 1 Kg, is 1 Kg blijven liggen. De rest van de benodigde hoeveelheid is uit een extra opgehaalde zak gekomen, doch waarbij eerst dat ene resterende kilogrammetje op de P.O. Kaart is geboekt. In totaal dus 3 Voorraaditems (wat in de situatie dat er ook nog volle zakken geraapt hadden moeten worden er nog meer zouden kunnen zijn geweest).

Stel dat we nu F4 gebruiken, dan zal deze F4 toets per Voorraaditem willen afboeken! hetgeen impliceert dat we 3 afboekingen moeten doen voor deze 3 Voorraaditems.
Voor deze situatie (waarin de Chargenummers die we hebben opgehaald) al bekend zijn, kost dat alleen maar onnodig veel werk.



Let op: F4 zullen we wel gebruiken als we bijv. meerdere vaten verbruiken, danwel een bepaalde hoeveelheid uit een specifiek vat willen afboeken.


Ok, als F4 dus afvalt, houden we Shift-F5 en F5 over.

Vanzelfsprekend geldt dat als we zouden beginnen met "Automatisch afboeken", daarna alle regels afgeboekt zijn, waarna we 'te laat' zijn met eventuele uitzonderingen waar méér of mínder geboekt zou zijn. We moeten derhalve eerst de regels afboeken die niet conform de norm zijn geboekt, en doen daarna "de rest" automatisch volgens norm. Merk op dat we v.w.b. het zakgoed precies hebben opgehaald en afgewogen wat we nodig hebben en we v.w.b. die regels dus eigenlijk nooit "handmatig" hoeven te boeken. Voor de hoeveelheid die uit een Silo geboekt wordt of de vloeibare produkten die tijdens het produktie proces worden toegevoegd kan een meer-/minder hoeveelheid aan de orde zijn.

Bij regel #20 vraagt het systeem om 112.817 eenheden SA005. Middels Shift+F5 boeken we deze regel af, en geven we aan dat we in totaal 115 eenheden hebben verbruikt.



F1 boekt nu FIFO 115 Kg af conform alle geldende regels; in dit geval 'moet uit Silo T1AA1 komen'.
Het Raadpleegoverzicht keert weer terug, en aldaar is zichbaar dat bij een norm vebruik van 112.817 en in werkelijkheid 115.000 verbruikt is.
Merk op dat het sterretje (*) achter de kolom 'Verbruikt' is verdwenen; dit is voor Automatisch Afboeken (F5) een teken dat deze regel al verwerkt is en niet meer automatisch geboekt mag worden.



Op eenzelfde manier kan ik voor regel #40 minder afboeken; geen 2.918 maar 2.750 Kg.



Twee (afwijkende) regels hebben we nu met de hand geboekt; bij deze regels is het sterretje verdwenen.



Alle overige regels (met *) zijn conform norm verbruikt, en kunnen we nu met 1 handeling afboeken middels toets F5 (Automatisch Afboeken).
Profit hoeft ons daar verder geen vragen meer voor te stellen; zakgoed is immers vooraf opgehaald (en gewogen) op onze Produktiekaart, van Silo voorraad is bekend uit welke Silo dit moet worden geboekt, en de extra af te boeken vloeibare produkten zullen worden afgeboekt uit de voorraad (vaten) die naar de Produktievloer zijn verplaatst.




Einde Aangepaste versie


Terugdraaien Produktieorder

Als laatste is dan nog "Terugdraaien Produktieorder" aangepast op de werkwijze met deze Produktiekaarten. Normaal gesproken als we een Produktieorder terugdraaien, worden de afgeboekte Grondstoffen teruggelegd op de Lokatie waar ze vanaf zijn geboekt. Dat is in dit geval de Produktieorderkaart G6AA2. Terugdraaien P.O. zal nu ook deze kaart weer formeel moeten koppelen aan deze Produktieorder! en alvorens we überhaupt de order mogen terugdraaien, zal deze Produktieorderkaart "vrij" moeten zijn, en niet ondertussen in gebruik zijn genomen voor een andere order (zo toch, dan moeten we die kaart eerst vrij maken, door de voorraad van die lokatie over te boeken naar een andere kaart).





(nog) Niet ontwikkeld - Rapen voor een Produktiestap

Binnen Profit kan een Produktieorder in formele Produktiestappen ("fases") worden ingedeeld. Zo kunnen we vinden dat we eerst grondstof A, B en C moeten ophalen, welke eerst een paar uur gemalen moeten worden. In een volgende Produktiestap moet ook grondstof D, E en F erbij, en moet er nog even verder gemixed worden. In een 3e Produktiestap komen de overige grondstoffen erbij en wordt alles nog eens goed gemengd.

Bij bovenstaande werkwijze zouden we een Produktiekaart mogen zien als zijnde "de grondstoffen die we voor een specifieke Produktiestap" hebben opgehaald (in plaats van alles voor de hele order). Met een separaat te ontwikkelen Scanterminalscherm zouden we dan ook een scherm kunnen ontwikkelen waarmee we de grondstoffen die op een "Produktie (stap) kaart" liggen afboeken in de betreffende Produktiestap.

Omdat de klant voor wie e.e.a. ontwikkeld is zelf nog niet in staat is om de Recepturen in te richten naar dit soort Produktiestappen, is e.e.a. achterwege gelaten; indien gewenst kunnen we dit altijd nog ontwikkelen.



(nog) Niet ontwikkeld - Vaten Orders

Hoewel gesteld is dat "vloeibaar" buiten beschouwing wordt gelaten, is er ook nog een categorie "vaten-orders", zijnde Produktieorder die hoofdzakelijk meerdere vaten als input hebben. Denk hierbij aan een Produktieorder waar 1750 Kg van dezelfde grondstof benodigd is, welke in vaten van 180 Kg op voorraad ligt. In tegenstelling tot "additieven" (waarvan maar kleine beetjes in iedere Produktieorder verwerkt hoeven te worden) geldt hier dat er wel degelijk "vaten" opgehaald moeten (en kunnen) worden uit het Magazijn.

Omdat deze situatie niet zo vaak aan de orde is, en mede omdat deze situatie voorheen ook al 'handmatig' afgehandeld werd, is besloten hier voor nu even niets aan te doen. Daarmee kan het Scanterminalscherm sneller worden opgeleverd en worden ingezet voor de vaker optredende orders: de zakgoed produkten.

Het idee is overigens om in deze situatie "vaten" op eenzelfde wijze op te gaan halen als zakgoed. De gebruiker zal daarbij als eerste een eventueel reeds aangebroken vat moeten gaan ophalen, en daarna net zoveel vaten als nodig is om de gevraagde hoeveelheid te dekken. Omdat "vloeibaar" op de Produktievloer zelf wordt afgewogen (en niet vooraf op de weeglokatie) zullen we nu meer ophalen dan we nodig hebben. 1750 Kg nodig bij 180 Kg in een vat zal leiden tot het moeten ophalen van 10 vaten. Hierbij zal de inhoud van de eerste 9 vaten (9 x 180 = 1620 Kg) volledig in de Produktiekuip mogen worden gegooid, en uit het 10e vat zal dan nog 130 Kg moeten worden gehaald. Om aan te kunnen geven dat het 10e vat niet volledig ingezet mag worden, hebben we bedacht dat we daar een grote (oranje) sticker op kunnen plaatsen, zodat zowel de produktiemedewerkers als Profit weten dat dát vat straks mogelijk een restant gaat bevatten. Omdat uit dat laatste vat een deel is afgeboekt (130 Kg van de 180 Kg) is na het gereedmelden van de Produktieorder er nog steeds voorraad aanwezig op de Produktiekaart: nl. de voorraad in de restvaten; de 50 Kg (180-130) uit het 10e vat. Deze vaten zou de gebruiker dan (met de scanner) weer kunnen terugverplaatsen naar het grondstoffen magazijn.
368  Heart-Profit Boards / Heart-Profit ERP Support / Re: Bewerking achteraf on: April 20, 2016, 10:37:40 am
N.b.: Ik dacht eigenlijk aan een andere eerste reaktie, die ik uiteindelijk heb weggelaten. Nu ben ik klaar met typen en kom ik er toch mee :

Volgens mij moeten jullie eens aan scannen denken. Ik bedoel, een deel van deze "ellende" ontstaat omdat je het allemaal achteraf moet doen (verwerken). Als je dit nou eens ter plaatse doet, dan heb je achteraf niets meer. En dan geldt dus werkelijk dat je alleen maar die kleine Receptuurtjes moet maken. Hooguit zal er heus wel 16+++ uur maatwerk bij komen kijken om e.e.a. voor jullie lekker (100% zoals je werkt) te laten werken, maar daarna kan de adminsratie naar huis (alleen Dinand blijft nog over natuurlijk yes).

Hoe dan ook, niet echt gerelateerd aan het onderwerp, maar ik vermoed zo dat als je dit scannen al aan het doen zou zijn, het ook nooit een onderwerp zou zijn geworden (die zeg maar twee scans die de man op het tasveld of waar dan ook extra moet doen, ofwel 7.3 seconden extra werk, ga jij echt niet wakker van liggen).
369  Heart-Profit Boards / Heart-Profit ERP Support / Re: Bewerking achteraf on: April 20, 2016, 10:31:30 am
Misschien snap ik wel niet goed wat nu de problemen zijn bij het maken van die extra Produktieorder. Kijk :

Dit doe je vast niet voor alle stenen (Artikelen) "tegelijk". Zo af en toe is dit nodig voor een nieuw (nog nooit eerder in blokverband gelegd)  produkt. Volgende week weer een nieuwe opdracht (Verkooporder), en de week daarna ook weer twee.
Je maakt een nieuw Artikelnummer aan op dat moment (niet eerder) en maakt een simpele receptuur met een input en een output regeltje.
Het Kompleet Gereedmelden doe je met 1 druk op de knop.

Nu kan je natuurlijk zeggen : ja maar pakken, lagen stuks gedoe en nog veel meer, maar ik zou denken dat wat dat allemaal ook is, nu heb je daar op dezelfde wijze last van.

Ok, dat is 1 antwoord (het 2e eigenlijk al);
Het andere antwoord is dat het vast wel is te maken om een DKK te laten optreden bij Omvormen (verhoogt onmiddellijk de Kostprijs). Maar ik heb werkelijk geen idee wat daar bij komt kijken. Ik vermoed ook dat het nu eigenlijk al niet goed gaat met de Statistieken. Dus zeg maar eens : Als je nu omvormt naar een ander Artikel, hoe zit het dan met de door de Statistieken gerapporteerde Kostprijs van zowel input als output produkt ? (dat je de Omvormkosten niet terugziet snap ik).
Dit zal wellicht wel goed zijn, maar ik vrees dat als we dat van dei DKK aan het maken zijn, we ineens tegen van alles aanlopen "wat dan eigenlijk ook moet", omdat je anders iets onverwachts niet meer snapt (denk maar aan Statistieken). Aan de andere kant, zo'n soort (goed werkend) mechanisme is er dus wel - bij de Externe Verplaatsopdrachten; we zouden dus moeten weten hoe het moet. Maar dit uitzoeken en je ben zo een dag verder om vervolgens te horen dat dat 8 uur kostte en de rest 16 uur waar je geen zin in hebt en je de 8 uur toch zou moeten betalen (vind ik, maar ik zou het aan de baas kunnen vragen quirk).
Kweenie.
370  Heart-Profit Boards / Heart-Profit ERP Support / Re: Abonnement on: April 20, 2016, 10:02:33 am
Na tel. overleg is dit volgens mij de bedoeling :

Iedere maand wordt een Verkooporder gemaakt met een Dienst als enige regel ("Maandelijks Abonnement XYZ"), prijs 1200. N.b.: Dat dit 1200 is voor die klant kan (tegenwoordig) worden vastgelegd in de Prijsafspraken.
Op regelmatige basis wordt bij de betreffende klant de voorraad aangevuld; daarvoor worden gewoon Inkooporders in het systeem gezet, wat verder niet ter zake doende is (is niet gerelateerd aan de problematiek). N.b.: Spectro zorgt er in feite voor dat er altijd voorraad is van de meerdere produkten (Artikelen). Ook dit doet niet ter zake.
Als er produkt wordt geleverd, gebeurt dit middels normale Verkooporders maar altijd tegen een Prijs van 0.00 (de klant betaald er Abonnementsgeld voor). N.b.: De betreffende Artikelen worden gewoon tegen hun normale Kostprijs geproduceerd en die Kostprijs wordt ook gewoon financieel geboekt bij de Fakturering.

Bij de Fakturering van het geleverde produkt krijg je nu een opbrengst van 0.00; Kosten zijn 1000;
Zoals ik het begrijp is het nu voldoende om in de Statistieken voor de geleverde Artikelen als geheel de Opbrengst vs de Kosten te zien voor de betreffende Debiteur. Hoe ?
N.b.: Omdat het te simpel is, zal het wel niet werken (ik zal vast iets over het hoofd zien).
De Statistieken (Standaard Overzichten) opvragen voor de ene Debiteur en de Artikelen 0 t/m ZZ. De "truc" is dat de Dienst daar ook onder moet vallen en wel Opbrengst en toevallig geen Kosten kent, terwijl de geleverde Artikelen daar eveneens onder vallen, die "toevallig" geen Opbrengsten kennen, maar wel kosten hebben.
Ik zou nu niet weten waarom hier geen opbrengst van 1200 en Kosten van 1000 uitkomt (en dus Netto Opbrengst van 200).

Als laatste : we hebben ook gesproken over het kunnen zien van de opbrengst vs de kosten van 1 produkt (Artikel), maar dit is niet mogelijk bij een abonnement voor meerdere Artikelen. Je zou het in de Statistieken wel kunnen opvragen natuurlijk, maar de Opbrengst is dan altijd relatief gezien te hoog (beter : de Kosten zijn te laag omdat er domweg maat 1 Artikel wordt meegeteld, bij een Obrengst die voor allen geldt (het abonnement).

Let op : Wat hiermee niet is geregeld is het kunnen opvragen van "nuttige" Statistieken voor juist alleen de Artikelen. Dit komt omdat de Artikelen tevens "gewoon" worden verkocht aan andere klanten. De Kosten zijn even nuttig als altijd, de Liters ook, maar de Opbrengst zal niet kloppen. Dit dan, tenzij je het Dienst Artikel mee weet te nemen - dan klopt het weer wel voor het totaal (maar nog steeds niet per Artikel individueel). Moeilijk uit te leggen, maar ik denk sowieso wel duidelijk.

Is dit wat ?
371  Heart-Profit Boards / Heart-Profit ERP Support / Re: Abonnement on: April 18, 2016, 08:07:23 am
Eh, leuke uitdaging ?
We komen er op terug. Maar inderdaad, als iemand intussen al een ideetje heeft ...
372  Heart-Profit Boards / Heart-Profit ERP Support / Re: Bewerking achteraf on: April 14, 2016, 04:32:37 pm
Quote
Maar mijn vraag is of het ook anders kan? Zou je bij het eenvoudige overboeken iets van bewerkingskosten kunnen toevoegen als optie of werken met DKK's  voor het nieuwe artikel?

Ik weet niet of je hier echt iets aan hebt, wat nl. afhankelijk is van wat je nu al "half" aan het doen moet zijn - mijn voorstel is volgens mij ook maar "half" is, maar is wel half anders. swoon

Als je een Externe Verplaatsopdracht maakt, die levert en weer ontvangt, dan kan je middels een DKK('s) de Kostprijs automatisch verhogen.
Wat je dan ook nog zou kunnen doen is dat je achteraf een Kenmerk verandert (of deze gaat invullen terwijl dat bij dit Artikel normaal niet het geval is). N.b.: Moet je wel wijzigbare Kenmerken hebben (wat niet gebruikelijk is en waarvan ik meen dat je dat kan instellen bij het Artikel zelf (tabblad met Eigenschappen).

Je zou hiermee aardig half op weg kunnen zijn ...
373  Heart-Profit Boards / Heart-Profit Releasenotes / Release Notes worden niet bijgewerkt on: April 13, 2016, 03:47:39 pm
Vandaag ontvingen wij de vraag of we zijn gestopt met de ontwikkeling van Profit.
"Hoezo ?"
Nou, omdat er geen Release Notes meer bij komen.

smile

We werken nog even hard aan het pakket, zo niet nog harder;
Het gegeven dat de Release Notes op dit moment niet worden bijgewerkt is het gevolg van een bug elders. In Profit zelf worden ze nog steeds bijgehouden (te zien na een Upgrade); als het probleem is opgelost zullen ze met terugwerkende kracht ook hier weer zichtbaar zijn.

Sorry voor dit tijdelijke ongemak !
374  Heart-Profit Boards / Heart-Profit ERP Support / Re: Heropenen kontrakt middels SHIFT-F7, funktie autoriseren on: April 12, 2016, 12:15:52 pm
Pascal, het uitzoeken waar hetgeen zit wat jij bedoelt kost al 0,5 uur. Dus ik zeg toch liever 1,5 voor de drie.
sorry
375  Heart-Profit Boards / Heart-Profit ERP Support / Re: Export teksten bij release-notes / terugvinden release-notes forum on: February 03, 2016, 04:28:23 pm
Quote
Op het forum zie je zo'n wijziging meteen,

En nieuwe ook. teasing
Dus ook die waar je de Upgrade nog niet van hebt. Wink
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 ... 273
Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.148 seconds with 12 queries.