Select Page

Tips, tricks and traps to create your JD Edwards BI Publisher documents

Every ERP system implies communication with third parties: Prospects, customers, employees, suppliers … These communications are materialized into documents such as invoices, purchase orders, delivery notes, statements …

These documents must meet two main criteria: firstly, they need to contain all relevant information, specific to the business and process at hand. Secondly, this information needs to be shown in such a way that is relevant and easily accessible.  This ensures the design and presentation of the document are in line with the image the business wants to convey.

To achieve both objectives, specific software is used to create and format these documents. For JD Edwards, BI Publisher has been integrated into the technical stack allowing you to take advantage of the templating technology provided by BI Publisher. You can find more information here.

Because it is a visible and tangible output of your ERP solution, it warrants specific focus in all stages of a project. In what follows, we present some best practice recommendations based on our experience.

Treat it as a  project within the project

Sometimes output documents are considered an extra step at the end of configuration. If this is the case the resulting documents will often not meet the expectations of the business. As in any project, it requires interaction between the business, the application consultants, and developers. Each step builds on the previous, so even the smallest changes can have a big impact.

We recommend you formally plan the following steps as soon as possible within the project.

  • Define responsibilities. A RACI chart will not only be very useful in clarifying roles but will force you to write down all steps required.
  • Define and agree design principles (more on this later)
  • Identify early information required. Often this needs development to include the required information in the XML file on which the template will be based
  • Establish change control as part of the process. The impact of last-minute changes to a document needs to be evaluated before undertaking it.
  • Keep a record of all issues and changes happening. It will help create a knowledge base to improve your process and establish lessons learned.
  • Define test data as part of the document design. This serves a double purpose:
    • Ensure no information is missing from the design
    • Facilitate testing, evaluation, and sign-off.

Define and agree a global design

A technical design agreed with all stakeholders and actors in the process, is crucial in streamlining the process and achieving a result that will satisfy business requirements. Some of the key questions to consider are:

Will the documents feature barcodes?

Barcode fonts need to be available in all environments where documents are generated. Several barcode fonts are available, so choose a font and agree to use the same one throughout the company ensuring consistency.

How to process different customer languages?

Unless you publish all your communications in a single corporate language, you will need to present documents in the customers’ mother language.

First, make sure customer language data is clear and available in the customer record. What about item description translations?

Do you want a single corporate document, design, and content?   but it simplifies governance and facilitates the use of a single design. Alternatively, you might choose to create a different template for each language, usually based on an initial corporate language template. The challenge is that any change will have to be repeated in all templates to protect the universal design. An obvious risk is that templates will start to diverge sooner or later.

If you opt for a different design for each country, then only the latter approach makes sense.

What type of paper will you use?

BI Publisher can use blank paper and incorporate logo’s, graphical design features, etc. In most cases, this is preferred as the pdf document will have a life of its own without being printed, in electronic communication, archiving, etc. Therefore, letterhead stationery with a preprinted logo is not required and not recommended.

But what about terms and conditions, an essential element in communication with customers?

Sometimes, pre-printed stationery and relevant documents use the appropriate paper when printing.

To embed terms and conditions in the template, you can either opt to include the full text in the template or use a sub-template. The sub-template(s) need to be available in a single location, accessible for all (business) users that define and manage terms and conditions. Both choices increase the complexity of the template significantly. It can be challenging to fit all required text in a document.

Your choice will depend on your own business practice and requirements: for instance how many languages are actively used.

Document Design

Lastly, some considerations on the design of the documents itself.

  • RTF templates are usually built-in Word. It is recommended that documents are also designed in Word. This will not only facilitate the template creation but also use a design that is achievable with the tool at hand. Defining a document in Excel, which is then printed “fit to page” offers no insight on which font size to use, proper scaling of logo’s, etc. Likewise, an image of an existing document will be impossible to reproduce exactly and would require a lot of trial and error.
  • If a graphical design carter exists in the company, make sure it is known and available to the team. It can provide guidance regarding fonts, colors, how to use the logo image and positioning, page orientation, margins, colors, etc.

Do you agree? Did we miss anything? Please let us know your feedback and we will respond.

Contact form

Consent

10 + 11 =