Het lijkt mij dat er iets fout gaat.

Vraagje : Merk je dat nu pas c.q. was het wellicht altijd al fout, of weet je eigenlijk wel zeker dat het ooit heeft gewerkt ?

Wim,


Zou het niet verstandiger zijn om te benoemen wat je werkelijke probleem is, in plaats van naar een oplossing te vragen ?
Ik bedoel, zaken in het pakket "misbruiken" kunnen we altijd nog als we (samen) vinden dat het niet anders kan. Maar op zich weet je waar "misbruik" toe kan leiden, dus ... ?

Peter

Op zich "lastig", of beter, raar ...

Dit wordt formeel gebruikt om hoeveelheden pallets te kunnen omrekenen naar hoeveelheden dozen zeg maar (en andersom), opdat je bij de VORegel kan kiezen (de klant kan dus 10 pallets tomaten X bestellen, waarbij de Raaplijst meldt hoeveel pallets er met de betreffende Verschijningsvorm de deur uit moeten <- kort gezegd hoor).

Nu gebruiken jullie dit toch niet (en wil je niet ook wat mij betreft), waardoor je dùs bent geholpen met domweg die 3 veldjes erbij. Maar vervolgens moet de rest niet denken dat je kan kiezen. Een inriching met of-of werkt misschien al niet eens (want het gaat verder dan alleen de betreffende Verschijningsvorm, zie "Komt uit" (o.i.d. !)) terwijl en-en volgens mij helemaal uit den boze is. Je zou dus iets krijgen met een dikke streep, met daaronder de nieuwe veldjes voor jou, met de opmerking "geen logistieke werking". Maar dan werkt het nog niet, want wat jij boven de streep invult heeft voor jou eveneens geen logistieke werking.

Een gedrocht dus.

Naar mijn mening kunnen we er dan beter iets nieuws voor maken, en daar betaal je uiteindelijk (waarschijnlijk) meer voor dan de gedrocht oplossing.

Als je nou zegt "laat dan maar zitten" zijn we er tenminste al weer vanaf.

Ja, ik denk het wel. Maar dat is dus gewoon fout, toch ?

Ik vrees alleen dat als wij deze fout oplossen je onmiddellijk ergens anders over klaagt. Een soort van : dit zit er expres zo in en wel voor jullie.

We zullen dit wel "oplossen", maar wees voorbereid !

Als je nu op basis hiervan nog meer trucs ziet (voor de Ordertoeslag) laat het dan even weten. Immers, dan zouden wij ook die met een Financiële Groep kunnen vullen (??) maar dan een andere ? En, als jij zegt dat het voor de vrachtkosten wel "werkt", waar komt die financiële groep nou vandaan dan ? (dit is ook precies waarom we het jou hebben gevraagd; wij zien die groepen hier ook gevuld, maar waarvandaan ? ...)

Sorry dat dit wellicht een ietwat knullig overkomt, maar sommige dingen leiden te lang een eigen leven om nog te weten hoe het in elkaar zit. Op zich niets aan de hand, maar dan gaat het uitzoekwerk ten eerste meer kosten dan het maatwerk, en ten tweede dus ook meer dan je wilt betalen. Nou ja, dat denk ik dan maar.
Achterdeur trucs werken dan vaak beter, zolang het maar geen misbruik wordt.

Overigens, tot dat soort trucs zou ook horen : het alsnog opnemen van een Artikelnummer voor dit soort zaken. Ik denk dat je er dan ook wel bent. Ik kan alleen niet overzien hoeveel programmatuur iets zegt van "als er geen Artikelnummer is ingevuld, dan ...".

Kijk voor de lol eens in LOVR wat er is ingevuld bij LOAG_AID (Artikelgroep), en probeer vervolgens eens een rapportage op (die) Artikelgroep ...
Het zal wel niet doen wat je wilt, maar je weet toch maar nooit.

Voor de rest ... alleen al het uitzoekwerk wat er moet gebeuren en hoe/of het kan zal je al niet willen betalen.

Het verhaal is op zich wel duidelijk, maar niet wat er nu verkeerd gaat;


Hoezo "dat specifieke kontrakt" ??
Als je dit gewoon hebt omgeschreven omdat je dat wel aardig leek, ok. Maar kan je dan ook vertellen wat er fout gaat. Anders gezegd, kiest het systeem nou een Kontrakt uit om die HPP datum te bepalen ? of ... wat gebeurt er nu eigenlijk (niet goed) ?

Tja, da's wel een goeie. Ik bedoel, zo af en toe worden dit soort zaken als additioneel maatwerk gevraagd (zal je zelf ook wel aan hebben meegewerkt), en wie denkt er dan aan zoiets ... Niemand dus.
En ik weet ook niet of dat wel zo gemakkelijk is in te bouwen (al was het maar omdat er intussen best veel van dit soort "toeslagen" zijn).

N.b.: Als je dit via DKKs weet te regelen werkt het wel, want daarop kan je expliciet rapporteren.

De vraag van Frans moet sowieso in de context worden gezien van wat Marco vraagt. Dus, zonder zo'n "server verse" zal dat heus niet lukken (althans, het zou heel normaal zijn dat dat niet lukt).

Het antwoord op de vraag van Marco is denk ik niet zo maar te beantwoorden; Ik zou er in elk geval niet vanuit gaan (lees : je mag dat alsnog voor iedereen doen).

Ik denk alleen dat de eigenlijke vraag daarover niet gaat; die gaat er meer om "kan ik beter een server versie nemen bij meer dan XX gebruikers ?"

Wel, ik zou naar de prijs kijken en dan doen wat het goedkoopst is.
Of die server versie ook zo maar werkt bij de huidige Heart-Profit programmatuur ? geen idee. Ik hoop het !

Een eerlijk antwoord (maar let wel, misschien niet juist !) :

Bij dat vorige topic heb ik al zitten denken "waarvoor is dit gemaakt, en wie gebruikt en, en vooral, hoe ? Namelijk, ik zie niet zo snel hoe dit kan worden gebruikt, deels om de redenen die je zelf al tegenkomt en zéker als de Historische Kostprijzen nog handmatig gewijzigd kunnen worden ook. Ik beoel, dan kan je er toch nooit meer iets mee ?

Ik vermoed aldus dat jij hier funktionaliteit hebt gevonden die niet is bedoeld voor "degelijk gebruik". Verander de regels een ietwat en het kan erop gaan lijken, maar veranderen van de regels zal betekenen dat diegene die dit ooit zo heeft laten maken iets niet meer kan doen (zoals dat Wijzigen bijvoorbeeld).

Het allerliefst heb ik dat je hier gewoon niets mee probeert te doen, en het anders neemt zoals het is.
Wat mij betreft hoort deze funktionaliteit niet te bestaan. En anders op een heeel andere manier.


PS: Als iemand bij ons kan achterhalen voor wie dit is gemaakt, kan ik het wellicht beter plaatsen.

Hmm ... Ik weet nog zo net niet of je wel gelijk hebt in je konstatering. Immers, je baseert je op een 0,1101 die ontstaan lijkt te zijn uit het wijzigen van een Historische Kostprijs (zie jouw laatste schermkopie, 1e regel) en ik denk dat dit niets doet voor de berekening.

Waarom je de Historische Kostprijzen kan wijzigen moet je mij niet vragen (en de Helptekst heb ik gelezen).

Dus ... ?



PS: Gezien je notatiewijze van de 2,438 ... ik neem aan dat je wel door hebt dat dit 2 euri op 24 ton is, toch ?

Ik snap wel dat je dat niet snapt. Zeker gezien de vorige versie.

Wat wij hebben bedacht (maar eigenlijk zo meegekregen als idee van jou zelf) is dat waar je een dokument kan emailen (automatisch) je deze niet beschikbaar hebt als kopie. Kan je natuurlijk wel weer een papiertje proberen te printen (kan bij de Fakturen meen ik wel), maar je kan het ook "archiveren". Wel, dat opslaan is dan leuk, maar opslaan als Kontakt is nog leuker.
Nou voel je wel, willen wij dit zelf gestand doen, dan moet het betreffende dus eerst kunnen worden ge-emailed. Technisch gezien heeft dit ook te maken met het ophalen van de NAW gegevens enz. en waarvan we hebben bedacht dat dit voor de Variabele Layouts allemaal werkt, en voor de niet-Variabele Layouts niet. En dat klopt ook wel aardig.

Voor een misschien beter begrip kan je het ook andersom bekijken :
Een willekeurige print kan je emailen, maar niet automatisch. Opslaan kan je'm ook, en redelijk automatisch, ware het niet dat je zelf de initiële opdracht moet geven. Opslaan als Kontakt zou ook kunnen, maar dàn krijg je dus problemen met het "dossier", immers, de sleutel moet op juiste wijze bekend worden gemaakt, en dat kan je alleen maar zelf doen voor zo'n algemeen printje.
Omdat nu alle Variabele Layout prints precies andersom waren gemaakt als dat ik wilde (als mijn ontwerp wilde), werkte het dus precies niét dat bijvoorbeeld een uitgaande Faktuur als Kontakt kon worden opgeslagen. Jaaa, die je met de hand deed. Die wel. Maar hoezo die ? immers, dat doe je als nazending of zo, en waar je de oorspronkelijke Faktuur niet doet, doe je deze ineens wel ? Raar.
En zo geldt dus dat alles wat automatisch kan a. een adres c.q. Kontakt sleutel heeft en b. desgewenst als Kontakt kan worden opgenomen.

Het is dus de regel met het idee erachter waardoor het Keurigingsrapport nu niet meer werkt. En dit klopt dus precies, want niemand wil dat ding (automatisch) kunnen emailen, en wat nu ook (nog) niet kàn omdat de gegevens daarvoor ontbreken. Emailen kan je'm dus heus wel (tenminste, dat hoop ik toch, handmatig), maar automatisch opslaan als Kontakt niet.

Ik denk niet dat we dit moeten doen, en zoals ik het zie is de vraag van Robert niet terecht geweest ...

Lees mijn opmerking als volgt :

Als het de bedoeling zou zijn de Eerst Mogelijke Verzenddatum te gebruiken om normaal op te leveren, dan MOET je dit op 200++ plaatsen in het systeem doorvoeren. Immers, anders is er niets consistent. Niets werkt namelijk met deze datum (doch zie zodirekt), en het betreft hier wel "logistiek". Dus bijvoorbeeld, waar de Rapellist logistieke werking mag hebben (je reageert er op, je gaat iets doen), laten de overzichten die je hier behoort te gebruiken (en dat is dus toevallig niet de Rapellist die jullie wellicht als een soort Raaplijst gebruiken) niets zien. Dat is toch raar. Verder zal de Behoefterun er ook niet mee werken, enz. en kortom, het klopt dus niet.

Dat dit wèl in Routeplanning wordt gebruikt is logisch. Immers, dit is veelal gebaseerd op 1 keer per week dezelfde route rijden (lees : die klant aandoen), en of die klant moet 6 dagen langer wachten omdat hij het net wilde hebben op de dag nadat de route is gereden, of hij krijgt het 1 dag te vroeg (mits toevallig (!!) aanwezig). Het laatste gebeurt via de eerst mogelijke verzenddatum, die zodoende ook op 6 dagen eerder zou kunnen liggen.

Nee hoor. En dan maken we het met Prijzen van 0,00 (kan later ook nog wel anders). 12 uur dus.

Aannemend dat je hierin gelijk hebt (ik heb het niet nagekeken) vergt dit wel een Bedrijfsparameter. Immers, iedereen werkt nu zoals het is, en dat kunnen we niet zo maar veranderen.

Trouwens, weet je dit wel zeker ? ik bedoel, ja, voor heel veel produkten zal het opgaan bij jullie, maar misschien toch ook niet voor allemaal ?