With the type 'Check In To Document Management' in the report rules it is possible to create a document revision with the report when printing a report. If I configure the Document No in the property list as follows 'DocumentNo=[@CUSTOMER_ORDER_IVC_REP/INVOICE_NO];' the revision is not created. If I omit the DocumentNo property, a new Document No is created each time the report is printed. How can I implement in the report rules that a document revision is created which is revised when the report is printed again?
Solved
Report Rules - Check In To Document Management
+4Best answer by Mathias Dahl
Hi Oliver,
I don’t think you can easily do what you want right now, assuming there is no document with the same Doc No as the invoice number at any given time the report rule is run.
The code that handles the "archiving" of the report/PDF has two "paths", you could say. Either you provide a document number, or you don't, and two different paths are taken.
If you provide one, and a document with that number exists, then a new revision is created and the PDF is checked in to it (assuming database storage is used for the document class in question). You can try this by manually creating a document with an invoice number you know, and then print that invoice.
If you don't provide a document number, well, then it works like what you have seen, that a new document is created and the PDF is connected to it.
So, the problem is that you want to combine these two pieces of business logic, but they don't work very well together.
In order to get new revisions of the same document created, you need to provide a document number, but you don't have that the first time the report is printed. And to get the document created in the first place you need to leave out the document number.
Something that might work is to set up a custom event that, when certain invoices are created (you need to find a good triggering point), then an empty document is created, with the document number set to the invoice number. Then, you have a report rule that sets the document number. Then, since the document exists, the "add new revision" logic should kick in.
Worth trying, perhaps?
/Mathias
+32Hi Oliver,
I don’t think you can easily do what you want right now, assuming there is no document with the same Doc No as the invoice number at any given time the report rule is run.
The code that handles the "archiving" of the report/PDF has two "paths", you could say. Either you provide a document number, or you don't, and two different paths are taken.
If you provide one, and a document with that number exists, then a new revision is created and the PDF is checked in to it (assuming database storage is used for the document class in question). You can try this by manually creating a document with an invoice number you know, and then print that invoice.
If you don't provide a document number, well, then it works like what you have seen, that a new document is created and the PDF is connected to it.
So, the problem is that you want to combine these two pieces of business logic, but they don't work very well together.
In order to get new revisions of the same document created, you need to provide a document number, but you don't have that the first time the report is printed. And to get the document created in the first place you need to leave out the document number.
Something that might work is to set up a custom event that, when certain invoices are created (you need to find a good triggering point), then an empty document is created, with the document number set to the invoice number. Then, you have a report rule that sets the document number. Then, since the document exists, the "add new revision" logic should kick in.
Worth trying, perhaps?
/Mathias
Hi Mathias,
today I had a ession with the customer and the partner and they showed to me what they did. They create a document without attachment when the object is created. Via a report rule th printed document is attached to the existing document revision. Until there, everything works as described by you. But if we print the report a second time, we would have expected that a new document revision would be created. That’s how we understood your solution. Unfortunately that’s not the case.
We see in report rule logs that the rule was executed. We don’t see any error message. But no document revision was created.
Best regards, Heinz
+32Hi,
Thanks for reporting back what they tried.
I cannot say for sure, since this is functionality that is seldom used, but there MIGHT be a bug in the business logic. You should have a look and follow the logic in the Check_In_Report method in DocumentReportArchive.plsql. There is this condition:
IF NOT Prelim_And_No_File_Exist___() THEN
prev_rev_ := max_doc_rev_;
max_doc_rev_:= Doc_Issue_API.Calc_New_Doc_Rev(prev_rev_);
Doc_Issue_API.New_Revision_(doc_class_, doc_no_, doc_sheet_, max_doc_rev_, prev_rev_, 'report_' || result_key_);
Doc_Issue_API.Copy_Info(doc_class_, doc_no_, doc_sheet_, max_doc_rev_, prev_rev_, 1, 1, 0); -- ALWAYS NO NEED TO COPY THE FILE.
END IF;
I'm not sure at all, but I wonder if that "IF NOT ..." there should be "IF ..." instead...
I’m afraid I don’t have the time to spend on investigating if that's a good or a false clue, but perhaps you or the partner can have a look? If the logic is flawed we can fix that from a bug fix. If not, and it's not just fitting for this customer, then you might need to make a small customization in that file.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.