So we have PS HCM and it can integrate with PS Financials, PS Learning Management and also other TPAs(Third Party Applications) through Integration Broker, APIs etc techniques. Also within PS HCM various modules exchange data using internal IB queues e.g. applicant data from Talent Acquisition Manager to Add a Person component for hiring, in earlier versions this exchange was handled by Component Interfaces and PeopleCode. Now to the fundamentals, PS HCM has a RDBMS at the backend and the basics involve a mix of database and application concepts, a few very important such basics are : Control Tables, Prompt Tables, Transaction Tables and Translate Values All delivered tables begin with PS , if you find a "_" between PS and the rest of the table name it is a non-system table e.g. PS_JOB, if PS and the rest of the table name is continuous then it is a system table e.g. PSOPRDEFN. The suffixes of the PS tables convey the table type, i.e. a view _VW, a control table _TBL, Control Tables end with a TBL and contain master data that will be maintained , accessed and used commonly across the organisation. The data contained in these tables are used in day-to-day transaction processing and thus ensures availability and usage of uniform and up to date across all implemented modules. e.g. PS_COUNTRY_TBL, PS_JOBCODE_TBL, PS_LOCATION_TBL, PS_DEPT_TBL etc. Considerable thought should go into the setup of these tables as one of the fields of these tables the SETID plays an important role on what data appears for which user on the transaction pages. Prompt Tables are associated with a field on a page and contain all or selected values (created through a view in this case) from a control table or a transaction table or a system table. PS delivers many prompt tables which can be used by the developer on custom pages and the developer can create prompt tables on his/her own. e.g. Transaction Tables are the tables contain data that is created and saved by the user. e.g. PS_JOB, PS_PERSON Translate Values also called XLAT items are associated with fields and contain values that are valid for that field, a very common scenario for creating XLAT values for a field are when the number of values are too less to be created as a prompt table and another scenario is when the values are not present in the database. An unique feature of XLAT items is that when they are created for any field they are stored in a common table PSXLATITEM, each XLAT item entry in this table contains the name of the field it is associated with, the value itself, an effective date, an effective status(perfect example of XLAT values), long and short names for the XLAT. So that is all for today folks, we will focus on some more heavily used basics like Effective Dates, Business Unit,Table Sets, Set IDs etc. in the next post.