Oracle EBS R12.1.3 Submit Request Delivery Options Button – Fax

Today we’ll tackle the Fax Tab

This tab allows for the delivery of the report in question via fax. Users are able to specify:

• Fax Server – The IPP server to use that has fax capabilities.
• Username – Some IPP servers require authentication, this field allows for the passing of a username.
• Password – Use this field to specify the password for the username entered in the previous field.
• Fax Number – Where to actually send the Fax!

Configuration
The fax functionality implemented via this tab utilizes IPP to communicate with a fax modem. Essentially you are setting up a printer that communicates with a fax modem. Oracle recommends the following setup:

• CUPS – Common UNIX Printing System to manage the IPP communication.
• efax – This is a piece of software that will communicate with a fax modem to send documents.
• FAX4CUPS - This is a piece of software that bridges the gap between CUPS and efax. FAX4CUPS exists on the system as a printer.
• Fax Modem – Similar to the modem you used to dial into AOL, Prodigy and CompuServe, but is specialized for faxing.

Once the above hardware and software are working, Oracle EBS needs to be configured so that it knows what Fax Servers are available. This is done in the same way that the IPP Print tab was setup with one addition. In the screenshot below you must check the box to enable the IPP Printer for Fax.

Follow this navigation path to access this form: System Administration Responsibility -> Delivery Options. Detailed information about each configuration item can be found in Part 2 of this series.

Functionality

In the end, once you have all of the software and hardware components working, the flow from Oracle EBS is as follows:

User submits document, a concurrent request is run.

For each Fax Number that the User Specifies:
a. The Output Post Processor communicates via IPP to CUPS and says that it has a job for the FAX4CUPS printer. If this communication is successful the Concurrent Request completes successfully.
b. CUPS gives the FAX4CUPS printer the document to send and the fax number.
c. FAX4CUPS communicates with efax and tells it to send the document to the fax number.
d. efax sends the proper commands to the fax modem
e. The fax modem connects to the fax number and sends the document.

As you can see in (a) above, once the Output Post Processor hands off the job to CUPS successfully, the rest of the process is assumed successful. This status indicator does not account for the actual status of the fax transmission which could be subject to a host of issues such as fax busy signals, invalid/wrong fax numbers, no dial tone, transmissions getting cut short etc…

Note that there is no bursting functionality associated with this form. What you set for your report parameters is what is going to be sent to the fax numbers in the list.

Pros and Cons
To me, the most important thing to consider for the pros and cons of this functionality hinges on 2 factors:

1. Volume of documents that need to be delivered.
2. How critical the documents are to the business.

For instance, if you need to deliver a low volume of one off documents and can manage exceptions manually, then this solution gives you a great way for your users to take control and stop walking to the fax machine.

However, if you need to deliver a high volume of documents and need an audit trail of what has actually happened with those documents then you may need a different solution that enables:

1. The ability to burst.
It’s important to note that this form only applies to one off transmissions to single fax numbers. That means that if you choose a range of invoices across multiple customers and you choose to use this functionality to fax the data, ALL of that data is going to the fax numbers specified (meaning customers will see each other’s invoices!). In the past I have blogged about BI Publisher’s bursting functionality that can aid in enabling this functionality.

2. The ability to determine the true status of the fax.
A fax can fail to be transmitted for a lot of reasons. The line could be busy, a person could answer the call instead of a fax machine, the connection could drop halfway through transmission, the number could be plain wrong, no dial tone or just no answer at all. Ideally you want a solution where your USERS can manage these exceptions instead of calling up a system administrator. The only way that users will be able to manage these issues is if they have visibility into the status of the documents and a way to correct the problem.

3. A queuing mechanism.
If a fax does fail for some reason, it would be nice if that fax could be retried a few minutes later automatically instead of having to send the fax again manually. Fax modems will attempt to send the document, but if it fails, it’s not going to try it again on it’s own. Software would have to manage any subsequent attempts.

4. The ability to use network or internet based fax servers.
Let’s face it, fax modem technology is old. There are much better options out there that provide better reliability, the ability to pump more faxes out of more lines and the ability to hook into your modern infrastructure (Fax Over IP, Digital vs Analog lines, Multiple Lines, etc…).

5. The ability to add more meta-data to the fax envelope. 
Information such as To Name, To Company, From Name, Document Number, Cover Page Remarks, etc… become extremely helpful in the identification of documents when an issue arises and for the professional presentation of the fax in the recipient’s hands.

So in the end, it all depends on your needs. If you’re looking for a solution that enables users to send a couple of faxes a day this functionality should suit. If you’re looking for a solution to handle some serious volume with mechanisms to handle the issues mentioned above, you might be wise to check out some alternative implementations.

So there you have it, the Fax Tab in all it’s glory. Next up the FTP tab.