Which POS?

[red1]

As you all know we got the old POS carried forward from Compiere and went through a big jump via Xpertya Spain, then Mario in El Salvador together with me in a more minor move. Then there is some big jump thru Adaxa Australia, and now we have to decide. Which POS do we want? The Adaxa POS has broken BP selection in the Xpertya's. Do we merge both? Which feature to leave out or take? Or is there anything extra to enhance within it? Or should we get back that POSterita? I am putting up a poll and also welcome replies to my questions here. You can make only one choice but you can change your vote.

Finally from here i have to create Fitnesse tests for an 'official' POS.

[globalqss]

Hi Redhuan, I prefer two options that are not present in the poll, so I comment here instead:

Option A:
- Integrate Adaxa POS fixing the flaws found (this is in my pendings for idempiere)

Option B:
- Create an integration layer with Openbravo POS

I vote for both options to be implemented.

About posterita my vote since the beginning is to deprecate it - and that was done in idempiere.

Regards,

Carlos Ruiz

[red1]

Yes Carlos, this is what i try to mean by the 'Merge' option. If you agree i will focus on 'Option A' and you can focus on the other option. Sysnova has agreed that i looked at Option A. I will study the broken part of Adaxa's POS and replace/review the counterpart workings from present POS.

[globalqss]

Excellent Redhuan, as usual I'll be in IRC #idempiere if you have questions about option A.

Regards,

Carlos Ruiz

[younex]

Hi.

Can´t find Openbravo POS on the Poll, is it missed?

Regards,
Younex

[zeeshan]

Hi Carlos,

Openbravo POS instead of unsupported Posterita would be a great addition.
How much work is involved in this?

Zeeshan

[red1]

Zeeshan,
I brought the above up with Carlos and he is tied up finishing a specific implementation on OB first before he can respond. However he welcomed if i understudy with him directly to do this. I am thinking of doing that for some time and it can hasten speed if Carlos and i pair together in the same room. It will be one-sided for a while though.

[red1]

I am ready to merge Adaxa POS on 361. The link to start to read to pick up the last discussion on it is http://sourceforge.net/tracker/index.ph ... tid=879335

[red1]

I have made some system changes to make it work on 361 AD but trunk binary (preliminary) and have submitted notes and scripts in same tracker: http://sourceforge.net/tracker/?func=de ... _id=176962

[red1]

Now the above task is quite completed. Below i attached a preliminary POS GUI testing that uses UISpec4J which is another Open Source project that programmatically test Java GUI Panels, which i successfully incorporate into Fitnesse to test our Java POS. I shall commit the code to trunk under POSFitnesse. (More notes below).

POSGuiFitnesse.gif (54.79 KiB) Viewed 3557 times

What the story script does is to pass the Business Partner field text such as by pressing a letter J will resolve to Joe Block. Then there are 2 buttons to click to order the items displayed. Then Payment button is pressed and the accounting consequence is captured. The code also try a 'Plus' click and it resulted on adding the item qty onto the first item selected. The logger also show complete cycle of the POS DocType been processed.

Thus this framework is also now viable for use through-out ADempiere such as the testing of its Main login. The code however use a POSApplication main class which bypass the Splash screen and the OKPressed check. Instead isConnected check is sufficient.

UISpec4J is very efficient as it acts according to visible object names without worry where the buttons or fields are actually located on the Java POS. The use of Fitnesse put more agility into the whole testing process.

I will document this fully and provide a guide how to extend the testing framework. This task is sponsored by Sysnova.

[red1]

The heart of the core is this code:

Code: Select all

   public Window getMainWindow() {
      cnt = false;
       final Window[] result = new Window[3];
       WindowInterceptor.init(new MainClassTrigger(PosApplication.class, new
       String[0]))
       .process(new WindowHandler(){
          public Trigger process(Window window) throws Exception{
             result[0]=window;
             window.getButton("Ok").click(); //1st window login preset to SuperUser
             return window.getButton("Ok").triggerClick(); //2nd window Client is preset to GardenAdmin and StoreCentral
          }
          })             
          .process(new WindowHandler(){
             public Trigger process(Window window) throws Exception{
                result[1]=window; //2 button pressed, with values passed from FitnesseStory script
                window.getButton(selected).click();
                window.getTextBox("BPartner").setText(bpartner);
                window.getTextBox("BPartner").pressKey(Key.ENTER);
                window.getButton("Plus").click();
                window.getButton(selected2).click();
               return window.getButton("Payment").triggerClick(); //
             }
             })
         .process(new WindowHandler(){
             public Trigger process(Window window) throws Exception{
                result[2]=window;
               return window.getButton("Ok").triggerClick(); //
             }
             })
          .run();
       return result[1];
       }

It took me a while to resolve to the above code as the exact workable syntax, while on a working holiday tour from Blackheath Blue Mountains, Australia, to Cagayan de Oro and Makati in The Philippines, back to Kuala Lumpur only yesterday.

Now i will explain the code. This main window is called from within the Fitnesse framework so that i can pass params to it in an efficient manner. The framework has to extend UISpec4J interface and override the getMainWindow as above. UISpec4J handles windows via its Interceptor interface shown above.

I set a cnt flag to fall when it is executed so that i check and refuse a mysterious repeat execution (no harm but it is irritating). In the init class, we set the GUI Panel class, in this case its POSApplication (left over from Compiere) that has a main method to call the Java POS only without the whole classic app.

There are nested inner classes, i defined according to how many successive windows i want to handle. At each window each line of code relates to each action that i wish to carry out.

In the first .process, i have to login the main dialog. By running Adempiere manually before it, setting to Store Central which carries the POS, the testing assumes the same context and so what is left for the first process is to double OK it.

The 2nd .process, using the 'selected' params from the Fitnesse wiki, which is an Oak item, will create the POS order with a Standard BP. I then test the BP field to accept a letter to auto populate the available BP in this case is Joe Block. Then i press the + sign to increase the qty for Oak. Then it is a 2nd selected item which is Plum. The Payment button is pressed which launches a pop-up and i click on its Ok button to process the POS Order.

It will go through the whole process till completion and closes the window. The accounting consequence is captured to prove the concept is complete and according to a POS DocType. The logger details are also available to prove that the POS has gone through the steps in the test.

The UISpec4J APIs were also tested to examine the visibility of objects within the POS Panel, and it is quite satisfactory as shown how we can interrogate the right buttons needed in such an efficient and short coded manner.

UISpec4J here is important because it allows proper testing that emulates the user interaction with a POS Screen without testing the code individually. It thus is a complete blackbox tester and can quickly prove the POS to be functioning within a short time, in this case merely less than 20 seconds.

Testing is not needed for the underlying Documents as they been working or tested elsewhere and here is focused on the actual and real POS interface testing.

This testing also will bring the testing of the Java client of ADempiere/Compiere into proven reach that is hassle free and quick to extend to cover any other aspects such as accessing Menu Tree and Menu bars, both already present in the arsenal of the amazing UISpec4J project code.

[red1]

While completing this POS testing framework to cover more operations i have done some research into the status of OpenBravo POS integration and here are the reference links i read:
1. http://www.adempiere.com/index.php/Spon ... ntegration
2. http://sourceforge.net/projects/adempie ... ic/3162659

I spoke abit to Carlos and Trifon who did this and Trifon told me what Carlos wrote in the thread above. He thinks 60 hours of his time can solve that, but then, what about the whole integration itself? And Carlos last advice is to check the OB latest stable source.

After checking with OB Site, i couldn't find yet the source even http://sourceforge.net/projects/openbravopos/
and so the situation does not look good meaning we may have to either continuing from the old TinaPOS as starting quite from scratch the whole integration of OB POS to ADempiere may even be a big question without the OB POS3.0 source.
I hope to do this with Manila because there are interested prospects there and they have more resources to absorb the whole works.

Any other ideas?

[zeeshan]

Isn't the openbravo POS code available at https://code.openbravo.com/pos ?

[red1]

I was accessing its mercurial path (hg.openbravopos) which turned empty. Anyway i will try that link. Thanks.

[red1]

Now i extended POSFitnesse to test for deletion of empty and normal POS orders (suggested by Adaxa as previous bug). Seems to work well as i confirmed by login in manually to check.

POSTestDelete.gif (50.86 KiB) Viewed 3498 times

Code: Select all

          .process(new WindowHandler(){
             public Trigger process(Window window) throws Exception{
                result[1]=window; //2 button pressed, with values passed from FitnesseStory script
                window.getButton(selected).click();
                window.getButton("New").click();
                window.getButton("History").click(); //
                window.getButton("Delete").click(); //deleting empty order
                window.getButton("History").click(); //
                window.getButton("Delete").click(); //deleting non-empty order
                return window.getButton("Logout").triggerClick();
             }
             })

POSDeleteLog.gif (92.65 KiB) Viewed 3498 times

Note from what we see above is that the coding can now be quite light and readable. UISpec4J also can make asserts as to displayed values, but its best to use Fitnesse to assert for higher user readability. Nevertheless this can be used entirely in classic JUnit if you like. All code is committed to SVN/branches/POSFitnesse.

[red1]

POSGuiTest.gif (62.74 KiB) Viewed 3478 times

The above is further extending of the testing suite. Now we control the plus and minus buttons in the POS. We also check the total amount displayed on the 3rd line of the table grid, which is before tax. This correspond to the figures in the Accounting Consequence.

Using this test in Fitnesse means that the tester can change the character in the B Partner field i.e. putting in 'C' will call up C & W, and 'T' should pull up TreeFarm etc. The plus minus can nett out the qty ordered for the first item and return the right total amt. The 2 buttons can also be changed to say 'Weeder' or 'Screen'.

Thus the tester can quickly affirm that the POS is working well.

[red1]

The following UISpec4J code will simulate login into the ADempiere login dialog. Therefore the tester need not preset manually. This test will key in SuperUser and System for the first dialog and in the 2nd dialog select Store Central.

Code: Select all

       WindowInterceptor.init(new MainClassTrigger(PosApplication.class, new String[0]))
          .process(new WindowHandler(){
          public Trigger process(Window window) throws Exception{
             result[0]=window;
//red1 - start of login dialog, commencing login sequence...
             window.getTextBox("userTextField").setText("SuperUser");
             window.getPasswordField("passwordField").setPassword("System");
             window.getButton("Ok").click(); //1st window login preset to SuperUser
             window.getComboBox("orgCombo").select("Store Central");
             window.getButton("Ok").click(); //2nd window Client is preset to GardenAdmin and StoreCentral
             return window.getButton("Cancel").triggerClick();
            }
          })      

[red1]

I made the POS to be slightly more intuitive on top of the good work by Paul Bowden of Adaxa and others. Take a look below and if anyone got better design ideas please let me know here. I made the Cashier name more bigger and bolder, and i replace the term "Sales Representative' as 'Cashier' to be more exact. The action buttons on the top row is also shifted around to make it more clearer for use i.e. New, Payment, History (that gives a cafetaria table name listing approach).

Also i tested the SKU and UPC barcode number input is working, and i set it as the default focus so a barcode scanner can just beam away. Solved some minor bugs along the way.

PosLook.gif (26.01 KiB) Viewed 3446 times

[red1]

There is some empty space below the grandtotal and it be good with the Payment button - nearer to the total makes it easier for the cashier eyes to follow. I am making the TOTAL font larger and stretched to take in 5 figures amt.

POSGui.png (52.77 KiB) Viewed 3443 times

[red1]

I put in some guide with fuller testing here viewtopic.php?f=28&t=1353

[jdcs]

I was accessing its mercurial path (hg.openbravopos) which turned empty. Anyway i will try that link. Thanks.

The current stable release of OpenbravoPOS is available at http://openbravopos.hg.sourceforge.net/ ... enbravopos
I wish to have it work with Adempiere as it can be installed independently.