Verwijderd schreef op dinsdag 08 februari 2005 @ 10:43:
Nog ff een vraagje:
Bij het importeren van de nieuwe orders, moet er dus eerst gechecked worden of die order al bestaat, als het goed is is dit echter niet het geval. Wanneer dit klopt, moet er een orderid gegeneerd worden. Gebeurt dit automatisch door Navision? Of moet ik eerst de MAX(orderid) ophalen oid?
In de Navision-standaard worden ordernummers automatisch gegenereerd. Je kunt vrij eenvoudig testen of dit ook voor jullie geldt:
- Ga naar Verkoop - Orders.
- Druk op F3 en daarna op Enter. Als het goed is verschijnt er een nieuwe order en wordt het ordernummer automatisch ingevuld.
Als dit het geval is, scheelt dat een hoop programmeerwerk. Wel is het van belang om in je dataport een stukje code op te nemen, waarbij de OnInsert()-trigger van de tabel Sales Header wordt aangeroepen. Vaak volstaat een INSERT-commando in de OnAfterImportRecord()-trigger van je DataItem in je dataport.
In dit geval zal het DataItem de tabel Sales Line (tabel 37) zijn. In de OnAfterImportRecord-trigger zal je daarom een stukje code moeten opnemen die automatisch ook de verkoopkop aanmaakt en vervolgens een INSERT doet in de tabel Sales Header (36). Globaal zal dat er ongeveer als volgt uit moeten zien:
code:
1
2
3
4
5
6
| WITH SalesHeaderRec DO BEGIN
INIT;
"Sell-to Customer No." := "Sell-to Customer No.";
"Shipment Date" := "Shipment Date";
INSERT;
END; |
Let wel: dit is dus even heel rudimentair, maar het gaat erom dat je een nieuw record initialiseert en vervolgens een INSERT uitvoert. Tussen INIT en INSERT kun je dan waardes toekennen aan de verschillende velden (zoals klantnummer, leverdatum, vestiging, etc....).
Het wordt wat lastiger om een controle uit te voeren op reedes bestaande orders. De primaire sleutel van de Sales Header tabel is namelijk het ordernummer, dus die is altijd al uniek. Hier zal dus wat programmeerwerk bij komen kijken. Er zal dus een verzameling van gegevens vergeleken moeten worden met de inhoud van zowel de tabel Sales Header als Sales Line. Bovendien is het de vraag of een order onder geen beding vaker mag voorkomen, ofdat klanten met enige regelmaat eenzelfde order in kunnen kloppen (bijvoorbeeld voor voorraadaanvulling).
Ook lijkt het me niet onverstandig om een controle in te bouwen dat een klant niet per ongeluk twee keer dezelfde order achter elkaar invoert (maar eigenlijk zou dit in de web-applicatie al afgevangen moeten worden). Hiervoor kun je werken met de variabelen Rec en xRec (Rec is het huidige record in de tabel en xRec het vorige). Door bepaalde velden van deze records te vergelijken, kan dubbele invoer worden uitgesloten. Bijvoorbeeld:
code:
1
2
3
| IF Rec."Sell-to Customer No." = xRec."Sell-to Customer No." THEN
IF Rec."No." = xRec."No." THEN
ERROR(''U heeft reeds een bestelling voor dit artikel geplaatst'); |
Wederom geldt dat dit een simpel (en niet zo netjes) voorbeeld is. (Tekstberichten dienen bij voorkeur als een tekstcontante gedefinieerd te worden, in plaats van hard gecodeerd.
Btw: Nieuw @ C/AL
Ik zag verder dat ik iig ook nog 2 "Application Object - Dataport" nodig heb.
Ik heb net het hoofdstuk van "Application Designers Guide" over dataports gelezen. Erg hulpvol.
Ze hebben het daarin echter over een aantal dingen:
- Field Designer
- Object Designer
- Service Mgt. Setup
Zijn dit ook allemaal aparte granules waarvoor een licensie beschikbaar moet zijn? Of zijn deze misschien embedded in andere granules?
Uit het bovengenoemde rijtje is de Object Designer een mogelijk struikelblok. Om toegang te hebben tot de Object Designer (wat noodzakelijk is om objecten te kunnen maken/wijzigen) is het het van belang dat een gebruiker over SUPER-rechten beschikt. Dit is een rol die is toe te kennen aan gebruikers. In de praktijk hebben alleen power-/key-users, systeembeheerders en ontwikkelaars deze rol toegekend gekregen.
edit:
Ik las net ergens dat je een solution developers license nodig hebt om deze dingen te mogen doen? Klopt dat of heb ik dat verkeerd? Dat zou iig niet zo mooi zijn, want dan moet ik het allemaal uitbesteden.
Een Solution Developer license is de 'moeder aller licenties'

Deze licentie is strikt voorbehouden aan Navision Nederland zelf en aan geauthoriseerde ontwikkelaars in dienst van leveranciers van Navision.
Voor de door jullie gewenste situatie zal zeker moeten worden ontwikkeld in Navision-standaard objecten (tabel Sales Header en Sales Line bijvoorbeeld) en dat kan inderdaad niet met een klanten-licentie. Voor klanten is het echter mogelijk om ook in de standaard-objecten te ontwikkelen: daarvoor kan de Application Builder license worden aangeschaft. Deze licentie kost echter €7800 en je leverancier zal dan geen verantwoordelijkheid meer nemen voor het onderhoud! Met de AB licentie kun je namelijk als klant zelf zeer diep in het systeem ontwikkelen en je NSC heeft daar dan geen grip meer op. Bestaande onderhoudscontracten zullen dan ook nietig verklaard worden als je overgaat tot aanschaf van deze licentie. Je zult dan ook een overeenkomst moeten tekenen met je NSC dat je NSC niet meer verantwoordelijk is voor fouten in de standaard-Navision objecten.
Aangezien je nieuw bent @ C/AL is het niet onverstandig om het een en ander inderdaad uit te besteden. Dit is echter wel een mooie case om jezelf verder te bekwamen in C/AL. Als je de beschikking hebt over een test-omgeving (bij voorkeur een omgeving die los staat van de overige ontwikkelingen en waarin datacorruptie geen probleem vormt), kun je bijvoorbeeld al experimenteren met het maken van de benodigde dataports

Je kunt natuurlijk ook op je eigen PC een lokale testomgeving aanmaken om in te 'fröbelen'

. <-- Sterk aanbevolen trouwens, als je nog geen of weinig C/AL-ervaring hebt.
[
Voor 9% gewijzigd door
Wok op 08-02-2005 20:48
]