Basis is duidelijk, maar er zijn toch wat tegenstrijdigheden.
Is het mogelijk een query in te bouwen die (het liefst elke dag automatisch) de volgende gegevens exporteert?
Het maken van de Exportfunktie is 1.
Het automatisch (herhalend) uitvoeren van zo'n funktie is 2.
#2 is op zich heel mooi mogelijk met bijv. een module Profit-Batch, waarmee je een 'taak' door een andere PC (een Batchprocessor) kunt laten uitvoeren, en de taak bijv. 1 dag later automatisch opnieuw kan laten uitvoeren (nog iets mooier: op basis van kalenders met bijv. werkbare dagen, want als er in het weekend niet gewerkt wordt, hoeft er geen export gegenereerd te worden). Die module hebben jullie echter niet.
Dit zou dan net zo opgezet kunnen worden als onze export naar Envicon onder 9-8-2.
Hier zie ik een optie 'Continue proces J/N' in staan. Feitelijk ook een methode om een proces te blijven herhalen, nl. door op een PC een taak op te starten, en die taak zichzelf als continue proces uit te laten voeren. Is op zich een methode, maar, realiseer je dat je hiermee een werkstation kwijt bent aan deze taak (een export), en als je nu een tweede export wilt op een vergelijkbare manier als 9-8-2, je dus 2 PC's als continue proces hebt draaien, en je 2 PC's niet meer kunt gebruiken. En dat terwijl ze misschien maar 1x per dag een taak moeten uitvoeren. Zie ook hier: betere methode is dan via de Batchprocessor, die continue op opdrachten van iedereen zit te wachten, en met een andere opdracht verder gaat als de vorige is afgerond, en weet dat als een opdracht is uitgevoerd, die opdracht eenmalig was (bijv. e.o.a. printje) of herhalend moet worden uitgevoerd.
Tsja... natuurlijk kan het ook als 9-8-2 worden opgezet, en waarbij je geen vinkje plaatst bij Continue Proces, maar ja, dan zal er niets 'Automatisch' aan zijn; dan is het dus handmatig. Jij krijgt een export als jij er om vraagt.
Ok, dan de inhoudelijke Query:
De bedoeling is dat dit in verkooporderregels wordt uitgevoerd.
Misschien is het beter dat je aangeeft wat je precies wilt bereiken met je export, en dat wij bepalen in welke tabel.
Om een voorbeeld te geven: een klant bestelt 100 Verschijningen. Maandag lever je er 80, en woensdag volgen er nog eens 20. Vrijdag stuurt de klant er 5 terug omdat hij die overhoudt. De klant krijgt een Faktuur van 95. Maar... het kan ook zo zijn dat je eerst 80 levert en faktureert, 20 levert en faktureert, en 5 retour krijgt en crediteert. In dat geval heb je 3 Fakturen. In alle gevallen heb je echter maar 1 Verkooporderregel.
Verkooporderregels heb je overigens ook al zonder dat ze gefaktureerd zijn. Wat dan te doen als de selektie op basis van de Verkooporderregel moet zijn?
Kortom, moet het niet zo zijn dat je bedoelt dat je Faktuurregels wilt exporteren i.p.v. Verkooporderregels ?
Het lijkt erop dat je je gefaktureerde produkten (aan wie, welke order, welk produkt, hoeveel) wilt exporteren.
DATLMUT is wel een veld uit LOUF (Fakturen), maar dat is niet de Invoice Datum zoals jij die noemt ! Die staat in FDATUM.
Ook geldt dat die DATLMUT niet altijd gevuld is.
Kostenplaats van de relatie
Wat bedoel je daarmee ?
Omzet RGLPRYS
Jullie faktureren alleen maar in euro's ?
Het gaat hierbij dan om data die sinds de vorige export (de dag er voor) is toegevoegd.
Als er ook nog de mogelijkheid zou zijn om handmatig en op een datarange een uitvoer te doen, zou dit helemaal mooi zijn.
Handmatig een range opgeven (Faktuurdatum van - t/m, of Faktuurnummer van - t/m) kan natuurlijk altijd.
Voor 'helemaal automatisch' zouden we moeten bijhouden of de Faktuur al geëxporteerd is (zoiets zouden we met Profit-Uservariabelen kunnen registreren, maar die module hebben jullie ook niet). Eenvoudiger is dan een selektie op Faktuurnummer of Faktuurdatum, maar, daar hoort wel bij dat je bijv. geen Faktuurnummers in verschillende ranges genereert, c.q. dat je geen fakturen antidateert (vandaag een faktuur genereren met als datum gisteren).
Ideaal zou zijn als het kan worden geëxporteerd naar een SQL server. Als Excel- of tekstfile.
Er is van alles mogelijk, maar het een zullen we langer mee bezig zijn als het andere.
Export naar Excel of een Tekstfile is redelijk standaard, maar, in theorie kunnen we ook best wel een connection maken naar een SQL server en daarmee praten.
Regels zouden dan ook 'anders' kunnen worden, nl. in de vorm van 'je moet alles overzetten wat daar nog niet staat'.
Het zou je wel in zoverre schelen dat de Excel of Tekstfile dan niet meer geimporteerd hoeft te worden.
Nadeel is wel dat wij dan mogelijk dingen moeten kunnen doen in die SQL wat iemand anders misschien niet wilt.
