Buiten deze discussie: Outlook express is ook al passé voor wat betreft MS. moet je gaan kijken naar Windows Live mail...
en als je dat doet waarom ook niet Thunderbird of misschien zelfs nog wel Evolution?


Ik zou zelf toch opteren voor de keuze om de bestanden als concept klaar te kunnen zetten in MS Outlook.

Immers als je eerst aan uw eigen mailbox mailt mis je ook weer de layout en adressering vanuit heart.

Laten we wel eerlijk zijn: Heart is niet gemaakt voor alle systemen en platformen, immers we doen ook exporteren naar excel en daar ondersteun je ook geen Works of Open Office ....

(ook al zou ik dat technisch wel een uitdaging vinden)

mk

Probleem zit in het feit dat kostprijs aan de inkoopzijde nu binnen jouw systeem 2 definities lijkt te hebben:

1e = is de kale regelprijs van de inkooporder
2e = de waarde waartegen het werkelijk ontvangen wordt in de voorraad (incl. DKK's e.d.)

Wat ons betreft is de 2e de echte kostprijs (gekoppeld aan financiele mutatie)

Jij registreerd in LOCP echter de 1e als zijnde de kostprijs.

dat is de discussie...

ellende hé,

zo'n klant die gaat nadenken........

Als je bedoeld het scherm LOCPARRA, ja


Dit betreft de waarde waarvoor het product op voorraad gekomen is
Dus incl. de kostprijs verhogende DKK's e.d.

Het lijkt er wat mij betreft op dat de tabel LOCP niet goed gevuld wordt.
2 charges gecontroleerd:
I00702002/1 bij IO 20100702002  regelprijs 0.20 + Dkk = ontvangstwaarde EUR 0.35/kg
I00326016/1 bij IO 20100326016  regelprijs 0.24 + Dkk = ontvangstwaarde EUR 0.39/kg


In LOCP staat echter voor de 2002/1:
13680 kg ontvangen
Hfl 6029.35056

dus dat is Hfl 0.44/kg hetgeen ongeveer EUR 0.20/kg is

Er wordt wat mij betreft een formeel foute aanname gedaan:
Immers een kostprijsverhogende DKK is kostprijsverhogend omdat daar een legitieme grondslag is.

Bv tranportkosten/verpakkingskosten/orderkosten e.d.
Deze waarde wil je laten doorrekenen in de voorraad aangezien het hier de verwervingswaarde betreft.
Dus dan geldt ok dat de waarde verhoogd moet zijn.

vandaar de door ons geconstateerde afwijking.

mvg

MK

eerst even en "domme" vraag:
waar vindt ik de chargeprijs in het systeem.

Nu kwam ik er n.l. achter via die af en bij actie......

Je zegt wel dat de overwegingen meer voor Wouter dan voor mij zijn.

Maar toch:
De prijsverhoging komt uit een kostprijsverhogende DKK op de inkooporder regel en is dus formeel niet "gefreubelt". Maar dit is een legitieme implementatie binnen het pakket.
Wat mij betreft is dit dan ook "de waarde" van de desbetreffende charge.

Het systeem echter gaat terug naar de "bestellingswaarde" ipv de "werkelijke waarde" en dat is volgens mij gewoon fout. Zoals je zelf n.l. aangeeft is de DKK een integraal onderdeel van de kostprijs.

Dat ik eventueel een verlies kan omvormen naar verlies = accoord, maar hoe ga ik er dan mee om als ik een keer wat over houdt, en dus moet "omvormen naar winst"?

Voorbeeld 2 regels in LOVM:
17/07/2010 om 7:18.33 en 7:18.56

Wat is hier gebeurt:
We hebben een voorraadverschil geconstateerd. Mijn medewerker boekt de restdrum af (met waarde EUR 0.71/kg) en boekt daarna in dezelfde run met dezelfde gegevens een kleinere hoeveelheid bij. Deze krijgt echter de prijs EUR 0.34 /kg

Nu is het zo dat eur 0.34 de inkoopprijs was welke in de order stond, echter het materiaal is duurder ingeboekt en ook bevatte deze een DKK van eur 0.15.
Beide gegevens zijn nu verdwenen, ondanks dat het materiaal op "werkelijke prijs" staat en niet op een "vaste prijs".

Kunnen jullie hier eens naar kijken, dit gaat dus niet goed.

Zou het mogelijk zijn om in de toekomst dit te realiseren.
Nu zien wij soms dat een order aangepast is maar niet meer sluit met de versie in de map met printjes.

In de huidige systematiek is dit niet te herleiden.

denk hier eens over na....


mvg

mk

Dit is op zich interessant.
Wordt dat dan en parameter die op alle mailverkeer in gaat grijpen of alleen bij facturatie?

het controleren en valideren van de facturen voor verzending is n.l. ook iets waar wij al mee bezig waren.

mk

Ik vond de post van johan pas toen jij erover begon en ik zocht op trefwoord kostprijs.

dus aub ja: zoek de verschillen en overeenkomsten
misschien kunnen we daar dan wat mee?

mk

Ik heb gezocht, maar je hebt gelijk: als ik Johan zou heten

Maar essentie van de vraag is hetzelfde: ik kan niet uit de voeten met een kostprijsbepaling op verschijningsniveau.
Zoek dit op receptniveau zoals aangegeven.

....

nee hoor, of ik moet malende zijn.....

Wij hebben een probleem:
Je kunt op diverse manieren tot een product komen.
Dat ondervangen wij door meerdere recepturen in het systeem te zetten.

Nu kan ik bij kostprijsberekening alleen kiezen voor een bepaalde verschijningsvorm, danwel voor alfabetisch de eerste als zijnde kostprijsbepalend.

Is het mogelijk om een vinkje op receptniveau te krijgen mbt kostprijsbepalend voor de massale herberekening en dat vinkje als selectiekriterium toe te voegen aan bovengenoemde functie?

Het vinkje bij het recept moet dan wel "uniek" zijn voor dat artikel (net zoals "DE KONTAKTPERSOON" bij een relatie)  is dit mogelijk en wat zijn hiervan de kosten?

mvg

MK

ok laat maar horen