map

Hello all !

I am using this as a scratch pad for writing down the modification requirements for ipost. Please feel free to edit it..D Shee

Urgent changes

  1. Move company selection from login to inside ipost
  2. Allow admin to assign company rights of access to user, user can access more that one company
  3. Allow user profile to be setup, storing info like "last accessed parameters" like company, report parameters, processing period
  4. Allow company calendar to be setup, storing info like "calendar to ipost period matching", period cut off, yearly cut off, monthly invoice run, ap run
  5. "Who is online" with log file of user at login (when login button in login screen is pressed), logout and timeout. Log stores info like user id, time, date, default company

Dear all,

more ipost modifications
---------------------------
1) We should be moving towards ipost 1.20, a full version of ipost consisting of SO, flexible invoicing, with full security, AP and Cash module

2) Security modifications consist of
    a) There will be 3 groups of users: admin, manager and normal user
    b) When you first install the software, a default user id admin will be created. 
    c) This admin id would allow you to create companies, users, etc
    d) When a company is created by admin, automatically a manager default id would be created.
    e) When the manager logins in, it will get straight into the company and the manager can then BLOCK admin  
        from getting in.
    f) If for some reasons the manager DID NOT BLOCK admin from getting into the company, admin would have all the rights as manager
    g) A manager can have access to more than 1 company.  This right is assigned by admin
    h) A manager can restrict a normal users from accessing reports, creating templates, posting, etc.  This is called functional restriction

3) Flexible invoicing
    a) Our current invoicing system is greared for Allstaff
    b) What we need is a generic invoiving module ( a web service or class would be good)
    c) Invoicing is now coupled with AR tightly.  This is OK provided we can take invoicing out and link it to SO.  Output should then be the same. 
    d) We need this flexibility so that if company wants just AR and no SO, we can bundle AR with invoicing

4) AP consist of
    a) Allowing invoices to be matched with payments
    b) Allowing partial payments
    d) Pre cheque run - payment cycle   
    e) Print ageing report

SO module
---------------
SO is more complex.  The goal that we set when we started ipost were two folds:

(1) ensuring that we did not miss out invoicing our client 
(2) and be able to monitor online the p&l by staff contract.

A business ground rule.. All SO entries must have PO number keyed in or failing which at least our Quotation number

SO considerations

(1) To ensure that we bill every staff contract every month, whatever NOT BILLED BUT PAID must be monitored and printed out and filed every month

(2) A NBP RECONCILIATION must be carried out every month

(3) Online P&L by staff contract showing details of candidate and  month BILLED, COST and NET

(4) Potentially there could be cases where there is no PO and therefore no revenue would be shown.  In cases like this, an estimated based on prorated income from Quotation should be used.

Subcode Changes

1. User definable subcode (just like template). Defining branch, dept and project should be done by user and NOT hardcoded!

Report writer

reportsample_2.gif

  1. Basic report structure HEADER, COLUMN HEADER (optional), BODY, FOOTER

Design concepts of flexible report writer

  1. User definable (without the help of programmer user can define, run and print any types of reports)
  2. User can print reports accross companies and datasets. Example, printing a consolidated B/S for 2 companies. Users can also print ACTUALS and/or BUDGETS and/or COMMITMENTS
  3. Users can run a "What if" report. Exmaple, if exchange rate is 2.7rm to 1 aud, what will be the results
  4. Report parameters can be saved in the user profile. This will allow the user to refesh the parameters the next time the user return to run the report
  5. Reports can be printed, exported to xls, CVS, html, pdf or text
  6. Reports can be re exported to a database table for turnaround reporting
  7. Reports can be run in a batch
  8. Reports can be run "script" base. This will allow a remote execution without having to open up the reporting screen
  9. Execution of reports can be triggered and return attached via email

Defining HEADER

  1. Width and number of lines
  2. Printed by, time, time and date, date, report id, user define text1-3, company name, company address, company logo, page number ? of ?, department id

Defining BODY columns

  1. User can define unlimited columns in a report
  2. Define table name as HEADER COLUMN name, column click sort enabled?
  3. General ttribute:
    1. Font size, type, weight, underline, italic, hyperlink, color, background color, text and number alignment
    2. Numeric format: currency, numbers, decimal places
    3. Rounding errors
  4. Column attribute:
    1. account code ...define breaks eg, 1-20-00-1, start position, length, capitalised, UPPER case, lowercase
    2. account description ...start position, length, capitalised, UPPER case, lowercase
    3. running no ...starting no, increments, reset on page break
    4. year-to-date ...yyyynnn to yyyynnn, absolute yyyy, relative yyyy +/- yy, inclusive, exclusive
    5. period-to-date ...nnn
    6. cumulative ......yyyynnn to yyyynnn, absolute yyyy, relative yyyy +/- yy, inclusive, exclusive
    7. period
  5. Column secondary arrribute: add, subtract, divide, %

Defining rows

  1. Account range... single or a range, to print
  2. Account type ...define range by type
  3. Totals ... Print no roll, Print and roll to next level, No print and roll, Roll and clear?

Arithematic

Conditional

Defining FOOTER

  1. Report parameter, page number ? of ?, text1-3
  2. Print line, dotted, dashed, solid, pixel size, color