This new KM document provides details about the new enhancements delivered in Q4 of calendar year 2018 including: ERP notification enhancements, Customer-Driven ERP enhancements, and legislative/localization updates. Doc ID 2486629.1. http://ora.cl/Sa28R
The Create Payment Control Group PDF (R04570) has been enhanced to provide a better user experience. The enhancement allows Accounts Payable users to more easily validate banking information when running electronic funds transfer payments.
The enhancement includes the following changes to the PDF output of the Create Payment Control Group (R04570):
In the header portion of the PDF:
The Payment Control Group number has been added. This number is stored in the automatic payment temporary tables A/P Payment Control Group (F04571), A/P Payment Header (F04572) and A/P Payment Detail (F04573).
The Bank Account Number displays both formatted and unformatted numbers. The Bank Account Information is stored in the Bank Account table (F0030).
In the detail portion of the PDF:
IBAN, SWIFT and Control Digit Information is printed for each supplier, if applicable. The Supplier’s bank account details are stored in the Bank Account table (F0030).
Label headings for all the bank related information (Bank Acc #, Transit #, IBAN, SWIFT and Ctrl Digit) have been added.
The concept of barcode came into existence in 1948 when Bernard Silver and Norman Woodland teamed up to create the most basic system for automatic machine reading of a string of product data. Since then , there have been many advancements in the technology and till date this technology is being used through out the industries in various fields. There exist quite a few types of barcodes now. Refer https://en.wikipedia.org/wiki/Barcode#Types_of_barcodes for details. One important addition came in form of a quick response barcoding scheme --The QRCode from Denso Wave., which is a two dimensional representation of data code. QR Code provides the following features.
Recently, we have noticed many clients trying to print QRCodes using JD Edwards Embedded BI Publisher. There is already a knowledge document which provides detailed steps to implement Barcode using RTF template in embedded BI Publisher. XMLP: Barcode Encoding with BI Publisher for EnterpriseOne (Doc ID 782809.1)
This post intends to summarize few of the key points needed for successful barcode generation using Embedded BI Publisher. .
Barcodes are a representation of a string of data in a barcode font. In order to be readable by barcode scanners, data represented in barcode format need to be preceded and followed by their respective control characters(start/stop). Any string of data cannot just use the barcode font directly. The data needs conversion before symbols in form of thick & thin lines, spaces & dots etc can actually represent the original data. Only once the data is encoded and represented in appropriate font , the scanners can read and understand them as they are. Examples of different kind of encoding schemes include Code128, Code 39, Code16K and ofcourse:Qrcode
And once the font is applied on this string , you get to see the actual Qrcode
How to encode ?
You do not encode the string on your own, although, you may do so if you understand the complete encoding scheme and algorithms. There are specified protocols and standards that should be used . These are available in form of already written functions and since JDE Embedded BIP uses Java , all you need is the correct class file or a jar file.
As for using simpler codes such as code 128 a, 128 b or 128 c the job is further simplified as xdocore library has the implemented code and a simple function call does the trick for you .
For details on how barcoding is used in Bi publisher, you may refer Tim Dexter's famous XML Publisher Blogs.
From JD Edwards perspective, things are not very different as it is the same publishing mechanism that is embedded in XMLP kernel. There is one extra step though, and that is to somehow make JDE system recognize the location of third-party jar file .
Since JDE tools release 126.96.36.199, we include BI Publisher core engine (10.1.3.4.1) which has built in support for barcode 128a,b,c. Using this version or higher versions which we use now, the barcode function can be invoked directly using the following command in your RTF template:
Where FieldName is the name of the dynamic field you want to convert to Barcode 128b.
Well , it is not the one officially implemented in xdo library and hence not completely within the scope of support. Although it is possible to implement, a direct format command like shown above may not work.
So we need to switch to old methodology of prior to Tools release 188.8.131.52 era.
We need following :
A program or method to convert the data in desired encoding ( A Java class file that has method to encode the data).
A font which can be used to represent the barcode in 2 dimensions. i.e. a QR code font.
Immediate queries which come to mind :
Does Oracle Jd Edwards offer any of these above for 2D fonts? No Neither do we provide any 2d barcode font nor do we ship any font encoder class or jar file.
BI Publisher offers the ability to execute preprocessing on the data prior to applying a barcode font to the data in the output document. For example, you might need to calculate checksum values or start and end bits for the data before formatting them.The solution requires that you register a barcode encoding class with BI Publisher that can then be instantiated at runtime to apply the formatting in the template. For information, see Advanced Barcode Font Formatting in Developer's Guide for Oracle Business Intelligence Publisher. To enable the formatting feature in the template, you must use two commands in the template. The first command registers the barcode encoding class with BI Publisher. This must be declared somewhere in the template prior to the encoding command. The second is the encoding command to identify the data to be formatted.
Registering the Barcode Encoding Class You can include barcodes in form fields.Use the following syntax in a form field in the template to register the barcode encoding class: <?register-barcode-vendor:java_class_name;barcode_vendor_id?> This command requires a Java class name (this carries out the encoding) and a barcode vendor ID as defined by the class. This command must be placed in the template before the commands to encode the data in the template. For example: <?register-barcode-vendor:'oracle.xdo.template.rtf.util.barcoder.BarcodeUtil';'XMLPBarVendor'?> *where oracle.xdo.template.rtf.util.barcoder.BarcodeUtil is the Java class and XMLPBarVendor is the vendor ID that is defined by the class.
Encoding the Data Use this syntax in a form field in the template to format the data. <?format-barcode:data;'barcode_type';'barcode_vendor_id'?> where the data is the element from the XML data source to be encoded. For example: LABEL_ID, the barcode_type is the method in the encoding Java class used to format the data (for example: Code128a) & the barcode_vendor_id is the ID defined in the register-barcode-vendor field of the first command you used to register the encoding class. For example: <?format-barcode:LABEL_ID;'Code128a';'XMLPBarVendor'?> At runtime, the barcode_type method is called to format the data value and the barcode font is then applied to the data in the final output.
Registration will tell the system to look for class file java_class_name ( oracle.xdo.template.rtf.util.barcoder.BarcodeUtil.) *Any other name may be used
What should be the content of this Java class that is used during registration ?
It is the implementation of the methods that are invoked at runtime. Overall three methods are expected inside the java source of this class.
* Return a unique ID for this barcode encoder
* @return the id as a string
public String getVendorID();
* Return true if this encoder support a specific type of barcode
* @param type the type of the barcode
* @return true if supported
public boolean isSupported(String type);
* Encode a barcode string by given a specific type
Out of these three methods the encode method should be using the Vendors logic to encode data either directly or indirectly .
For demo purpose , one can create an RTF template with below contents:
Here the string http://communities.oracle.com is hardcoded string and not an xml element (you may use any xml element name ). oracle.sample.MyWrapper is the class that the system will read for encoding methods.
So the flow looks as below:
JDE XMLP Kernel--calls --> XDO Library--> invokes--->Rtf template processor-- calls --->oracle.sample.MyWrapper (class method--qrcode)----> calls-->Third-party encoder method in third party class file or jar file (e.g.QrcodeEncoder.class from IDAutomation)
You can create a file MyWrapper.JAVA by using a sample here SAMPLE1 . Modify it to import packages provided by vendor and call the vendor method . For Vendor's api, IDautomation as an example : Refer their documentation here : QRCODEIDAUTOSAMPLE
MyWrapper.java's relevant part will look something like below: Please note that below is just a snapshot and is not complete code .
Once MyWrapper.Java is saved, compile it using the same JDK as being used by your enterprise server and possibly on same platform to create MyWrapper.class file.
Insert this class file in package structure oracle.sample and place it in XDO-core.jar file on the enterprise server/system/classes folder. Also insert "QRCodeEncoder" class or related jar file((or any other vendor's class or jar file) in this same location .
This new KM document shows the steps, with screen prints, to pass a variable to override the data selection in a report using the Orchestrator Studio report option. Doc ID 2479495.1. http://ora.cl/wl26C
This new Information Center has setup/configuration documents, how to documents, and bugs related to E1 Customer Relationship Management. Plus, there's a Resources tab with links to documentation, training, Advisor Webcasts and more. Doc ID 2478849.2. http://ora.cl/jm1OH
A little known feature in SWM Case Management is the ability to bill for cases to a customer who is not set up with a warranty entitlement. The functionality is easy to enable and it allows the system to create a workfile (F4212) record that ultimately is converted into a an invoice. As with service work orders and service warranty contracts, the Case Management billable system integrates with Service Billing (48S) and Accounts Receivable (03B).
Case Management offers two billing methods:
Time and Material - captured using the Case Time Entry (P17505) application
Flat Rate - captured at the case header level in the Billing Information screen.
For a quick explanation of how the process flow works, refer to Doc ID 1487595.1, and click on the link titled "Billing for Cases".
In 9.2, the Vertex database user password is now encrypted in F7038T. In previous releases, the password was stored in plain-text in F7308, so the password could be updated manually with services down. This prevented the vertex user ID from getting disabled while the AS400 and the E1 vertex passwords were being changed to be synchronized. In 9.2, services have to be up to access P7308 and make the change to the password. However, if there is a mismatch between the password defined in P7308 and the password at the AS400 level, the AS400 Vertex user profile can be disabled. This document explains the recommended procedure for changing the Vertex password. Doc ID 2478337.1. http://ora.cl/cB7na
There is a new tabbed document consolidating FAQs and troubleshooting for Security History. The tabs include: Overview, How-To Documents, Information Captured by Security History, Roles and Security History, Security History reports, Troubleshooting / Known Issues, and Other Security History Resources. Doc ID 2476995.2. http://ora.cl/Zl04l
Managing financial commitments is a very important task for customers needing to track expenditures, either in the public or private sector. Financial commitments can have a huge impact in controlling expenses for the year and to allow budget amounts to stay on track. Often times, we see discrepancies between the commitment amounts from what is committed on the order versus the amount open on the order. There can be numerous factors that cause these integrity issues, which can be covered in another topic. This blog is to provide a best practice for managing these commitment integrity issues and how to properly fix these integrity issues.
Identifying Commitment Integrity:
To properly identify if an account has an integrity issue, it is recommended to run the R40910 (Commitment Integrity Report) on a regular basis. This report compares data from the F4311 (Open Amount) to the F43199 (PA Ledgers – Committed Amounts), as well as the F43199 (PA Ledgers – Committed Amounts) to the F0902 PA ledger amounts. This report can be ran to display all accounts, but the output of the report can be greatly reduced by setting a processing option to display only the accounts that have an integrity issue (Processing Option #1 on the Process tab). It’s often asked how often this report should be ran. There really isn’t a right or wrong answer to this question. It really depends on how many transactions are being processed that affect commitments. For some customers, running this report once a week may be sufficient, while other customers find they have to run it multiple times a day. What you want to avoid is turning on financial commitments, processing transactions for a year and then decide to run this report. Trying to play catch-up in fixing integrity issues can be a difficult task. Having recent data in the system will more likely allow for the ability to determine what caused the commitment integrity (process related, data related, etc.). All batches that affect commitments (receipts and voucher batches) should be posted prior to running this report. Otherwise, false variance will appear on the output of this report.
Fixing Commitment Integrity Issues:
Once valid commitment integrity issue has been identified, the next steps to resolve the issue is running the purge, rebuild and repost process. Most customers familiar with processing their financial commitments are familiar with this process, but as a reminder, information on this process can be found in Encumbrance Purge / Rebuild / Repost Process (Doc ID 625633.1). What I would like to discuss in this blog are best practices when running this process. First, you must decide on what data selection should be used throughout the process. Was the commitment integrity issue caused by only one document? If so, it may be best to data select on this one document in the R43199P and R00993. The issue is that the R00932 only allows data selection on the F0901 table, so the account number on the order would need to be known to complete this process. If you believe this issue may be related to many different transactions, then the account number can be used throughout the entire process. What should be avoided is running this process wide open and rebuilding and/or reposting transactions that are already correct. Another piece of advice is to double check that all of the batch applications are properly executing. Any easy way of doing this is to keep the P40230A open for inquiry during the purge and rebuild process. Once the R43199P (Purge) is ran, the P40230A should not display any records for that account or document (depending on the data selection used). These records should reappear when the R00993 is executed. You should also see the program id of the F43199 records being updated with the R00993 value after the rebuild is done. The same can be said for the F0902 PA ledger records after the R00932 is ran.
Hopefully, the above tips will help you manage your commitments. Staying on top of these transactions to ensure that the transactions are being processed without integrity issues will make life easier with this complex process. If you’re new to this process, another helpful document to review is Checklist for Troubleshooting Commitment / Encumbrance Integrity Issues (Doc ID 657403.1). And as always, feel free to interact with other users in the Distribution - JDE1 (MOSC) Community or work with Global Customer Support by opening a service request to assist with these commitment issues.
Starting with Tools Release 9.2.3 with Applications release 9.2, there is a new business function which can be used to call Orchestrations from E1 applications, B98ORCH. This new KM document explains how to implement this new object. Doc ID 2474665.1. http://ora.cl/Qd2zd
There is a processing option in Fulfillment Workbench Program (P4277701) for 'Availability Notification'. You can use this option to notify the user when the fulfill quantity exceeds the quantity available.
Valid Values are:
Blank = The system does not set a warning or an error when the fulfill quantity for this item exceeds the available quantity.
1 = The system sets a warning when the fulfill quantity for this item exceeds the available quantity.
2 = The system sets an error when the fulfill quantity for this item exceeds the available quantity.
If you have this processing option set as 1 = Warning or 2 = Error but no warning or error is displayed on the screen when the fulfill quantity for this item exceeds the available quantity, the issue may be due to the incorrect setup in P41001 (Branch Plant Constants) for availability definition.
If you are experiencing this issue, then check out the following KM document and verify if the availability definition in your Branch Plant Constants is setup correctly or not:
No Error in P4277701 For Item With No Availability (Doc ID 2358507.1)
New features for Orchestrator are available in EnterpriseOne Tools Release 9.2.3: Message Center and My Worklist composed page. Also, a new menu called Manage Notifications is available in the user ID drop-down list. This new KM document provides information and links to the associated guides for the features. Doc ID 2472426.1. http://ora.cl/BV2Ug
This new KM document provides tabs with information for: Project Forecasting assumptions, Steps Needed to Create a Forecast, Forecast Posting, and Additional Resources and Information. Doc ID 2468592.2. http://ora.cl/oK3PH