lopres toont onjuist saldo emballage

[Johan]

VRAAG: Waarom rekent profit bij LOPRES Printen Saldo Emballage afgesloten Emballage records wél mee als het gaat om het bepalen van het 'aantal emballage heen', maar worden deze niet gezien als "retour ontvangen" wanneer deze records afgesloten zijn?

Er is bij ons volgens mij een aantal afgesloten emballagerecords, waarbij de aantal retour niet ingevuld lijkt te zijn. Daardoor toont LOPRES een ander saldo dan bijv. LOELRA3 (raadplegen retour te ontvangen emballage totaal). Daar zie je namelijk alleen openstaande emballage. (waardoor daar dus 19 als saldo staat)

Vanwaar dit verschil?

Peter Bovenstaande waren de vragen. Mocht je het leuk vinden: hier volgt nog een stukje toelichting, maar die moet je niet lezen, werkt hooguit verwarrend!

Toelichting

Je mag het ook andersom zien: Pas LOELRA3 aan op LOPRES, het gaat mij er om, dat ik die saldo's tussen een raadpleegfunctie en een printfunctie niet normaal vindt. Waarom biij een printfunctie een andere waarde tonen dan bij een raadpleegfunctie?

Via LO<3-2-6-9-9-2-3> kom je bij LOPRES Printen Saldo Emballage.

    ARTIKELNUMMER    OMSCHRIJVING                                   SALDO
    ===============  ========================================  ==========

    29026            Pallet 100x120 Kunststof Blok                     23

Dit wordt afgedrukt. Dit klopt niet met andere saldo afdrukken. Oorzaak daarvan lijkt me het feit dat er een aantal records is die WEL zijn afgesloten, maar ZONDER een aantal retour. In de bijlage twee groen gearceerde records. Hierop is het aantal RTR niet ingevuld. Maar ik zie deze groene records ook niet meer terug bij raadplegen ontvangen / te ontvangen emballage.

Maar JOHan dan klopt de rekensom nog niet: 31- 5 - 2 = 24 en niet 23 .

Dat komt omdat ik 8 pallets retour kan vinden. er zijn daadwerkelijk 8 retour geregistreerd, maar in LOEL zijn dat er maar 7. En dan klopt het LOPRES saldo wel. Want 31 - 8 is 23.

Dit is mijn analyse, die vast wel weer helemaal fout zal zijn, want wellicht zet ik jullie met mijn analyse wel op een dwaalspoor. Ik wil gewoon weten waarom Afgesloten emballage zonder retourontvangsten bij de ene functie wel wordt verwerkt in het getoonde saldo, en bij de andere functie niet.

[Johan]

maar als ik dit zo nog eens bekijk: het is vreemd dat de op 19-10-2006 retour ontvangen (op 18-10-2006 verstuurd) pallet niet is bijgewerkt in LOEL. Dus emballage is daar retour ontvangen, wel afgesloten, maar het aantal retour lijkt niet bijgewerkt te zijn.

[Johan]

Ik vind dit echt vervelend. Hoe leg je nou een klant uit dat je enerzijds een saldo van 19 hebt, en anderzijds een print hebt waarop een saldo van 23 staat. Het betreft een artikel waarvan we volgens de artikelgegevens "Eigenaar" zijn van de emballage. 

[Peter Stordiau]

Dit is een redelijke slag in de lucht (en vooral : zonder dat we in jullie systeem hebben gekeken) :

Ruwweg 3/4 á 1 jaar geleden is het geheel rondom de jou genoemde fenomenen volledig op z'n kop gegaan. En let wel, daarvóór bestonden prints/overzichten enz. niet in een versie die je kon gebruiken om duidelijk te maken wat het emballage saldo was. E.e.a. kon wel worden duidelijk gemaakt, namelijk middels het zelf salderen van verschillende overzichten plus de wetenschap hoe e.e.a. precies moest worden geboekt. Dit laatste was cruciaal (en is het nog steeds als je het verschil kwa funktionaliteit nooit hebt ervaren);

Zonder nog precies te weten wat er destijds allemaal aan de orde kon zijn om a. zaken fout te kunnen doen en b. zaken in het gareel te laten lopen waar gerelateerde aspekten domweg fout werkten, kan ik in elk geval deze hoofd-tip geven :

Bij het boeken van de retour emballage was het in de eerdere versie van de programmatuur voor de hand liggend (het werd uitgelokt) dat de Retour Ontvangsten werden geboekt bij het deel wat feitelijk is bedoeld voor "Inventarisatie". Dit mocht op zich ook wel, mits je inderdaad ermee rekening houdt dat je aan het inventariseren bent (Uitstaande Emballage bij de klant) en een ingevoerde "1" ook "1" betekent, en niet "-1".

Eenieder die met de -toen- nieuwe versie van deze programmatuur (best veel omvattend) aan de gang ging, moest feitelijk eerst opnieuw inventariseren, omdat anders *wij* er niet vanuit konden gaan dat je in het trajekt daaraan voorafgaand de zaken goed invulde. Ook (en nogmaals) : bepaalde delen werkten destijds niet goed, met als gevolg een handmatige manipulatie die je met goed fatsoen niet juist *kon* volbrengen (eerst binnenboeken, maar gebeurde elders ook al automatisch, en daardoor zelf de Voorraad weer handmatig elimineren).

Alles samengevat : Ik vermoed dat bij jullie die Inventarisatie niet is gedaan.
Ook : Dit wordt bij meerdere klanten excessief gebruikt, en wij kennen geen meldingen dat e.e.a. niet juist dan wel niet consistent zou zijn (na die inventarisatie dus !).


Heb je hier iets aan ? ik kan het alleen maar hopen.

[Johan]

hmm, misschien alsnog maar eens inventariseren, want van bepaalde palelts zijn we helemaal geen eigenaar, dus die indicator moet om.

Maar hoe inventariseer je dit?

Ik stel me zo voor dat je nieuwe artikelen aanmaakt, met de indikator op de juiste stand (eigenaar nee)  en dan per deb/afleveradres openstaande saldo's overnemen.

[Peter Stordiau]

Er is bij ons volgens mij een aantal afgesloten emballagerecords, waarbij de aantal retour niet ingevuld lijkt te zijn. Daardoor toont LOPRES een ander saldo dan bijv. LOELRA3 (raadplegen retour te ontvangen emballage totaal). Daar zie je namelijk alleen openstaande emballage. (waardoor daar dus 19 als saldo staat)

We kunnen sowieso even kijken hoe "normaal" dit eruit ziet.

[Peter Stordiau]

Maar hoe inventariseer je dit?

Begin maar vast te lachen : alle geleerden hier weten dat niet (en bij mijn vorige post was ik zelf al weer vergeten hoe het zat) :
3-2-5-1 (F1) leidt je tot Bij/Af Voorraad Mutaties, ooit bedoeld om middels -dan- absolute getallen een begin situatie voor een klant aan te brengen. Ga maar na, dit werkt ook, want een "-1" zal ook leiden tot -1 (absoluut t.o.v. 0).
Dit betreft ook precies de funktie die ik eerder bedoelde, en die niet gebruikt mag worden voor het bijwerken van het saldo. Waarom niet ?

Omdat betreffende prints/funkties dit meenemen (een ingevoerde "-1") om te laten bijdragen aan het saldo. Of anders gezegd : genoemde funktie betreft geen Inventarisatie als zodanig, maar gedraagt zich zo op het moment dat alles op 0 staat. En aldus, hiermee een onjuist saldo korrigeren lukt je never nooit.
(probeer in je hoofd te krijgen dat deze funktie nooit mag worden gebruikt voor korrekties, want dat lukt je dus niet, en tevens dat deze funktie niet mag worden gebruikt voor Retour Ontvangst (of verzending zo je wilt) omdat (tegenwoordig !!) dit overal automatisch gebeurt. Konklusie : als deze funktie eenmaal is gebruikt voor Retour Ontvangst (dan wel korrektie) komt het nooit meer goed (lees ook : heb je misschien jouw "fout" te pakken).

Vraag voor ook ons is nu even hoe je nu wèl korrigeert c.q. inventariseert (behoudens een nieuwe klant), en dat kan hopelijk worden verteld door Yvonne die er vandaag niet is.

[Wouter Rijnbende]

Volgens LOEL Raadplegen te Ontvangen Emballage
Geleverd: 31, Retour: 7. Saldo zou derhalve 24 zijn, ware het niet dat er 2 records zijn die afgesloten zijn terwijl nog niet alles retour ontvangen is (de door jouw in het rood gemarkeerde regels, 4+1 = 5) maakt tesamen een saldo van 19 voor het scherm LOELRA3.

Volgens LOEE Raadplegen Retour Ontvangen Emballage
4+1+1+2 = 8, hetgeen niet overeenkomt met de 7 uit LOEL.

LOPRES
Toont initieel 31 geleverd, 8 retour, saldo van 23.

LOVI Voorraaditems
Toont op dit moment een openstaand saldo van 19.

Tsja... en wat is nu goed? c.q. wat heeft wat veroorzaakt? en hoe verder?

De 8 die volgens LOPRES retour zijn ontvangen komen uit LOEE. Maar is dit juist? Volgens mij wordt je debiteur gecrediteerd vanuit LOEL, en daar staan er 7.

Kun jij eens uitzoeken voor hoeveel stuks die debiteur creditnota's ontvangen heeft (liever gezegd, v.w.b. welk deel hij weet-/denkt dat hij retour gezonden heeft). M.i. moet de boel rechtgebreid worden naar een saldo van 19, maar dat wordt lastiger (met verantwoording) als die man er al 8 terug heeft gestuurd.

[Johan]

VELD1   VELD2   VELD3   VELD4   HOMZET   VKILO
MULAM1   MULAM1       3   29026   1026679   -45,38000000   -1,00000000
MULAM1   MULAM1       3   29026   1026693   -136,14000000   -3,00000000
MULAM1   MULAM1       3   29026   1028762   -136,14000000   -3,00000000
               -7,00000000

7 zo te zien zie ook printfile.

[YK]

Vraag voor ook ons is nu even hoe je nu wèl korrigeert c.q. inventariseert (behoudens een nieuwe klant), en dat kan hopelijk worden verteld door Yvonne die er vandaag niet is.

Ook ik kan hier geen antwoord op geven, ik weet het gewoon niet.

[Wouter Rijnbende]

Je zou nog kunnen kijken wat een Voorraadmutatieoverzicht o.b.v. Lokatie 000M3 toont v.w.b. dit Artikel...

Ik denk dat we moeten (mogen) stellen dat het openstaande saldo van 19 korrekt is.
Retour ontvangen toont aan dat er 7 retour zijn gezonden, dit aantal is ook gecrediteerd.
Dat zou moeten inhouden dat er initieel 26 geleverd zouden moeten zijn, waarmee we op een verschil van 5 komen t.o.v. het huidige aantal.
Die 5 zouden dan die twee afgesloten records van 4+1 moeten zijn, met die opmerking dat je m.i. zelf niet in staat bent deze af te sluiten voordat ze volledig ontvangen zijn. Het zou kunnen zijn dat iemand al eerder eens problemen met dit item gehad heeft (deze klant) en ons gevraagd heeft die regels af te sluiten.
Op zich niets mis mee, toen, maar ondertussen wordt e.e.a. in een verantwoordingsprint gebruikt die hierdoor nu ineens niet meer aansluit.

M.i. moeten wij die regels van 4+1 elimineren. Mee eens?

[Peter Stordiau]

Ik vind het prima dat er (in tegenwoordige consistentie) geen Inventarisatie funktie meer is hiervoor; dan moeten we die maken.
Ik snap alleen niet dat de drie klanten die hier excessief bij waren betrokken dit niet zouden kunnen hebben doen. En momenteel kan ik ze alle drie niet te pakken krijgen.

Wordt vervolgd.