Heart-Profit ERP
July 01, 2024, 08:33:56 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 [85] 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 ... 273
1261  Heart-Profit Boards / Heart-Profit ERP Support / Re: Iemand ODBC-koppeling in Excel 2007 icm Windows 7 werkend? on: August 26, 2010, 03:43:36 pm
Geen antwoord van mijn zijde, maar de wellicht van belang zijnde vraag of je het op die andere PC's wel werkend hebt (je zegt dat bijna wel, maar toch net niet).

Ver weg staat mij bij dat ik ooit iets heb gelezen dat je de nieuwste versie van Excel nodig hebt, maar ik heb ook het gevoel dat dit net ergens anders over ging. Wouter weet dat hopelijk, maar die is al weg. Morgen weer.
1262  Heart-Profit Boards / Heart-Profit ERP Support / Re: Printen kontrakt klient - opties J en R rubriek 'Alleen openst. kontrakten' on: August 26, 2010, 02:10:51 pm
Pascal, dat de "R" anders moet zou je uit de helptekst kunnen afleiden, maar waar haal je vandaan dat de "J" anders moet ?

Ik snap wel dat je dat kan willen, maar dat is een ander hoofdstuk ...
1263  Heart-Profit Boards / Heart-Profit ERP Support / Re: Geen aparte landcodes voor Tsjechië en Slowakije on: August 24, 2010, 02:54:26 pm
Volgens mij kan je dat gewoon zelf veranderen hoor. Ik zou alleen zelf even moeten opzoeken hoe ...
1264  Heart-Profit Boards / Heart-Profit ERP Support / Re: onderhoudsmodule on: August 20, 2010, 01:21:48 pm
Quote
Houdt er wel rekening mee dat je dan een hele subadministratie erbij krijgt om bij te houden.

Ja, en dan ook nog een redundante sub administratie.

Quote
De mogelijkheden die je daar hebt zitten zo ver ik weet niet heart.

Wel, als ik het zo bekijk zijn de mogelijkheden van dat pakket ook niet erg nodig/nuttig voor onze vragensteller hier. En verder ? ik zou niet weten hoe jij betreffende mogelijkheden zou weten/kennen. Maar misschien ben ik in deze iets vergeten.
Overigens mag je nog steeds gelijk hebben; ik weet het gewoon niet.

Wat ik wel weet is dat het 100% niet slim is om iets dergelijks in een derden pakket te gaan bijhouden. Maar ja, misschien is het wel toegestaan er ook even op te wijzen dat wat jullie in deze zullen doen en nodig hebben - als ik het mag vergelijken met wat Dinand nodig heeft en daaruit een grootste gemene deler destilleer - jij (Marco) het wel op de achterkant van een sigarendoosje kan doen. Nou ja, zo ongeveer dan

Ik zeg nogmaals, ik weet het niet, en kan hooguit proberen uit te duiden hoe het geheel in Heart-Profit is opgezet (en waarom).

Laten we beginnen met te stellen dat een mengertje iets anders is als een kraan. Je zou ook kunnen zeggen dat een terrein van 0,5HA iets anders is dan 10HA. Nee, dat zegt niet alles, maar toch wel wat.
Een menger is niet alleen iets anders als een kraan aangaande de omvang en complexiteit, maar vooral aangaande "degelijkheid" en "gevaarlijk" om het zo maart te zeggen. Een motor van een menger kan stuk gaan en dan mengt 'ie niet meer, en de motor van een kraan kan stuk gaan en dan ... geen idee, maar het lijkt me minder handig en onveilig;
Als ik een menger heb dan zal het me vast wel een worst zijn welke onderdelen er precies inzitten, maar als ik een kraan heb dan zou het wel eens verplicht kunnen zijn om dat te weten. Net zoals alles wat daar omheen hangt aan specifikaties en wat al niet meer.

We kunnen denken dat een willkeurig pakket (doch goedgekeurd door Marco, dus niet helemaal willekeurig) dit alles op vloeiende wijze kan, maar ik geloof er niet zo in. Ik geloof er niet zo in omdat er te veel komt kijken aan handmatig werk òm dat te kunnen doen / bijhouden. Dus bijvoorbeeld, als ik een bout in een motor vervang dan behoor ik (als ik het helemaal goed doe) ook het serienummer van die bout in de "stuklijst" genoteerd te hebben. En, waar een willekeurig pakket dat wellicht wel kwijt kan, ga je mij niet vertellen dat het handig is om dit op redundante wijze bij te houden - c.q. naast een pakket wat nu net gemaakt is voor dat soort zaken (ERP).
Dn nòg is het heus niet normaal om "equipment" zoals dat heet op te bouwen uit onderdelen die feitelijk uniek worden gemaakt door die serienummers, maar in Heart-Profit kan dat in elk geval wel, als het nodig is (lees : kan ook zonder serienummers).

Als een machine onderhoud nodig heeft dan is dat in Heart-Profit een werkorder, en of daar nou onderdelen bij geplanned zijn, of dat deze achteraf gebruikt nlijken te zijn, het lijkt me toch wel erg handig om dit net zoals gebruikelijk te kunnen inkopen, om dit op voorraad te kunnen hebben, om dit te kunnen gebruiken kwa kostprijs, en eigenlijk om dit allemaal te kunnen doen op de manier die je gewend bent. Doe je dit niet, dan heb je 90% niet begrepen. Lijkt mij.

Als je een beetje "echt" denkt, en bij Dinand z'n bedrijf mag dat best denk ik, dan hangt er nogal wat af van het onderhoud en de verdere planning. Nu is dit weliswaar bij iedereen wel het geval, maar als ik "chemisch" bezig ben zoals Marco dan zie ik dat toch iets anders als die ene kraan die ik heb en die in onderhoud moet. Anders gezegd, als je maar wilt heeft dit alles met je verdere planning te maken, en je hoeft zo'n ding maar als resource op te nemen, en je ziet aan je planning wel wet er gebeurt. Nee, ik zeg niet dat Dinand dat wil (en sterker, ik zeg wel dat Marco dit wil, haha) maar het is in elk geval een overweging om zoiets niet "extern" te doen, want het integreert domweg anders niet (ja, alles dubbel bijhouden).

Zoals e.e.a. in Heart is opgezet mag je voor je zien dat dit wordt gebruikt door een club als de Nederlandse Aardolie Maatschappij (in de tijd dat er nog flink naar olie werd gezocht) en dat dit normaliter te groot is voor een willekeurige Heart-Profit klant. En ik ben heel eerlijk : het wordt ook niet gebruikt bij de gratie van het ontbreken van klanten die zoiets ècht behoeven. Een vraag zoals die van Dinand is dan ook vrij zeldzaam.
Hierbij moet ik ook meteen aantekenen dat het expliciet plannen van onderhoud iets heel anders is als het uitvoeren ervan en alles wat daarbij komt kijken. Ofwel, het mag bekend zijn dat Heart-Profit niet echt is gestoeld op alles wat expliciet "projektmatig" is. Toch is dit betrekkelijk, want als er één bedrijf is wat projektmatig werkt is het het bedrijf van Dinand wel. Echter, de nadruk ligt uiteindelijk toch op de produktie (enz.) waardoor het geheel in consistentie toch best wel aardig lukt. smile
Evenzo met het plannen van het onderhoud; alle voorzieningen zijn er, maar laat het systeem nou niet automatisch een onderhoudsbeurt plannen omdat een wet (die je kenbaar hebt gemaakt) zegt dat het nodig is (dat soort zaken zitten dus in het pakket van Marco). Welnee, je zet je Werkorders er in (eventueel op tevoren aangegeven schema en dan gegenereerd), en waar de (grafische) planning het betreffende equipment wel buiten gebruik stelt, zal je tegen die tijd de order (het onderhoud) wel uitvoeren, of doet dat een week later gezien de verdere planning. Heeft dat boutjes, moeren, accuus en riempjes nodig ? dan wordt dat vanzelf wel ingekocht zoals je gewend bent, en als je nog een zuiger hebt vervangen dan weet je die wel te boeken als altijd. En dus :

Quote
Dit soort systemen zijn nooit beter dan degene die ze vult....

en dus slaat dit m.i. niet echt ergens op. Tenzij je van je normale produktie ook een zooitje maakt, dan gaat het hier ook op (wat absoluut niet is bedoeld om te zeggen dat Marco's administratie dus een zooitje is, in tegendeel). Neen, het komt domweg voort uit het gebruik van een derden systeem ...

Vanuit een iets andere invalshoek dan zo valt te lezen (maar waar Marco o.a. heus wel op doelt) moet ik wel zeggen (en waarschuwen voor) dat je niet "zo maar" even je machinepark in onderhoud doet op de door mij gesuggereerde wijze. Immers, als je niet oppast verdubbelt je artikelbestand met alle motortjes en ringetjes en weet ik veel, en verstand heb je er ook nog niet van. Dus, het is een "wereld" op zich, naast je normale werkzaamheden, met een eigen berg voorraad waar je niet goed van wordt. O ja, die voorraad hadden we al gezien. Ok, nu nog even inbrengen, en af en toe ook even inventariseren, enz.
Dus nogmaals :

Quote
Dit soort systemen zijn nooit beter dan degene die ze vult....

Hmm ... Er zit echt wel iets in. Dus, als je de ringetjes en verder geneuzel *niet* invoert terwijl ze er echt wel inzitten en altijd worden vervangen voor een paar euro, tja, hoe houd je dàn de kosten goed in de gaten ? Het hangt er dus maar net vanaf hoe sluitend je het hebben wilt, en hoe erg het is als het helemaal niet sluitend is. Of : wat je er nog aan hebt als het niet sluitend is.

Uit het bovenstaande mag volgen dat er niet één reden is om dit alles bij te houden (desnoods "half"). Je kan het voor de kosten doen, voor de planning van je produktie, voor de automatische inkoop, voor de veiligheid, voor de wet (= veelal veiligheid), voor de planning van het onderhoud zelf (als die rime niet wordt vervangen eind 2010 knapt de boel vanzelf), en vast nog wel meer.

Goed, Dinand, ik denk echt wel dat dit werkt voor jullie, ook al omdat je alles "half" màg doen. Er zal misschien wel het e.e.a. bij komen kijken alvorens je het precies zo hebt zoals je wilt, maar werken gaat dat heus wel. Echter, voordat je zo ver bent om het te proberen, moet je eerst goed weten hoe belangrijk je de integratie met de rest van het systeem vindt; In deze post heb ik tussen de regels door wat voorzetjes gegeven, maar wil niet nalaten de grafische planning nog eens expliciet te noemen, domweg omdat je er waarschijnlijk niet eens weet van hebt (dat die zo ongeveer bestaat) terwijl ik wel aardig 100% zeker weet dat jullie die willen hebben c.q. gaan gebruiken. Als er dan één ding erg handig is, is het voor het hele jaar al kunnen zien welke machine wanneer hoe lang in onderhoud is, opdat je in elk geval weet dat je daar geen produktie kan plannen (lukt je ook niet). En afhankelijk van hoe je het in elkaar draait, strekt dit t/m leveren. Nou zal je er met je berg vrachtwagens wellicht best uitkomen (zoals tot op heden), maar met die bijzondere kraan zou het iets anders kunnen zijn.


Nog één opmerking die in eerste instantie niet gerelateerd lijkt, maar het wel degelijk kan zijn :
De Grafische Planning zal (aannemend dat ons dat leuk lukt) ook voorraad lokaties bevatten als zijnde "resources". Ik kan zelf geen goede voorbeelden voor Dinand noemen, maar dat kan hij denk ik zelf wel. Denk in elk geval aan iets van het moeten drogen van stenen, en zolang die stenen in de betreffende ruimte liggen, kan je producren wat je wilt, maar de ruimte is "in gebruik". Dit wordt meer gemaakt voor toepassingen als die van Marco (en denk dan maar aan een stapeltje silo's), doch denkelijk is dit voor iedereen van toepassing. Wel, afhankelijk van wat voor een soort "ruimte" dat is, kan ook die onderhevig zijn aan onderhoud (zoals domweg periodiek moeten schoonmaken). En, omdat het uiteindelijk een prodktiemiddel is, is het erg handig om te kunnen "zien" dat je aldaar niets kan plannen kwa produktie als het onderhoud daar is.

Rest mij om te melden dat ik het zelf erg leuk zou vinden om die betreffende modules een keer in vol ornaat aan het werk te zien (we hebben ze toch niet voor niets gemaakt) ? maar ook dat er heel heel veel bij kan komen kijken, als je maar wilt. Anders gezegd, een module "Profit-Onderhoud" gaat je de kop niet kosten, maar "afhankelijk van" komen er meer modules bij kijken. Ik hoef bijvoorbeeld maar te verwijzen naar het enorm handige van "scannen" in dit geval (hoezo zo'n dom ringetje helemaal administratief moeten verwerken ? -> gewoon scannen op de Werkorder, klaar), en je kan al wat extra buien zien hangen. Maar goed, het is altijd weer voor het gemak;
Het is nog altijd zo dat we niet voor niets een 94 modules hebben waarvan "jij" er ook 35 in gebruik hebt. Dat is omdat je (veel) verder kan. Redelijk eeuwig.

Dinand, ik hoop in elk geval dat je iets aan deze post hebt, gewoon voor de juiste overweging. Een pakket van een derde is mij ook goed, als je uiteindelijk maar het beste hebt voor de organisatie. Wat dat betreft valt een advies van Marco ook werkelijk niet verkeerd, en kan ik alleen maar hopen dat Marco hetzelfde heeft overwogen als jij nu kan (maar ik herinner het me niet smile).
Peter
1265  Heart-Profit Boards / Heart-Profit ERP Support / Re: Vraag: hoe wordt de vervangingswaarde van een productieartikel bepaald on: August 18, 2010, 01:32:34 pm
Ok, ander idee :

Voor produktieartikelen gebeurt het op basis van de ingevulde Vervangingswaarden van de grondstoffen die dan via het Recept tot de Vervangingswaarden van het te produceren produkt leiden. Maar ...

Ga je maar afvragen wat er gebeurt als je van de 10 grondstofregels in het recept van slechts 1 de Vervangingswaarde hebt ingevuld. Of die andere 9 tellen dan niet mee (kan je zo zelf proberen) of van die andere 9 wordt één van de andere Kostprijzen genomen.
Denk dan ook nog wat verder aan het gegeven dat je het over een halffabrikaat kan hebben met een Vervangingswaarde die al dan niet is ontstaan uit de ingevulde Vervanginsgwaarden bij de grondstoffen, en je weet gewoon niet meer wat je eraan hebt.

Dus, zonder verder te kijken zou ik zeggen "laat maar, niets mee doen"; het kan gewoon niet zinvol werken.

Als je dit wel graag wilt, dan stel ik voor om de Vervanginsgwaarde van het te produceren produkt invulbaar te maken. Het zal wel een Bedrijfsparameter kosten (4 uur), maar de eigenlijke aanpassingen (niet meer overschrijven uit berekeningen) maken we dan wel gratis.

Of als je uiteindelijk iets heel anders wilt, laat het dan even weten.
1266  Heart-Profit Boards / Heart-Profit ERP Support / Re: FAKTUURLAYOUT wordt niet meer geaccepteerd in LORDWY on: August 17, 2010, 11:29:49 am
7-3-F4-1

Nee, dat vind je niet zo maar. no
1267  Heart-Profit Boards / Heart-Profit ERP Support / Re: Vraag: hoe wordt de vervangingswaarde van een productieartikel bepaald on: August 17, 2010, 06:14:33 am
Handmatig. Dus, wat je zelf invult geldt.
1268  Heart-Profit Boards / Heart-Profit ERP Support / Re: helptekst komt niet overeen met actieve veld on: August 05, 2010, 12:09:26 pm
Dank je Marco. We zullen het aanpassen.
1269  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 03:15:44 pm
Het zal heus "ergens" vervangen, anders was het wel dezelfde funktie gebleven.

Zullen we dat voor morgen plannen, en dan zo vroeg mogelijk ? Moet jij even de tijd aangeven, ok ?
1270  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 02:24:19 pm
Terecht dat je dat niet kan vinden; Bevindt zich in een alternatieve funktie (LOPRVORV).

Nou weet ik niet hoe belangrijk het is dat je dit kan zien ... Maar het lijkt me dat je dit wel moet kunnen beoordelen door dit tijdelijk bij jou erop te zetten.

Gebruiken jullie deze funktie sowieso (LOPRVORL) ?
Zo ja, is er een moment op de dag dat deze funktie kan worden vervangen door de alternatieve zodat je 'm kan bekijken ?
1271  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 01:42:07 pm
Ik zoek het wel even uit.
1272  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 12:01:50 pm
Heb je de eerste Bedrijfsparameter al aangezet ?
Dat zou ik in elk geval eerst doen.
1273  Heart-Profit Boards / Heart-Profit ERP Support / Re: Waar haalt LOPRTV Printen Transportlijst Vervoerde de palletinformatie vandaan? on: August 02, 2010, 11:34:15 am
Nou, dan kan jij beter uit de voeten met die wazige print dan ik.
Geef voor de lol eens één voorbeeld uit die If/Else zooi van het gebruikte veld waarop jij moet doelen ?
1274  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 11:28:31 am
Johan, heb je verder nog veel te doen vandaag ?

Merk op dat alleen waar "GEREED" bij staat er ook daadwerkelijk is. De rest (en meer natuurlijk) kan ook worden gemaakt, maar daarvoor moet je dan zelf opdracht voor geven.


  • Bedrijfsparameter Expeditie "Volume Factor Standaard Verschijningvorm". =0001=
    In het FO omschreven als "sd" (standaard doos) en bedoeld om het volume van alle verschillende Verschijningsvormen om te rekenen naar een standaard volume of beter : standaard Verschijningsvorm, waarbij vervolgens de hoeveelheid die op een pallet past kan worden uitgedrukt in aantallen Standaard Verschijningsvorm. Dit laatste is op zich weer nodig om het volume van verschillende palletsoorten tot uitdrukking te kunnen brengen.

    N.b.: De in het FO genoemde "sd" zal vanaf heden in het pakket "SV" gaan heten.

    4 uur, EUR 496,--.  = GEREED =


  • Bedrijfsparemeter "Aantal Standaard Verschijningsvormen op blokpallet". =0002=
    Soortgelijk aan =0001= maar nu om de verschillende palletsoorten te kunnen omrekenen naar een standaard, en voor welke standaard de blokpallet wordt genomen.

    4 uur, EUR 496,--.  = GEREED =


  • Toevoegen / Wijzigen / Verwijderen Palletsoort. =0003=
    2 posities voor de identifikatie lijkt voldoende.

    In deze entiteit op te nemen in elk geval de velden Aantal SV op pallet en Uitdrukken in Palletsoort;

    De laatste is bedoeld om aan te geven in welke van de andere Palletsoorten de aan de orde zijnde Palletsoort moet worden uitgedrukt. Zie het volgende voorbeeld :

    Blokpallet bevat 150 SV'n en verwijst naar Blokpallet (dus 1:1);

    SkidXL bevat 180 SV'n, dus uitgedrukt in Blokpallets zijn dit er 180/150 = 1,2. N.b.: Als dus één SkidXL moet worden vervoerd, wordt (aan bijvoorbeeld de vervoerder) gezegd dat het het volume van 1,2 blokpallets betreft. Ook : Hoeveel SkidXL's er aan de orde zijn wordt bepaald door het aantal SV'n (waarbij de SV ontstaat uit de werkelijk gehanteerde Verschijningsvorm en het aldaar aangegven volume met haar relatie naar het volume van de SV.

    Hierin tevens op te nemen de afmetingen (LxBxH) van de pallet. N.b.: Waarschijnlijk wordt dit verder niet gebruikt, maar kan theoretisch gezien worden gebruikt voor de bepaling van de hoogte van (gestapelde) pallets; Indien tijdens het maken van onderhavig maatwerk wordt bepaald dat de afmetingen van de pallets hiervoor niet kunnen worden gebruikt, kunnen deze rubrieken (LxBxH) vervallen.

    11 uur, EUR 1.364,--.  = GEREED =


  • Raadplegen Palletsoorten. =0004=
    11 uur, EUR 1.364,--.  = GEREED = (TE VINDEN VIA 1-1-1-8-9-4)


  • Aanpassen Toevoegen / Wijzigen / Weergeven Debiteur m.b.t. "Default Palletsoort" en "Stapelhoogte daarbij". =0005=
    De intevullenPalletsoortmoetbestaan(=0003=), maar mag ook worden leeggelaten.

    N.b.: Het betreft hier de Palletsoort die op zich eveneens als default op de Verkooporderregel zal verschijnen.

    De ingevulde Stapelhoogte (indien ingevuld) zal moeten worden gerespekteerd bij het opbouwen van de pallets in het magazijn. N.b.: In feite wordt dit bepaald door de verschillende Afleveradressen van de Debiteur, doch bij XYZ zijn de Afleveradressen bepaald door de Debiteur (die onder een Groepsdebiteur hangen als werkelijke Debiteur). Heart Intern : Voor het pakket is dit feitelijk onjuist, en zulks dient in de Helptekst te worden genoemd.

    2 uur, EUR 248,--.  = GEREED (BIJ AFLEVERADRES IPV DEBITEUR !) =


  • Aanpassen Toevoegen Verkooporderregel m.b.t. Palletsoort =0006=
    Indien bij de Debiteur een Palletsoort is ingevuld zal deze default worden voorgesteld en mag worden overschreven.

    Let op : Het aantal SV dat aan de orde is zal worden getoond, maar mag niet worden overschreven (lees ook de opmerkingen onder =0005= aangaande het eventueel ingevulde Aantal SV voor de Debiteur !).

    Het aantal SV dat aan de orde is bij de opgegeven Palletsoort (mag per Verkooporderregel anders zijn) wordt berekend volgens de logika zoals geïmpliceerd in dit ontwerp; dit behoeft echter (nog) niet duidelijk te zijn, waarvoor wordt verwezen naar het FO van XYZ zelf; hetgeen dáárin aangegeven zal in elk geval worden gebruikt (zonder tegenbericht uiteraard).

    De Palletsoort en weergegeven aantal SV zal geheel onderaan worden opgenomen in LOVRTV (uitgangspunt moet zijn dat het niet reëel is om dit anders te willen (denk in dagen extra werk)).

    5 uur, EUR 620,--. = GEREED (OOK BIJ WIJZIGEN !) =


  • Raadplegen Virtuele Raaplijsten m.b.t. "Totaal blokpallets" en "Totaal europallets". =0007a
    Let op : Met "Virtueel" wordt hier bedoeld dat a. ook als er nog geen Raaplijsten zijn, het mag lijken alsof er al één is (denk aan Raaplijst 0), terwijl b. het aantal blokpallets en aantal europallets feitelijk alleen kan worden geregistreerd op Raaplijstniveau in verband met de mogelijkheid van Deelleveringen.

    N.b.: Bij XYZ treden normaliter geen Deelleveringen op, maar wat uiteindelijk toch (technisch) het geval is op het moment dat een Verkooporder deels uit magazijn Nederland en deels uit Magazijn België wordt geleverd.

    Heart Intern : Aangezien het uiteindelijk om de funktionaliteit zoals hierna beschreven onder =0007b= gaat, lijkt het het beste (?) om met een Tijdelijk Bestand te werken dat ofwel is opgebouwd uit Verkooporderheaders ofwel is opgebouwd uit Raaplijst Headers wanneer deze laatsten bestaan voor betreffende Verkooporders. Verder, omdat er geen in de database bekend middel is om de selektie te beperken, zal het Tijdelijke Bestand moeten worden opgebouwd uit een (geïmpliceerde) datum-reeks, waarvoor bijvoorbeeld het Verkoopordernummer (van/tot) mag gelden. Het lijkt dan verstandig om een "harde" maximale reeks in te bouwen, zoals bijvoorbeeld "100 dagen", waarmee de gebruiker niet per abuis (typefout) het Tijdelijk Bestand laat opbouwen uit Verkooporders c.q. Raaplijsten die meer dan die beperking (zoals "100 dagen") wordt opgebouwd.

    Heart Intern, Let op : Wellicht is het een betere oplossing als hiervoor een apart bestand wordt bijgehouden, met als sleutel het Raaplijstnummer, en waarbij ook Raaplijst 0 aanwezig is als er nog geen daadwerkelijke Raaplijsten zijn. Dit zal de verdere hieraan gerelateerde funktionaliteit verregaand vergemakkelijken (zoals =0007b=) maar met als penalty dat dit bestand redundant is (als de Verkooporder wordt verwijderd moet het record uit dit bestand eveneens worden verwijderd, net zoals andersom : als iets een Verkooporder genereert zal dat in dit bestand eveneens een record moeten aanmaken). E.e.a. in overweging te nemen, waarbij de gereserveerde tijd wordt geacht vast te staan (zie onder). Het moet dus wel uit kunnen ... (en dat kan het waarschijnlijk nooit).

    Waar het het uiteindelijke doel is om ofwel op voorhand het verwachte aantal blok-/europallets te kunnen overrulen (want het systeem berekent het theoretisch), dan wel achteraf te kontroleren of de faktuur van de transporteur juist is (en die is opgehangen aan het aantal blok.europallets), is deze "ene" Raadpleegfunktie dus de ingang tot het wijzigen op voorhand wat in de Verkooporder Header zal zijn geregistreerd, dan wel het bekijken achteraf wat in de Raaplijst Header(s !) zal zijn geregistreerd (via Touchscreen leveren, zie =0009= hierna).

    12,5 uur, EUR 1.550,--.


  • Wijzigen Virtuele Raaplijsten m.b.t. "Totaal blokpallets" en "Totaal europallets". =0007b=
    Let op : Waar de ingang immer de Raadpleegfunktie uit =0007a= is, bevinden de gegevens aangaande euro-/blokpallets zich op het niveau van de Verkooporder Header als er nog geen Raaplijsten voor de Verkooporder bestaan, of op het niveau van de Raaplijst Header(s) als er al wel Raaplijsten bestaan. Uiteraard betreft dit een slecht genormaliseerde situatie, die kwa consistent houden extra tijd vergt (welke tijd in deze funktionaliteit =0007b= is begrepen).

    Hierin tevens begrepen de berekening van het aantal bedoelde pallets en het adekwaat bijhouden daarvan. Algemene opmerking hierbij : het is niet zo gemakkelijk als het lijkt om dit werkbaar te houden.

    Het is de bedoeling dat het systeem berekent hoeveel pallets er aan de orde zijn, wat in eerste instantie in 2 decimalen gebeurt. Let wel, de berekening op 2 decimalen (meer mag ook) dient op Verkooporderregel al zo te geschieden, maar op het niveau van de Verkooporderregel wordt niets opgeslagen (!!). Het wordt dus iedere keer opnieuw berekend. Zo ook als het totaal op Header niveau moet worden weergegeven : dan is alles opnieuw berekend. Let op : Dit berekenen dient alleen te gebeuren als het betreffende scherm wordt opgevraagd (scherm 5 van Weergeven en tabblad 4 van Wijzigen). Merk op dat hiermee slechts de bedoeling van "niet onnodig veel berekenen -> kost tijd" wordt aangegeven; uiteindelijk moet het berekenen overal gebeuren waar nodig (en waar dit nodig is wordt hier geen uitspraak over gedaan; dit blijkt vanzelf).

    Als het systeem op enig moment heeft berekend dat er 16,30 blokpallets zijn benodigd, zijn dit er volgens het FO 17, maar is het XYZ toegestaan er alsnog 16 van te maken (of 18, enz. enz.). De problematiek zoals geïmpliceerd in de tweede alinea bevindt zich dan in bijvoorbeeld (!) het gegeven dat er van 16,30 18 is gemaakt terwijl a.g.v. een wijziging in een Verkooporderregel de 16,30 is veranderd naar 16,90, die 16,90 lijkt te kunnen leiden tot de zelf ingegeven 18, maar als e.e.a. nader wordt beschouwd de 18 nu toch 19 moet worden (er *is* per slot van rekening 0,60 bijgekomen, en het hangt er maar net vanaf in hoeverre de 18e pallet al bijna vol was of niet). Hiervoor is het volgende bedacht :

    Op het moment dat de gebruiker een door het systeem berekende hoeveelheid van 16,30 omzet in 18, wordt ook de 16,30 daarbij opgeslagen. Dus, je ziet de basis voor de verandering.

    Naast bovenstaande lijkt het zinvol om ook een korte regel "kommentaar" hierbij te kunnen opnemen, waarbij de persoon die de moeite heeft gedaan om tot "zijn/haar" berekende 18 te komen kan aangeven "18,20". Dus, als het systeem later met 16,90 op de proppen komt, en met de zichtbare wetenshap dat de 18 was genoteerd uit een berekende 16,30 en de 18 al voor 0,20 vol zit, durf je (en niet alleen diezelfde gebruilker) zonder alles opnieuw te doen gemakkelijk de 18 te handhaven (want theoretisch betreft het 18,20 + 0,60 = 18,80).

    Let op : Het hierboven genoemde is aan de orde voor zowel blokpallets als europallets.

    Voor alle veldjes, inklusief de berekeningen via de aan de orde zijnde (verschillend per Verkooporderregel) pallets en gedefinieerde SV'n enz. :

    20 uur, EUR 2.480,--.


  • Aanpassen Rapellist m.b.t. weergave te gebruiken Palletsoort an Stapelhoogte. =0008=
    E.e.a. zoals aangegeven per Verkooporderregel en verder op de ene kombinatie van ingevulde velden voor het starten van de print (dit door XYZ aan te geven). Zijn er meer kombinaties aan de orde dan moet voorshands worden gesteld dat de benodigde tijd hiervoor lineair is.

    Zie voor de Stapelhoogte =0005=.

    2,5 uur, EUR 310,--.  = GEREED =


  • Aanpassen Touchscreen Leveren Verkooporder v.w.b. het deel Emballage en het aantal geleverde blokpallets. =0009=
    Zoals besproken, een persoon op de raapvloer weet de verschillende typen fysieke pallets om te zetten naar aantallen blokpallets en aantallen europallets (bijvoorbeeld : een volle vrachtwagen bevat 33 europallets).

    Merk op dat in bedoeld Touchscreen scherm de emballage reeds wordt opgegeven, doch dat dit zal zijn bedoeld voor de juiste registratie van Emballage c.q. statiegeld (of kosten). Voor de volledige set aan Extra Meegeleverde Emballage (die op zich regel voor regel wordt ingegeven) zal eenmalig worden gevraagd om het aantal blokpallets en het aantal europallets. N.b.: Omdat het hier om gehele getallen gaat, is het niet de bedoeling dat het aantal blokpallets wordt berekend uit het aantal opgegeven europallets of andersom.

    De gegevens worden weggeschreven in de betreffende Raaplijst Header.

    Heart Intern : Dit is het moment (althans bij de eerste Raaplijst) dat op het laatst de overgang van de gegevens van de Verkooporder Header naar de Raaplijst Header mag plaatsvinden (zie fenomeen Virtuele Raaplijst). Immers, vanaf hier zullen de pallet gegevens uit de Raaplijst Header geput moeten worden. E.e.a. verder uit te werken (kan Indikator veld in LOVO zijn).

    6 uur, EUR 744,-- indien òf =0007= òf= 0010= wordtafgenomen. Anders 12 uur meer.


  • Vervallen. =0010=


  • Aanpassen diverse funkties m.b.t. interpretatie "Theoretisch aantal pallets". =0011=
    Op diverse plaatsen in het systeem wordt gewerkt met een zgn. Theoretisch aantal pallets, wat eenzelfde doel heeft als het hier voorgestelde maatwerk, doch minder nauwekeurig werkt en niet zo ver is doorgevoerd. Zonder te stellen dat deze betreffende funktionaliteit moet worden geëlimineerd, zal toch minimaal op die plaatsen waar nodig een expliciet onderscheid worden gemaakt tussen de berekende pallets van dit maatwerk, en de bestaande berekende pallets. Waar nodig moet ook de helptekst worden aangepast.

    4 uur * 50% = 248,--. = GEREED =

swoon
1275  Heart-Profit Boards / Heart-Profit ERP Support / Re: palletsoorten een paar vraagjes on: August 02, 2010, 11:05:38 am
Quote
KOrtom: waar gebruik je dit nu?

Zoals het tot op heden is opgezet : Om te kunnen kontroleren of de vervoerder in rekening heeft gebracht wat jij dacht dat hij zou moeten.
Pages: 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 [85] 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 ... 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.169 seconds with 12 queries.