Attain3.10 when trying to post and invoice with some error on the header and/or lines, a number is already assigned. When you try again (suppose you still have an error) the number is incremented with 1, … When you post the document you get your final number. As a result there is a gap in the invoice numbering which is legally not allowed as far as I know in Belgium. Isn’t there a patch or something to solve this one ? Thanks, Gunther
Hello Gunther, I am puzzled by your posting. Are you saying that your Attain system does not “roll back” the number series if you have an error on posting? This is not how Navision normally works. Has your system been developed? If the number series ‘jumps’, you could reset the last number used in the No. Series and then post the invoice. Alternatively, you might want to look into why it is not rolling back. Please could you let us know some of the details relating to this error? Hope this is of help! -------------------------------- Edward Bloomfield Navision Support Consultant Cambridge Online Systems Limited www.cambridgeonline.net
I am a little puzzled too. The process of posting is supposed to assign an Posted Invoice No. at a point and then a COMMIT is called to keep it there. That’s why an Invoice No. appears in the header. I believe the only way you could be experiencing this is by customizations. Do you have any customizations in Codeunits 80 or 90, or even in 396? Cheers! Kristopher Webb Kelar Corporation, Canada
Verify COMMIT in codeunit 80 and 90 W1. If the posting is interrupted due to an error, the number assigned should be stored in field 63 Posting No. in table 36/38 then, next attempt to post should use that number without get a new number from No. Series.
I agree with Elena. If the Serie No. related to your Posting (Invoice, Credit Memo, Shipment, …) is incremented when an error occur, you must find one COMMIT command before the code originated the error. And probably that COMMIT line will be documented as an modification of the standar database. gjgarciasm@terra.es Bye
Well I see that the BE version of Attain 3.01 has no problem, while the BE version of 3.10 has the problem. Also on the official NSC portal of Navision I see there are complaints from other countries as well. The reply from Navision is : issue will be solved in 3.60. When I look at the code I see : Code Codeunit 90 OnRun() section Attain 3.01 IF Invoice AND (“Posting No.” = ‘’) THEN BEGIN IF (“No. Series” <> ‘’) OR (“Document Type” IN [“Document Type”::Order,“Document Type”::Creditnota]) THEN TESTFIELD(“Posting No. Series”); IF (“No. Series” <> “Posting No. Series”) OR (“Document Type” = “Document Type”::Order) THEN BEGIN “Posting No.” := NoSeriesMgt.GetNextNo(“Posting No. Series”,“Posting Date”,TRUE); ModifyHeader := TRUE; END; END; Attain 3.10 BE IF Invoice THEN BEGIN IF (“No. Series” <> ‘’) OR (“Document Type” IN [“Document Type”::Order,“Document Type”::“Credit Memo”]) THEN TESTFIELD(“Posting No. Series”); IF (“No. Series” <> “Posting No. Series”) OR (“Document Type” = “Document Type”::Order) THEN BEGIN “Posting No.” := NoSeriesMgt.GetNextNo(“Posting No. Series”,“Posting Date”,TRUE); ModifyHeader := TRUE; END; END; Attain 3.10 W1 IF Invoice THEN BEGIN IF (“No. Series” <> ‘’) OR (“Document Type” IN [“Document Type”::Order,“Document Type”::“Credit Memo”]) THEN TESTFIELD(“Posting No. Series”); IF (“No. Series” <> “Posting No. Series”) OR (“Document Type” = “Document Type”::Order) THEN BEGIN “Posting No.” := NoSeriesMgt.GetNextNo(“Posting No. Series”,“Posting Date”,TRUE); ModifyHeader := TRUE; END; END; If I change codeunit 90 OnRun section in Attain 3.10 BE to : IF Invoice AND (“Posting No.” = ‘’) THEN BEGIN IF (“No. Series” <> ‘’) OR (“Document Type” IN [“Document Type”::Order,“Document Type”::Creditnota]) THEN TESTFIELD(“Posting No. Series”); IF (“No. Series” <> “Posting No. Series”) OR (“Document Type” = “Document Type”::Order) THEN BEGIN “Posting No.” := NoSeriesMgt.GetNextNo(“Posting No. Series”,“Posting Date”,TRUE); ModifyHeader := TRUE; END; END; Then everything works fine. But I guess Navision didn’t make the change just to cause this problem, I guess they needed to do so. So I’m not so keen on implementing change, … what could go wrong.
I would change the IF in CU 90 as it is in CU 80 … but I don’t know the impact. In version 3.10 IT, CU 90 works fine because that part is localized.