Mobile POS integration with CRM

[red1]

As is now, with the recent integration of OB POS to ADempiere, it carries Customer information which can be expanded to cover all details from the Customer model in ADempiere such as CreditLimit, Contact Details etc. The POS can also be made to store for example 'Total Sales Amt' to allow checking by the POS and awarding bonus points for gift redemption promotions.

We (Dirk and I) like to go further where the POS can be used as a mobile device by roaming salesmen to check on Requests (send in via the web UI of ADempiere) while visiting their allotted customers. The OB POS panel can be extended via the scripts to carry an extra tab on the Requests window and tabs model. Eclipse can use the WindowBuilder plugin to better edit a duped panel from say 'Product'.

Then there is the idea on the occurrence of events, say when a customer submits a request, the App Server can send out to the queue under the queue-path of the customer search-value i.e. JoeBlock (spaces removed) thus /requests/JoeBlock.

The OB POS can upon synching pick up according to its allocated customers, again lets say JoeBlock is one of them, will have the synching done respective to the paths. The info is then displayed in the new panel.

This may pose some questions such as:
1. How to handle empty paths i.e. those that has no requests? One answer can be to have no empty paths, i.e. just have all customers as paths whether they have requests or not.

2. This may mean for many customers there may be many paths. How can we manage or search for information on the queues page. One answer can be to write a new activemq command set to display queues and its contents according to configurable or filter criteria.

Specs to be cont'd

TODO tasks involved preparing code portions or POC for each specs above.

[red1]

But then, a particular customer may have multiple requests or updates and this makes his queue-path storing multiple messages, so we certainly have to find an API to handle EOQ (end of queue messages) which i have not been successful during the integration works. So this TODO may be an important pending one.

More scenarios to specs out TODOs to come so that we can have some picture on writing here.

[red1]

The message from the POS to the ERP can be constructed according to the Request model where it contains the "Result". This is for POC purpose and later we can expand to cover all the other fields in the Request Tab (saving the tab will populate the rest thus we can reuse the MRequest class during synching).

[red1]

Dirk has committed branches/POS_CRM that has an extended panel for managing Requests on the Standalone POS, and i have committed branches/AD_POS_CRM with a new process to send Request-Updates to MQueue. I have also added a small xml tag that picks up the ActualLifeTimeValue from C_BPartner table which can be used for the 'Bonus Points Redemption' idea stated above. The AD_POS_CRM includes the present POS_ActiveMQ, so we have all such processes from ERP to POS consolidated in one place.

Each customer request (as described above) should be having its own path such as /requests/JoeBlock (SearchValue field which is single phrase, thus need not remove spaces), and the POS should scan its own customers and read those request-updates. Then the POS can send back further action result to the Queue for the ERP to pick up (via the general import loader model).

[red1]

At the moment the XML tag code (trimmed off redundant tags for faster reading) for this are:

Code: Select all

writer.writeStartElement("DocType");
writer.writeCharacters(MRequestUpdate.Table_Name);

writer.writeStartElement("CustomerName");
writer.writeCharacters(bpartner.getName());

writer.writeStartElement(MBPartner.COLUMNNAME_Value);
writer.writeCharacters(bpartner.getValue());

writer.writeStartElement(request.COLUMNNAME_R_Request_ID);
writer.writeCharacters(Integer.toString(request.getR_Request_ID()));

writer.writeStartElement(reqHeader.COLUMNNAME_Summary);
writer.writeCharacters(reqHeader.getSummary());

writer.writeStartElement(request.COLUMNNAME_Result);
writer.writeCharacters(request.getResult());

writer.writeStartElement(request.COLUMNNAME_Created);
writer.writeCharacters(request.getCreated().toString()); 


[red1]

I have sent the full exporting package to the branch in SF via SVN.
After applying the migration scripts in it you can export your RequestUpdates to the MQueue.

CRMsend2queue.png (36.85 KiB) Viewed 7602 times

Upon completion you should get a success return message.

2queueSuccess.png (32.09 KiB) Viewed 7602 times

Then you can look at your Queue Server to see that all customers in the selected category has their paths created.

queueAdmin.png (32.27 KiB) Viewed 7602 times

But only one customer has 2 requests which was what the Request window had in my ERP.

Code: Select all

<?xml version="1.0" ?><entityDetail><type>openbravoPOS</type><detail><DocType>R_RequestUpdate</DocType><CustomerName>Seed Farm Inc.</CustomerName><Value>SeedFarm</Value><R_Request_ID>100</R_Request_ID><Summary>Could you please trim the trees for me?</Summary><R_RequestUpdate_ID>100</R_RequestUpdate_ID><Result>Some Unicode test: Some Extended Characters: ?????? European Characters: ???-???????aracters &gt; 100h: ?? Greek: ????? Cyrillic: ????????? Arabic: ??????</Result><Created>2005-07-18 19:52:48.0</Created></detail><detail><DocType>R_RequestUpdate</DocType><CustomerName>Seed Farm Inc.</CustomerName><Value>SeedFarm</Value><R_Request_ID>100</R_Request_ID><Summary>Could you please trim the trees for me?</Summary><R_RequestUpdate_ID>1000000</R_RequestUpdate_ID><Result>We suggest to be always nice to your plans, talk with them and water them regularily.</Result><Created>2011-11-02 22:13:56.0</Created></detail></entityDetail>

[red1]

red1: Dirk, hengsin asked before to me if i am forking OpenbravoPOS.. wana ask u your roadmap too so that we can build on it and see
[07:40am] banym: guten morgen red1
[07:41am] red1: hope u will grow your hair back!
[07:41am] red1: winter is here!
[07:41am] banym: yes need my hat all the time ^^
[07:41am] banym: it's getting cold now … but still no snow ….
[07:41am] banym: not nice winter up to now
[07:42am] banym: but it's a nice idea to fork the pos … maybe there will be some more sponsoring on that project
[07:42am] banym: red1-bos
[07:42am] banym: red-pos
[07:42am] red1: there is already sponsoring .. thats why i could do it
[07:42am] red1: but yes.. more sponsoring needed
[07:42am] banym: nice
[07:42am] red1: or HamburgerPOS
[07:43am] banym: you can change the color to red for better branding
[07:43am] red1: the sponsorship is just to integrate.. thats all
[07:43am] red1: now a42niem can spend little time to get one more thing onboard the CRM
[07:43am] banym: that would fit with the hamburg flag aswell I think it has red init
[07:43am] red1: and today later i m going somewhere near Munich to try get POS deal that also needs CRM / total sales value
[07:44am] hengsin: CRM = adempiere CRM or is something else ?
[07:44am] red1: yes CRM = Request model
[07:44am] red1: there are two CRMs in ADempiere = Requests .. the other is BP Info
[07:44am] red1: such as lifetime value
[07:44am] hengsin: ic, the model is ok but it lack a decent web and mobile front end
[07:46am] banym: CRM would be a thing i am interessted in. but i only will develop it for idempiere if there is sponsoring for that functionality
[07:46am] banym: now i know how complicated this stuff is done by oracle on demand and maybe there is some need for doing it open and better
[07:47am] red1: thats what Dirk is trying to extend.. copying the Product tab for example
[07:47am] red1: its ok on a IPad
[07:48am] banym: but there need alot of more done. requests, opportunities, leeds, service requests and better better reporting
[07:49am] red1: well 80% can be solved in some steps
[07:49am] banym: today?
[07:51am] red1: ok firstly do u know the BP window?
[07:51am] red1: BP record has lots of SugarCRM stuff
[07:51am] banym: yes
[07:51am] red1: i.e. LifeTimeValue, ActualLifeTImeValue, Credit Limit.. contact info, Sales Rep
[07:52am] wariola joined the chat room.
[07:52am] red1: those are basis for tracking leads till level of long term sale
[07:52am] red1: now the POS <> AD is done
[07:52am] red1: its framework
[07:52am] banym: yes but you dont want to have leeds managed as business partners
[07:52am] red1: its matter of adding more fields to it to pass back
[07:52am] red1: then?
[07:52am] banym: i wouldn't do it this way. this will mess up the business partner.
[07:53am] red1: what Dirk did is to track CRM (Requests) or tickets
[07:53am] banym: i would create a new entitiy for leeds which can be migrated to businesspartner if it comes to business
[07:53am] red1: that is outside but linked to the BP structure
[07:53am] banym: this is more common way because you have lots of leed sourcec with often bad quality
[07:53am] red1: perhaps we can use the tickets?
[07:54am] red1: cos tickets requests is just empty model in one way for further configs
[07:54am] banym: the ticktes are good for service requests
[07:54am] red1: i.e. request type can be "lead handling"
[07:54am] red1: and that ticket has status and levels of actions
[07:54am] red1: can that fit into your leads model?
[07:54am] banym: mor
[07:54am] banym: more
[07:55am] red1: more?
[07:55am] banym: will write down my process today in the afternoon with some diagramm
[07:55am] banym: then we can have a chat on that base
[07:55am] banym: maybe dirk wants to join
[07:55am] red1: ok.. just let the dog out.. he is waiting why i am not walking it to the fields behind here
[07:56am] red1: i am now the dog walker for Dietmar
[07:56am] banym: there needs a lot of more extra work done for the workflows and the reporting stuff
[07:56am] red1: he woke late every nite to migrate his servers
[07:56am] banym: hehe
[07:56am] banym: have fun and keep you warm
[07:56am] red1: we also have to think which direction the POS goes to
[07:57am] red1: but we can make the model open for variants...
[07:57am] red1: ok out...
[08:11am] hengsin: adempiere's bp have all this flag, iscustomer, isemployee, isprospect, etc. so it is kind of the original idea to dump all legal entity you deal with there, be it vendor, prospect, employee, etc.
[08:13am] banym left the chat room. (Ping timeout: 240 seconds)
[08:15am] red1: good point hengsin .. will copy banym when he gets back