print immediate

We have created a new UBE but the users are having trouble remembering to do the print immediate for this UBE. Is there anyway to automatically set this flag for a certain UBE or version?

Hi Carol

If I am not mistaking, 8.12 has this option now. If you are not on this release, you can always visit Alex's website (Everest Software International). He has developed a tool called "Autoprint". Works beautifully.
Just mention my name so I can get the commission

Carol,

I have done this twice.

Firstly to print immediate automatically when based on User ID. it involves modifying the P986162 and a custom UDC. I have posted this solution as an attachment (click here to download the attachment) to post# 92300. You could modify this solution to suit your needs.

Then, recently, I had a request for it to be more flexible. I changed this to to be based on UBE, User Id and Version or any combination thereof (taking into account that you can't have a version without a UBE). It also had to work when UBEs were submitted externally via the RUNUBE command (which does not launch the P986162). It is more complex and was built on top of the first solution and still allows the first solution to work. This solution involves:

- further modifications to P986162
- a JDE trigger on F986110
- a custom NER
- two custom UDCs

If you (or anyone else) are interested, I will post the second solution too.

Peter,
I'm interested, please post solution #2.
TIA

Gene

I have installed this code for automatic BOL prints using Create!Form and it works great.

For example, when I submit a R5542530 job to JDE-BAT, the table trigger looks for a match in the printer setup screens for user/report/host/status when sends the file to the new default printer, i.e. Create!Form. I also added a status of PI for Print Immediate so JDE does not use this printer setting.

I have read that you should be able to mod this code so that my status is a CF (copy file) or EF (Email File) and you specify a file share or email address as the "printer name" and off you go. I have not tested this though.

A trick to watch for:
- The "Default Pathcode" setting on your Enterprise Server JDE.ini is where the server looks for triggers. The trigger MUST be deployed in that environment on the server for the trigger to work.


Now, I add a default printer setting for any of my "Print Immediate" print jobs and off it goes to Create!Form or any other printer I define. It has been working for 1.5 years so far and never missed a beat.

Attachment 2

Attachment 3

Gene,

Sorry for the delay in my reply, I've been busy - and of course there was the weekend.

I have attached the second solution.

I have used a custom debugging business function in the ER for some of the objects. I have not included the NER, UBE or Table specs for this. If you (or anyone else) are interested, I will post it too.

If there are any questions on either of the solutions I have posted, please ask - either by reply to this post or by private message.

If anyone notes any glaring problems, please let me know. We have been using this in production since February this year without problem. If anyone has improvements I would also appreciate being informed.

How to get the Server Job Number to pass the value to NER?

Just wanted to mention that we have a canned commercial solutioon for this - a software package named "AUTOPRINT", which you can find on the WEB site in my signature...

I am not so knowledgeable about this matter. So i have to learn it. Thanks for the post.


plan solution commission de surendettement</font> - commission de surendettement, vous pouvez demander un dossier de surendettement.</font>plan solution commission de surendettement</font>

JDEList,

Print Immediate Update

Please keep the following in mind if using the attachment to my post (new site 110060) (old site 121267) in this thread

For those who have used the attachments I have provided in this thread and in (new site) thread 26192 (old site thread 102171) - BF B986162B mult print copies of UBE (new site post 92300; link http://www.jdelist.com/vb4/showthre...2B-mult-print-copies-of-UBE?p=92300#post92300) (old site post 102978) (in one way or another) I have a couple of updates, both related to F986110.

Firstly I changed the the JDE triggers on the table to fetch the row from the F986110 as not all fields are necessarily populated. This made the whole process work better.

Secondly, after upgrading to E9.1 and TR9.1 (which included new machines) we were receiving the following error in our logs and one UBE was printing twice, this error also seemed to be preventing some debug log detail to be recorded:

KNT0000106 - JDENET_ReceiveMsg failed. Error = 11

This has been investigated over a number of months, including with Oracle Support (and Development). Oracle Development replied with a comment to the effect that system tables (which includes F986110) should not be modified, which includes adding JDE triggers.

Using a custom debugging NER and Table, I found out that the F986110 JDE trigger was running twice before before the UDC was updated (this will make sense if you have followed the detail in the attachment to my post 21267 in this thread) and thus the UBE was printed twice. This situation, I believe, also caused the error above.

I believe that the increased speed of the new hardware and not the modification (added JDE Triggers) to the system table caused this problem. However, to avoid both the problem itself and any other issues that may cause Oracle to baulk at providing assistance in the future, the method of printing of UBEs on completion has had to be changed. The method of skipping the printer selection screen remains the same.

The new method is in test at the moment and looks like it will go into production soon. It uses the standard (new) JDE default printer functionality. The enterprise server JDE.ini and web server JAS.ini files are updated to print immedediately. This is an all or nothing option, so all UBEs will print on completion. However, using the default printer functionality, only this UBEs that are needed to be printed on completion have a real and valid printer. The default printer allocated to *ALL environments, *PUBLIC and *ALL UBEs does not actually exist and so will not print.

The only problem is that called/child UBEs inherit the default printer from the calling/parent UBE and so any default printer set up for the called/child UBE is ignored. This is a problem if the calling/parent UBE is not to be printed but the called/child UBE is to be printed. As all our printing is channeled through Create!form this problem is remedied using Create!form.

The default printer search is done in the following order (I did not test the order including the environment):

1) UBE, Version, User
2) UBE, *ALL (all versions), User,
3) *ALL (all UBEs), *ALL (all versions), User
4) UBE, Version, *PUBLIC (all users)
5) UBE, *ALL (all versions), *PUBLIC (all users)

If you are on Version 9.1, I am wondering why you are setting the jde.ini setting for print immediate and not just setting it at the version level. I have a client where they were running multiple versions of the pick slip which would print immediately and to the proper printer. This was accomplished by setting the "Print Immediate" flag at the version level. The jde.ini file did not need to be changed for this.

Also, I solved the challenge of child UBEs inheriting default printer settings from the parent by adding some code in the Do Initialize Printer event in the child and using the data in the Default Printer table to get the child UBEs to print on their default printer. If this is of any interest I can post this little solution.

Scott,

Thanks for the information.

I was aware of the print immediate at the version level, but, if memory serves me correctly, to change that it requires a check out - change - check in for each version. For that we need to go through our change management processes - even though it would probably involve only one off changes. It is easier and simpler to have the printing set in one place.

With regard to the inheritance of default printers, I am interested in your solution. There are a couple of standard UBEs that we want the child to print and not the parent. These I probably won't change. But there are a number of custom UBE's to which I would like to apply your solution. So I would appreciate it if you could post it.

Thanks Peter and Sean for sharing your "Print Immediate" solutions. It turns out we are using Sean's modifications at my client. It's been in place for several years and works just fine.

However, a warning: One thing to watch for with the custom Print Immediate(ly Afterward) modification is that it will interfere with any "Do Initialize Printer" Event logic you might put into a UBE to dynamically select printer output.

It seems the reason is that when the UBE runs, JDE is treating it as normal (non-PI) - just generate the PDF and write it to disk. The "Do Initialize Printer" event may execute, but is ignored because no output is being sent to printer at this time. Moments later the job finishes to "Done" status, the F986110 NER Trigger picks it up and submits it to the printer defined in F986167. Therefore, dynamic printer selection done within UBE NER is lost.

The workaround is simple enough: Create a version of your UBE with the normal "Print Immediate" option enabled in OMW. Now the job will print immediately to the printer set in "Do Initialize Printer" Event. Then you will want to remove any "PI" records in F986167 that would lead to double-printing the report.

I'm going to quote something for effect, because we were recently bit hard by this issue when we attempted to upgrade to 8.98.4.14:

system tables (which includes F986110) should not be modified, which includes adding JDE triggers.

Click to expand...

DO NOT apply JDE NER Triggers to F986110 or any other system tables in the F9x range. Oracle Support told us the same thing that they told peterbruce: just don't do it.

There are optimizations in newer versions of the JDE toolset that use special JDE kernels for processing system table IO. These kernels ARE NOT capable of executing BSFN logic and you will run into problems just like we did. In our case, our Print Immediate mods quit working all together.

We are scrambling to find a workaround for our new-found "Print Immediate" issues. There are several I've seen here that could work.

Thanks peterbruce for your updates.