External_SQL.DB_KantenbandData.xml

Gechecked bij Giel:
Onbehandeld fineer gaat in plaats van 4 passen telkens maar 2 passen doen (zoals melamine), omdat we hier geen SCHIELE pas nodig hebben.
Ze worden dus ook gedraaid en gekanteld zoals de melamine versie.

Het lijkt erop dat de oude programma's niet meer gebruikt zullen worden. D.w.z. opkuisen die handel!

We gaan de lang en kortteksten nog overlopen met JB, maar lijkt me wel als gevraagd. zie ik na en unittest ook

ok, wordt nagezien.

inderdaad met giel afgesproken om een tax only te testen. ook voor kamerfrees bestanden.

Hopelijk zitten DOM kenmerken niet in APPS of dto klassen.

done.

Er zijn andere testen voorzien met aantal 1. (ander kaartje.)

Had ik bewust nog laten staan omdat het wel es gebeurd dat ze er toch bij moeten. maar inderdaad beter weg als we het nu toch niet nodig hebben. solved.

Volgens mij is dit een volledige V1-doos.
Aansturing zal moeten aangepast worden om wikkel-op-maat te snijden. Geen idee of we dit al ergens in onze code hebben.

Bij Probox komt dit probleem momenteel niet tevoorschijn,
maar je moet wel eens nakijken, want ik denk dat bij de probox-verpakking sowieso de TAX-only-wikkels ook moeten gesneden worden.

Key = 1 tot 5
dit geeft aan dat er 2 zijkanten per groepje liggen (is idd zoals de robot)

Dus bij TAX-only zal deze maar half gevuld zijn, indien 1 stuk gevraagd.

GENERIEK\TAOR_BOX\VET\TAOR_BOX_C_Z.JPG --> bestaat er een Front-olny image ("VET") voor de etiketten?
zoals op het ProductieDetailBlad.

Volgens mij is hier een stukje vertaling vermist.
Dit geeft ook aan dat er geen UT is op de langtekst voor Tax-onlies. Klopt dat?

Ik heb te weinig kennis om na te kijken of deze file inhoudelijk correct is.
Dit zal moeten proefdraaien, of iemand van de machine (Giel?) kan dit misschien controleren?

zie opm. Probox-test

ik heb toch een lichte voorkeur om alle verschillende onderdelen te testen : rug, front, bodem, zijLi en zijRe.
Moet daarvoor dan geen iterator+while gebruiken, mag gewoon opsomming/insert onder elkaar zijn

Aantal op 1 zetten.
(of tijdelijk nog op 2, vanwege kamerfrees)

idem bij V1-test

moet niet afleiden van TAX.BaseLosseComponent,

idem bij V1-test

Beter een ander getal nemen, want hierboven heb je ook al "100" gebruikt als LadeHoogte.
Risico op "niet ontdekken van fout" doordat je met dezelfde getallen werkt in verschillende "dimensies".

(moet ni per sé een realistische/echte ladeDiepte zijn)

TestZijkant (Li/Re) niet aanwezig?

Deze zit nu ook in de klasse vhTest.Utils.APPS.PM.Maatwerk.dto.TAORKenmerken : method LegeKenmerken()

Juister is TAORKenmerken.RugHoogte
(echter, alleen in geval van verlaagde rug zou je het verschil zien)

Gekopieerd van LBX, zekers :-P
mag weg, hé.