Hi: In MBS/Solomon, there is a feature that stores a default G/L account on the Vendor card. So when you create a purchase invoice, the first purchase line has the vendor’s default G/L account already populated. I’m trying to emulate this feature in Navision 3.70. The user also wants to default the Purchase Line type to “G/L Account” (they don’t use any of the other line types). I’ve added code already that takes the default Vendor G/L account and places it in the Purchase Header (in hopes that there will be easier access by the purchase line subform). I have no problem in populating the “No.” field with the default G/L account if I force the user to enter/validate the “Type” field on the Purchase Line. However, if I default the “Type” to ‘G/L Account’, that field is never validated, and the ONVALIDATE trigger for “Type” does a lot of stuff to the purchase line, e.g. populates the “Buy-from Vendor No.”, and other things. Does anyone have any ideas on how I could get the Purchase line to do all of the following: (a) a default type of G/L account, (b) a default value for the “No.” field and (c) have all the stuff done from the ONVALIDATE trigger of the “Type” field? If you’re certain you can do it, and you think it’s only a few hours of work, I’m even willing to pay you as a subcontractor. Feel free to contact me off-forum if necessary at email@example.com Thanks, Ron
I suggest this in PurchHeader Buy-From Vendor No. OnValidate()
IF Vend."Default G/L Account" <> '' THEN BEGIN PurchLine.RESET(); PurchLine."Document Type" := "Document Type"; PurchLine."Document No." := "No."; PurchLine."Line No." := 10000; PurchLine.INIT(); PurchLine.VALIDATE(Type,PurchLine.Type::G/L); PurchLine.VALIDATE("No.",Vend."Default G/L Account"); IF NOT PurchLine.INSERT(TRUE) THEN ERROR('Default line exist') OR MODIFY(TRUE); END; If you use it I will take a beer for those 3 minutes it took If you don’t use it, I guess I am way off - not that unusual :)
Am I missing something here. Most of the Validation on the Purchase Line is done on the No. field? (a) You can set the default Type in a couple of spots. Change the Table InitValue, or add code to the NewRecord event on the Purchase Order Subform. In your case, the Table change is probably the best. (b) The default for No. field is the one that has to be validated. The code above gives you an idea of what needs to be done here. You may need a CurrForm.Update on the Vendor No. to show the new line. (c) I think you just need to Validate the No. field here, and not worry about the Type field.
Chrisk: There is a lot of stuff done on the validation of the “Type” field. This is where the Buy-From Vendor No. is inserted into the Purchase Line, among other things. And, the code tries to insert a new Purchase Line record when the Purchase Header “No.” field is populated - before the Buy-From Vendor No. is ever entered by the user. This is causing the error “Buy-From Vendor No. must not be blank” when I try to insert code to modify the purchase line.
LG: I had code similar to your suggestion before. I also tried your code exactly. It does the same thing - results in the error “Buy-From Vendor No. must not be blank” when the Buy-From Vendor No. is input. This is the same problem I have been having. I try to insert code to modify the purchase line. Apparently, at this point in the code, the Purchase Header record has not been committed, so the code in PurchLines.ONVALIDATE retrieves a blank “Buy-from Vendor No.” and the validation code fails. Ron
So true Ron… Header is not committed (theLG - quick but wrong… as usual :)) try:
// LAHESTO NOLUG IF TRUE THEN BEGIN PurchLine.RESET(); PurchLine."Document Type" := "Document Type"; PurchLine."Document No." := "No."; PurchLine."Line No." := 10000; PurchLine.INIT(); PurchLine.SetPurchHeader(Rec); PurchLine.Type := PurchLine.Type::"G/L Account"; PurchLine.VALIDATE("No.",'1910'); IF NOT PurchLine.INSERT(TRUE) THEN ERROR('Default line exist');// OR MODIFY(TRUE); END; // LAHESTO
Am I missing something here? But in 3.70 you have this functionalty as standard!! It’s called Standard Vendor Purchase Codes and you got similar functionalty on the sales side (called Standard Customer Sales COdes)! So why create this new functionality?
Standard Vendor Purchase Codes would work except I think you would still have to add the automation. In the end, it would be the same amount of work, but using the Std. codes would allow a much greater flexability. I still don’t see the Type validation updating the Vendor No…Is that custom?
Chris/Erik/LG: As Chris mentions, I don’t see how std. purchase codes would work to default the Purchase line to a specific G/L acct/department. Plus, you’d have to set up unique purchase codes for each combination of gL acct/Department that you want to use as a default. But I haven’t really looked at this feature in very much detail. Regarding the validation of Type updating the Vendor No, I mis-spoke. The OnValidate trigger for “No.” is the one that does the TESTFIELD for “Buy-from Vendor No.”. Since I’m trying to set the “Type” and “No.” in the same section of code, I got confused. But I still have the same problem - “Buy-From Vendor No.” is still blank. I’m going to try to add the call to “SetPurchHeader” per LG’s recommendation, but in looking at the code for that function, it doesn’t appear that it commits the Purchase Header either. Thanks for all your suggestions. I’m eager for more. I’ll post my test results shortly. Ron
… it doesn’t appear that it commits the Purchase Header either. …
Not necessary in this case…
LG: Well, your addition of SetPurchHeader to the code did in fact work! I’m assuming that the code in this trigger forces a COMMIT on the Purchase Header. Thank you very much. Beer’s on me the next time we’re in the same city. I don’t get to Sweden very often (only once in my entire life). Do you ever come to Los Angeles ?
LOL, no sorry Ron… don’t think I’ll reach LA in the close future but I can send my old pal Anders G from BMI to have a beer and a laugh (New York is just 'round the corner, isn’t it hahah… ok, it’s a huge land u sit in).