We are evaluating Victor's Libero POS - Great work by the way.
- There is a line in VPayMethodLine :
public final static String TENDERTYPE_Cash = "B";
Should this not be "X" to correspond to cash on Adempiere.
- There is some hard coding of Spanish - I would like to change to call MSG.translate and contribute these changes back.
Hi Martin, I was doing similar evaluation this weekend. I did some sort of "reverse-engineering" and these are my findings. I'm sure they can help you.
The first task I think is to create a 2pack package with the new tables, columns, references, etc.
I see libero POS is developed using the best practices for extensions, so it seems it can be installed as an extension without disruption on core (installer just need the 2pack to add the new dictionary things).
There are just 2 core classes changed (ProcessInfo and ReportStarter, with some patch to use jasper in processes). I would advice to discuss the two changes in forums and add them to trunk if useful for everybody.
Possibly I can help also with standardization of this POS, but I'm not sure how must be the mechanism to help.
I also want to thanks Victor and e-Evolution for giving the example of openness to the rest of implementors here.
Finally Adempiere is finding the way to contribute new functionalities as extensions without disrupting core, and **e-Evolution** is the real **pioneer** on this matter: Manufacturing, Payroll, Cashflow and now the POS.
* POS_IdValidator - class to validate the TaxID - i.e.: org.eevolution.pos.LEC_RUCValidador
* POS_C_BP_Group_ID - BP groups (separated by ;)
* POS_Gender - to indicate the AD_Reference_ID of Gender
* POS_OrderType_Reference - to indicate the AD_Reference_ID of order type
* POS_M_Shipper_ID - to indicate the shipper
* POS_OtherPayments - the AD_Ref_List_ID of tender type "Other Payments" (select * from ad_ref_list where ad_reference_id = 214)
* POS_ServerIP - aside POS_ServerPort used to validate certain actions to be done just on server (i.e. add miles)
* POS_BP_Invoice - to define type id (C_BPartner.typeid)
* POS_Original - text for Original watermark
* POS_Copy - text for Copy watermark
* POS_2Copy - text for Second Copy watermark
* POS_JDBC_URL, POS_JDBC_Controler, POS_JDBC_User, POS_JDBC_Password - to establish direct connection to database (?)
* POS_BP_Type - reference for bp type
* POS_C_Country_ID - country for the city list
* POS_Activity_ID - activity to assign to the invoice C_Invoice.C_Activity_ID
* POS_C_PaymentTerm_ID - payment term to assign to the invoice C_Invoice.C_PaymentTerm_ID when the line is for credit
* POS_ServerPort - aside POS_ServerIP - create a connection to db server (i.e. credit card validator)
* POS_Milles - if zero the fields associated with miles are not shown
* POS_WatermarkSize - size of the watermark message
* POS_Number_Copies - number of copies to print on invoice
COLUMNS ADDED ON TABLES
* C_POS.C_DocTypeReval_ID (to indicate the return doc type - credit note)
* C_OrderLine.Group2 -> passed to C_InvoiceLine.Group2
* C_POS.CashDrawer - POS mode -> 0/CallCenter, 1/POS(default), 2/ReadOnly, 3/Payment, 4/Pay
Warning!! in adempiere this reference is defined:
- description (as processCodeLocal)
NOTE: they are created automatically
CREATE SEQUENCE eevolution_transaction_ INCREMENT 1 START 100000
CHANGES TO MAKE IT WORK WITH CURRENT TRUNK
* Classpath is pointing to jvm 1.6 for Mac, it needs to be changed to use the default of eclipse, or your own 1.6
* VPrintManager is using two changed methods of iText: width and height needs to be changed to getWidth and getHeight.
It is good to hear such peer review on Libero POS. Bravo to Victor Perez and his wonderful team!
I made some of the changes this weekend just to get it up and running. Thanks for your detail analysis , it will definitely help. I think you should add this to the wiki.
I will go ahead and create the 2Pack package. How would I contribute this.
Also will need to change the spanish hard coding. It will be great if Victor could review and commit these changes.
Hi Martin ,Carlos, Red1!
Thank very much to review our work , let me explain the status this contribution and the reason because we created
a new POS.
after the review and suffered with Posterita we discard this because follow reasons :
1.- Is very hard get fast entry POS in a WEB POS environment in special when the end user want use short keys.
2.- Posterita was development using STRUTS that is good framework but is complex implement usability in a WEB UI.
3.- The separation of Posterita of community.
Next we evaluate the current ADempiere POS we discard this because follow reasons:
1.- we need new functionality for Call Center that AD POS have not,even with the improves of OpenXpertia guys based on the Compiere implementation , the functionality are not enough for our requirements.
2.- The AD POS not support the advanced payment or payment with multiple payment term
So the final decision was start from zero, Libero POS was started 2 year back. the ADempiere Best Practices did not exist then we try to write the code best way, so please is not surprise us if the code need some refactor.
Also we know that did exist some static references that we are changing and replacing the spanish comment to english.
the most of the new tables were added to meet requirements our customer, currently we are removing the vertical code and we think that 2pack do not is necessary because now is fully Integrated with ADempiere core.
we started the debug and clean a few weeks ago
Now we are setup to release Libero POS as ADempiere extension. and we are work in http://adempiere.svn.sourceforge.net/viewvc/adempiere/contributions/e-Evolution/POS/ branch.
I think would be good idea to create a new tracker for this extension.
we also think in create a best documentation that we will go filling
about the technical revision:
COLUMNS ADDED ON TABLES
* M_ProductPrice.VersionNo, is not necessary my customer need have multiples price list version in same sales order lines
* C_BPartner.Gender, I think that can evaluate add this field into the contact user, in general is standard information
* C_BPartner.TypeID, indicate the Document identification , so we can add a new field to support this or use the greeting field, this field is use to identified if document identification is Passport , identity card, etc
* C_POS.C_DocTypeReval_ID (to indicate the return doc type - credit note), in Latin America is very common link the credit note with the original invoice so I think that would be good to can add this new field.
* C_OrderLine.Group2 -> passed to C_InvoiceLine.Group2, was added for vertical requirement and currently the code was removed
* C_InvoiceLine.Group2 was added for vertical requirement was added for vertical requirement and currently the code was removed
* C_Order.C_Channel_ID was added for vertical requirement and currently the code was removed
* C_Payment.C_CreditCardTerm_ID was added for vertical requirement and currently the code was removed
* C_Payment.TV_CardloggerResponse_ID was added for vertical requirement and currently the code was removed
* C_POS.CashDrawer - POS mode -> 0/CallCenter, 1/POS(default), 2/ReadOnly, 3/Payment, 4/Pay, was added for vertical requirement and currently the code was removed
* C_Order.Help, was added for vertical requirement and currently the code was removed
,was added for vertical requirement and currently the code was removed
Warning!! in adempiere this reference is defined:
I think that we can solve this add new reference type - N/CreditNote
in summary any suggestion is welcome.
Please commit the vpos.form file to svn - it is not in synce with the vpos.java file. We use the myeclipse matisse plugin to open gui classes and it requires the .form file.
how to download svn?
Log in to post a comment.