|
|
| Added: |
> > |
|
| Added: |
> > |
| Get all Socorro buildings in table | found at bottom of BARS printout | |
| User Manual: guidelines for username & password creation when adding new person, and procedures (like notifying them via email) | perhaps we can add tools to make this easier (auto-generated email notification?) | |
|
| Changed: |
< < |
| Receipt Summary Report: multiple payments need to be shifted to right by 2 columns | | |
|
> > |
| Receipt Summary Report: multiple payments need to be shifted to right by 2 columns | | |
| Bank Deposit crashes if bilss + coins != cash | | |
|
| Changed: |
< < |
| Receipt Summary Report: add payment detail | easy | |
| Receipt Summary Report: get rid of item total | easy | |
|
> > |
| Receipt Summary Report: add payment detail | easy | |
| Receipt Summary Report: get rid of item total | easy, but left in until add item accounts is done | |
|
| Added: |
> > |
| "View Undepositied Receipts" -> "Create Bank Deposits" button | | |
|
|
|
| Changed: |
< < |
| JE's for A/R receipts wrong | see updated MR | |
| JE's for Receipts die when there is no customer | | |
|
> > |
| JE's for A/R receipts wrong | see updated MR - this has not yet been fixed, but JE now has unit tests | |
| JE's for Receipts die when there is no customer | new unit test | |
|
| Changed: |
< < |
| Browse Item Definitions has mispelled Definition | | |
|
> > |
| Browse Item Definitions has mispelled Definition | | |
|
| Changed: |
< < |
| 'Debt' in JE CSV file should be 'Debit' | | |
| AR Receipt created from Invoice w/ out contact info crashes | | |
| AR Receipt should use same contact info used by Invoice | | |
| In all printout headers, 'science' mispelled | | |
|
> > |
| 'Debt' in JE CSV file should be 'Debit' | | |
| AR Receipt created from Invoice w/ out contact info crashes | wrote unit test for this, but doesn't crash! | |
| AR Receipt should use same contact info used by Invoice | | |
| In all printout headers, 'science' mispelled | | |
|
|
|
| Added: |
> > |
Discovered after sponsor testing began.
| Item | Response | done? |
| Required fields known to user before Entering | Perhaps by bolding requried labels? | |
Discovered after sponsor testing began.
| Item | note | Priority | done? |
| 'finalized' mispelled in main res screen | | 2 | |
| external visitors should not be able to create Invoices from res | | 1 | |
|
| Added: |
> > |
Discovered after sponsor testing began.
| Item | note | done? |
| International Provinces can't be specified | I think this is a bug: this might be a required part of an address, and right now there's no place for it | |
| Is Postal Code being a required field bad for Int'l addresses? | maybe not a bug | |
| Item | Response | done? |
| Time Zones confusing - seems that are validated, but what's the correct format? | Drop down? | |
| Add Observatory to Organization type | easy enough - that's what we are after all | |
|
| Added: |
> > |
| Unit tests not working for JEs in sqlite | | |
|
| Added: |
> > |
| An Int'l address doesn't show up in customer contacts for transaction | | |
| Item Defs that use invalid accounts shouldn't show up in Item Definition searches | | |
| Add more Item Def Types | see email from Lisa | |
| Browse Item Definitions has mispelled Definition | | |
| Item form Qty -> Qty/Charge | to match transaction printout | |
| First line of Remit Address should be NRAO | | |
| 'Debt' in JE CSV file should be 'Debit' | | |
| AR Receipt created from Invoice w/ out contact info crashes | | |
| AR Receipt should use same contact info used by Invoice | | |
| In all printout headers, 'science' mispelled | | |
| Receipt Summary Report: multiple payments need to be shifted to right by 2 columns | | |
| Item | Response | done? |
| Default Note text per site would be nice | and pretty easy | |
| Include next to Transaction Print button, Create JE and Delete | easy | |
| Printouts: Notes should be bold and up top | | |
| Charge Account authorizations was talked about in meetings, but did not make it into any MR | hmmm... | |
| In Manage Transactions, searching by range of BOS ID would be good | | |
| Dates in reports should have form Month/Date/Year | | |
| For User Manual: before deleting a transaction, add why in the Note | | |
| Receipt Summary Report: add payment detail | easy | |
| Receipt Summary Report: get rid of item total | easy | |
| Receipt Summary Report: add item accounts | this will be a big rework | |
|
|
|
| Deleted: |
< < |
| Include Type, Site in Item Definitions | | |
|
| Changed: |
< < |
| When Customer is selected for transaction, init contacts w/ their defaults | | |
| Need way to blank out customer name in transaction | | |
|
> > |
| When Customer is selected for transaction, init contacts w/ their defaults | needs better unit tests | |
| Need way to blank out customer name in transaction | | |
|
| Changed: |
< < |
|
> > |
| Include site and type for Item Definition screens | no way to manage Item Definition Types - thats OK | |
| Validate transactions as they move from Not Ready to Ready | | |
|
| Changed: |
< < |
| get all files, classes, objects to use consistent nameing scheme | only a few offendors |
|
> > |
| get all files, classes, objects to use consistent nameing scheme | only a few offendors | |
|
|
|
| Added: |
> > |
| For Int Dept Sale printout, print Charge Accounts | | |
| When Customer is selected for transaction, init contacts w/ their defaults | | |
| Need way to blank out customer name in transaction | | |
| Printables of transactions need dollar format | | |
| Undeposited Receipts ready for deposit should also be only Ready and/or Entered | | |
| Journal Entries: put in additional check that only transactions from the site of the admin can be put in a JE | | |
| Receipts Summary Report: include site "All" | | |
|
| Changed: |
< < |
| Need input on exact format of transaction printouts | |
| Do we need to validate transactions before they go from Not Ready to Ready? this will save problems of trying to enter incomplete Transactions into PS | |
|
> > |
| Need input on exact format of transaction printouts | no major comments yet, except above bugs |
| Do we need to validate transactions before they go from Not Ready to Ready? this will save problems of trying to enter incomplete Transactions into PS | Yes! - send Christine notes on what gets validated. |
|
| Changed: |
< < |
| Item Definitions can make life easier. What's the best way to manage them? | |
| Do the reports, specifically the receipts one, make sense? If not, how to improve? | |
|
> > |
| Item Definitions can make life easier. What's the best way to manage them? | include site, type in filter |
| Do the reports, specifically the receipts one, make sense? If not, how to improve? | discussed, see above changes, and below future changes |
Features for future BOS Releases
- A more detailed report tying togethor revenue accounts and nightly stays in guest houses
- a user preference page, specifically so that a user's preferred site can pre-set all the Site drop downs
- Enhance Bank Deposits: be able to select/deselect from the list of undeposited receipts which ones will go into Bank Deposit?
|
|
|
| Changed: |
< < |
| Upgrade SQLAlchemy | Ray's working on it | |
|
> > |
| Upgrade SQLAlchemy | Ray's working on it - are there speed issues? | |
|
| Changed: |
< < |
| Use LEFT JOIN in manage trans query | need latest SQLAlchemy | |
|
> > |
| Use LEFT JOIN in manage trans query | need latest SQLAlchemy | |
|
| Changed: |
< < |
| Manage Transactions: filter by type | | |
| Manage Transactions: filter by Org Name, Person First Name | | |
| Manage Transactions: diplay Org Name | | |
| Manage Transactions: make BOS ID link to printable transactions | | |
|
> > |
| Manage Transactions: filter by type | | |
| Manage Transactions: filter by Org Name, Person First Name | need First Name? | |
| Manage Transactions: diplay Org Name | | |
| Manage Transactions: make BOS ID link to printable transactions | | |
|
|
|
| Changed: |
< < |
- Work Estimate - 3-4 FTE weeks? TBF
- What are the Use Cases for BARS Invoicing and Receiting functionality? These should be similar to the Use cases listed in the Project Charter without the external interfaces (People Soft, User Databases).
- What is the Gap Analysis between the above item and current modules?
- What kind of Requirments can we develop from the above two items?
- Can/Should we create MRs for the Invoicing & Receipting modules?
|
> > |
- Work Estimate - 17.25 FTE days or ~ 3.5 FTE weeks
- Work to finish Reservations - 1 FTE week
- What are the Use Cases for BARS Invoicing and Receiting functionality? These should be similar to the Use cases listed in the Project Charter without the external interfaces (People Soft, User Databases). 0.25 FTE day
- What is the Gap Analysis between the above item and current modules? 0.25 FTE day Currently, it looks like we might want to scrap the current Object Models.
- What kind of Requirments can we develop from the above two items? Yes, we should be able to create requirements: 0.25 FTE day
- Can/Should we create MRs for the Invoicing & Receipting modules? Yes, I think we should create MRs for this stuff. 1.0 FTE day
- Can/Should the current framework for maintaining state used by the Invoiceing modules? In our opinion, there must be a better way then the form-based method used by this framework (and the Reservations module). We should put effort into researching other ways of handling the state between "submitions": 0.5 FTE
- Can/Should we reuse the templates used for displaying content already developed? I think we can reuse this, but refactoring will be needed: 2 FTE days
|
| Changed: |
< < |
-
- How much effort to finish Invoices?
- How much effort to finish Receipts (if we can separate the two)?
|
> > |
-
-
- Effort to decide on a package, install it, and learn how to use it: 2 FTE days
- How much effort to finish Invoices & Receipts? Well, after all the above prep work is done, we'll actually have to:
- Design Object Models. 1 FTE day
- Code Object Models using data persistence layer. 3 FTE days
- Place new object into current modified Invoicing framework. 2 FTE days
|
| Changed: |
< < |
- Work Estimate - 4-8 FTE weeks? TBF
- Include questions from option #2 above.
- What are the Use Cases for BARS People Management? These should be similar to the Use cases listed in the Project Charter without the external interfaces (People Soft, User Databases).
- Can Requirements and MRs be developed from above?
|
> > |
- Work Estimate - 32.5 FTE days or ~ 6.5 FTE weeks
- Include questions from option #2 above. 17.25 FTE days
- What are the Use Cases for BARS People Management? These should be similar to the Use cases listed in the Project Charter without the external interfaces (People Soft, User Databases). 0.25 FTE days
- Can Requirements and MRs be developed from above? We think so. 1.50 FTE days
- How much effort to create People object model: 1.0 FTE days
|
| Changed: |
< < |
-
- How much effort to refactor Invoicing & Receipts modules to use these tables?
|
> > |
-
- How much effort to refactor Invoicing & Receipts modules to use these tables? Well, if we're recreating the objet models anyways, we'll have them use People objects instead of managing this information themselves. So we don't need to count this as extra effort here.
|
| Added: |
> > |
-
- Almost forgot! How much effort to migrate BARS and CRAINS database
|