Peter,

Ik ga nogmaals kijken of wij het gebruik van het veld "eerst mogelijke verzenddatum" consistent kunnen doorvoeren t.b.v. originele vraagdatum klant. Om het misbruik van het veld "leverdatum" op te kunnen heffen wacht ik op het alternatieve voorstel voor een nieuw coderingsveld op debiteur / VO niveau. In principe zou ik er dan ook uit moeten zijn.


Groet,


Andries.

Beste specialisten.

Ik heb behoefte aan een datumveld op VO niveau waarin ik de originele vraagdatum van de klant kan invullen.
Dit wil ik graag om te kunnen bepalen of wij "on time" leveren. De KPI ronde voor 2010 komt er weer aan, vandaar dat de wens weer eens sterker wordt.
In het topic http://ha1.heartprofit.nl/profit/index.php?topic=20705.msg29741#msg29741 heeft Menno al een de suggestie gedaan om daar het veld "Datum in huis" voor te gebruiken. Voor mij prima, maar daar komt een foutmelding als deze datum vóór de datum verzenden ligt. Daarnaast wordt de datum in huis wordt ook weer aangepast als we de leverdatum aanpassen. Maar wellicht dat daar iets los te koppelen is via een bedrijfsparameter.

Groet,

Andries.

Robert,

Dank voor je toelichting. Dan zal ik de optie gebruiken om een offerte te kopiëren, het afleveradres te wijzigen in de juiste, en dan de oude offerte te verwijderen.

Groet,

Andries.

Beste,

Als ik het afleveradres van een offerte wil wijzigen kan ik daar niet bij. Het veld is grijs. Voor zover ik kan zien is er geen DYNSCREEN ingevuld. Het betreft de functie LOOFWY, veld AFLVRNR.
Ik heb de discussie m.b.t. afleveradressen en gekoppelde DKK's bij VO's gelezen, maar ga er vanuit dat dit bij een offerte niet zo werkt.
Kortom, ik zou graag op offerte niveau bij "openstaande offertes" het afleveradres willen kunnen wijzigen.

Groet,

Andries.

 

Thanx!

Andries.

Heren,

Ik kom het volgende probleem tegen:
Bij het toevoegen van een factuur met een kosten regel zonder dat ik deze koppel / refereer aan een andere factuur van dezelfde klant, komt er geen ICL levering op de factuur, terwijl dit wél zou moeten.
Ik doe als volgt: 3-3-1-F4. Vul daar het Klient ID in. In dit geval een Franse klant met een Frans afleveradres. Ik vul geen factuur referentie in. Vervolgens met F1-F4. (LOFRKRTV) Daar vul ik het bedrag in met de omschrijving en het grootboeknummer. Bevestigen met F1.
Bij het printen van deze factuur komt er geen "ICL levering" op de factuur te staan, terwijl je dat wel verwacht. Wat doen we daar dan fout?

Groet,

Andries.

Hoi,

Ziet er erg goed uit. Qua prijs en interne verkoopbaarheid momenteel te duur. We gaan verder nadenken over bredere toepassingen. Dat zal echter nog wel even duren. Dank tot nu toe.

Groet,

Andries.

Peter,

Jouw remedie maar overgenomen. We blijven dit volgen. De debiteuren waren inderdaad echt allemaal op JA gezet. Check na conversie heb ik zelf ook uitgevoerd.
Degene die op Nee stonden, waren nieuw toegevoegde debiteuren, waarvan er een DE debiteur is

Groet,


Andries.

Heren,

Ik kom het volgende probleem tegen:

We hebben enige tijd terug alle debiteuren op BTW berekenen JA laten zetten. Om toekomstige fouten hiermee te voorkomen heb ik via dynscreen dit veld default op J gezet bij LORDOP en LORDWY en het ook gedisabled voor de gebruikers.
Nu heb ik tóch een factuur fout , waardoor ik er achter kom dat als ik in het scherm kijk met LORDRA "zie" ik het veld aangevinkt, maar met de F1 "kijk functie" LORDRAWX, staat het BTW bereken veld tóch uit.
Ook de functie LORDZBRA geeft de terechte foutmelding dat BTW berekenen niet aan staat.
Zo zijn er inmiddels toch al weer 5 debiteuren waarbij BTW berekenen uit staat opgenomen.
Hoe kan ik dat echt voorkomen?

Groet,

Andries.

Peter,

Dank voor je antwoord. Heb je ook een richting qua prijs waar ik aan moet denken voor de module workflow?
En om het ook goed intern te kunnen "verkopen", wie werkt er al mee zodat ik de overige opties een beetje kan inschatten?

Groet,

Andries.

Beste specialisten,

Ons Bedrijfsbureau gebruikt de functie LOUVRA om te kijken of er nog ongeprinte verkooporders aanwezig zijn, waarvan er een wijziging heeft plaatsgevonden die voor hen relevant is.
Dat doen ze nu door regelmatig even in het menu LOUVRA (via 3-1-9-3) te kijken. Een user button om dit te versnellen werkt niet. Door alle hectiek schiet dat er momenteel even regelmatig ook bij in waardoor er fouten kunnen ontstaan.
Mijn vraag is of er ook een melding via bijv. Outlook, of bijvoorbeeld een standaard printje uit een printer kan komen wanneer er weer een nieuwe verkooporder is toegevoegd die printstatus "O" heeft. De bedoeling daarvan is dat ze actief geínformeerd worden wanneer er handelen verwacht wordt, in plaats van dat ze zo eens af en toe moeten kijken.

Verder zie ik dat de database (LOUV.DBF) die daar voor gebruikt wordt nogal wat vervuiling bevat. Voor zover ik ingelicht ben, vervallen de VO's hieruit als ze gefactureerd zijn. Onze database bevat nog een aantal orders die reeds lang gefactureerd zijn.....
Hoe kunnen we dat (laten) opschonen?

Uiteraard voor verdere uitleg beschikbaar 

Andries.

Peter,

Ik ga een poging doen om te omschrijven wat ik wil bereiken.
Deel 1:
Er is een klant. Die krijgt zijn gevraagde goederen. Om zoiets te berekenen als marge geven we de VO via een DKK ( ik ontkom er toch niet aan om het te benoemen...) een voorcalculatie vrachtkosten mee.
Deel 2:
Er is een transporteur. Die vervoert de goederen voor onze klant. Hij stuurt daarvoor een factuur. Die factuur boeken we in bij de financiele administratie zodat we die ook kunnen registreren en betalen. Hij wil immers zijn geld krijgen voor de geleverde diensten.

Nu komt de link naar deel 1. Die transport factuur gaan we ook koppelen aan de betreffende VO om te bepalen of we vooraf de juiste marge berekend hebben. Nu hebben we immers de echte kosten. En die gaan we koppelen aan de juiste DKK voor die VO (= nacalculatie). Dan kunnen we de echte marge voor die VO bepalen.
Die koppeling van de transport factuur verzorgt de transportplanningsafdeling. Vervolgens gaat daarna de afdeling finance de ingevoerde bedragen weer controleren op juistheid.

Die transport factuur hebben we dus 3x in handen. Met name het koppelen en de controle op juistheid van de gegevens vind ik een omslachtige manier van werken.

En nu komt mijn wens: Van dat "3x in handen", daar wil ik vanaf.
En mijn idee was om de transportfactuur in te boeken en vervolgens direct te koppelen, waardoor een extra controle ook niet meer nodig is.
Uiteraard sta ik open voor andere ideeën die dezelfde proces verbetering kunnen bewerkstelligen.

Groet,

Andries.

Beste,

Bij gebrek aan reactie zal ik proberen mijn vraag concreter te maken:
Kunnen we een aanbieding krijgen voor een pop-up scherm dat verschijnt na het invoeren van een factuur? Dit om de betreffende factuur direct aan een bestaande DKK van een VO of IO te kunnen koppelen.

Het pop-up scherm zou mijns inziens moeten bevatten:
- keuze het type order: inkoop of verkoop (of ook nog productie ??)
- invoerveld voor het VO of IO nummer
- invoerveld voor de gewenste DKK
- invoerveld omschrijving
- default het volledige factuurbedrag wat overschrijfbaar zou moeten zijn voor degene die niet het hele bedrag aan de DKK van één VO of IO willen koppelen.

Daarbij zou het ook handig zijn om ook het voorcalculatorische DKK bedrag zichtbaar te hebben, zodat de mogelijkheid er is om bij het koppelen van de laatste factuur voor die DKK, de DKK ook af te kunnen sluiten.

Als niet het hele factuurbedrag gekoppeld wordt, de optie voor een nieuw scherm om de rest te koppelen of om door te gaan met de volgende factuur in te boeken.

Met een bedrijfsparameter zou dit de huidige optie LOFZTV dan vervangen.


Groet,


Andries.

Menno,

Wat zou het kosten om een extra keuze te maken die inkooporders in leverweek rapporteerd? Wat mij betreft zou het dan heel mooi zijn voor die leverweek, de openstaande inkopen, met de geplande leverweek te berekenen, en de reeds geleverde orders op met de ontvangstweek.

Kunnen jullie daar wat mee, of zijn er andere opties zoals bijv. in het rapport zelf een extra kolom toe te voegen zodat naast de leverdatum ook een leverweek staat?


Groet,

Andries.

Menno,

Mail is onderweg. Aangegeven de 2 varianten. 1e variant op weeknummer, 2e variant op leverdatum selectie voor diezelfde weeknummers.

Groet,

Andries.