Initial discussion with Aila, Rey, and Jong. covering what needs to be done.

WHAT:
In relation to the JDA replacement we are pushing, we were tasked to move forward with the Consolidator Model limited to Aeropostale covering all stores. 

For the benefit of the others, Consolidator would mean the following:
Take and cache data out of DB2; Covering tables affecting inventory; Stored on MySQL; Using Pentaho as data delivery.
POS will be updated to spat out a file for every transaction; File will pass through and stored somewhere (on-premise/cloud); Ingest files and inject data to the Consolidator database.
Write an application to enable transfer, receiving, viewing of inventory against the Consolidator database, and others to be determined; To be used by the stores, HQ and warehouse; Design to follow:
Trickle polling of transaction data affecting inventory back to JDA using polling mechanism.
WHY:
Objective is to give a close to real time inventory and enable our end-points (Brick & Mortar/ Online). The stakeholder would want to see the limitation and potentials in two areas:
Observe the potential of the build model; if this will not work, it then help justify the proposed NAV LS Retail.
See the strength/weaknesses of our existing POS to align to our current as well as future needs; If this works, the possibility of moving to NAV LS Retail is justified and help us on the cost side of things and retain the current POS for the meantime; If not, should provide realization on the move for ERP and POS. 
HOW:
Hi Aila & Rey. Review JDA tables needed and provide us schema;
Hi Aila. Create the data delivery tool using Pentaho
Hi Jong. Create the tables on our new MySQL server
Hi Jong and Rey. Discuss transaction interfaces needed for the front-end
Hi Jong. To design the UI's for stores, warehouse, and HQ