Oops. Ik zag iets anders voor me bij LONX, welke tabel het inderdaad niet hoeft te doen. Excuses (maar je had natuurlijk ook meteen die andere moeten noemen).

Maar goed, dan is het antwoord bijna nog simpeler : als bestanden als deze het niet doen, zijn ze in gebruik. Ofwel door iemand die er in zit (ik weet even niet of je dat zelf kunt zijn -> moet je wel iets hebben gedaan kwa "werken" in Profit), dan wel door iets als een backup of zo ...

Er komt meen ik ook een logbestand uit ... staat daar niet nog veel meer op dan ?

En houd s.v.p. in gedachten dat er sowieso iets niet lijkt te kloppen bij jullie (in deze).

Zou je intussen wat willen doen ? iedereen vrijgeven, en betreffende bestanden even met de hand doen. Als het dan nog niet wil is er iets heel anders aan de hand. Laat dan iedereen eruit, en bel z.s.m. Robert even.. N.b.: Dit (bellen) heeft alleen nut als iedereen er uit is, ok ?

Krijg je denk ik altijd wel. Mag ook, en geeft niets.

Ja, dat had ik intussen ook al bedacht. Dat werkt, zeg maar, vriendelijk.
Maar ja, je moet zo'n "fout" toch kunnen herstellen ? Dus, PO is geprint, en dan denk je "oops, er moest nog wat bij". En dan ?

Buiten dat, moet Johan dus (als dit zo blijft) die "bijstellingen" doen voordat de PO is geprint.
Johan, kunnen jullie dat ?
Je kunt ook zeggen : zo niet, hoe kan het dan bestaan dat de operator -die aan de band staat zeg maar- dit wel weet ?

Wie weet hier de logika van ?

Intergamma layouts worden ook gebruikt door minimaal één klant wat ik weet. Of die voor jou, Johan, bruikbaar zijn is wat anders.

Ik denk echter dat je je (heel wat) meer moet verdiepen in EDI in het algemeen. En, een layout kun je dan wel zo voor elkaar hebben, maar voordat je overeenstemming met de andere partij(en) hebt, ben je zo maanden verder. Dit doe je niet tussendoor hoor !
Overigens moeten wij de ingaande kant(en) maken. Dat kun je dus niet zelf. Als de gewenste layout nog niet bestaat, i.h.a. tussen de 4 en 8 uur voor een ingaand bericht.


Hahaha, pas dan maar op dat je hier niet in terecht komt : http://fox.wikis.com/wc.dll?Wiki~EDI~SoftwareEng

Marco, bel s.v.p. Yvonne hier even over;
Ik denk niet dat jouw rechttoe rechtaan notatie wordt begrepen. Praten gaat denk ik (en hoop ik) makkelijker.

Voordat je belt, zorg s.v.p. dat je zelf de inhoud van de Excel die ik je gisteren heb voorgrschoteld doorgrondt, zodat Yvonne in dat soort termen met jou kan kommuniceren. Althans, ik vermoed dat het een afgeleide kan worden van die "print" (Resultaatlijst).

Ik heb zelf niet zo veel sjoege van spacecakes (ga meer over de paddo's), maar je (we) moet je misschien afvragen wat er voor zorgt dat een Keuring "afgesloten" raakt. Dit dan in kombinatie met het "bijstellen" wat je technisch gezien - en formeel doet.

Dus, kennelijk doe je eerst een Keuring, sluit die op de e.o.a. manier af, en gooit er dan VOLGENS HET SYSTEEM nog iets bij. Let op dan, want het heeft te maken met de chronologische volgorde van zaken. Dus wat gebeurt er feitelijk ? je doet een Keuring, gooit er vervolgens iets bij, waarna het systeem heus wel denkt dat je er iets bij gooit a.g.v. de eerdere Keuring. Goed heh ? en vooral ook zo logisch ...

Anders gezegd : je mag er wel iets bij gooien (mardy grass expirmentje enz.), of gewoon, omdat het nog niet in de Receptuur staat, als je het maar wel doet voor de (eerste) Keuring(en).
Alles bij elkaar heb je goede kans dat het fout gaat omdat je domweg (en toevallig) de Keuringen eerder inbrengt dan de extra grondstof (n.b.: die pas formeel Bijstelling heet nadat 'ie in een volgende Doorgang terecht is gekomen !).

Misschien heb je hier iets aan ?

Wat is het verschil met de Planningshorizon ?

Printen naar een PDF doe je middels een speciale Queue, en dat staat helemaal los van alles. Het is in feite gewoon een printer.
Eén ding natuurlijk : de output is een bestand.

Nadat het bestand gemaakt is, ware het Excel, PDF of nog steeds prfile.prn, wil je het mailen.
Mailen doe je van "een" bestand, en welk bestand dat is maakt niet uit (hooguit zal het systeem moeten weten dat het om een specifieke output gaat van een batchopdracht die moet worden gemailed, en dat zit wel in die 20 uur).


Over LOVCBV2 :
Met een 1,5 uur is dat geregeld.
Als het nog niet duidelijk was : ieder printje kan standaard via de Batch worden verwerkt;
De rest kan allemaal zo worden gemáákt dat het via de Batch kan worden verwerkt, en een deel doet dat ook (al) bij aanvraag van anderen. Zie het lijstje van eerst in een ander topic).

Zojuist hierover telefonisch gesproken;

Is moeilijk oplosbaar (m.n. ook procedureel) en zou eigenlijk vanuit de organisatie anders moeten worden aangevat.

Ik denk dat we voor 20 uur een heel eind zijn met

• Konverteren van prfile.prn naar Excel.
• Het kunnen opnemen van geadresseerde(n).
• Het automatisch emailen.

Misschien impliceer je wel meer "nut" dan je zelf dacht (niet dat ik je onderschat hoor). Immers :
Email is niet alleen een kommunikatie middel, maar ook een trigger (dit laatste doel je in dit geval zelf op). Om dit goed te begrijpen moet je eigenlijk de "email aktiviteiten" rond de Webshop kennen, waarbij je niet alleen zaken zoals Orderbevestiging, Pakbon, Faktuur toegemailed kunt krijgen en wat kwa inhoud nuttig is, maar waarbij je ook (bijvoorbeeld) weet dat als je een email van een pakbon krijgt, de goederen juist de vrachtwagen zijn ingegaan (dit geldt weer als trigger).

Ik zou de emails van Profit-Batch niet laten afhangen van printjes, maar van alles. Dus, stel we draaien de Behoefterun in de Batch, als het ding klaar is kun je er een email van krijgen. Maar, je kunt natuurlijk ook het hele bedrijf een email doen toekomen als bijvoorbeeld het Reorganiseren klaar is. Kwestie van inrichten ...

En omdat jij het wel leuk over buitendienstmedewerkers hebt, die momenteel heus niet BUITEN met een laptop met Profit erop rondlopen, zal ik je het idee aan de hand doen van vervoerders die wel degelijk met Profit rondlopen - buiten dus - en die bij de klant aan de deur (bijvoorbeeld) Emballage mee terugnemen, en dit realtime in Profit boeken. Het effekt ? de klant krijgt onmiddellijk een email met de afgiftebevestiging van de emballage. Overigens heeft de vervoerder éérst gezien hoeveel Emballage er bij de klant uitstaat, opdat het saldo een beetje binnen de perken blijft.


Goed, dit heeft maar weinig met Profit-Batch te maken, maar wat ik in mijn zo ongeveer eerste post aangaf, is dat wat jij wilt eveneens niets met Profit-Batch te maken heeft. Althans, niet als het slim in elkaar wordt gedraaid, en jij van het printje wat je (regelmatig) maakt domweg kunt opgeven naar wie het (en in welk formaat) moet worden ge-emailed.

Snappu ?
Geef nu maar snel die 20 uur uit.

Ok, duidelijk.



Als je maar weet dat je je ook kunt laten verwittigen als een Batchjob klaar is. Ook goed voor de konditie als er iedere 5 minuten een printje klaarligt.

E.e.a. heeft niets met lokale printers versus centrale printers te maken, vooral ook als je weet dat je die lokatie printers net zoals voorheen kunt blijven aansturen.
Overigens, een lokale printer die alleen vanaf de betreffende PC benaderbaar is, is uiteraard altijd "fout". Dus, maak daar een netwerk (shared) printer van, en je hebt geen verschil met voorheen (ja, dat je iedere 5 minuten wakker wordt van een printje dat je niet zojuist "zelf" hebt opgestart).

Niet dus. Een Batchprocessor is immers een PC elders in het netwerk. Die heeft wel een Troep directory, maar dat is niet echt die "van jou".

Johan,

Voordat we onnodige dingen gaan doen ... (terwijl wat je wilt best handig kan zijn, maar dan voor funktionaliteit op zich c.q. heeft niets met het "probleem" te maken) hoezo sabotage ?
Kun je uitleggen wat je denkt dat anders is t.o.v. normaal printen ?

Tip : wat mij betreft niets.

Ehh Pascal, ik geloof niet dat je begrijpt hoe het in elkaar zit.