Vraagje met betrekking tot routeplannen: We willen graag per Route / levering een losdatum/tijd kunnen invullen. Nu kan dit wel via menu routeplan <7 - Shift F5 - select levering - F5>, echter dit is wel een omweg op het moment dat je routes maakt.

Daarom zouden we graag ná het genereren van een route,  lorlra (Raadplegen leveringen van een Route) tevoorschijn willen hebben.

Dus, ik heb een routeplan ( route ongeacht voorraad, ten behoeve van bulkgoederen: J)
Ik ga er van uit dat het genereren van de te leveren artikelen is uitgevoerd..

Vanuit hoofdmenu is het pad dan:
<3-2-2-1-1- select route - f2 - 3 - 2 > (LORPODRA - Raadplegen te leveren artikelen (op te nemen) )

Ik ga een x aantal regels taggen, daarna <Shift F5 > (LORPRLTG (Genereren Route + Levering))
dan < benodigde velden invullen - F1> --> nu kom je weer terug in LORPODRA

Vraag is: Kun je in plaats daarvan, ook lorlra  aanroepen, van de zojuist gegeneerde route. Dan kun je namelijk van daaruit even een levering selecteren en met <F5> de losdatum/tijd aanpassen.
Als je geen losdatum / tijd invult, en op ESC drukt, gewoon weer terug naar LORPODRA,zoals nu ook gebeurd.

nb. Voordat ik op term externe verplaatsopdracht wordt afgerekend: Misschien heet dit ook wel anders.
Het zou gewoon leuk zijn, dat  het transport van product X vanuit Leeuwarden naar ExternProductiestation, vergezeld kan gaan van een "profit"-vrachtbrief.

In wezen gewoon een productieorder, waarbij de Afboeking eerst een vrachtbrief nodig heeft. De output hoeft wat mij betreft niet per se als goederenontvangst in Profit te staan, ik wil 'm ook wel als opboeking op de productieorder "ontvangen".

Het is een tijdje geleden, maar ik weet dat er zoiets als externe verplaatsopdrachten bestaan, die o.a. voor "dummy" verkoop en inkooporders zorgen, om formeel de vrachtbrieven / ontvangsten mogelijk maken. Waar zit deze optie ook al weer?

Ik heb een product X op voorraad, die ik verstuur naar een extern productiestation, daar laat bewerken, en daarna ontvang als product Y.

Dat transport naar extern productiestation, gaat nu met een handgeschreven vrachtbrief.

Of behoren die verplaatsopdrachten in een aparte module thuis?

Bij het toevoegen van inkoopfacturen gaat het volgende mis:
   ____________________________________________________________________________________________
    DATUM  : 24-03-14    TIJD : 11:38:35          VISUAL FOXPRO         UID : MD     
      KODE : 9999     MESSAGE : Index does not match the table. Delete the index file and re
      AREA : 35         ALIAS : LOR0              INDEX : LOR0_IN1      ROW : 84188
      LINE : REWRITE = 0 .AND. (PAGECLCK = 0 .OR. SCHERMF = PAGECLCK)               
      STCK : SYERAH  SYEV  SYOF1  SYOF  LORIFRRA  ADFITV  LOFINRRA  LOFI  LOIB  LO  SYSA  LOIN
              PROFIT8
      XST  : =MEEL=[LO][PASSW_S]4[LOIB]3[LOFI]1[LOFIRA][]BackspaceBackspacePgDnPgUpPgUpPgUpPgU
             pPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnPgDnEsc[LOFI]F22[LOFINRRA]petwi1P
             gDnPgDnPgUpPgUpPgUpPgUpPgDnPgDnPgDnPgDnF4[ADFITV][CRTID_S]petwi1Tab[ADFI_FID_S]Ta
             b[ADVA_VID_S]EscEsc[ADFI_FID_S]Esc[LOFINRRA][]F4[ADFITV][CRTID_S]petwi1Tab[ADFI_FI
             D_S]Tab[ADVA_VID_S]MouseMouseTab[BEDRAG_S]186900Tab[FAKOMS_S]Tab[FAKDAT_S]12Tab[DA
             TBET_S]Enter[EBKSTNR_S]50003691F1
    ____________________________________________________________________________________________
    DATUM  : 24-03-14    TIJD : 11:39:41          VISUAL FOXPRO         UID : MD     
      KODE : 9000     MESSAGE : TBC / COPY K:\FOX\LO\LOTB\                                 
      AREA : 0          ALIAS :                   INDEX :               ROW : 0
      LINE : H:\FOX\LO\LOTB\                                                       
      STCK :
    ____________________________________________________________________________________________
    DATUM  : 24-03-14    TIJD : 13:20:12          VISUAL FOXPRO         UID : MD     
      KODE : 1881     MESSAGE : Error with CNTDATA - Height : Expression evaluated to an ill
      AREA : **         ALIAS : LOIRRA2           INDEX : A1            ROW : 7078
      LINE : REWRITE = 0 .AND. (PAGECLCK = 0 .OR. SCHERMF = PAGECLCK)               
      STCK : SYERAH  SYER  ON...  SYST  SYST2  SYSMRE  SYGB  SYIF  LOIRRA2  LORIFRRA  ADFITV  L
             OFINRRA  LOFI  LOIB  LO  SYSA  LOIN  PROFIT8
      XST  : =MEEL=[LO]4[LOIB]3[LOFI]2[LOFINRRA]F4[ADFITV][CRTID_S]MouseMouseMouseMouseMouseMou
             sepetwi1Tab[ADFI_FID_S]MouseTab[ADVA_VID_S]Tab[BEDRAG_S]186900Tab[FAKOMS_S]Tab[FAK
             DAT_S]12-03Tab[DATBET_S]Enter[EBKSTNR_S]50003691F1
    ____________________________________________________________________________________________

Mijn vermoeden is dat er een plusteken is gebruikt in het faktuurnummer danwel boekomschrijving

eerder kon dit wel, zie afbeeldingen.

Het meest vervelende is nu, dat er ook geen nieuwe factuur (zonder plusteken) kan worden toegevoegd, ook niet na reorganiseren tbc en proofit afsluiten + opstarten.

Is dit aub te verhelpen?

Lang geleden is in overleg met Menno van Empelen en ons, het bepalen van de (commerciele) keuringswaarden onder de loep genomen, en verder uitgewerkt door zijn collega's bij Heart Profit. Waarvoor nog steeds dank.
Dit is verweven in de functie LOPRKRV1 Printen keuringsrapporten. (LO<3-2-7-8-3>), en schuilt onder het aangevinkte rubriekje "Gem Voorlaatste 3 produkties", waarschijnlijk in combinatie met het rubriekje Keuringsrapport a/c.
Met dat aangevinkte rubriekje, spreek ik over commerciele keuringswaarden.

Voor mijn gevoel, werkt deze systematiek al een tijdje niet helemaal feilloos. Vandaag daarom aandacht hiervoor:
Het lijkt er op, dat het bepalen van de commerciele keuringswaarden niet werkt, als er op de feitelijk geleverde charge geen waarden ingevuld zijn. Waarden worden bij ons pas bepaald bij het Gereedmelden van een Productie order. Daarom spreek ik onderstaand over Gereedgemelde productieorders. Maar je mag hiervoor ook lezen: Productieorders / charges zonder ingevulde waarden.

Voorbeeld:
Ik heb in de Laco Test bestanden een verkooporder 20140305002 regel 1, waarop de 20002 vrsvrm KE25 wordt geleverd, van charge 96832. Dit is een charge waarvan de PO de status Z heeft (alleen opboekingen). De output van deze PO wordt al wel uitgeleverd.

Om toch het keuringsrapport mogelijk te maken, heb je die mooie functie "Gem Voorlaatste 3 produkties" die een rapport mogelijk maakt. Probleem is hier: Het keuringsrapport blijft vwb de feitelijke informatie geheel leeg, er worden geen voorschriften waarden etc. afgedrukt.
De drie voorgaande productieorders horen een rapport wél mogelijk te maken. Dit betreffen:

201402070007 ==> charge 96338
201402130053 ==> charge 96491
201402200036 ==> charge 96624

Die allemaal de keuringenswaarden ingevuld hebben (Hoogste doorgang ==> 3)

Laten we ons even beperken tot 1 keuringsvoorschrift, voorschrift 110

Charge      waarde   norm
96338        9,26   10
96491        9,58   10
96624        9,55   10
1e x norm   10,00   10
2e x norm   10,00   10
3e x norm   10,00   10
som:      58,39   
           /6   
Commerciele waarde:   9,73   

Op het keuringsrapport komt dit dus niet terug, want deze is leeg.

Nu zul je misschien denken: De geleverde charge "Moet" ook meetellen met het bepalen van de commerciele keuringswaarde, echter met het volgende voorbeeld wil ik aantonen dat dit niet zo is:

Artikel 20082 vrsvrm KE25 van charge 96277 ga ik leveren op Verkooporder 20140306002. Om het gemiddelde te kunnen bepalen kijk ik naar de voorliggende 3 producties. Dat zijn achtereenvolgens de productieorders:
201310100033 ==> Charge 93428
201401030024 ==> Charge 95436
201401090066 ==> Charge 95604
201402060006 ==> Charge 96277 ==> geleverde charge

Het voorschrift 270 uitgelicht:

Charge      waarde   norm   doorgang
93428      17,60    15   3
95436      17,55    15   3
95604      18,65    15   3
96277      nvt       = geleverde charge
1e x norm   15,00    15   
2e x norm   15,00    15   
3e x norm   15,00    15   
som:      98,80      
         /6      
Commerciele waarde:   = 16,47 (afgerond 16,5)

Die staat ook keurig op het rapport. (zie afbeelding). Zou charge 96277 wel meetellen, dan had daar een andere waarde gestaan.

Sinds kort heb ik de bedrijfsparameter expeditie, Aut. Prntn Keuringsrprt J/N/K op K staan

na het goedkeuren van de raaplijst
XST  : =LACO=[LO][PASSW_S]3[LOVE]2[LOVELE]3[LOVELERL]2[LOLLRA1][]F5[LOLRRG] --> en dan f1
Wordt de vrachtbrief geprint (omdat ik dat vinkje aan heb staan) en volgt eventueel het pakbon verhaal.

Daarna komt nu de optie 3 - LOLRGK met de vraag of je het keuringsrapport wilt afdrukken. Druk op <enter> ja, en dan kom je bij LOPRKRV1 printen keuringsrapport terecht.

Valt er iets te maken dat je die 3 - LOLRGK gewoon achterwege laat, en LOPRKRV1  ook niet toont, maar gewoon uitvoert? Met respect voor de aldaar met dynscreen ingestelde waarden.
In wezen gewoon dezelfde techniek als die x - keys gebruikt. (zie website x-keys ).
Dit is een bijzonder handige oplossing om toetsaanslagen te verminderen, echter het enige risico van het inregelen van deze optie via X keys is even, dat die Pakbon er als Vraag tussendoor kan komen, afhankelijk van de parameter daarvoor op afleveradres niveau, blad 6.

Mogelijk met een uitbreiding van de bedrijfsparameter Aut. Prntn Keuringsrprt J/N/K met een A van automatisch of iets dergelijks?

Wat kan ik nu van e.e.a. verwachten? Is dat wel of niet voldoende hoogte? Zijn er nou werkelijk geen Profit klanten die met iets dergelijks in Profit reeds werken? Mogelijk registreren ze dit in een apart pakketje, dat zou prima kunnen. Dan vraag ik me af: is dat Excel, of wordt hiervoor een andere toepassing gebruikt, waarmee je grip houdt op de hele handel?

We willen namelijk binnenkort de administratie van e.e.a. beter inzichtelijk krijgen. Bij voorkeur nog in het 1e kwartaal van 2014.

De achterliggende gedachte achter mijn opmerking voel je waarschijnlijk wel aankomen: Ik wil graag dit proces efficiënter laten verlopen, zonder dat er foute keuringsrapporten worden gemaakt. Vooral ook zonder dat de expeditie medewerker daarvoor op extra knoppen hoeft te drukken.

In wezen, een techniek die je ook terugziet bij de Pakbon. (die kan ook automatisch gemaild worden na het goedkeuren van de raaplijst)

Ik zou daarom graag die keuringsrapporten wel automatisch willen printen bij het goedkeuren van de raaplijst. Omdat we niet blindelings durven te vertrouwen op de keuringsrapporten, zouden we deze het liefst eerst naar de kwaliteitsdienst willen sturen (printen of mailen). Na beoordeling deze mailen naar de klant. Als op termijn blijkt dat de fout kans (op onjuiste keuringswaarden) erg klein is, dan kunnen we de stap van de kwaliteitsdienst er ook tussen uit halen, en direct naar de klant mailen.

Ik snap dat dit consequenties heeft. Er van uitgaande dat we LOPRKRV1 als uitgangspunt mogen nemen, denk ik aan het volgende:

- Ontvangst Keuringsrapport per mail ook echt kunnen mailen.
Dat betekent dat je de relatie/kontaktpersoon bij tv/wy afleveradressen Blad 6, moet respecteren voor het mailadres. Dan kun je 1 kontaktpersoon gebruiken, en tevens nog een alternatieve relatie kunt selecteren. 
Genoemde kontaktpersoon moet dan uiteraard wel een mailadres hebben. Bij de pakbonnen doe je dit zelfden, maar het aparte dáár is, dat je ook bij toevoegen / Wijzigen kontaktpersoon een rubriek "Ontvangst pakbon" "-/E " moet invullen. Is een dergelijk rubriek bij tv/wy contactpersonen ook echt nodig voor keuringsrapporten?  dat vraag ik me sterk af, omdat het afleveradres dit m.i. al regelt.

Los daarvan zal het mechanisme van het maken en mailen van een PDF (net als bij Facturen / pakbonnen e.d.) ook bij Keuringsrapporten moeten worden toegepast.

- Keuringsrapport laten beoordelen door de keuringsdienst alvorens te mailen.
LOPRKRV1, toevoegen een rubriek "Respecteren verzendwijze Keuringsrapport J/N". Waarom? --> Bij de expeditie moet deze rubriek op N staan. Op die manier zou ik willen afdwingen, dat het keuringsrapport daadwerkelijk eerst naar de keuringsdienst gaat. (hetzij per mail, hetzij een print of)
Staat deze rubriek op J, dan wordt eerder genoemd mechanisme uitgevoerd, en wordt het keuringsrapport werkelijk verstuurd. (en opgenomen als kontakt)

- Kan het nog mooier / efficiënter?  
Ja, in plaats van bovenstaande, zou de ultieme wens het volgende zijn: Alvorens het (automatisch) versturen van een keuringsrapport, eerst controleren of álle commerciële keuringswaarden op dat rapport binnen de normen (tolerantie positief/negatief) vallen.
Zo ja --> verstuur naar de klant
zo nee --> verstuur deze naar de kwaliteitsdienst, dan weten ze dat er iets niet klopt. Om het dan nog mooier te maken, zou toch helemaal prachtig zijn, dat ze ook zien wat er niet klopt. Dat er een melding bij staat, op welk punt het niet klopt.

E.e.a. zou betekenen dat je eerst een (tijdelijke) tabel moet opbouwen, per Raaplijst / artikel / vrs/ charge met alle keuringsnormen, toleranties en commerciële waarden. Hiermee wordt dan gecontroleert of de waarden binnen de toleranties blijven, en dan pas gaat bepalen of het onder het kopje ja of nee gaat vallen. En ik snap ook, dat je daarbij rekening moet houden met de numerieke / alfanumerieke waarden van die keuringen. Het gaat bij ons veelal om numerieke normen en toleranties.

Zouden jullie aan de hand van bovenstaande, aub mee willen denken in het efficiënter maken van dit proces. Met een belletje vullen we dit vast verder in. Bij voorbaat dank.

Een elfstedentocht is nog niet in zicht, maar mogelijk ga ik me even op glad ijs begeven, met betrekking tot (commerciële) keuringsrapporten.

Aan de hand van de Rappellijst (van "gister") wordt uitgezocht wélke verkooporders voorzien moeten worden van een keuringsrapport. Per geldende verkooporder wordt dan gecontroleerd of de raaplijst al gemaakt en geraapt is. Zo ja, dan worden de keuringsrapporten 1 voor 1 afgedrukt, gecontroleerd en verstuurd. Alles behalve efficient!  Hier mag nu verandering in komen.

Daarvoor is in de bedrijfsparameters Expeditie, op Blad 5, de rubriek "Aut. Prntn Keuringsrprt J/N/K " te vinden. Tot dusverre stond deze op N. (prod. best Laco).

De helptekst zegt mij:
--> Dat klopt, en werkt.

--> en dat klopt niet helemaal.
Het keuringsrapport wordt namelijk niet automatisch afgedrukt. Hiervoor komt net als bij optie J, eerst een vraag in beeld.

Om te beginnen is mijn vraag is dan ook --> Waarom wordt dit niet automatisch worden afgedrukt?
Misschien beantwoord vraag 2 dit deels:

Vraag 2 is nl: Vanuit welke functie gebeurd dit vervolgens?
Als ik het goed volg, is dit gewoon loprkrv1, net zoals je nu gebruikt voor de huidige werkwijze. Op het moment dat je nu echt automatisch keuringsrapporten gaat afdrukken: Hoe zorg je dan, dat LOPRKRV1 "juist" wordt ingesteld? Dit met betrekking tot o.a. de rubrieken Gem. Voorlaatste 3 producties, Afdrukken Hoofdcharge, Keuringsrapport A/ C(die zou uiteraard uit de verkooporder header moeten volgen), en mogelijk ook de zo pas ontwikkelde rubriek taalkode die ik op het forum voorbij zag komen  ( http://ha1.heartprofit.nl/profit/index.php?topic=25770.0 ) .

Eerst dit maar even helder, dan komt later het vervolg wel

Ik beleg 's ochtends m'n boterham, maar beleggen bij de Beurs of termijnmarkten is geen dagelijkse kost voor mij. Mijn collega's weten hier wel veel van, en bovendien heb ik  o.a. via http://nl.wikipedia.org/wiki/Future ook nog wat kennis op kunnen doen. Echter, mijn collega's weten evenmin als ik, nog niet hoe dit correct geadministreerd en gevolgd kan worden in Profit.

Future's / commodity's worden bijvoorbeeld ingezet voor de handel in Aardappelen, brandstoffen etc. Commodity's zijn voor bepaalde bedrijven "nodig" voor de bedrijfsvoering. Bijvoorbeeld de kerosine voor een luchtvaartmaatschappij, zij kunnen zich hiermee indekken tegen het risico van prijsstijgingen. Zij hedgen hun risico.

Wij gaan deze Futures / Commodities gebruiken voor Graan. (Milling Wheat)

Even wat code's voor onderstaande toelichting:
code   omschrijving, alle prijzen per ton:
C   Aankoopprijs Graan bij Graanleverancier
G   Grondstofkostprijs
K   Kwaliteitspremie
X   Aankoopprijs Future
Y   Verkoopprijs Future
Z   Resultaat Future

KKM, dat is dus ons bedrijf. De kwaliteitspremie is nodig, omdat de Commodity gebaseerd is op kwaliteitsniveau "0", maar de feitelijke grondstof die uiteindelijk gekocht wordt, kan een ander kwaliteitsniveau hebben. Ik laat deze eerst even achterwege, maar die komt later nog wel. (nadat onderstaand verhaal duidelijk is)

• KKM koopt een Future bij een Clearingsbank voor bedrag X per tn, met kwaliteitsniveau “0”
• Op een bepaald moment verkoopt KKM (een deel van) deze future, stel even 1000 tn,  voor bedrag Y per ton aan diezelfde Clearingsbank . (Y-X) vormt resultaat Z . Tot zover een financiële transactie.
• “Hiervoor” koopt KKM op datzelfde moment een partij graan, stel even 1100 tn, in bij de Graanleverancier voor bedrag  C per ton, met kwaliteitsniveau “1”.  1100 ton is ongelijk aan 1000 ton, omdat we gebonden zijn aan afname van volle schepen. 1000 ton is gebonden aan de future, de overige 100 ton is dat niet. De graanleverancier ziet ook de inzet van de future niet terug
• Er wordt dus een contract afgesloten met Graanleverancier, die ter stond wordt afgeroepen. De factuur van Graanleverancier moet voor wat betreft Bedrag C opgesplitst worden:
• Het verschil tussen tussen de Verkoopprijs van de Future (Y) en aankoopprijs van het feitelijke graan (C) , is de kwaliteitspremie K
• de eerste 1000 ton graan heeft als gevolg van de future, de volgende grondstofkostprijs: C - Z   = G
• voor de laatste 100 ton graan, geldt C = G
• Hoe ik K hier nog in moet verrekenen, heb ik nog niet helder, ik hoop op dit punt snel terug te kunnen komen.

 

Wie heeft ervaring met het administratief correct verwerken van future's in Profit? Hoe administreer je dit, zodat je hier controle over houdt? Hoe doe je dit in Profit?
Ik wil namelijk kunnen zien wat het rendement van een commodity is, en voor welk feitelijk inkoopcontract deze is ingezet. Voel je vrij om in dit verhaal te corrigeren, als ik hier onjuistheden in heb opgenomen.


Een future heeft uiteraard een looptijd, daarom heb ik vooralsnog voor het kopen van een future een inkoopcontract in gedachten, bij leverancier Clearingsbank. Zo heb je een duidelijk beeld van de aangekochte future's. Wanneer tzt (een deel van) de future wordt verkocht, ik een Verkoopcontract in gedachten, voor debiteur Clearingsbank. Eerst ontvang je dan op basis van het inkoopcontract 1000 ton, en die lever je daarna direct op het zo pas gemaakte verkoopcontract. Ben benieuwd in hoeverre deze gedachtegang klopt.

Dan  komt het feitelijke koppelen met de inkoop van het fysieke graan bij Graanleverancier aan bod. Wat mij betreft via een inkoopcontract bij graanleverancier. Hoe zorg je hier dat je kunt herleiden welke futures hierbij gebruikt zijn? Ik heb geprobeerd iets te doen met een DKK "Future_Resultaat", maar krijg hier vooralsnog geen grip op.

De inkoopprijs bij de leverancier, is niet de prijs is die het product ons uiteindelijk kost. Je wilt op 1 of andere manier duidelijk maken, dat het Future resultaat van invloed is op Grondstofkostprijs. Je moet dit weten om een zuivere grondstofkostprijs te bepalen.

Alvast veel dank voor het meedenken en uw suggesties.

Bij diezelfde helptekst staat ook, dat hetgeen jij noemt ook :
En dat samentellen staat bij mij juist op Ja (ipv nee). Maar goed, omdat het allemaal uit dezelfde type "verwijderingsbijdrage" bestaat, zal dat voor samengetelde DKK's ook wel gelden.

Maar prima, het verhaal is me wel helder, punt er achter. 

Ik heb desbetreffende DKK's een andere omschrijving meegeven (dezelfde omschrijving als ik bij dat artikel 00030 had), zodat in iedergeval de gewenste omschrijving op de factuur tevoorschijn komt.

Vraagje: Kun je bij bestaande verkooporderregels, getriggerd door een DKK de omschijving nog aanpassen? Er is namelijk een serie orders ingebracht, waarbij de "verkeerde" omschrijving bij de Verkooporder regel is weggeschreven. Daarvan staat een deel op routeplan etc.

betreft DKK BHEF1, BHEF2 en BHEF3 in de Meel productiebestanden.
Betreft verkooporders
DKK-id          Niveau                 Niveau-waarde                     
BHEF1   Verkooporderregel   20140130076/  1
      20140131008/  1
      20140131008/  3
      20140131035/  1
      20140131039/  1
      20140131039/  3
      
BHEF2   Verkooporderregel   20140130077/  1
      20140131003/  1
      20140131003/  3
      20140131003/  4
      
BHEF3   Verkooporderregel   20140130075/  1
      20140130075/  3
      20140130079/  1
      20140130079/  3
      20140130079/  4
      20140130080/  1
      20140130080/  3
      20140130081/  1
      20140130081/  3
      20140130082/  1
      20140130082/  3
      20140130083/  1
      20140130083/  3
      20140131048/  1
      20140131049/  1
      20140131050/  1

die met een "foute" omschrijving weggeschreven zijn. Kun je zo'n DKK-omschrijving opnieuw generen bij die verkooporders? (zodat de nu geldende DKK omschrijving daar komt te staan)

het waarom: De omschrijving van het getriggerde artikel nummer, wordt niet afgedrukt bij dat artikelnummer, maar bij het artikelnummer van het feitelijke eindproduct. zie afbeelding

DAT HELpt helemaal niks, want dan wordt de artikelomschrijving van overige producten om zeep geholpen

nb. Speelt in Meel Test voor eerst
nb2: Ook als je bij de DKK zegt, "noemen op factuur" Nee, (en triggert artikelnummer dus nog steeds op art. 00030 vbw BTW e.d., dus niet gebruikt als taalartikel), dan nog wordt de omschrijving van de DKK gepakt, in plaats van die van het kostenartikel.

Ja, wat een leuk subject.
Probleempje: Ik heb een DKK, extracomtabel en opbrengstverhogend, spelend bij afhalen en leveren. Triggert artikelnummer 00030 vanwege de btw toestanden.
Ik heb tevens de rubriek "noemen op factuur" aangezet.
Bij bedrijfsparamters Art.omschrijving DKK opbrengst, staat artikel 00030. De (artikel)omschrijving daarvan, wil ik dus graag op de factuur terug zien (variabele layout) .

Echter, ik krijg enkel de omschrijving van de DKK op de factuur, in plaats van de omschrijving van het taalartikel.
Hoe zorg je ervoor dat je de omschrijving van het taalartikel op de factuur krijgt?

ik gebruik de layoutvariabele %HH:AROMS:40.0%

De rood omkaderde omschrijving krijg ik te zien, in plaats van de gewenste groen omkaderde variant.