Functionality Explanation Document

Workflow implementation in the Transaction screens plugged in:

Transaction Screens:
1. Item Requisition
2. Item Transfer Requisition
3. Service Item requisition
4. Invoice Management
5. Scrap Initiation
6. Quotation Management
7. Cheque Management
8. Provision Entries
9. Service Work Order
10. Purchase Indent
11. Service Indent
Workflow implementation in the Master screens plugged-in:
Master Screens:
1 Vendor Master
2. Item Master
3. Electricity Master
4. Generator Master

5. Vehicle Master

6. Petro card Master

7. Communication Master

8. Building Management

9. Chart Of Accounts
Data needs to be dumped in the tables mentioned below.
1. C_WF_STEPS_MD(NSPIRA_COM_DEV)
2. C_WF_DECISION_MD(NSPIRA_COM_DEV)
Dependencies:
1. TRANSACTION_ID
2. WORKFLOW_STATUS (LOVVALUES)
3. STATUS_ID (LOVVALUES)
2. SCREENKEY column in C_WF_TEMPLATE_M Table of (NSPIRA_COM_DEV)
Tables Involved:
As workflow implantation is same for all the screens I am explaining the same in common.
1. First we should have the screen key in C_WF_TEMPLATE_M Table of (NSPIRA_COM_DEV)
2. All the screen keys are available in T_ADMIN_SCREEN Table of (NSPIRA_ADMIN_DEV)
3.As TRANSACTION_ID field in our Master table of our transactions is mapped with
C_WF_TRANSACTION_T Table of (NSPIRA_COM_DEV),we should check whether the
TRANSACTION_ID is generated and filled with the same or not.
4. C_WF_TRANSACTION_DETAILS_TD and C_TRANSACTION_DETAIL_HISTORY Tables of
(NSPIRA_COM_DEV) maintains the history about the transactions made from the specific
screens.
5. When coming to C_WF_STEPS_MD and C_WF_DECISION_MD Tables we can have n no of
Approval levels.
6. We should maintain the approval levels by filling the steps in C_WF_STEPS_MD Table. We
dont have any restriction that we should have only specific no.of level of approvals that is
wrong we can have any no of levels we want.
7. C_WF_DECISION_MD contains the decisions for the steps mentioned for that screen.
8. We have 3 decision Records for a particular step. For Example if we have n no of steps then
we will have n*3 no of Decision Records (Approved, Rejected, Discard).
9. NOTIFICATIONMESSAGE and NOTIFICATION_MESSAGE_QUEUE Tables of
(NSPIRA_COM_DEV) contains notification messages after the transaction is made.
10.The important thing with workflow Implementation is we should have grant permissions to
insert the data into the tables to be inserted from that particular schema.
Functionality:
Here is the Explanation about workflow concept how actually it works.
1. After saving one new record into our Master table one new Transition ID gets generated.
2. As the steps mentioned it goes to the Approval levels.
3. In Approval screen the user can have 3 options (Approved, Rejected, Discard).
4.If the user approves the transaction then it goes to the next level, if any ,otherwise It remains
like that
5. For Example assume if we have 2 levels of approval, go through the below
a)Approved Process(Completely)
* If the user approves in the first level then it goes to 2nd level approval, the user approves
there also
means we can say that the approval process is completed fully and the WokFlowStatus will
be
(Approved) and status will be in Active mode.
*After the first level approval the workflow Status and Status fields remains same as pending
as It should go to the 2nd level, once the 2nd level is also done then WokFlowStatus and
Status fields will get changed to Approved and Active modes respectively.
b) Approved in the First Level, Rejected in the 2nd Level
*If the Transaction approved in the first level and rejected in the 2nd level then it goes to the
first level Approval again nothing but WokFlowStatus and Status fields remains with the same
status.
c) Approved in the First Level, Discarded in the 2nd Level
*If the Transaction approved in the first level, but discarded in the 2nd level, in that case it
completely gets vanished means it does not go to the first level instead the WokFlowStatus and
Status fields will be in Discard and Inactive modes respectively.
d) Discarded
*Irrespective of the level if the Transaction gets discarded then it completely vanished and will
be in Inactive mode.
e) Rejected in the First Level:
*If the Transaction gets rejected in the first level then it can be Reinitiated means we can treat
the same as a new Transaction which is waiting to be approved.
6. we are showing the Transaction history in our main grid there one popup after clicking on
workflow Path.
This process is the same for all Transaction Screens and Master Screens as well but what the
difference is For Transaction screens we are not permitting the user to edit once approval is
done completely but not the same with Master screens as we are permitting the user to edit
depends on our requirement after done with approval process also.

New Screens:
1. ProviderToVendorMap
Dependencies:
a) Provider Category (LovValues)
b) Vendor(I_VENDOR_CAT_SUBCAT_MD(Inventory Schema))
c) Provider Type (LovValues)
d) Provider Name(F_SERVICE_PROVIDER(FA Schema))
e) Address1(ADDRESS (COM Schema))
f) Address2(ADDRESS (COM Schema))
g) Country(COUNTRY in COM Schema)
h) State(STATE in COM Schema)
i) District(DISTRICT in COM Schema)
j) City(CITY in COM Schema)
Functionality:
a) This is to map the provider to vendor
b) Provider Type is available only for Electricity Type
c) Address1 and Address2 fields are saved in ADDRESS (COM Schema) Table
d) We get vendor data based on Provider Category from I_VENDOR_CAT_SUBCAT_MD
(Inventory Schema) Table.
e) As F_PROVIDER_TO_VENDOR_MAP (FA schema) is mapped with F_SERVICE_PROVIDER (FA
schema) it holds the details about these fields
2. Loan Purpose Master
Dependencies:
L_LOAN_PURPOSE
Functionality:
We simply save the Loan Purpose code in L_LOAN_PURPOSE (Loan Schema) table.
3. Item Model
Dependencies:
a) MODEL_CD
b) MODEL_NAME
c) ITEM_SUB_CATID (ITEM_SUB_CATEGORY)
Functionality:
a) We load the Item subcategory dropdown with data in ITEM_SUB_CATEGORY (INV schema)
table.
b) The entries will be saved into I_MODEL_M (INV Schema) table.
4. Bank Creation
Dependencies:
a) BANK_CD
b) BANK_NAME
Functionality:
a) We save the Particular bank code along with bank name in BANK (FA Schema) table
5. BRS Parking Screen:
Dependencies:
a) ACCOUNT_ID (CHART_OF_ACCOUNTS)
b) BRANCH_ID (BRANCH)

Functionality:
a) Transaction Date is Todays Date only. The system directly binds today date
b) Branch dropdown is loaded with Branches from BRANCH (ADMIN Schema) table
c) Bank Accounts Dropdown is loaded with data from BRANCH_BANK_ACCOUNTS (ADMIN
Schema) table against to that selected branch
d) We can have the transactions in our grid of debit or credit type or we can upload the file
which is having the details of same by clicking on upload button
e) We disable Add button to add grid records manually if we try to upload the file and vice
versa. Switching is done automatically.
f) When we click on save button the data is saved into F_BRS_PARKING (FA Schema) table

6. More Details tab in Communication Master:

Dependencies:
a) Billing Cycle (LovValues)
b) Billing Type (LovValues)
c) Bandwidth (LovValues)
Functionality:
a) This tab occurs only when we save Communication Master with Communication Type as
MPLS
b) If we want to specify the contract period then chose contract dropdown as Yes and based on
the specified contract period in months it calculates Contract End Date automatically.
c) When we save the data it stores the data in F_COMMUNICATION_MOREDETAIL (FA Schema)
table
d) We can Edit the same and save the data as well