I am referring to a complaint of closed source here http://groups.google.com/forum/#!topic/ ... 4FbCR91rhI. In my opinion, one should not worry over closed code suspicion among open source projects. You just check its sources and if its not active (good sign as it may mean it is perfect software, or bad sign as it may mean no one is working with it, or they keeping their changes private), go look for another that is.
So i prefer to look at http://bitbucket.org/ghintech/posintegration and https://bitbucket.org/ghintech/unicenta. Those are open sources of Eduardo Gil's work, which he improved upon my OpenbravoPOS integration by upgrading to Unicenta (OpenbravoPOS has also gone inactive been commercially run and Unicenta seems a good active fork). You can check its commits seems to be active as there is movement even some days ago.
I just downloaded the iDempiere-side source and made a binary tested it working with its 2Pack in my Eclipse source with iDempiere latest 3.1. I am uploading the screenshots progress in next post.
The menu seems to have extra items since the last time I first did it. The Export2Queue below seems as intuitive as i left it too.
I checked its import Orders (from POS) and see that it has extra fields. I cannot find a README. I wrote Egil to give me one. If not, you can go through the source code to find out what it is doing and modify. Or you can contact him, failing which you can contact me, to work together, refactor and document a new guide. In order for that, you should be a developer or have one at your side, so you can contribute back at the same time. I will like to see that this work is properly abstracted for easy and vast use.
You have to install NetBeans in order to run UnicentaPOS from source. I am able to do that (thanks to advice from Eyog Leyonce) and below is the screenshot showing the synch buttons done in Unicenta.
After that you can deploy as binary by running the build from NetBeans. The jar can then run from command line java -jar "/usr/local/unicenta/dist/UnicentaPos.jar". I am not uploading the jar because it does not work in another location other than the one Netbeans advised above. Eyog also confirmed from his machine over in Cameroon. Try Google and follow some deployment advice https://netbeans.org/kb/docs/java/javas ... y.html#run. If anyone finds out how to deploy then tell me so we can distribute the binary easier.
Solved it! RTFM! The README said that it needs its lib folder alongside for its dependencies. zip up together with its lib folder, so here it is in the SourceForge repo.
I have also redone http://wiki.idempiere.org/en/Plugin:_Unicenta_POS page and moved the previous contents to http://wiki.idempiere.org/en/Plugin:_Wanda_POS so there be no confusion and there is freedom of choice.
I tested with latest ActiveMQ 5.9.0. The IDempiere side sending.. host is 'localhost' as my ActiveMQ resides locally same machine.
After some days of studying the bugs in Unicenta POS code, generally null failures, solved by checking for nulls, it can now show up its Products synch from iDempiere queue. Note that all products must have UPC/EAN numbering. It was the initial big bug that i finally solved by putting those values in at the iDempiere side. Also note that we need not use the Synch buttons under the Administration panel. Ghintech (Venezuela/Panama) has made an improvement to auto time. Go to the Resources item and at openbravo.properties to see the orders-minute is at 1 minute each synch. You can set it to longer.
After some days of fixing (minimizing luggage) the code to handle strictly POS, but powered by iDempiere in the rear, i am ready to commit this as entirely new forks and maintain them as such. It follows my policy of separation of concern. Let each layer does its job best - POS just capture sales, and ERP does the heavy intel. CAVEAT: My pos version is more specific to simple restaurants/cafes connected to an ERP. For higher uses, the Ghintech version will be the direction.
I managed to test the import to be intact on the ERP server side. It even consolidate the importing into a single customer header order since the last process.
I have made the ActiveMQ reading to be more meaningful. Here is a retest on already imported message to get the expected response.
(This is a pending work in progress) as menu items are ordered, it is the resultant raw material that is finally affected and the restaurant need not do the stock ordering again.
1. There is pragmatic and less transfer of info to and fro. Just sending list of Cashiers, Customers, Products, Pricings and StockQtys though sent is not important. Thus we need not keep sending stock qtys. Its integration with the ERP will resolve that via replenishments.
1.2 The ERP side receipt likewise consolidate auto-sent POS orders. What is vital are material consumption for replenishments.
3. Particularly for restaurants, the products sent are part of the Menu Engineering (using BOM template) as parent and at the server side, there will be a 'raw materials' process to convert the sold 'parents' into BOM children such as rice, sugar, flour, veg, milk, coffee, etc!
In this way it becomes a powerful full cycle ERP that makes stock-checking update redundant. The raw materials are moved to the POS virtual locator and upon process, becomes consumed to trigger replenishment as set in its reorder rules. Of course there will be inaccuracy and thus the replenishment calculation will buffer some fraction for error and atuned as time and experience goes on as to the accuracy of the menu engineering templates.
The nett effect is POS franchisees have minimal extra paper work or stock checking.
1. I have removed any core changes or overloading of iDempiere models, introduced by Ghintech. The POSIntegration is further reduced from other features added such as CreditMemo and resend Orders handling. I feel it is best handled outside the POS environment. The POS should be purely for fast and efficient gathering of POS activity. When you open POS Integration menu you will see only two simple items - Export to Queue, and Import Queue to Orders. That is it.
1.2 However we must thank Ghintech for their contribution which improve the synch from POS to MQ with automatic timer. It is now set to 1 minute in the Orders-Minute tag in the Openbravo.properties. This looks practical because at POS side, the users might be lazy or too busy to manage sending back orders. But i am not taking their Cash Closing back to ERP. Let those be handled at POS stations respectively. ERP should be just to gather total sales, (nett with refunds) and credit totals. I weigh this against the sheer need of maintanability. Usually developers overload code and leave them badly commented or designed. In the end, we ended up with lots of time wasting and even lost of productivity. I prefer things to remain as unperturbed, elegant as they are. This integration is purely to fulfil 80% of the biggest needs and leave the rest to workarounds or localised extensions.
Previously the same happened in Cameroon when i taught there and introduced my Openbravo POS integration for them to improve. Their WandaPOS ended up adding on Android interface that began to bog down and became unwieldy. So it is no surprise they do not make the light of day. If there is any specific important feature set to add on it should be a separate regime for the sake of sanity.
1.3 I also simplified the Import to Orders. First there is no longer going thru the I_Order stage. Synch back is done directly to Sales Orders. I also consolidated similar Customer headers. Walk-ins will be bunched into one big Standard Sales Order at every synch. If you do not synch for whole day and synch only once, you will find your your POS sales in one single huge order for per POS Locator. That should be fine, because HQ are not expected to micro manage and POS locations still keep their respective details.
2. I done my best (and still improving when there is new discovery) to avoid technical mistakes during use. For example if there is sudden outage and breakdown and some orderlines are duplicated, the ERP side will detect them and avoid rewriting the same lines.
3. Intending for simple multiple cafes setup, I am a fan of WebServices. I am very impressed with Apache Active Message Queue, as it is very light to setup and stays alone on the cloud. This makes both the POS and ERP side out of the grid. It is simplistic, minimalist and asynchronous, which should be a favorite in remote areas. I also reduce the payload of each XML packet. This is very elegant to me. The Active MQ is just a post office that you drop your packages and forget. On your ERP side, you do not get visitors. They do not call you, you call the post office up to get your mail. And its only one way. I am also dropping the sending by POS of new customer and cashier details. I feel they can be sent separately to ERP thru other means. Leave POS to do what it does best. Learn from Larry Ellison's folly with the Sun/Oracle Thin Client project which crashed due to Larry's constant adding on. In fact, Eduardo Gil of Ghintech complained to me his clients in Panama is getting more bogged down and they are moving towards web-services. He told me he will publish his soon and i will provide links to it.
So i hope users will differentiate between this and Ghintech's that resolves much accounting needs of big malls and Latin America fiscal printing control. We still work closely together sharing ideas and agreed to focus on separate but complementary ends.
7. ERP: Import Queue Orders anytime daily.
Now you can open your Sales Orders to see the results.
Bravo! You got awesome centralised control of all your POS outlets.
Below is a movie explaining the above.
Next i will make the raw material consumption analysis for a whole supply chain to automate and save big money for a multiple restaurant chain operations. This process will complete all those imported Sale orders, calculate nett quantities, explode their BOM children consumption and issue out replenishment orders.
Latest: As promised, I have done a simple but effective plugin to resolve restaurant kitchen supply management http://wiki.idempiere.org/en/Plugin:_AutoBOMOrder.
In order to make use of it together with POSIntegration, define the restaurant menu items as BOM products where the raw ingredients are the store materials that are sent from the central HQ, i.e. flour, rice, sugar, bread, meat, fowls, dispoable containers, etc as its BOM children.
Later i will post a set of Excel CSVs for users to map their products, prices, BOM relationships easily and get them imported quickly into the database.
In order to import in a list of new products and in BOM format to fit the restaurant supply chain cycle above, here is a movie showing my latest shortcut using CSVs.
Bring the csvs into your Excel and replace with your own Product Data. Follow the instructions clearly.
Note that the tool is intelligent, as it will try to Update first before Insert. Results log in the Description of each Module Creator record will say how many lines in the CSV are Inserted and Updated.
If you wish to update information, make sure you use its 'Name' column. If not, arrange for its first two columns that you wish to be the unique key set for the WHERE clause. You may append more columns of information at the back of any CSV, and they will be updated without worry.
Use your originating Excel spreadsheet with reference data sheets normalised to exact iDempiere ERP database models is probably the fastest way in the world to migrate all your legacy data.
Fetch the sample excel here http://sourceforge.net/projects/red1/files/Utils/ (ProductMigration.xlsx). Put in your own legacy data. Export to CSVs. Truncate the trailing suffix -Table-1. Zipped up and in iDempiere, attach to a Module Maker and GenerateModule, shall import the data into working iDempiere ERP models. Export to your POS via Apache ActiveMQ, make sales, synch back to ERP, and view raw materials consumed at the POS via its Replenishment Report!
Make significant improvement due to bug reports from Vassili at http://groups.google.com/forum/#!topic/ ... LtsY1EINnI.
1. Import to Order will now differentiate multiple POS stations having different AD_Org_IDs. They will be stored in separate Sales Orders with respective AD_Org_IDs.
2. At the POS client (Unicenta2) side, I have to make its importing process to take multiple XML strings and (a) reject those not of the same POSLocator (meant for other POS client stations) and (b) continue going through the other XML strings as there may be other Product Categories.
I tested that to work well sending Bushes and Tools categories from iDempiere to ActiveMQ to my Unicenta2 POS.
3. Export to Queue (i discovered while testing my own case) was exporting all Locators as product instances irrespective whether they have stock or not. I shut that up by simply checking for zero stock in that locator. So make sure you have stock if you want a particular product to be sent to your POS stations.
As usual, source is at http://bitbucket.org/red1/posintegration2 (for server side).
Unicenta2 side is at http://bitbucket.org/red1/unicenta2.
It seems that if products does not have stock in iDempiere, they would not be sent over. Also i realised the AutoBOMOrder breaks the accounting consequence trail because the BOM parent is not recorded in final sales order.
1. I made an alternative Export2Queue2.java to bypass 0 storage.
2. Later i will make a cockpit even handler that records proper BOM sales and trigger a ProductionPlan to consume the raw materials. Then Replenishment can occur.
Below, I screenshot from another recent prospect.