Options

Modifying Codeunit 80

cabcab Member Posts: 12
Hi
I would like to inform the User before a Sales Invoice with an unpriced(0) line is about to be posted. This is to prevent despatched goods being invoiced without a value. Warehouse despatch is active.
I have created a new function in Codeunit 80, that checks for this condition and to display an ERROR whenever a sales line with zero value is encountered.
I have retained a copy of Codeunit 80, and created an alternative form where a supervisor may post the unpriced Sales invoices.
I have since been told that..
“The way in which this change has been developed is totally inappropriate and I would not recommend allowing it to go live. Codeunit 80 - Sales - Post is one the largest most central codeunits in NAV and it should not be renamed or copied in this way.
A warning should have been coded into Codeunit 81, before codeunit 80 is called. Then you have no need to create a new object for one thing and it is far easier to manage in the future."

Could anyone explain the merrit to why my method is inapropriate...

Answers

  • Options
    DenSterDenSter Member Posts: 8,304
    It's not a good practice to keep multiple versions of one process. Better would be to program the existing one around the situation. Modifying codeunit 80 though, which indeed is one of the most crucial codeunits in the system, should not be taken lightly at all. I would personally put logic like you mentioned in the release function. Add the check in the release function and don't allow the order to be released if your conditions are not met. Sales Orders (as well as Purchase Orders) cannot be posted unless they are released.
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    cab wrote:
    Hi
    I would like to inform the User before a Sales Invoice with an unpriced(0) line is about to be posted. This is to prevent despatched goods being invoiced without a value. Warehouse despatch is active.
    I have created a new function in Codeunit 80, that checks for this condition and to display an ERROR whenever a sales line with zero value is encountered.
    I have retained a copy of Codeunit 80, and created an alternative form where a supervisor may post the unpriced Sales invoices.
    I have since been told that..
    “The way in which this change has been developed is totally inappropriate and I would not recommend allowing it to go live. Codeunit 80 - Sales - Post is one the largest most central codeunits in NAV and it should not be renamed or copied in this way.
    A warning should have been coded into Codeunit 81, before codeunit 80 is called. Then you have no need to create a new object for one thing and it is far easier to manage in the future."

    Could anyone explain the merrit to why my method is inapropriate...

    I have done a lot of Navision implementations, and can not think of even one client that posts Sales orders/invoice, that did not have modifications to Codeunit 80. Navision did a survey some years ago, and the most modified table by Partners for their clients is T37, the most modified Codeunit is 80.

    Its this flexibility that has made Navision what it is today.

    now having said that, I need to also say that no one should even consider touching CU80 in a live environment unless they are fully trained, and know what they are doing. This is not work for someone that is on their first implementation, but something that is done the first few times under the supervision of a team leader that will make sure it is done properly.

    So yes it can be done, but only by someone that knows what they are doing.

    Out of curiosity , was it the client or another developer in your team that told you this?
    David Singleton
  • Options
    cabcab Member Posts: 12
    Hi
    Thanks for the prompt and relevant response(s).
    I agree that CU80 is critical, and should not be changed by someone who is inexperienced. The changes were made in DEV and will not see LIVE(it seems).
    Back to resolving the issue...
    The client insists on ERROR massage on post of a zero invoice...and a routine where such invoices may be posted(under supervision).
    I would like to know what BEST PRACTICE would be.
  • Options
    cabcab Member Posts: 12
    I have done the following to resolve the issue would appreciate if an experienced developer can confirm.

    In CU81

    Create a Function checkamount(VAR SalesHeader)

    WITH SalesHeader DO BEGIN
    SalesLine.SETRANGE(SalesLine."Document No.",SalesHeader."No.");
    SalesLine.SETRANGE(SalesLine.Amount,0);
    IF SalesLine.FIND('-') THEN BEGIN
    IF NOT CONFIRM(Invoice %1, Line %2 has a value of %3. Do U want to continue Post?) THEN
    ERROR(The Invoice was not posted);
    END;
    END;



    Call OnRun trigger to Checkamount(SalesHeader)
  • Options
    DenSterDenSter Member Posts: 8,304
    First, if you are going to explicitly code the SalesLine part, then you don't need to put the 'WITH SalesLine DO' around it.

    Second, the PK of the Sales Line table is document type, document number and line number. You should set filters on the doc type and doc number to get the right sales lines.

    Third, I would use ISEMPTY, because yo're not looking at any actual field values.

    Fourth, don't use the 'SalesLine' variable. That is a global variable that is used throughout codeunit 80, and you don't want to mess around with that. Create your own variable.

    Finally, you don't want to put any dialog in any posting routines. That creates unpredictable blocks. If someone gets a phone call with that dialog on the screen, you might block users for long periods of time.
  • Options
    ayhan06ayhan06 Member Posts: 210
    you must consider following situations as well:
    1. you are checking every line of sales order.. description or accidentally created lines will encounter error..
    2. your code checks every line but you need only lines whose "qty. to Invoice" is different than zero...

    ....

    this list can be expanded... i think you should do this with help of experienced developer and consultant.
Sign In or Register to comment.