iDempiere FitNesse!

! 

! 

iDempiere FitNesse! 

! 

Copyright (C) 2015 Redhuan D. Oon ! 

THIS IS AN IROSES* QUALITY ASSURANCE PAPER TO PROMOTE A 

HIGH STANDARD OF PROFESSIONAL ERP IMPLEMENTATION. FREE 

DISTRIBUTION AND TRANSLATION ALLOWED AS LONG AS ORIGINAL 

COPYRIGHT(S) REMAINS INTACT! 

! 

! 

! 

*IROSES IS A JOINT BRAIN-CHILD UNDER FORMATION WITH A HUGE 

FAN AND FRIEND, A LARGE IDEMPIERE USER AND CONTRIBUTOR TO 

GERMAN LOCALISATION, HERR ANDREAS THIEL, RESIDING IN 

SAARBRÜCKEN, GERMANY. THIS IS THE LINK TO HIS CONTRIBUTION - 

HTTP://WIKI.IDEMPIERE.ORG/EN/AULERSIPEL HEIL THIEL!

iROSES 

iDempiere FitNesse! 

Testing Framework for ERP Software Excellence 

iDempiere FitNesse 

By:! 

Redhuan D. Oon aka red1.! 

(Paper started in early September, 2015 in Mexico City, an hour 

away from Victor Perez, in Pachuka, who took offence of my 

blistering testing reviews on his Libero modules to the extent of 

removing my name from the history page of ADempiere wiki and 

putting himself in my place instead. He phoned me up on hearing I 

have landed, to say, ‘Hola soy amigo!’).! 

October 5, 2015! 

version 0.5 ! 

This paper is part of a testing series that covers many plugins such 

as German Localisation, Forecasting, Budgeting, Manufacturing, 

POS Integration, Mobile Integration and Warehouse Management.! 

It also includes an introductory operational guide to the new 

Forecasting module (pages 25-36).! 

Much gratitude to Zeeshan Hasan, of SYSNOVA, Bangladesh, for 

his unwavering long term support.! 

! 

! 

RED1’s THREE LAWS: 

Information is Free 

YOU HAVE TO KNOW 

People are Not 

YOU HAVE TO PAY 

Contributors are Priceless 

YOU HAVE TO BE 

any comment or feedback over the content of this material can be 

emailed to me at red1org@gmail.com or red1@red1.org or 

red1@adempiere.org 

Page 

2 of 41 

Copyright (C) 2015 Redhuan D. Oon

iROSES 

! 


sponsored by 

BANGLADESH 

! 

IT IS BEST THAT ANY REQUEST FOR ASSISTANCE BE MADE 

TO THE OPEN COMMUNITY OR THROUGH FORUMS. WE ARE 

MORE EFFECTIVE IN HELPING YOU COLLECTIVELY RATHER 

THAN SINGULARLY. PLEASE BE CONSIDERATE BY 

CONTRIBUTING BACK OR SPONSORING OTHER WORKS AND 

ANY OF THE CONTRIBUTORS. YOU BE APPRECIATED ALSO. 

Page 

3 of 41 


iROSES 

! 

! 

! 

Table of Contents! 


Something About Me! 6! 

Best Open Source Application! 8! 

Importance of Testing! 9! 

Features! 11! 

My Roll Back Improvement! 12! 

Create Record Auto! 13! 

Handling Info Window! 14! 

Developer User Guide! 15! 

Developer Setup! 15! 

Create A New Test! 15! 

Roll Back Or Commit Option ! 18! 

Read Record! 19! 

Location of Fixture Story! 20! 

Location of Source-Code! 20! 

Ready-Made Test Suite! 21! 

Quick Test! 21! 

Test Cash POS Order! 22! 

Run Process! 23! 

Assert Record! 23! 

Assert Variable! 24! 

Forecasting! 25! 

Reusing Forecast Model! 26! 

Forecast Menu Structure! 27! 

Sales Plan Info Window! 28! 

Testing Budget to Sales Forecast ! 29! 

Purchasing Forecast Info Window! 30! 

Testing PO Forecast to PO! 31! 

Testing Sales Order to Forecast! 32! 

Testing Forecast Model Processing! 33! 

Putting It All Together! 36! 

German Localisation ! 37! 

Manufacturing! 38! 

Page 

4 of 41 


iROSES 

! 

! 

 


Warehousing! 39! 

Point of Sales! 40! 

Mobile Apps! 41 

Page 

5 of 41 


iROSES 

Something About Me! 


There is something that you might not know about me. I am in fact one of the rarest 

certified testing expert around. Yes, I have the certificate here to prove it. So please.. ! 

! 

As you can see, it even gives me the authority to put on my sheriff’s badge. I will go and 

make one and wear it to walk around whenever there is a software failure around town. 

The CTFL may be quite some time ago and may have expired. But the last time I 

checked, the testing doctrine is the same. ! 

Anyway, what did I learn during the course before passing the exams for this certificate? 

So here it is, the few major things that surprised during the course.! 

1. Thou shall test. Would you get on board a plane that is not tested? Of course it is 

tested, everyone assumed. Otherwise it will not fly.! 

2. Testing is more expensive than development. Yes, you hear me right. Or I have 

heard the lecturer wrong. At Microsoft, there are 5 testers to each developer, and in 

Adobe, there are 20 testers to each developer.! 

3. Testing actually begins with the review of requirements specifications. Yes, again, 

you hear me right. It does not begin with the code. If something is not specified 

correctly, without documentation then what the heck are you testing the code for?! 

Page 

6 of 41 


iROSES 


4. Each testing opportunity cost should be calculated and specified. If a certain test is 

not taken what will be the cost of that piece of code failing? What is the insurance 

premium on it? If a Sales Order is faulty, how much does the user stand to lose? A 

security camera guarding a dog fails, or guarding the bank vault fails, the costs are 

different.! 

5. Do not test yourself. Yes, you heard me all right. A code should be tested not by 

yourself because you are obviously bias and prejudiced, but by another person who 

is definitely more bias and prejudiced (against you). In fact the same company 

shouldn’t be testing code done from within the company. It should be carried out by 

another third party company. Best still, if that company is a specialised one focussed 

only on testing. And out of the country.! 

So please, now, answer this question. Would you ever, ever, even think about, letting 

your software be used in your business or factory, without even having someone like me 

testing it? ! 

! 

! 

Professore Dr. Jesus Zavala Ruiz, who works on Open Source 

Software Self-Organisation Theory, here in the Chapingo 

Autonomous University of Mexico, is obviously highly impressed 

when I showed him my testing engine and the certificate above. ! 

My 15 year old son, on the other hand is not. Obviously he is 

extremely jealous because he does not possess such certification 

before. I have taken him out of school to follow me around the world 

so that he can never have the chance to possess any.! 

! 

Page 

7 of 41 


iROSES 

Best Open Source Application! 


Speaking about putting on a badge, on September 16, Infoworld, the famous IT media 

online magazine, announced iDempiere as the Best Open Source Application for, I 

quote, ! 

“Small and midsize companies have great choices in Odoo and 

xTuple. Larger manufacturing and distribution companies will need 

something more. For them, there’s iDempiere -- a well maintained 

offshoot of ADempiere with OSGi modularity.” 

iDempiere, is now declared, by an external independent source, without any commercial 

solicitation on our part, to be an outstanding high end ERP application, above Odoo and 

xTuple and within our heavyweight turf, soundly beating Openbravo, ADempiere and 

Compiere. Considering that the others are more heavily funded, with corporate offices, 

media campaigns, paid mercenaries and semi closed sources due to their so called well 

thought out business models.! 

In iDempiere we have none of the above and yet we beat them. We cannot close down 

as there is no borrowed venture capital fund to repay and no one on the payroll to be 

fired. There is no President CEO to run off with the loot. No head quarters to be bombed. 

Page 

8 of 41 


iROSES 

Importance of Testing! 


The screenshot below paints all the words needed to explain the importance of testing. It 

is an output at the end of clicking on the Suite play button of an open source testing tool 

called FitNesse that is setup for iDempiere, a free ERP software. The coloured shaded 

areas showing what went right or not, coupled with the time it takes to run each test in 

sequence automatically. The suite comprised of many tests, each performing very 

detailed step-by-step operation that will take a human hours to carry out and without 

human error. This test suite took 22.46 seconds to complete, beyond any human 

competition.! 

Yet hardly any implementors, developers and users I know involved in this complex open 

source ERP software project actually use tools such as this to conduct testing after 

every change of code or before any deployment of a copy of the system over to a live 

production instance. ! 

Some of my personal contacts in the project are also guilty and have suffered badly from 

non testing live deployment. Of course today whenever i talked to them they nod their 

heads in agreement but old habits die hard. It is better to stop all other work and go test, 

test, test.! 

Tests do not lie. They are computed out by dumb machines no doubt but they do not 

deviate from what they are programmed to do. And they do it at lightning speeds. It 

actually saves money, and disaster such as happened in http://red1.org/BlackPaper.pdf.! 

Page 

9 of 41 


iROSES 


Perhaps this image I chose from the hundreds of graphs and statistics in the Web best 

scare the wit out of some of you as to what can happen before it happens.! 

Also there is a wrong way to test which is to test what you do by yourself. You would not 

want to prove yourself wrong most of the time. Testing should also not be done within 

the same team or the same company. It is best done by an external and professional 

company or body that is measured by the number of bugs they find in your software. I 

know because i learned it while getting CTFL (Certified Testing Foundation Level) 

training and passing the exams a number of years ago.! 

Of course, having a global open source community grants us free testing all round the 

globe and round the clock. But testing costs 5 times more than developing, according to 

Microsoft closed door payroll of such personnel. In Adobe, they hire 20 testers to each 

developer. Testing is a very expensive and extensive non stop activity. Relegating testing 

to tools such as FitNesse and later incorporate it into the Jenkins CI suite is the best way 

to take testing out of one’s focus and blind spot into a strict disciplined approach that can 

guarantee better efficiency as later we shall demonstrate.! 

In this paper, I shall go through each test, to look under the hood at its source code so 

you can understand more easily and modify or improve the code to share with the 

community. This is in accordance with the FLOSS character of this project. Others who 

do not understand or able to read code might want to take their leave. It guarantees my 

job safety.! 

Reference online guide http://wiki.idempiere.org/en/Fitnesse.HowTo ! 

Reference online test script guide http://wiki.idempiere.org/en/Fitnesse.FixtureReference ! 

My modifications and test scripts - https://sourceforge.net/projects/red1/files/Testing/ 

Page 

10 of 41 


iROSES 


Features! 

The FitNesse plugins, are yet another set of amazing work from Carlos Ruiz, 

GlobalQSS, of Colombia, under sponsorship of TrekGlobal, USA. The two plugins are 

built into the iDempiere stack and can be run right away in an iDempiere instance with 

minimal tinkling. Been OSGi plugins, they can be installed, started, stopped without 

impacting the running instance. With the latest modifications introduced by me, they will 

not affect the database even, as at the end of each test, the workload is not committed. 

Thus the tests can be run over and over again and with testing data changes for end 

users to see the effect of a variety of tests on to their systems, and able to quickly 

analyse them before deployment to production instance. Values of test data and 

parameters and even target tables or processes can be easily changed by lay users with 

minimal technical or coding know-how.! 

Page 

11 of 41 


iROSES 


As seen above the page uses Wikimedia style, thus allowing users who are familiar to 

edit the contents of the page. They can change the name of the @parameter@, @SQL 

script, *Table* name, operations such as Read Record, Create Record, Delete Record, 

Set Variable, Set Doc Action, Assert Record or Variable, and determine what the input 

and output should be. The wiki style also allow remarks and guidance to be put onto the 

page for readability.! 

What is fantastic about Carlos Ruiz work is that the plugin performs all ERP specific 

processes and procedures in exact context required in the code. All that users need to 

do is just to define what they want in wiki text form without any extra testing Java code to 

be written. You can now access any table model in the database, execute any server 

process from the Java code, and modify any document in the supply chain, by simply 

typing inside the wiki and press Test or Suite. This is as English language Drools as it 

can get.! 

Different operational text blocks can be put into a single page if desired as a single test 

run. The blocks can be shifted around as one moves text around a document. Each 

page can be children of a suite for a single chain of execution.! 

My Roll Back Improvement! 

I submitted such an improvement here. http://idempiere.atlassian.net/browse/IDEMPIERE-2860. 

As can be seen from my Skype with the big man, he seems to like it. ! 

This improvement is important because without it, any tests will be committed to the database 

and will affect the data test plans which is already fixed and assume a clean database. It will 

require constant restoring of the database back to run the test set again. The incorporation of 

trxName handling in most of the code parsing also opens up future possibilities. I also 

incorporate a Commit tag in case the tester really wants the test to be in database for further 

checking. Pick up the plugin to replace in iDempiere-server here: Plugin:_FitNesse_RollBack! 

Page 

12 of 41 


iROSES 

Create Record Auto! 


I also contributed a fixture code that 

allows creation of new records to be 

faster without specifying the fields and its 

values. Just by a blank line will allow the 

code to fetch the right data types and 

populate as many fields possible in the 

table. The user can still specify own 

values underneath the blank line. An 

example is given here of creating a Sales 

Order. The other fixture code remains the 

same. The result is shown below it.! 

An example of mixing lines into it to make 

it a Purchase Order is given here in raw 

text:! 

|*Table* ! |! C_Order! |! 

|! |! |! 

|c_doctypetarget_id | @Ref= c_doctype 

[Name='Purchase Order’].c_doctype_id !|! 

| C_Currency_ID | ! 100 |! 

| isSOTRX | ! N ! |! 

|*Save* | | 

Page 

13 of 41 


iROSES 

Handling Info Window! 


I made yet another useful and very important fixture method to test InfoWindow that has 

processes attached to them to process the record set it displays. By specifying Read Info 

Window, the code will take the specified Info Window, extract its SQL sequence, and read its 

database result to pass to the next fixture ‘Run Process’ to execute. This is very useful because 

a growing number of iDempiere data processing constructions are using the InfoWindow 

approach. Below is an example of it working while testing the Forecast module.! 

This script display at its first box will access the Info Window named ‘Generate Sales Forecast’ in 

AD_InfoWindow table, and access its AD_InfoProcess via the next box to execute 

GenerateBudget2SalesForecast which reads off the first box result. Below is the result.! 

The above successful read is evident as it returns the process full response dictated by the 

process code. This addition does not change Run Process script and is backward compatible.! 

The only bug I had was that the PInstance ID does not persist and so i made an incremental 

hack to track it back. For most purposes it should work and even allow to specify secondary 

process of the InfoWindow. The Read Info Window only extracts the first record and thus the 

process will always handle one line of resultset. This is sufficient to test that they work in 

accordance. The raw script is given under the Forecast Module later.! 

! 

Page 

14 of 41 


iROSES 

Developer User Guide! 


As the online wiki guide should be sufficient, this guide intends to really go into the exact 

testing scripts or Fixture stories as they are called by the FitNesse authors and trace the 

exact Java code snippets that handle them. Much can be learned and more time saved.! 

! 

Developer Setup! 

I am using my developer setup environment so that during FitNesse testing, a debug mode can 

be used to check the actual code parsing under the hood. Contributed original work can be read 

directly online from http://wiki.idempiere.org/en/NF001_Fitnesse_Integration wiki by Heng Sin.! 

Following the tutorial given and as an iDempiere developer, I can completely setup inside my 

Eclipse IDE environment. In a materialised iDempiere source-code for the IDE, you should be 

able find the two FitNesse plugins already present within the stack. During debugging usually 

they are set in lazy mode and need to be started in the OSGi console.! 

After starting they should be in active mode. Otherwise FitNesse will not connect to the ERP. 

Once that is OK, run the FitNesse engine externally by going to the ‘fitnesse’ folder location in 

the source code and execute java -jar fitness.jar -p 8089 so it can be accessed at that port 8089. 

Pressing the Suite button on the top left should give you the first screen-shot in this paper. From 

here, my tutorial shall assist with full illustration from this point onwards.! 

! 

Create A New Test! 

Let’s try by using the Create 

Record to add any record that we 

want. Let us make a new User 

record. Further below is what i 

prepared in raw text mode. It is 

clear that we need to know the 

exact Foreign Keys to lookup. 

You can access the GardenWorld 

sample database quickly by going 

to http://red1.org/DocBook and 

search for any window to get to 

its tabs’ table data. ! 

First, we have to add a new test 

to the suite. Click on the Add 

Child in the FitNesse FrontPage 

or the iDempiereSuite within.! 

For this simple testing, I choose to add within the iDempiereSuite. Later, for Forecast Module 

chapter has its own suite all nicely arranged out.! 

Page 

15 of 41 


iROSES 


! 

Set it to Test type. Put a Name as above. Do not disturb the Content value. Click on Add.! 

Page 

16 of 41 


iROSES 


Now you can click on that new link ‘Create Any Record’ to enter the wiki text. A simple way is to 

copy and paste from the ‘Create Business Partner’ page below it. As advised, I use my DocBook 

to find out the field names, and arbitrary 

values to think about putting them in.! 

So here is my starting page in its wiki 

test. Let’s give it a go.! 

Note that i added Roll Back so that the 

transaction is properly closed and any 

creation is not finally saved into the 

database, messing it up.! 

Once I clicked save, below is how it 

looks. I then can try it by pressing test. 

The bottom green coloured box at 

*Save* confirms that it works. But we like 

to see if it really does. We can use the 

Read Record to check. Let’s see what 

updated value a user record does.! 

Note also that we can have a *Commit* 

in Roll Back in case the new record is needed.! 

Here, we have successfully made a 

new wiki test page in the iDempiere 

FitNesse test engine. And the test 

works! Let’s add a read script to see if 

the test also can do so. But first when 

I checked via iDempiere login, I can 

confirm that this record was not 

created. ! 

I paste the text here so that you can 

copy and paste back to your wiki to 

try.! 

!include -c TestLoginGardenAdmin! 

!|Create Record|! 

|*Table* |AD_User |! 

|NAME |@random_string(Red1,6)|! 

|Value |@random_number(,,8)|! 

|Email |red1@red1.org|! 

|Password|@random_string(aaa,6)|! 

|Phone|@random_number(,,8)|! 

|*Save* | |! 

!|Roll Back|! 

|*RollBack*|TRUE|! 

Page 

17 of 41 


iROSES 

! 

Roll Back Or Commit Option ! 


I then test with the Roll Back option of Commit.! 

Then in the iDempiere browser, I could see that a new record similar to this test is created. ! 

The test works with the commit action to quickly create what I wanted. 

Page 

18 of 41 


iROSES 

Read Record! 


Here we try to read the virtually created AD_User even though not committed to prove that the 

testing does persist during runtime only.! 

Just look at its blistering speed of 0.026 second! Here we see that it does return the same values 

and so this test is a resounding success. Note that we get the same ID by 

@AD_User.AD_User_ID@ that fetches from same memory during testing. There is also no trace 

of the record during my own normal login to check, as its not committed. However this also 

discover a hole in vanilla iDempiere. We can get to the password! What a catch! Anyway, for 

now you can save your fixture story.! 

! 

Page 

19 of 41 


iROSES 

Location of 

Fixture Story! 

Whenever you press save, 

your fixture story is saved in 

the location of FitNesse 

folder under FitNesseRoot, 

exactly where you are to 

replace with my similar 

named folder, zipped at 


http://sourceforge.net/projects/red1/files/Testing/ ! 

! 

Location of Source-Code! 

You might want to know later during the sample suite extravaganza, where all the code comes 

from.! 

The java class names are obvious and refer to the wiki text block titles. Thus to create a new title 

is simply to have a corresponding Java class with the same name with its spaces removed. 

Notice how I did with my new class, RollBack.java.! 

Page 

20 of 41 


iROSES 

Ready-Made Test Suite! 


We shall now go through important tests within the suite created by Carlos Ruiz. His 

work is really amazing that he provides more than sufficient examples to allow me to 

pick it up rather quickly. ! 

! 

Quick Test! 

The purpose of the quick test is to make sure your FitNesse engine is working fine besides 

checking if your database is alive and responding. It also demonstrate the use of Set Variable 

and Read Record.! 

You can find the two source code Java classes that handle them namely SetVariable.java and 

ReadRecord.java. The @InventoryLevelBefore@ are arbitrary variables that you set for runtime 

reference later in the wiki script. They are not reserved or hard-coded. This is a powerful 

mechanism that Carlos Ruiz introduced to allow capturing or passing of values during the tests.! 

! 

! 

! 

Page 

21 of 41 


iROSES 

Test Cash POS Order! 


This test page is an example of an 

elaborate long test with many Java 

classes used to perform many tasks. 

First it sets variables for later use. It is 

testing for a sales of qty 2 and checking 

later if the inventory is correctly reflecting 

that from the POS order operation. In the 

next read record test, it is checking the 

Business Partner’s details. ! 

Next is the creation of the master detail 

record structure of a Sales Order. Note 

how the DoctType setting or POS Order 

is done. ! 

Also note how the first master table 

C_Order’s key ID is passed to the sub 

detail C_OrderLine_ID as its parent 

foreign key ID. The variable used is 

@c_order_id. c_order_id@! 

! 

Page 

22 of 41 


iROSES 

Run Process! 

The next testing task in the page is Run 

Process which will Complete the POS Sales 

Order. See how simple it is. The 

*ProcessValue* corresponds to the name of the 

process record. ! 


The other variables with paired values are the 

parameters to pass to the server process. 

Finally a *Run* sends it away.! 

You can now imagine any sort of process to test with this simple framework template.! 

! 

Assert Record! 

This test checks if the expected result placed in the 

box is returned correctly during runtime testing. Here 

the new order is supposed to give a grand total of 

67.50. Let’s compare the results below.! 

The earlier green boxes are bypassed as we have 

gone through such. Here we see the Run Process is 

successful with feedback of the model data set 

returned. So is the Assert Record feedback similar 

value to the expected setting. Thus its all green and deemed correct.! 

Page 

23 of 41 


iROSES 

Assert Variable! 


This last test now takes the earlier variable and assert it to the SQL that is extracting the total 

QtyOnHand from M_Storage table.! 

Here is the result shown in the page test. However before this, the assertion was comparing 

string value and thus 28 is not equal to 28.0. I gave a patch to solve it here:! 

https://idempiere.atlassian.net/browse/IDEMPIERE-2859 ! 

However Carlos Ruiz has remarked that indeed it is to test string value, and so I added a new 

fixture code ‘AssertString’ strictly for strings, and this AssertVariable be for both alphabetic and 

numerical values if they can be deduced as such during the assertion.! 

Next the rest of the page is testing the existence of spawned records such as Invoice, Payment 

and Shipment. This is all easily done by reading and asserting the associated records. This test 

page is a very informative and educational reference for any other testing to be quickly setup as 

most of the operations are covered by it.! 

! 

! 

Page 

24 of 41 


iROSES 

Forecasting! 


Purchasing Forecast is an approach to shorten the supply chain functionality in the ERP 

bypassing inventory replenishment control and manual requisition. ! 

Purchase forecasts are generated during Sales Forecast and even Sales Order when 

the plugin is active. You will get this line in the log console: ! 

INFO: .. IS NOW INITIALIZED! 

The purchase forecasts are then processed into actual purchase orders. ! 

Sales Forecast blanks can also come out from Budget Plan Details that are sales target 

type for the user to fill up details (if the Budget Plan is abstract).! 

The Forecasting module is a standalone plugin with no core table change and thus pose 

no impact or conflict to other.! 

The illustration above shows how the coloured area stands for the whole plugin, and the 

cutout is part of the underlying core that it is not trespassing on. The Budget Plan 

module, together with the Sales Forecast, Sales Orders and Purchase Orders remain 

intact and outside the plugin. The Budget plugin is also upgraded to include the 

contribution from Deepak Pansheriya - http://logilite.com/budget-journal-enhanced-budget-module/! 

If anything changes in the plugin, it does not break those outside. If anything outside 

changes it may break the plugin but that is easier to solve than the other way round. The 

plugin is small, the core is huge. Perhaps this should be my 4th mantra. The core is 

huge, you have to plugin. 

Page 

25 of 41 


iROSES 

Reusing Forecast Model! 


The Purchasing Forecast is reusing the Sales Forecast model tables of M_Forecast and 

M_ForecastLine with an additional M_ForecastProcess to handle the purchasing associated 

operations without impacting the present forecast model. The whole model is also presented in a 

new window away from the Libero Manufacturing module where it is originally maintained.! 

As seen above, the Purchase detail will reuse the Line tab, but the Process tab at the bottom will 

indicate if it is a purchasing forecast. A blank process detail means it is not a PO Forecast but 

just the usual Sales Forecast. If there is a detail as it is in this case, then it is a PO Forecast. You 

can go to the main tab ‘Forecast’ to review its header information.! 

Under the line tab, is already stating the Product, Quantity, Period and Date Promised. In the 

Forecast Process tab, will store the Purchased LeadTime which is partially hidden to the right 

side of the row.! 

The Forecast Process tab also keeps track of the origin of the Purchase forecast such as 

whether it is from one of these: Sales Order and OrderLine, or Sales Forecast and ForecastLine. 

In this case it is from a Sales Forecast. (The Forecast column is quite redundant as it is a repeat 

of the main tab. It can thus be easily hidden using the Tab Editor. I will remove it in the next 

upload commit.)! 

The Forecast Process tab also keeps track if this PO Forecast has been processed, together 

with its generated Purchase OrderLine reference ID. ! 

! 

Page 

26 of 41 


iROSES 

Forecast Menu Structure! 

You can find this new Forecast Model under the Forecast 

Orders menu (after packing in ForecastWindow.zip or 

installing the plugin - org.purchasing.forecast.jar). Here 

on the right, is the menu below alongside the Budget 

Sales Planning. Note the last item in it, Generate Sales 

Forecast is associated with Forecasting and so will only 

work if the Purchasing Forecast plugin is also active. If 

the Generate Sales Forecast is not used, it is of no 

requirement to either modules to be present at the same 

time.! 


Purchasing Schedule is an Info Window that reviews the 

Purchasing ForecastLines and allow its selection to be 

processed into Purchase Orders.! 

The first item, Generate Purchase Forecast, creates PO 

Forecasts from Sales Forecasts. The 2nd item, Generate 

Purchase Orders creates POs from PO Forecasts. This is 

basically the main purpose of this module. Sales 

Forecasts to PO Forecasts to POs.! 

The POs are also consolidated according to similar 

vendors supplying those product items defined in the forecasts.! 

Below, next page is the Generate Sales Forecast Info Window. It goes through the Budget Plan 

Detail lines to sniff out those that are sales targets and display them for further action. That 

means those that have isSOTrx field set to ‘Y’ and the Accounting Element field empty. Those 

budget details, you have to create them and ensure that they possess Product, Qty, and Period 

values to be flagged for display in the InfoWindow.! 

Once they are selected, they can be processed into Sales Forecast lines under a single forecast 

header.! 

Note that in the Budget module, there is a Budget Configurator that you have to setup. You can 

refer to the Budget.pdf at http://sourceforge.net/projects/red1/files/p2/Budget/! 

Note also the Import Budget Plan. You can run the File Import Loader and load up 

BudgetTestImport.csv (same location above). Then run the Import Budget Plan. But you may still 

need to set a Sales Forecast candidate by making a new detail without Accounting Element and 

proper values as stated in the first test below for Purchasing Forecast module. 

Page 

27 of 41 


iROSES 

Sales Plan Info Window! 


The Budget Module is linked to this Forecast Module by allowing a subset of Budget Plan Details 

that are for Sales targets to be converted to Sales Forecasts. Below is the Budget Plan Detail 

Rules tab that contains sales target because the Accounting fields is blank and thus not for GL.! 

In the Generate Sales Forecast (InfoWindow) it can display this record for selection to process 

into a Sales Forecast:! 

Now it be nice for the FitNesse test to read this InfoWindow, its content, and activate that 

process button. In fact with my added improvement it does. We can now Read Info Window and 

pass to the prevalent Run Process to do so.! 

Page 

28 of 41 


iROSES 

Testing Budget to Sales Forecast ! 


Below is the raw script to make that happen. It is placed side by side with the wiki display version 

of the FitNesse interface. Note the pre-requisite information stated in the wiki header.! 


!|Read Info Window| ! 

|*InfoWindow*|Generate Sales Forecast|! 

!|Run Process|! 

|*ProcessValue*|GenerateBudget2SalesForecast|! 

|*Run*||! 

!|Roll Back|! 


When this test is executed, the resulting 

dataset from the Budget Plan line 

pertaining to Sales target is processed 

and below shows its success.! 

The process returns other information 

such as whether any of the result has no 

qty or no customer or no period (to 

gather its date promised). This will aid 

the user to go through the Forecast 

model window later to put in such 

missing details. You can change the 

Budget Plan Detail Rules tab data on 

the earlier page to see a 

different run result. This is 

very fast to execute as can 

be seen takes less and less 

seconds at each run. You 

can add another text box to 

Read Record of 

M_ForecastLine to check 

any of the actual results. 

Again when run, should just 

take some extra 

milliseconds.! 

Note that Budget Plan Sales 

Target could be a high level 

plan or general target which 

requires more exact planning at the forecast stage. From this Sales forecast, it can then be 

processed as shown before this to Purchasing forecast and so on till Purchase Orders. Thus this 

is a complete supply chain link from budgetary planning until actual purchasing decision. 

Page 

29 of 41 


iROSES 

Purchasing Forecast Info Window! 


Below is the Purchasing Schedule Info Window (labeled as Purchasing Forecast) with its 

selection criteria panel to filter further the row set data. (The contents are converted Sales 

Forecasts and so they appear as Purchase ForecastLines. Your fresh DB should not show this 

yet.)! 

Been an Info Window (created by Heng Sin and then improved by myself, Anthony Soosah, Hiep 

LeQ and others) this can be easily modified or configured under the System Application 

Dictionary (AD) as to its selection panel and column display. It also allows a selection of those 

rows to be processed by the Generate Purchase Order button.! 

Now we see again another test fixture that does the above to get the Purchase Forecast 

InfoWindow and Generate Purchase Order. Execution and results are shown on the next page.! 

! 

! 

Page 

30 of 41 


iROSES 

Testing PO Forecast to PO! 


! 

!|Read Info Window| ! 

|*InfoWindow*|Purchasing Forecast|! 

! 

!|Run Process|! 

|*ProcessValue*|InfoForecastGeneratePO|! 

|*Run*||! 

! 

!|Roll Back|! 


! 

! 

! 

! 

The above is the raw story 

script and the right is the saved 

wiki from it. A note to testers 

how to determine the Process 

value, is by looking at the 

InfoWindow’s process tab and 

copy paste the Search Key 

value there. As seen above, it 

is InfoForecastGeneratePO.! 


! 

! 

When the test is started, on the 

right is the green result. 

Page 

31 of 41 


iROSES 

Testing Sales Order 

to Forecast! 

Next we go to other ways of 

creating Sales Forecasts. There 

is a Sales Order way which is 

due to the plugin Model or Event 

Validator that acts when you 

complete it. Here is the test in 

full.! 


! 

First a Sales Order is made 

u p o f C _ O r d e r a n d 

C_OrderLine, so these two 

tables are populated and 

processed respectively.! 

! 

! 

The C_OrderLine taking the 

parent ID from the table above, 

C _ O r d e r v i a t h e 

@C_Order.C_Order_ID@ variable.! 

The Run Process completes the 

order and Assert Record finds out 

that indeed M_ForecastProcess is 

created proving the PO 

ForecastLine exists. 

Page 

32 of 41 


iROSES 


Testing Forecast 

Model Processing! 

Then there is a manual way 

through the Forecast Window. Here 

is a fixture code to create a Sales 

Forecast header and line and then 

process all in the DB. ! 

There is an additional script to test 

the Lead Time calculation which is 

basically adding backwards number 

of days set in the Product PO 

(Vendor) DeliveryTimePromised 

field, to the DatePromised in the 

Forecast.! 

Here the Vendor for a Product is 

updated by 2 days.! 

The Product PO is then read 

back to confirm the setting.! 

Here my new Create Record Auto 

fixture is used to make it faster to 

define new table tests with a blank line 

trigger. ! 

Note how simpler it is. Each table 

definition has a blank line. The detail 

line has an additional line to define the 

p a r e n t I D . T h u s m i x i n g w i t h 

conventional statements as in Create 

Record fixture is allowed and working 

as can be seen with M_ForecastLine.! 

Also note that the RollBack feature 

closes the active transaction thus 

freeing connection to avoid memory 

leak and slow performance when more 

tests are loaded into the testing suite.! 

From the initial Generate POForecast 

to PO, it is easy to add one more test, 

another Run Process to convert the 

runtime generated PO Forecasts to 

Page 

33 of 41 


iROSES 


Purchase Orders. Then reading back the record allow the PO Forecast to be tracked 

back accurately via its ID for the final Purchase OrderLine to show what is the date 

Ordered and Promised as required.! 

Below is the successful test results. ! 

Results remarks continued on the next page. Indeed, this test is very versatile, easily 

setup with no code meddling such as the case with JUnit testing. This saves a lot of time 

and I feel smooth sailing when I just add that last small process snip.! 

In fact upon running the test, I detected two errors in my code of not setting the 

mandatory data well. After fixing that in my modules, the test confirms back everything is 

in order.! 

! 

Page 

34 of 41 


iROSES 

The table is successfully 

updated for the Product ID 

= 138 (Hoe 4ft) as shown 

and then read back to 

confirm the 2 days lead 

time setting. ! 


You can change that 

Delivery Time Promised 

and view the results at the 

bottom to confirm that the 

PO created has its Date 

Ordered set backwards 

accordingly.! 

Note that the POs are 

consolidated to respective 

vendors and returned 

message of success.! 

With that we have covered 

the whole module from top 

to bottom. Every time there 

is a change, just run these 

tests on a trial version to 

get a quick instant glance if 

anything is broken.! 

Page 

35 of 41 


iROSES 

Putting It All Together! 


The power of FitNesse is the way it can package a series of tests together into a suite. Thus I 

have done that with Forecasting as shown below, marked as ForecastModuleTesting.! 

Clicking on the last suite brings you to this page. And you can press the Suite button to run all of 

the tests. However you may need to remove the Roll Back in between so that they have time to 

breathe. Running each individual one will work though.! 

This suite story folder is uploaded into my Sourceforge repository. 

Page 

36 of 41 


iROSES 

German Localisation ! 


As part of my project work is mainly in Germany with AulerSipel group of companies that 

contributed a lot to German Localisation, I am also advising a full set of tests for them to 

assist in their migration from iDempiere 1.0c to 2.1 or 3.0, where such tests are 

paramount to ensure that the ERP application performance remains secure and 

consistent afterwards. This test suite is also useful to the German community as a 

number of the plugins they developed together with me are of common need to the 

community there. These tests are also useful for the world at large as there are plugins 

that are of global usefulness.! 

 

Page 

37 of 41 


iROSES 

Manufacturing! 


Perhaps this is the most painful part that truly needs testing to work all out for. The 

Libero Manufacturing module as reviewed few times over about 5 years span by me 

personally has discovered some unfinished features and breaking code. It is an 

ambitious project trying to cover a huge span of the Manufacturing and Distribution 

horizon. It could have been better organised into more distinctively separate modules 

and and better interfaces. Another challenge is the lack of real subject matter experts 

involving in this project or publishing a good model to follow.! 

However previous tests were able to ensure certain parts of it worked according to its 

coded intent. My review and upgrading of Libero is still ongoing to make it more 

wholesome that involved me going to Denmark to get input from a turbine and truck 

body maker. More complete tests are needed as well as regressive testing to ensure 

nothing before it has been broken. ! 

I did a major renaming exercise within the code merely sticking to the Libero project 

name and all vendor or developer names are removed as namespaces. Original copy 

right and authorship is kept intact attributing to Jorg Janke of Compiere and eEvolution 

of Mexico. You can follow this progress in my forum here http://red1.org/adempiere/ 

viewtopic.php?f=45&t=1775&p=8691#p8691 ! 

! 

(As I am writing this here in Mexico, I am due to meet up with the original creator of 

Libero and Forecasting, who has called me up by phone and told me about his latest 

forecast enhancement. I shall examine that and see if this model holds up without any 

cross impact and where need be I shall adjust and take advantage of any goodies 

contained in them.)! 

! 

! 

Page 

38 of 41 


iROSES 

Warehousing! 


Orignally also under Libero, but this time Muiltimage of Slovakia under Norbert Bede has 

done tremendous improvements to it and it is now a big task to document all their work 

and setup a good testing engine at the same time.! 

! 

! 

! 

Page 

39 of 41 


iROSES 

Point of Sales! 


The prevalent popular or preferred POS system undergoing continuos integration works 

to iDempiere is from Openbravo POS fork of Unicenta. ! 

! 

! 

! 

Page 

40 of 41 


iROSES 

Mobile Apps! 


There are quite a number of mobile apps emerging stronger such as SpinSuite Android 

and iUIMobile! 

 

Page 

41 of 41

iDempiere FitNesse!

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?