Idem Piere Fitness e

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

http://wiki.idempiere.org/en/AulerSipel

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

any comment or feedback over the content of this material can be emailed to me at [email protected] or [email protected] or

[email protected]

Copyright (C) 2015 Redhuan D. OonPage � of �2 45

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

mailto:[email protected]



iROSES iDempiere FitNesse!!!!

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


sponsored by

BANGLADESH


!Table of Contents!!

Oversight! 6! Try the examples now! 6!

Something About Me! 7!

Best Open Source Application! 9!

Importance of Testing! 10!

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



!!!

!!!

Direct Sales Lead Time! 39!

Putting It All Together! 40!

German Localisation ! 41! Manufacturing! 42! Warehousing! 43! Point of Sales! 44! Mobile Apps! 45



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 - [email protected]


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

http://red1.org/adempiere/viewtopic.php?f=28&t=1813



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


iROSES iDempiere FitNesse4. 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.!!!

!Copyright (C) 2015 Redhuan D. OonPage � of �8 45


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.



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


http://red1.org/BlackPaper.pdf


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 !


http://wiki.idempiere.org/en/Fitnesse.HowTo

http://wiki.idempiere.org/en/Fitnesse.FixtureReference


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


iROSES iDempiere FitNesseAs 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!


http://idempiere.atlassian.net/browse/IDEMPIERE-2860

http://wiki.idempiere.org/en/Plugin:_FitNesse_RollBack


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* | |



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



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


http://wiki.idempiere.org/en/NF001_Fitnesse_Integration

http://red1.org/DocBook


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


iROSES iDempiere FitNesseNow 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 |[email protected]|!|Password|@random_string(aaa,6)|!|Phone|@random_number(,,8)|!|*Save* | |!!|Roll Back|!|*RollBack*|TRUE|!


iROSES iDempiere FitNesse!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.



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

!



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




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

!!!



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



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



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

!!


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


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.


http://sourceforge.net/projects/red1/files/PurchaseForecast/

http://logilite.com/budget-journal-enhanced-budget-module/


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

!



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.


https://sourceforge.net/projects/red1/files/PurchaseForecast/

http://sourceforge.net/projects/red1/files/p2/Budget/


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



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 R e a d R e c o r d o f M_ForecastLine to check any of the actual results. Again when run, should just t a k e s o m e e x t r a 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.



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

!!



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 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.



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 c r e a t e d p r o v i n g t h e P O ForecastLine exists.



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



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.


iROSES iDempiere FitNesseThe 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.!



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 d i f f e ren t mode ls . F i r s t l y 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!



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 Ruiz’s @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!



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 pass ing o f pa rame te rs f r om in i t i a l 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.



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 u p l o a d e d i n t o m y 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.




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>



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.)!

!!!


http://red1.org/adempiere/viewtopic.php?f=45&t=1775&p=8691#p8691


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

!!



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

!!



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

<in progress>


Idem Piere Fitness e

Documents

Transcript of Idem Piere Fitness e