Post & Print - Sales Invoice

omyvadiya

Hi,
I am trying to use the standard Post & Print option that is on Sales Invoice Page. I am getting the following error:

Microsoft Dynamics NAV

---

The Sales Invoice Header does not exist. Identification fields and values: No.='XYZ1812RI0016'

---

OK

---

In Demo database its working fine, but in my database it is showing the above error.
The Sales Post and Print cdu is not customized.


On debugging it is getting stuck in the .Get function mentioned in the below code:

DocumentRecordRef.GETTABLE(HeaderDoc);
CASE DocumentRecordRef.NUMBER OF
DATABASE::"Sales Invoice Header":
BEGIN
SalesInvoiceHeader := HeaderDoc;
SalesInvoiceHeader.SETRANGE("No.",SalesInvoiceHeader."No.");
SalesInvoiceHeader.GET(SalesInvoiceHeader."No.");
SetCustomReportSelectionRange(

Developer101

which object is this that is having error?

TallyHo

HeaderDoc is not a std. NAV variable name.
This is a modification.

omyvadiya

Table - 9657 (Custom Report Selection), PrintCustomReports function

omyvadiya

@TallyHo - It is std in Nav 2016 IN version

omyvadiya

PFA, it is non-modified table, HeaderDoc is a local Parameter in the function.

Developer101

omyvadiya wrote: »

Hi,
I am trying to use the standard Post & Print option that is on Sales Invoice Page. I am getting the following error:

Microsoft Dynamics NAV

---

The Sales Invoice Header does not exist. Identification fields and values: No.='XYZ1812RI0016'

---

OK

---

In Demo database its working fine, but in my database it is showing the above error.
The Sales Post and Print cdu is not customized.


On debugging it is getting stuck in the .Get function mentioned in the below code:

DocumentRecordRef.GETTABLE(HeaderDoc);
CASE DocumentRecordRef.NUMBER OF
DATABASE::"Sales Invoice Header":
BEGIN
SalesInvoiceHeader := HeaderDoc;
SalesInvoiceHeader.SETRANGE("No.",SalesInvoiceHeader."No.");
SalesInvoiceHeader.GET(SalesInvoiceHeader."No.");
SetCustomReportSelectionRange(

weird code GET after setrange as doing pretty much same thing

TallyHo

@TallyHo - It is std in Nav 2016 IN version

Yes, my mistake!

TallyHo

"On debugging it is getting stuck in the .Get function mentioned in the below code:"

The get I 'get'. Set the pointer after setting the filter.

|You should focus on the place from where PrintCustomReports is called as shown in de debugger.

TallyHo

Try adding the code on the beginning of the function.
message('%1',headerdoc.isrecord);
Is it an actual record in the Var?
It probably is.. sales invoice header, but give it a try.

rahul_jnk

Is SalesInvoiceHeader."No." having the correct value?

omyvadiya

yes the document no. that is passing in SalesInvoiceheader.No. is correct

rahul_jnk

Was there any database corruption? Try rebuilding indexes.

omyvadiya

Nopes, there isn't any database corruption

TallyHo

Below the code from CU82.

SalesInvHeader."No." := "Last Posting No.";
This I do not trust, probably the reason


Try to add
SalesInvHeader.FIND;





IF Invoice THEN BEGIN
SalesInvHeader."No." := "Last Posting No.";
SalesInvHeader.SETRECFILTER;

CustomReportID := CustomReportSelection.PrintCustomReports(SalesInvHeader,SendReportAsEmail,FALSE);
IF CustomReportID = 0 THEN
PrintReport(ReportSelection.Usage::"S.Invoice");
END;

rahul_jnk

Try rebuilding indexes. As its standard code I suspect that could be the case - db corruption. You can do it from development environment untick maintain index for the corresponding key ( No. ?). save the table and tick again and save the table.

omyvadiya

Hi @TallyHo -
Thanks,
your custom code helped me in the Post and print,

But, the Report is not having any data related to the posted invoice, only the hardcoded part is printing and the default values.

TallyHo

So this probably means that the "Last Posting No." is not correct.
In theory it is possible that NAV starts posting an invoice, fills the last posting no.
but has a rollback due to an error while posting.
The value for last posting no stays in the table, but the invoice does not exist.
I've 'misused' this field many times, so It could be that NAV was adjusted to fill this field differently.