Als ik deze draai over alle klanten (F) en periode bv 01/01/2008 - 01/02/2008
Dan geeft hij in de print deze periode 2 maal weer ipv 01/2008 t.o.v. 01/2007

        DEBITEUR : 100389                        KLANT1, ergens
              01-01-08  01-02-08             0,00           450,30             0,00           141,14         0,00 %           0,00        68,66 %         309,16            0,000          228,000
              01-01-08  01-02-08             0,00           450,30             0,00           141,14         0,00 %           0,00        68,66 %         309,16            0,000          228,000
        DEBITEUR : 101200                        Klant 2, daaro
              01-01-08  01-02-08             0,00           905,60             0,00           588,40         0,00 %           0,00        35,03 %         317,20            0,000          640,000
              01-01-08  01-02-08             0,00           905,60             0,00           588,40         0,00 %           0,00        35,03 %         317,20            0,000          640,000

ben erin, lijkt gekoppeld te zijn aan lopabewy

zal ik vandaag alle tabbladen gaan disabelen en eens verder proberen...

ja en dan weer F5 op het bedrijf, maar welke authorisatie is deie 2e F5, want bij een "normale gebruiker zie ik die niet...

werkt wel want onze klanten zijn op start nummer bedrijfsuniek (anders houden wij ze ook niet meer uit elkaar.

Maar Stel dat ik jouw voorstel wil volgen?
Hoe geef ik hem toegang tot bedrijfsparameters zonder hem een system manager te maken?

klopt, is ooit juist voor ons gemaakt ...

Is gewoon zo
AD Productions
AD Chemicals

Kan het veld INGCLNR dat nu in bedrijfsparameters staat (optie 3, tabblad 2) verplaatst worden naar de financiele parameters 7.8.1.1?

Dit daar we momenteel meer dan 1 clientnummer hebben en ik eigenlijk de boekhouder geen rechten wil geven in LOBHBERA en LOPAMN (wijzigen bedrijfsparameters)

Maar hij moet dat nummer wel aanpassen als hij namens een bapaalde BV data verstuurd aan de bank.

behalve de 2 genoemde tabellen, moet ik nog meer plaatsen controleren?

PS: Off topic:
Hoe gaan jullie hier op termijn mee om, Ik bedoel dus de velden waar 3 sleutels gecombineerd worden tot 1 unieke sleutel.
Database technisch voel ik er op termijn toch meer voor als dat (ooit) overgaat naar een "normale" veldenstructuur waar een sql achtige statement de sleutel bepaald.
Dit ook met zicht op later overzetten van a;lle tabellen naar SQL of Oracle (ja ik geloof Peter nog steeds als hij meld dat het andere database management systeem er aan komt)
Dat betekent echter wel deat de "roeleveld" in de prullenmand moet...
En daarmee is een van de oudste nog draaiende modules dan om zeep geholpen?
 

Ik heb TOSH000290 omgezet naar TOSH100130

Bij controle is gebleken dat alle teksten die gekoppeld waren aan de keuringen (LOARKVRA) en die gekoppeld waren aan de receptregels (LORTTDRA) niet zijn omgezet naar het nieuwe artikelnummer.

Kunnen jullie hiernaar kijken aub.

in ieder geval wordt de APTX_KEY in LOUX en LOBX niet goed herkend, hier staan de teksten nog met
"ADPROD     TOSH000290     A003C" en "ADPROD     TOSH000290     6612AM    5" als sleutel

Ik kan eventueel wel browsen en wijzigen maar voordat ik zoiets doe heb ik graag even dat jullie het controleren ivm de gekoppelde sleutel verwijzingen

Ik heb het net even in testbest uitgetest, maar het klopt wat jij zegt.

MAAR...
(het zou niet zo zijn)

Ik moet eeerst een flink stuk "doorenteren" alvorens dit werkt.
Ik weet niet waar jij die controles uitvoert, maar als ik het getal wijzig van een bestaand verlies naar een andere waarde dan doet hij het soms niet, tenzij ik eerst alle velden afloop.

Er zit dus nog een 2e probleempje in deze functie mbt waar die trigger bepaald wordt.
het lijkt er in ieder geval op dat dat niet direct bij het genoemde veld is.


mvg

Marco

met dank, het werkt nu inderdaad

(alleen in txt bij authorisaties toont hij nog geen omschrijving bij de LORTTNRA, maar dat doet niets af aan de functionaliteit)

Ik ben ermee aan het testen, maar de authorisatie werkt niet.
Ik heb expliciet aangegeven op
LORTTDRA0 en LORTTNRA0, maar die komen niet in de impliciete authorisaties naar boven

doe ik wat fout?

OK,

Als ik een regel heb met daarop bv 2% verlies (bv als gevolg van verdamping van een oplosmiddel uit ene verfrecept) en ik wil die aanpassen naar bv 2,2% kan ik dat niet direct ingeven.
Je moet dan de receptregel eerst weer terug zetten op 0% verlies, even opslaan en dan het goede % ingeven.
Anders komt er een totaal andere waarde in het recept tevoorschijn.


mvg

MK

Graag zou ik middels een vinkje de hieronder genoemde functies kunnen sturen mbt "verliesfactoren receptuur negeren"
Dit daar mijn mensen graag beide kostprijzen willen weten.
Voorkeur middels Dynscreen instelbaar

LOKPARKK
LOKPAR
LOKPVKHB

Wat moet dit gaan kosten?


mvg

Marco

Beste Menno,

Jij vroeg vorige keer of dit mogelijk was, en ik zei toen dat het niet direct mogelijk is om van een receptregel met 50 delen component A met verlies 5% dit om te zetten naar 6%
Want als er de nodige tekst aan een regel hangt wordt je niet blij als je alles opnieuw in moet tikken

Ik heb wel een workaround gevonden die meestal werkt (waarom soms niet weet ik trouwens niet)
Maar de oplossing is simpel:
Als eerste zet je de verleisfactor terug naar 0%
Het systeem berekent dan de originele input.
UIt het recept gaan en er weer opnieuw in (waarom weet ik niet maar ik denk dat er af en toe een variabele niet geheel gecleared wordt)
En dan het nieuwe verliespercentage ingeven.

Dat voorkomt het tikwerk op de receptregel.


mvg

MK