Ik wilde in het kader van de controle van de koppelingen verpakkingenbelasting de DKK tarieven printen middels LOPRDF (8.9.2.5)

Echter ik kwam er na het printen achter dat de prijsfactor staffels heierin niet meegenomen worden.

Iemand enig beter idee?

mvg


Marco

Wij willen wat strakker gaan werken met kredietlimieten.
Dat betekent in ons geval dat wij dan moeten gaan werken met orders welke geblokkeerd worden op basis van de financiele info.
Ik weet dat dit werkt, we hebben het nu n.l. als melding aan staan.

Echter ik heb een probleem met enkele grote klanten, welke soms voor een heel jaar orders insturen. Die vliegen dan over hun kredietlimiet.
Om daar nu elke order weer te laten deblokkeren door een "controller" is ook niet echt slim.

Mijn vraag is de volgende:
Zou het mogelijk zijn om een run te verzinnen welke de openstaande orders met blok status uitfilterd, deze op leverdatum sorteerd naar klant en dan de orders tot het bedrag van de kredietlimieten weer vrijgeeft?

Dat betekent dat de verkoopbinnendienst n.l. binnen hun bevoegdheid die order toch kan laten uitleveren.

Voorstel is selectie:
klant van/tot
leverdatum van/tot

Dit om de te voorkomen dat het een hele zware run wordt om te draaien

Hoe denken jullie hierover?

mvg

Marco

Dat is trouwens een vreemde functie, in sommige layouts moest ik er bv 2 plaatsen om 1 lege regel op papier te krijgen, dus geef het niet op als het de eerste keer niet direct werkt.

mvg

Marco

Wij pakken dit pragmatisch op:

Productie boekt grondstoffen af
Daarna keuring e.d.
Opboeken wordt niet afgesloten

Indien materiaal is vrigegeven voor tappen, dan eerst afvullen, als gereed is opbrengst bekend
Dan afboeken gronstoffen afsluiten tegen werkelijke opbrengst

Daarna afgetapte materialen in magazijn opboeken

Zo houdt je de prijs  "correct", immers wat je insteekt en uithaalt zijn dan ver bekend.

Met dank voor het mailtje.
We gaan het testen

we hebben hiermee meerdere problemen gehad

1* was het door een defecte index op LODF
Ook bleek het fout te gaan bij splisting als afleveradres aangepast werd, dit is nu als het goed is niet meer mogelijk bij een DKK welke met zo'n dummy kostenregel werkt.

Wat nu deze maal de reden is weet ik niet.

Ik krijg ondanks jullie aanpassingen nog steeds orders, waarbij de DKK met gekoppelde dummy artikel zoals deze gebruikt wordt in de door jullie voorgestelde DKK inrichting voor de dekking verpakkingenbelasting, waar deze DKK niet meegekopieerd wordt bij het splitsen van de verkooporderregel.

zie orders:
   - 20080331026
   - 20080506016
   - 20080604002

Deze 3 orders samen zijn al goed voor een bedrag van € 500.00 aan verpakkigenbelasting welke op deze wijze dan dus uit mijn zak moet komen ipv gefinancierd te worden door de klant.

(Iemand van jullie nog interesse om wat bij te dragen aan het "steunfonds")

mvg

Marco

 

Ok bedankt ik denk dat ik de implicaties nu wel in kan schatten

Dat weet ik, maar dat evrschil loopt in korte tijd weg.
Mijn vraag is echter of dat ergens anders nog problemen kan geven (ik heb niets meer "retour te ontvangen"

mvg

MK

Ik wil het artikel EMB975ai2, welke gelijk loopt met de verschijning 975ai2, omzetten naar een "normale inclusief" verpakking.
Dat wil zeggen dat ik het vinkje "hergebruik bij inhoud 0" uit wil zetten.

Behalve dat ik de kaart "emballage in gebruik" leeg moet boeken, is er verder nog iets waar ik rekening mee moet houden?

mvg

Marco

ik krijg nog steeds verpakkingsaantallen met 3 cijfers achter de komma, zie mail

Volgens de operator: "gewoon opgeboekt op order 200806030038"

Probleem treedt op bij afboeken 1 IBCvanaf E7074 artikel STOR100030

bij 2 users op verschillende machines hetzelfde probleem.
op deze locatie staan nu 2 IBC's,moet er 1 zijn

zal het met onze financiele mensen kortsluiten en dan terug komen

Het verhaal is dat ik die zaken n.l. ook moet verantwoorden op de BTW aangifte (het zijn daar ook aparte posten)  dus lijkt het me dat die zaken ook herkenbaar moeten zijn in het printje dat jullie aanbieden

kijk er eens naar en kom erover terug aub