!

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
SAARBRCKEN, GERMANY. THIS IS THE LINK TO HIS CONTRIBUTION HTTP://WIKI.IDEMPIERE.ORG/EN/AULERSIPEL HEIL THIEL!

iROSES

iDempiere FitNesse

iDempiere FitNesse!
Testing Framework for ERP Software Excellence
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 6, 2015!
version 0.7 !
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-39).!
Much gratitude to Zeeshan Hasan, of SYSNOVA, Bangladesh, for
his unwavering long term support.!

!
!

RED1s 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 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

!
!
!
!

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 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

!
!

Table of Contents!
Oversight!

6!

Try the examples now!

6!

Something About Me!

7!

Best Open Source Application!

9!

Importance of Testing!

Features!

10!

12!

My Roll Back Improvement!

13!

Create Record Auto!

14!

Handling Info Window!

15!

Developer User Guide!

16!

Developer Setup!

16!

Create A New Test!

16!

Roll Back Or Commit Option !

19!

Read Record!

20!

Location of Fixture Story!

21!

Location of Source-Code!

21!

Ready-Made Test Suite!

22!

Quick Test!

22!

Test Cash POS Order!

23!

Run Process!

24!

Assert Record!

24!

Assert Variable!

25!

Forecasting!

26!

Reusing Forecast Model!

27!

Forecast Menu Structure!

28!

Sales Plan Info Window!

29!

Testing Budget to Sales Forecast !

30!

Purchasing Forecast Info Window!

31!

Testing PO Forecast to PO!

32!

Testing Sales Order to Forecast!

33!

Testing Forecast Model Processing!

34!

Testing Delivery Lead Time!

35!

Testing Qty Balance!

37!

Testing Reversed Balance!

38!

Page 4 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

!
!

iDempiere FitNesse

Direct Sales Lead Time!

39!

Putting It All Together!

40!

German Localisation !

41!

Manufacturing!

42!

Warehousing!

43!

Point of Sales!

44!

Mobile Apps!

45

!
!
!

Page 5 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Oversight!

Try the examples now!

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

(A) Install org.idempiere.fitnesse.fixture_< timestamp >.jar and

org.purchasing.forecast<>.jar in your idempiere-server OSGi
console.!
(B) Replace FitNesseRoot into your /fitnesse/FitNesseRoot location.!

!
To learn more, follow and ask in my forum: !
http://red1.org/adempiere/viewtopic.php?f=28&t=1813 !

!
!
THIS WORK IS ALREADY SPONSORED BY !
SYSNOVA, BANGLADESH!
If you wish to give more to me and my 15 yr old son traveling around the world in
pursuit of freedom and happiness, adventure and knowledge, here is my PayPal
account - red1@red1.org

Page 6 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 sheriffs 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 me 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 7 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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
shouldnt 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 8 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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, theres 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 9 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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. Making new tests on my new modules has resulted in many errors found.!

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 10 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 ones 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 !

Page 11 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 12 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 13 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 14 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 15 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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!

Lets 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 16 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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

Page 17 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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. Lets 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. Lets 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! Lets 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 18 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

!Roll Back Or Commit Option

iDempiere FitNesse

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 19 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 20 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 21 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 22 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 Partners 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_Orders 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 23 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Run Process!
The next testing task in the page is Run
Process which will Complete the POS Sales
O r d e r. S e e h o w s i m p l e i t i s . T h e
*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. Lets 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 24 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 25 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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: <EVENT VALIDATOR FOR SALES ORDER TO GENERATE PURCHASING FORECAST> .. 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 26 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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. LeadTime is calculated from the product vendor DeliveryTime.!
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. It can be removed 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 27 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 28 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 29 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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.!
!include -c TestLoginGardenAdmin!
!|Read Info Window| !
|*InfoWindow*|Generate Sales Forecast|!
!|Run Process|!
|*ProcessValue*|GenerateBudget2SalesForecast|!
|*Run*||!
!|Roll Back|!
|*RollBack*|TRUE|!

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 30 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 31 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Testing PO Forecast to PO!

!include -c TestLoginGardenAdmin!

!
!

!|Read Info Window| !

|*InfoWindow*|Purchasing Forecast|!
!|Run Process|!
|*ProcessValue*|InfoForecastGeneratePO|!
|*Run*||!

!|Roll Back|!
|*RollBack*|TRUE|!

!
!

!
!
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
InfoWindows 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 32 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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
up of C_Order and
C_OrderLine, so these two
tables are populated and
processed respectively.!

!
!
The C_OrderLine taking the
parent ID from the table above,
C_Order
via
the
@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 33 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 parent ID. Thus mixing with
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
Purchase Orders. !
Page 34 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Testing Delivery Lead Time!

Continuing from the last section, 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. This is the most complex test in the series to see if
everything holds through such rigorous activity. Finally the tests runs and below is its outcome. !

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 tests, I detected many errors in my code of not setting the
mandatory data well or missing conditions. After fixing that in my modules, the test
confirms back everything is in order.

Page 35 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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. !
Yo u c a n c h a n g e t h a t
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 36 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Testing Qty Balance!

As one of the requirements is also
to check the balance quantity from
outstanding orders where Sales
will add to the Purchase Forecast
and Purchases will reduce it. The
last two tests in one allows some
mixing of models to black box test
such assumptions over those
different models. Firstly a
straightforward test with a Sales
Order of 1 combined with a

Forecast of 3, to see the balance needed to be

ordered or purchased increased to 4. !
The Lead Time also holds intact
throughout. !
Go try it yourself. See if you can
beat my time of 0.951 secs that
I took for this test!

Page 37 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Testing Reversed
Balance!
It is good to test if a combination
of models act in concert will the
code break. Since there are two
ways to create Forecasts, and
two type of Orders, we are trying
both combination together with
the first one above and here is
the second one where we try a
Purchase at the same time with
a PO Forecast and then see if
will decrease to 2 instead of 4.
The same test is easily reused
by changing Standard Order
to Purchase Order using the
power of Carlos Ruizs @Ref=
parser without looking up what is
the exact DocType ID to use.!
Here it is at a blistering 0.777
secs!!
The final result at the bottom showing the
expected balance of 2. That is, a Purchase
of 1 similar item, together with a Forecast of
3 has resulted in 3 - 1 = 2.!
The final Purchase Order generated is thus
ordering a further 2 of the item, together with
the earlier Purchase Order of 1.!
Again, try it yourself and see if you can beat
my record of 0.777 secs!

Page 38 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Direct Sales Lead

Time!
This final test is a repeat of the
SalesOrder to Forecast test but
with more stuff in it to play with. !
Here the normal Sales Order
triggers the Event Validator to
create a PO Forecast that is
eventually processed into an
actual PO with lead order time
accounted for.!
Note the 0.5 secs it took!!
!

The successive reading of records allow the

passing of parameters from initial
C_OrderLine table to the ForecastProcess
table whose ForecastPOLine_ID was
obtained and used to track down the created
Purchase Order, thus proving the correct
working and linking of reference IDs to the
process tab of the Forecast Model.!
Do understand that all these tests are
progressive for eventual bug scenarios as
sometimes it is harder to find the bug out if
too many things are tested at the same time.
You can always use the theory of elimination
to isolate a single action that may be the
culprit. Shuffling scripts around can also help
understand if a code is acting prior or after
the fact. But remember also the actual fun
and power of solution is in the source code
itself but at least these tests let you have a
fast grasp to pin point at almost an instant.

Page 39 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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. !
If you are a newbie to
Wikimedia style usage
you have to Google to
find out. Here on the
FrontPage is already
links at the bottom to
show you examples
how to setup tests.!

!
!
!
!
!
!
!
These test scripts can
be collected in one
folder, FitNesseRoot
from my SourceForge
repository at http://sourceforge.net/projects/red1/files/Testing/. Then replace this in your
iDempiere / fitness / FitNesseRoot folder.

Page 40 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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.!
<in progress>

Page 41 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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 !
<in progress>!
(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 42 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

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.!
<in progress>!

!
!

Page 43 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Point of Sales!
The prevalent popular or preferred POS system undergoing continuos integration works
to iDempiere is from Openbravo POS fork of Unicenta. !
<in progress>!

!
!

Page 44 of 45

Copyright (C) 2015 Redhuan D. Oon

iROSES

iDempiere FitNesse

Mobile Apps!
There are quite a number of mobile apps emerging stronger such as SpinSuite Android
and iUIMobile!
<in progress>

Page 45 of 45

Copyright (C) 2015 Redhuan D. Oon