Heart-Profit ERP

Functie: LOTSMOOS

Bij het TS goederenontvangst wordt de datum (van vandaag) niet automatisch aangepast. Normaliter staat de datum op "vandaag". Als het scherm 's nachts aan blijft staan dat blijft de datum op dezelfde staan de volgende dag waardoor je Profit opnieuw moet opstarten.

Kan dit aangepast worden?

In theorie wel ja, maar niets zegt dat daar altijd de datum van "vandaag" moet staan.
Het is bewust zo gemaakt dat je er ook morgen van kunt maken.
Ok, je zou via een timertje iets kunnen inbouwen dat die datum nooit op een dag in het verleden kan staan...

Ach... de gebruiker kan zelf voor "de volgende dag" kiezen, en als dit maar 1x per dag hoeft te gebeuren is dat toch niet erg?

Ik denk dat je de tijd beter kan investeren in een mogelijkheid dat zo'n scherm 's na xxx minuten inaktiviteit terugkeert naar het hoofdmenu en vrijgeeft; houd je ook geen files open voor je backup (en bij opnieuw aanroepen van je scherm, staat je datum vanzelf goed).

Waarom niet? 99% van de producten die op leverdatum vandaag staan komen toch ook vandaag binnen? Of dacht je soms dat alle producten vandaag op leverdatum gisteren binnenkwamen?

En denk daarbij aan: vandaag 1 datum aanpassen, morgen 2, overmorgen 3 en ga zo maar door. Profit past de datum gewoon niet aan.
Ik wil er best morgen van maken, maar dan alleen voor de levering van een product dat eigenlijk morgen binnen zou moeten komen en niet voor iedere levering.

Niet 1x maar minimaal 50x. Iedere keer dat je het scherm verlaat (om naar een ander TS te gaan) moet je de datum veranderen.

Vind je dat makkelijk voor TS en scanner gebruikers? Ik vind de upgrade zowieso niet lekker werken. Ik ben een uur bezig om iedereen uit Profit te krijgen waarbij ook nog te kans bestaat dat er een fout in zit en niemand verder kan.
Stel je voor dat er 15 chauffeurs met scanners rondrijden en 10 man beneden met scanners lopen en ik dan eventjes een upgrade wil uitvoeren. Moet ik eerst controleren of iedereen netjes is afgesloten, waarbij ook nog de kans bestaat dat ondertussen iemand weer Profit opstart, werkt niet echt lekker hoor.

PS: de discussie loopt met Peter.

Dat had je er niet bij gezegd  :wink:

Dit lijkt i.d.d. fout.

Zoals je het omschreef, kwam het eropneer dat je op de 06-03 naar Toevoegen Verkooporders gaat, dan de orderdatum op 06-03 komt te staan, en inmiddels wordt het 07-03 en de orderdatum staat nog op de 6e. Zo kunnen we overal wel iets inbouwen als je het scherm over een daggrens heen open laat staan...

Als je het scherm verlaat en opnieuw opstart, en hij met de oude datum komt, dan is er iets fout. Hier ga ik even naar kijken...


Als dit een reaktie op mijn opmerking is, dan begrijp ik hem niet  :scratching:

Demis, ik ga ervanuit dat je serieus bent met je opmerking !?

Het zou i.i.g. niet moeten kunnen. Bij aanroep v/h scherm wordt de rubriek gevuld met de Systeemdatum.  :( dus als je het scherm verlaat en opnieuw ingaat, behoort de datum van vandaag er te staan.

Je hebt vast wel een VNC connectie voor me naar dat TS scherm. Benieuwd wat "de datum" van die PC op dat moment is.

Ik ben zeker serieus met mijn opmerking(en).
Als ik niet 's ochtends de PC opnieuw opstart dan wordt er elke 5 min gebeld of ik dat aub wil doen, ivm het niet aanpassen van de datum.

I.v.m. een dit weekend uitgevoerde Upgrade zijn de PC's sowieso afgesloten en opnieuw opgestart;
afgesproken dat ik morgen even via een VNC verbinding kijk.
:17c:

Ongeloveloos  :eek:

Op de taakbalk staat een datum 11-02-2008, en die control, die bij initialiseren gevuld wordt met de systeemdatum, staat op 10-03-2008.

Zal hier eens een scherm 's nachts aan laten staan; kijken wat het resultaat is.

Wordt vervolgd...

Ik kan het hier nadoen, maar begrijp er nog even niets van.

Ik konstateer dat het Object opnieuw geïnitialiseerd wordt bij het verlaten + het opnieuw aanroepen van het scherm;
als ze geïnitialiseerd wordt, gebeurt dat met de Systeemdatum;
via een separaat window zie ik dat de Systeemdatum op vandaag staat;
maar de spinner staat op gisteren. :crazy:

Ik houd je op de hoogte...

Zit me trouwens nèt te bedenken...

Onderstaand een wat technisch geneuzel... maar ik zet het toch even op het forum, al was het maar om het later nog eens terug te kunnen vinden...

Er zit een 'bug' in VFP m.b.t. Objecten en het niet kunnen vrijgeven van de Classdefinities waarop zij gebaseerd zijn. In het kort komt het eropneer dat als ik de sourcekoding van een TS scherm wijzig, en iemand anders hier heeft dat scherm al een keer opgestart (let wel, niet aktief, maar gewoon een keer opstarten is voldoende), dan kan ik mijn source niet compileren omdat de destination (de oude gecompileerde versie) nog in gebruik is.
Profit afsluiten (degene die dat scherm opgestart had) is de enige remedie.

Ik heb hier altijd iets achter gezocht als "VFP bewaart die Classdefinitie intern voor het geval ze nogmaals zo'n Object moet aanmaken", maar, kombineer ik dit probleem met jouw probleem, dan heb ik een heel ander vermoeden...

Ik begin nu te vermoeden dat VFP intern een kopie van het Object bewaard, opdat als we nógmaals zo'n Object nodig hebben, hij het kan kopiëren van de vorige. Omdat een kopie van het Object 'live' gehouden wordt, zal de Class waarop ze gebaseerd is ook in gebruik blijven, en kan dus niet worden overschreven. Niet kunnen overschrijven betekent niet kunen worden voorzien van een nieuwe versie, hetgeen impliceert dat als we 2x achter elkaar een Object aanmaken, de Properties (Eigenschappen) van dit Object gelijk zullen zijn, en een kopie rechtvaardigt...  Wat er verder met het Object moet gebeuren staat beschreven in een Initialisatie Procedure, en daar daarin "coding" kan staan, wordt die vervolgens wél uitgevoerd, maar de basis voor het Object zou de kopie kunnen zijn.

Als ik hierin gelijk heb, dan gaat VFP ervanuit dat de default Eigenschappen van een Object enkel bestaan uit "constante waarden"; die kun je immers zo kopiëren naar een volgend Object. In het huidige voorbeeld wordt echter een van die Eigenschappen gevuld met een variabele waarde, nl. de Systeemdatum...

Geneuzel... of misschien de verklaring voor hetgeen nu gebeurt... het is i.i.g. een theorie waarom het Object welke vandaag wordt aangemaakt, en geïnitialiseerd wordt op de Systeemdatum, zich meldt met een datum van gisteren, toen het Object voor het eerst gebruikt werd... Als mijn theorie klopt, houdt dit in dat het toekennen van de variabele waarden niet vanuit de definitie van het Object mag plaatsvinden, maar via de Initialisatie Procedure...

Misschien kan ik dit al testen met het aanpassen van de datum van de pc, en anders moeten we even tot morgen wachten...

Mijn theorie klopt...

Probleem is bij deze opgelost (vereist wel een Upgrade, waarvoor we eerst nog classes beschikbaar moeten stellen, dus meld je even bij mij als je een Upgrade gaat aanvragen).