Nee joh ! Het gaat niet om geheimen of zo. Typen werkt hier even niet. Geen email dus.

Geef maar een voorbeeld (funktienaam zoals LOPOGM, maar mag ook AD funktie zijn) waar je die 25000 gehanteerd wilt zien.

Ja, duidelijk, en op zich best handig. Maar dàt werkt in de meeste gevallen al niet. Probeer maar ...
Probeer vooral ook even meerdere fakturen voor eenzelfde bedrag te vinden, en zie hoeveel je eruit krijgt.
Maar zie óók, dat *als* je eenmaal dat overzichtje met meerderen hebt, je vervolgens gewoon kan boeken (ook hier, probeer maar).

Ik geef toe : een beetje een raar verhaal hoor. Maar deze funktie is ooit van onze eigen administratie meegekomen (als een soort toegift, want "ze was er toch"), en dat had dus niet moeten gebeuren (want feitelijk niet compatible).

Goed. Wat mij betreft heb je dit nog nooit gebruikt, en probeer je nu te achterhalen of het wat voor je kan betekenen. Je snapt wel wat de bedoeling is, en wij snappen wel dat het wat beter werkt met een (op te geven) marge (centen afwijking). Moeilijk kan die funktie niet zijn, de huidige aanpassen is geen doen (gaat ook niet gebeuren). Is dit een idioot voorstel  ? :

Ik denk dat we voor een 14 uur wel iets kunnen maken wat doet wat de huidige funktie ooit beoogde, maar dan zo goed en beter als JIJ kan bedenken (ik wil nog wel meehelpen). Je krijgt wel 50% korting a.g.v. het akefietje met de huidige funktie.
Bedenk maar veel meer om je Ideal klanten / betalingen te kunnen vinden/matchen. Maakt mij niet uit.
Wel moet je voor die 14 uur bedenken dat waar we in zoeken de openstaande fakturen betreft, wat op zich kan worden uitgebreid met weet-ik-veel (alles wat jij nuttig vindt). Alleen dàt wordt dan meerwerk wat we kunnen bespreken.
Merk op dat je de funktie moet zien als "iets vinden", en dat het kunnen boeken van een Betaling eigenlijk bijzaak wordt (maar er uiteraard ook gewoon in zit). Dus denk bijv. ook in het zoeken in Afgesloten Fakturen; ik zeg maar wat.

Is dat wat ??

Vaak biej te bange ?

Nee, klinkt toch niet goed. Opnieuw :

Daar was ik al bang voor.
Maar ik bedoel, waar zie jij dan die 25000 nog gebruikt/toegepast worden ? (ik weet dus gewoon iets niet)

Zal wel een TV/WY/VW/RA extra worden dan. Da's die 22 uur, weet je nog ? Maar vaak biej te bange.

Haha.


Ik hoor het jullie zuiperts zo zeggen inderdaad. Ik heb alleen nooit zo doorgehad dat je de hele dag door zuipt !
(maar het zou wel het e.e.a. verklaren)
 

Niets daarvan. Je moet aangeven per Receptuur wat de doorlooptijd van de Produktie is.

Dit maar even gequote als bruggetje naar iets wat ik toch al wilde zeggen :

Het mag raar/zeldzaam/onverwachts klinken, maar waar wij nu al vanaf vorige week merken dat jij behoefte hebt aan een telefoontje met uitleg over bepaalde zaken, en waar we nu eens *niet* via het forum willen werken (onverwachts dus), is het aantal keren dat wij hebben gebeld en jij zal terugbellen intussen niet meer te tellen. En maar blijven voortborduren op een basis die je even niet hebt ...

Niet handig.
Intussen ben je er vandaag ook weer niet, dus je zal je stem wel kwijt zijn of zo.
Maar nog steeds niet handig.

Mwah, wel aardig, maar niet helemaal terecht denk ik;
Wij hebben tot nu toe (demo's) steeds Plankritische Bewerkingen erin geblazen, omdat natuurlijk niet iedereen die heeft (moet je wel een reden voor hebben, en dat begint bij de Produktieplanning module - die jullie al helemaal niet hadden).
Kortom, daar haden *wij* niet aangedacht ...


Je hebt het "inblazen" niet alleen gekregen omdat wij er niet aan gedacht hadden dat je anders weinig kunt, maar vooral omdat je nu natuurlijk geen bal kunt. Niet kunt zien ook, en dus ook niet kan beoordelen. Dat, terwijl je toch zo je best doet ...

Dit gezegd hebbende, het inblazen volgens een door jou op te geven vaste tijd (per PO) is tijdelijk. Het geeft je dus slechts te gelegeneid om te spelen/kijken, en iedere Receptuur waarin je e.e.a. wel nauwkeurig/reëel hebt gedefinieerd, wordt wat dit betreft ook gerespekteert.
De waarde wordt dus niet en nooit overgenomen uit het Artikel.
(hou daar nou mee op !)

O jee o jee o jee

Robert, ik weet niet of het verstandig was om dat te posten. Ik heb het in elk geval niet gedaan, wetend wat de reaktie zou worden ...
Toch ?

Zie ook mijn "ik heb het gevoel dat ik teveel moet uitleggen", want in zachte bewoording vertelt dat Marco vast veel weet, maar hier toch even wat kennis onbeert (op het logische vlak). Deze tekst had ik graag willen vermijden (jaja, zelfs ik ), maar nu is het niet anders. Op zich intussen "onze" schuld.


En dat gevoel is juist, maar wordt veroorzaakt door het niet kunnen meedelen in wat wij hier allemaal weten. Niet jouw schuld uiteraard, maar wel een gegeven. Waar we nu voor moeten oppassen is dat we hier niet gaan lopen discussiëren over hoe e.e.a. moet, want dat weten wij echt wel (zolang het maar geen chemische rotzooi wordt ).

Samengevat voor nu, wat Robert jou probeert duidelijk te maken is dat je de oorzaak aan de verkeerde kant zoekt, omdat je eerst in Profit zal moeten zijn. Het lijkt alsof Robert dat tegen mij zegt, en komt daarmee wat ongelukkig over naar jou (iets van "help, we weten het niet !"). Maar Robert is meer diplomatiek dan ik, en had willen zeggen "Marco snapt het niet !".
... dat hebben we hier gisteren namelijk al uitgebreid doorgesproken ...

Maar het komt heus goed hoor, de planning kan het wel. Nu de logica in Profit nog. Zoals gezegd :
Even uitzoeken ...

Daar was ik al bang voor.

Dank je.

Vraagje omdat ik geen zin heb om het uit te zoeken : Waar definieer je die Ontvangstnaam ?
(jij weet het uit je hoofd)

Bedoel je nu per Interface ?
Dus, bedrag anders voor Gereedmelden Produktieorders vs. Fakturering etc. etc. ?

(anders kan ik niet bedenken wat je bedoelt)

Deze nog even :


We hebben intussen een voorziening gemaakt die Plan Kritische Bewerkingen voor je genereert in de Planning (waar ze ontbreken in de Recepturen). Dan kan je ook nog eens iets zien ...

(moet nog worden overgestuurd hoor -> zal wel morgen worden)

Aangaande het eerste : nee, natuurlijk niet. Als dat zo was hadden we dat wel gehanteerd.
Het is ook niet waar dat het veld waar jij op doelt ook maar enigszins iets met de Produktieplanning zou kunnen doen (ik krijg het gevoel dat ik teveel moet uitleggen ?).

V.w.b. de Waarschuwing : Ik weet op dit moment even niet hoe dit is geregeld, maar dat heef denk ik niet veel met waarschuwingen als zodanig te maken (daar zou je niet goed van worden, al is het maar omdat je 100 orders tegelijk over de deadline heen kan duwen).
Dus, dat er zoiets in zal moeten zitten is duidelijk (maar denk meer aan kleuren), en dat dit in de basis ook zo is, is *mij* duidelijk. Alleen vraag ik me op dit moment af hoe e.e.a. is geregeld richting de Levering, waar je het hier immers over Produktieorders hebt die daar niets van weten.
Even uitoeken ...

Het volgende ligt nu voor :

Het probleem met de "zie specifikatie" zou moeten kunnen worden opgelost door in het resulterende overzicht (gegenereerde Afschriften) te kunnen wijzigen, om de run vervolgens opnieuw te draaien die dan de aangebrachte wijzigingen meeneemt als zouden ze (de faktuurnummers) er vanaf het begin zo hebben ingestaan.

Het probleem met de onjuiste Debiteur kan worden opgelost door na het zien van het resulterende overzicht de Ontvangstnaam aan te passen naar de juiste, om vervolgens de run opnieuw te draaien.
N.b.: Dit gaat fout als er betalingen tussenzitten van twee B.V.'s die eigenlijk dezelfde Debiteur betreffen.
Dit kan op zich worden opgelost door het resulterende overzicht te daadwerkelijk te verwerken (Afschriften worden gejournaliseerd), met daarbij het idee dat als de Afschriften nogmaals worden gegenereerd, de reeds verwerkte Afschriften niet nogmaals in het overzicht zullen voorkomen.
In dit geval betekent het dus : Genereren - Verwerken - Ontvangstnaam aanpassen - Genereren - Verwerken (- enz.).

Let op : Bij bovenstaande hoort m.i. een nieuw veld bij de Faktuur, wat iets mag heten als "Betalende instantie". Waar dit verder moet worden gebruikt (rapportages) is op dit moment (nog) niet van belang, mits maar formeel kan worden aangetoond hoe de aansluitingen lopen. Dit moet worden gezien als : Als Jan de Debiteur is, maar Piet heef betaald, dan valt niet te bewijzen dan Jan NIET heeft betaald (hoeveel Afschriften wil je de inspecteur geven ?), en het bewijs dat Piet heeft betaald (een feitelijke onbekende) zegt niets, behalve dat het wel zwart zal zijn. Je moet dus bewijzen dat Piet behoorde te betalen, en dat loopt via dit veld (ook al andersom aangebracht -> betaling zorgt voor vullen veld). Vervolgens krijg je het verhaal dus andersom, en de inspecteur zal voor iedere op deze wijze andere betaler kunnen zien dat dit altijd klopt (denk met name aan veel van deze situaties), terwijl de afschriften op zich toch ook wel aansluiten. Ja, ik zou er nog wel mee weten te frauderen, maar zonder zo'n veld wordt dat stellig gedacht terwijl ik het niet doe en ook niets heb om het mee te bewijzen (het afschrift van Jan bestaat domweg niet en dat klopt ook - maar vinden kan je zoiets niet).

Een eventueel probleem met een nog niet bestaande Debiteur wordt opgelost door deze Debiteur in te brengen, en de run nogmaals te draaien.

E.e.a. verder uit te werken.