Heart-Profit ERP
July 06, 2024, 01:10:31 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: TS Goederen Ontvangst m.b.t. Printen Etiket i.g.v. V.P.O.  (Read 810 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27445


View Profile WWW
« on: November 01, 2016, 01:35:25 pm »

Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=27692.0 beschrijft dat het TouchScreenscherm Goederen Ontvangst, welke altijd opnieuw een Subchargenummer genereert, nooit bedoeld is geweest om Verplaatsopdrachten mee binnen te boeken. Toch hebben we met een aantal simpele aanpassingen (en blokkades) ervoor gezorgd dat dit nu toch mogelijk is.

Helaas gaat er nu bij een andere klant iets fout, die dit scherm blijkbaar ook gebruikt, voor een situatie die ons nog niet helemaal duidelijk is, maar, waarbij het eropneer lijkt te komen dat e.e.a. op basis van inrichting en interne afspraken nog enigzins gebruikt kan worden.

In hun situatie wordt gebruik gemaakt van een Extern Magazijn waarin alle voorraad wordt opgeslagen; zowel grondstoffen als eindprodukten. Van Eindprodukten mag duidelijk zijn dat als we die geproduceerd hebben en de blikken voorzien hebben van etiketten met Chargenummers erop, we niet zullen willen dat als deze blikken aankomen in het Externe Magazijn de Chargenummers ineens veranderen door het TS Goederen Ontvangst. Zou de blokkade uit de genoemde Releasenote er niet zijn, dan ging dit hopeloos verkeerd als deze Eindprodukten toch via dit scherm werden ontvangen. Maar... bij deze klant gaat dit toevallig goed want "we gebruiken het scherm niet voor eindprodukten."

Voor "grondstoffen" wordt het scherm wel gebruikt en wordt een "legitieme" reden aangevoerd waarvoor het alsnog nodig is een nieuw etiket te kunnen printen: Grondstoffen worden ingekocht bij een Leverancier en worden ontvangen in het Externe Magazijn. In het Externe Magazijn draait geen Profit en kan dus ook niet vanuit Profit een etiket worden gegenereerd-/geprint. Omdat de goederen administratief wel op voorraad geboekt moeten worden (op de Externe Lokatie) worden de goederen ontvangen (overigens via hetzelfde TS Goederen Ontvangst), wordt er een Subchargenummer gegenereerd, maar, wordt hiervan geen etiket geprint (deze zou nl. op een andere Lokatie terecht komen). En dus wordt gesteld dat als de voorraad vanuit het Externe Magazijn naar de produktielokatie verplaatst wordt, er op dát moment alsnog een etiket geprint moet worden!

Klinkt logisch, maar blijft raar, en werkt enkel op basis van een reeks aan toevalligheden die op elkaar afgestemd zijn. Frappant in het verhaal is ook dat bij het leverende deel van de Verplaatsopdracht vanuit het Externe Magazijn de produktielokatie bepaalt welke Charges er verplaatst moeten worden. Op zich natuurlijk gewoon de werkelijkheid, maar... als het chargenummer wat verplaatst wordt een Chargenummer is welke door Profit gegenereerd is, en ze in het Externe Magazijn niet over dit etiket beschikken, hoe weten ze dan welke partij er geleverd moet worden?

Achteraf blijkt dat dit goed gaat, omdat de goederen in het Externe Magazijn worden opgeslagen op palletplaatsen, en de klant de Chargenummers die zij toekent terugmeldt aan het Externe Magazijn.

Nog steeds geldt dat we niet voorbij mogen gaan aan alle overige zaken die omtrent een V.P.O. zijn dichtgespijkerd; zo zullen we nog steeds enkel mogen aangeven: "ja, dit produkt is ontvangen" of "nee, dit is nog niet ontvangen" maar mogen we NIET aangeven dat we van de 40 verzonden zakken er slechts 38 hebben ontvangen. Deelontvangsten zijn immers nog steeds niet ontwikkeld voor V.P.O.'s.

De oplossing: In de eerder genoemde Releasenote hebben we gesteld dat we enkel kunnen aangeven dat de regel is ontvangen; dat blijft. Ook is gesteld dat er i.g.v. een V.P.O. nooit een nieuw Chargenummer wordt gegenereerd; ook dat blijft. Maar... de blokkade voor het kunnen printen van een etiket is m.i.v. deze Releasenote opgeheven! Waar eerder als uitgangspunt werd genomen dat als we een partij verplaatsen deze al gelabelled zal zijn met een etiket (en het niet zinvol is het etiket opnieuw te printen omdat deze niet anders zal zijn dan het etiket welke al op het blik / de zak zit), stellen we nu dat we best een etiket mogen printen, echter, wat we dan krijgen is een etiket gebaseerd op de Charge(s) die verzonden zijn.

Ofwel, stel dat we op Inkooporder 20161101023 regel 2 een produkt inkopen en dit leidt tot Subchargenummer C6B10230201, dan zullen we misschien bij die Goederen Ontvangst nog niet direkt ons etiket op de Verschijningen (of pallet) kunnen plakken (omdat dit in het Externe Magazijn wordt ontvangen), maar, zodra die voorraad naar onze produktielokatie wordt verzonden zal bekend zijn dat het Charge C6B10230201 is die verzonden is, en dus is het toegestaan om dan alsnog een etiket te printen op basis van dié Charge.

Let op: één van de uitgangspunten binnen deze simpele methode om toch Verplaatsopdrachten te kunnen ontvangen via dit TS scherm, is dat de levering van de leverorder als 1 Raaplijst-/Pakbon de deur uit gaat. Zou de verzending van 40 zakken van 25 kg worden verdeeld over 2 leveringen op dezelfde Verplaatsorder, dan zal het TS scherm aanvullende selekties behoeven (= maatwerk) omtrent het kunnen aangeven welk van de 2 leveringen nu wordt ontvangen.

Meteen komt er nog weer een volgend probleem om de hoek kijken: Bij het toekennen van Subchargenummers maken we binnen Profit verschil tussen Verschijningen die altijd eenzelfde inhoud hebben (zakgoed of blikken) en voorraad waarbij ieder item een andere inhoud kan hebben (vaten, containers). Vaten worden dan ook stuk voor stuk ingeboekt. Als we 5 Vaten van 180 liter ontvangen, wordt er voor 5 Subcharges gekozen (dat doet de gebruiker) en kan ieder vat separaat van een ander vat worden gescand. Nu blijkt echter dat in het Externe Magazijn deze 5 vaten als 1 partij worden binnengeboekt...

Een oplossing zou hier kunnen zijn dat we voortaan wel 5 nieuwe Subcharges mogen genereren, doch dat gebaseerd op dezelfde Hoofdcharge als die geleverd werd. Dit kan echter niet, omdat er ook partijen op voorraad liggen (en verplaatst worden) waarbij het Chargenummer bijv. '02-2016' bevat, in plaats van een Hoofdcharge. In zo'n situatie zouden we geen subcharge kunnen genereren.

Altijd een nieuw Subchargenummer genereren (zoals het feitelijk vroeger werkte) is ook niet wenselijk, immers, waar het Externe Magazijn expliciet de opdracht krijgt om Charge C61xxxxxxxx te leveren, zouden wij deze gaan ontvangen als C6Bxxxxxxx. En, daar een Chargenummer ook de ouderdom impliceert c.q. bepalend is voor FIFO afboeken, is dit ineens een nieuwere Charge uit november geworden in plaats van een charge uit januari (C61).

Vooralsnog derhalve terug naar het 1e ontwerp: de voorraad zal worden opgeboekt onder hetzelfde Chargenummer als waaronder het geleverd werd. De gebruiker krijgt bij een Verplaatsopdracht de mogelijkheid een etiket te printen, maar, dit wordt in dit geval niet een Etiket die gebaseerd is op een Inkooporder, maar betreft een Etiket van een Voorraaditem; op eenzelfde wijze als dat deze via Hoofdmenu-1-4-9-6-4 kan worden geprint. Op die manier volgt er altijd een etiket, ongeacht of het geleverde Chargenummer nu formeel al bekend is, danwel een Charge betreft die handmatig is ingevuld (of een dummy Charge betreft van een handmatige opboeking). Deze methode zal v.w.b. het printen altijd moeten werken, ook zal zouden we er later voor kiezen om alsnog een nieuw Subchargenummer te genereren of desnoods een hele nieuwe Hoofdcharge.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOILGLF1    Omschrijving (nog) niet bekend    03-10-2016    01-11-2016
LOILOGST    Omschrijving (nog) niet bekend    07-10-2016    01-11-2016
LOPRVBEV    Printen Etiket Voorraad-item    29-07-2016    01-11-2016
LOTSGO      TouchScreen Goederen Ontvangst    07-10-2016    01-11-2016
Logged
Pages: [1]
  Print  
 
Jump to:  

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.156 seconds with 20 queries.