Klantnaam is zichtbaar op de Pakbon !

Ahh ... : http://ha1.heartprofit.nl/profit/index.php?topic=17552.msg19300#msg19300

De reden is dat er bij het Faktureren twee printers tegelijk aan de orde kunnen zijn; 1 voor de Fakturen, en 1 voor Accept Giro's.
Hoe dan ook, daarom kan het niet automatisch, want het systeem zou niet kunnen raden over welke van de twee je het hebt.

Ik geloof niet dat er nog iemand is die van de Accept-Giro's mogelijkheid weet ... misschien slopen we het er wel uit, dan is dit eeuwige probleem eruit. 

Dirk-Jan,

Op zich zou het wel kunnen, maar we willen toch eerst even aanzien hoe het loopt met zo alle perikelen bij elkaar.
Zo blijkt bijvoorbeeld dit board op zich niet gebruikt (zoals je zelf al aangeeft) en wordt de hele indeling al anders.

Punt ook hier is : er zijn mensen die vragen hoe iets moet in het algemeen (op het Support Board), waarbij e.e.a. uitmondt in een print + tip voor de betreffende variabele, waarna het dus weer niet hier staat. En zo loopt alles vanzelf door elkaar en dat werkt het juìst niet.

Wat bedoel je nou met FP1/FP2 ?

Tja, als jij tegenwoordig "formeel" voor jezelf werkt, hoor je er vast wel ook een beetje bij. 

Bij mijn weten wel ja.
En zo toch niet dan kun je 'm weer opnemen. 

Nou, daar kan ik nog eens iets mee. 
Waarom is het de oplossing niet ? werkt het vastzetten niet of zo ?

De enige vraag aan onze kant is eigenlijk : hoe krijg je het voor elkaar om tijdelijk die andere printer te kiezen, c.q. de Faktuur daarheen te dirigeren. Immers :

Bij Printen Fakturen kun je niet te werk gaan zoals gebruikelijk; Je kunt hier alleen maar de printgegevens expliciet opnemen via Systeembeheer - Printen - enz. , en dan voor de funktie LOPRUFF.

N.b.: Op de eerste vraag hoeven we eigenlijk geen antwoord, maar als het zo is dat dit "tijdelijk dirigeren" toch lukt, wordt het wel heel erg verwarrend voor gebruikers ...

Heb je dat al met DynScreen geprobeerd ?
of is dat een domme vraag ?

Ja, die moet zijn ingevuld. Maar ook :
Goederen Ontvangst Palletnummer = Ja (zelfde tabblad, enkele rubrieken verderop).

Vergeet niet dat je hierna de Etiketten opnieuw moet genereren (!) en printen natuurlijk. 

Je doet niets fout Frank. Wel suggereert de melding dat je een produktie charge (e.d.) scant bij Goederen Ontvangst, terwijl je daar natuurlijk een zelf gegenereerde sticker moet gebruiken om te scannen.

Ik wil niet te veel speculeren op wat je precies doet, maar zoals het scannen in die hoek is opgezet, dien je eerst de stickers te hebben, die je vervolgens scant bij het op de partij plakken, en waarbij het systeem weet welke Inkooporder(regel) het behelst. Dit staat namelijk in de barcode.

Klopt dit een beetje met hoe jij denkt dat het werkt ?

Ik vind toch dat het wel kwaad kan, want het wordt een zooitje zo.
Maar ik vind ook dat het nog even zo mag blijven, namelijk totdat we een verbeterde "ingang" hebben tot de funktionaliteiten. En die zou er over een maandje wel moeten zijn.

Ik begrijp niet waarom e.e.a. niet met Verzamelfakturen-alléén zou kunnen werken. Gewoon die run nogmaals opstarten (fout, gaat vanzelf) en in die volgende doorloop komen de Fakturen er wederom "verzameld" uit, maar nu voor de volgende Konditie.

Jij hebt dit gemist, of je bedoelt toch weer iets anders.

Dit afsluiten mag van mij ook hoor.

Hier nog een beetje pratend over dit onderwerp, komen we erachter dat er eigenlijk geen reden meer is om het te benaderen in de volgorde zoals aangehaald;

Tegenwoordig mag gerust het FaktuurLayout-ID zoals genoemd worden gebruikt om de Logistieke Faktuur Layout mee aan te sturen. Dit, terwijl iedereen tot vandaag eigenlijk niet beter weet dan dat je daar de Taalkode voor dient te misbruiken. Zie ook betreffende Helptekst, die bij deze zal worden aangepast.

Als ik jouw laatste post lees, wil ik je dit in elk geval niet onthouden :

Als je met Verzamelfakturering werkt, ontkom je er niet aan op "regelniveau" van de Verzamelfaktuur - die dus meerdere Verkooporders bevat (op welke wijze ook ontstaan) - de Orderreferentie te noemen. Merk op dat waar er meerdere Regels van één Verkooporder worden afgedrukt, je dùs ook net zo veel keren dezelfde Orderreferentie ziet.

Dit heeft niets te maken met een niet-Verzamelfaktuur, waarbij alle zichtbare Regels horen bij die ene Order die je nu faktureert, en waarbij je dùs ook in de Header die ene Orderreferentie kunt noemen, en waarbij het ook nog eens merkwaardig staat om per Regel steeds dezelfde Orderreferentie te noemen.
Feit is dat je *eigenlijk* niet met één Layout uit de voeten kunt, tenzij wij e.e.a. zo aanpassen dat dit formeel wel kan, maar JIJ vervolgens zit met de dynamiek. Immers, je moet bij de Verzamelfaktuur niet alleen in de header de Orderreferentie weglaten, maar óók de tekst "Orderreferentie : ". Hetzelfde voor de niet-Verzamelfaktuur maar dan op Regelniveau.

De laatste alinea suggereert dan dat wij ook die tekst "Orderreferentie :" dynamisch moeten maken (leeglaten wanneer niet aan de orde), maar je altijd nog met de positionering hebt te maken, die afhankelijk van hoe je e.e.a. indeelt onaangetast kan blijven, of juist de hele boel op z'n kop zet. Bijvoorbeeld : Als de Orderreferentie als enige op een aparte regel staat bij de Verzamelfaktuur, krijg je een lege regel als je 'm weglaat omwille/bij de niet-Verzamelfaktuur. In dat geval zou je te maken hebben met een optionele regel ... en het wordt van kwaad tot erger.

Twee Layouts is de oplossing.
Momenteel zou je dat al kunnen doen MITS e.e.a. op Debiteur niveau kan worden bepaald. Dus, als Debiteur-X altijd een Verzamelfaktuur krijgt, en Debiteur-Y juist nooit. Je kunt dan de Taalkode van de Debiteur misbruiken om door te koppelen naar de verschillende Layouts. N.b.: Mooier is het om dit via de FaktuurLayout-ID te doen die op het 7e Tabblad van de Debiteur staat, ook al is deze formeel ergens anders voor bedoeld; de eerste 3 posities van wat aldaar wordt ingevuld, bepaalt de Layout-ID voor de Logistieke Faktuur.

 

Houd wel het vetgedrukte in de gaten; als dat niet zo is moeten we iets maken, en houd voor je beeldvorming dan maar alvast rekening met 2 dagen werk minimaal.