Introduction to pERP
From PERPWiki
Contents |
About pERP
pERP, which stands for Project Enterprise Resource Planning, is open-source accounting and stock management software. ERP software ties together the various parts of a business so that data can be freely exchanged and shared internally. The production department can see what is in inventory. The sales department can see what is in line for production, with completion dates. The purchasing department can generate automatic purchase orders based on scheduled orders, existing stock levels and supplier lead times.
pERP is now in beta release. This means that it has reached a stage in its development where it should be largely bug-free, should perform most tasks as expected, and is ready for real data. The project is far from complete. There is basic functionality, but some modules are only roughed in, which means they aren't pretty or smooth to use. There is limited reporting capability. Documentation may fairly complete for some modules, only in the outline stage for others. At this stage, the documentation only covers "what it does" and a bit of "how it works". This documentation is not intended as user training material.
pERP coordinates a group of applications called eGroupWare. In its present form, pERP contains the following modules, not all of which will be visible to the average user:
- Accounts Payable - Manage vendor account info, generate and track purchase orders, arrange incoming shipments, receive goods, receive & pay supplier invoices
- Accounts Receivable - Create customer accounts with associated information including branch stores; arrange outgoing shipments (basic), invoice customers and receive payments for customer orders
- General Ledger - The Accounting Team can examine transactions, enter transactions, reconcile bank accounts (and, eventually, create a variety of reports)
- HR Manager - Managing staff - tracking performance reviews, tracking incident reports.
- Inventory - Track parts and finished goods; manufacturing options; track & manage inventory levels at various locations, ship parts between locations
- Manufacturing - Generate work orders and batch work orders, set options for manufactured goods, create and manage build lists (bill of materials)
- Payroll - Works with TimeSheet data to handle all payroll functions - deductions, vacation pay, stat holidays, issuing cheques
- Sales Orders - Generate complex pricing structures, create and track sales orders (eventually this will tie to Inside Arctic)
In addition, the following are some of the applications available from eGroupWare, and how pERP uses them:
- Address Book - Full of features! all customer, vendor, and internal addresses are stored here
- Administration - Ways for the IT department to set access levels and configure basic information and functions
- Calendar - With Address Book and InfoLog, the calendar provides basic CRM and scheduling, with links to iCal
- Home Page - This highlights "for your attention" tasks. The Purchasing Manager will see PO requests that need approval. A purchasing agent might see a list of orders scheduled to ship. Accounting staff might see a list of POs received but not yet invoiced by the suppliers.
- InfoLog - A way of tracking information related to your work - price overrides, phone calls, to-do items, etc. *Logout - This icon, when present, does the same thing as the Logout command on the Information Bar.
- Project Manager - A way of scheduling, tracking, and costing projects.
- Time Sheet - An application for tracking labor time for employees and projects.
- Work Flow - A workflow defines a common order of process-steps to be taken for a certain type of work. pERPs workflow-system ensures all steps are taken (and in the right order) and tracks the progress of a product along the production line.
When will pERP be ready for final release?
The initial design parameters of the project were never clearly defined, so there is not a point where it can be said, "There, we have met the stated requirements." Instead, pERP has been an evolving organic that has been revised frequently when someone thinks of something else it needs to do.
The beta version of pERP went online in October, 2007, and it has been in use worldwide by various companies for various purposes in areas other than manufacturing.
There will probably never be a "final" version. pERP will continue to change and grow in response to user suggestions and as new functions are required.
Testing pERP
Introduction
pERP, has reached a stage in its development where it is ready for people who have detailed knowledge about a particular business function to begin using pERP to do some jobs.
Because this system is new and different, it may seem strange, awkward and slow at first. As you gain familiarity with pERP some of this will go away, but some parts are still under development and will still be slow and awkward. Your suggestions will help correct this.
User Testing
User Testing is the process used to help identify the correctness, completeness, security, and quality of the software. It involves checking the following things:
1. Things work For a particular area of pERP, everything present should work without extraneous error messages generated by the program.
2. Things work correctly pERP should function correctly. For example, if you're moving stock, the stock count at the source location should decrease by the amount moved, and the stock count at the destination location should increase by the amount moved.
What we need you to do has five parts.- Use the modules - to see how they work for you in doing your job, using real data for real tasks.
- Report bugs or problems - if you encounter something that doesn't work, or doesn't do what you expected it to, please let us know.
- Request changes or new features -"It would be much more efficient if I could do it this way!" We need your suggestions.
- Provide positive feedback - If something works, is really slick, makes sense -- we need to know that. We can study what works well and apply those methods or layouts etc. to other sections
- Comment on the documentation - Please remember that at this stage we are not producing step-by-baby-step training manuals. You might have to read carefully, study the material, and think things through. If you received a manual, how can we improve it? Is it clear, accurate, helpful? (and if not, don't just complain - suggest something better!)
How to Test
Start by trying to do normal, everyday tasks. After you've verified that those are working well, move on to the weird things that only happen once in a while, or are a variation on what is normally done. You may not even think of these 'odd-balls' until one pops up. Be sure to note what needs to be done, how you want to do it, and whether or not you could get the task done in pERP.
Testing is something that must be done slowly and carefully. You are trying to determine steps that break the system. Should you succeed, you need to be able to report how it was done, so the problem can be fixed.
When Things Don't Work
If you do find something that doesn't work, don't get frustrated. Your testing has paid off; this is what you've been looking for! These problems are known as bugs, after a moth that jammed one of the first computers. Here's what to do:
1. Do it again. See if you can figure out what makes it break. Does the problem happen every time, or only when using certain settings? For example, does it work for existing dealers, but not the dealer you just created? Does it work for parts, but not assembled goods? Does it happen for US suppliers, but not for CA suppliers?
2. Report it. How to report a bug is dealt with below.
3. Keep going. If the bug prevents you from continuing your work, make sure you mention that in your report, as this will be given a higher priority than a bug that involves appearance on the screen or alignment of columns. If you can, carry on or move on to another section.
Reporting Bugs
Reporting a bug is the first step in getting it fixed. The more accurate you can be in your report, the faster the problem will get corrected.
How do I report a bug?'
- Use this (form), called a "ticket". We suggest that you right-click and choose New Tab for the form, so you can still see your original pERP page.
- Use an internal method set up by your workplace
Companies that operate pERP may have internal methods of reporting tickets, such as by email or a request tracking system. Your IT department will set standards for how you should report using these methods. If you work for Blue Falls Manufacturing, for example, you should follow the directions in the print materials that you were given (and remember, you signed a form certifying that you had received and read those materials. Find them. USE THEM.)
An example of a poor report in a ticket. You should complete the following sections ONLY:
- email address or user name. If you use an email address, you may receive a request for additional information and will be notified when the bug is fixed.
- Short summary (also called Subject Line)
- Type (choose Bugs or Feature Request. Ignore the other choices)
- Full Description (don't bother with formatting, K.I.S.S. rules apply)
- I have files to attach to this ticket.
If you need to attach a file (screen shot) then check off that box and click Submit. An attachment form will open. Follow the steps indicated to attach your image, then click Add Attachment. We suggest that you close the report tab when you're finished.
What should I put in my bug report?
Your report should contain the answers to the following questions:
- What browser were you using (Internet Explorer, Safari, Firefox etc.)? If a screen does not look right, if fields aren't lined up, or something doesn't work, please be sure to tell what browser you are using when you send in a report (form). Please do this every time you send a ticket.
- What were you doing when it happened? List specific steps that you took. If the bug can't be duplicated, it can't be fixed.
- What were you working with? Give specific reference numbers for what you were doing. If there's an Order number, give it. If there's a Supplier or Client, give their number or exact name.
- What is the error message? Copy the actual error message off the screen, even if it doesn't make sense to you. The error message is essential to pinpointing the problem.
- Would a picture help? If a picture would clarify or illustrate what is going on, take a screenshot and attach it to your report:
- Windows: press [Shift] + [PrtScn], open Paint, paste (CTRL-V or Edit > Paste) then save the picture as either a jpeg or png.
- Mac: pressing [Apple] + [Shift] + [3]. This will place the image on your desktop with a name like Picture 1.png
- Attach the image file to your report. If a picture won't help, then don't take one.
- Did this prevent you from continuing to work? pERP often has different ways to approach a task, and it could be that trying another method will let you keep going. That's important to note in your report.
- Was your data saved? Sometimes your data will be saved correctly despite the error. You should log out, then log back in and look to see if your entry was properly recorded. If it was, that's important to note in your report.
NOTE:
You can select and copy an error message into the body of your email; it's text, and while it may be gibberish to you, it will be clear to us. But please don't try copying and pasting an entire screen - the result is gibberish to us! If you need to show all or part of a window, use screen capture as discussed above.
Subject Lines
The summary or subject line is what the developers use to search, find, and organize reports. A good subject line is a big help to you, too, in remembering what you reported. To start with, here are some less-than-useful and some helpful subject lines:
Not Helpful:
- Subject: pERP
- Subject: accounting
- Subject: problem in perp
- Subject: testing
- Subject: (left blank) - (Reports with blank subject lines will be rejected automatically)
More Helpful:
- Subject: Difficulty logging in to pERP (Apollo Test)
- Subject: perp screen frozen at Edit Customer page
- Subject: Unable to enter new customer Brikman Cement
- Subject: Error on saving new PO #BRI001-000506
- Subject: GST Calculation incorrect in SO-00123
Bad Examples
Here are a few examples of bad bug reports:
Subject: pERP
Message: Unable to do make payment in pERP. Please fix it. Also, the list of orders is wrong,
it doesn't work.
You can see the problem with this report.
- It gives almost no information.
- The information provided is ambiguous because payment and orders can refer to incoming or outgoing, and the list of orders can either not work, or be wrong, but not both.
The lack of good information guarantees that you will have to be contacted when it's time to fix this bug. If it's a week later, will you still remember what happened, or will you be unable to provide the details needed? When you see the response in your email, will the subject tell you that there's been some progress on your report, or will it be confused with the other bugs you've reported?
There are actually two bugs in this report. The inclusion of two separate, unrelated bugs in one report means they cannot be dealt with separately. Any questions or comments have to specify which bug, and the issue cannot be resolved until both bugs are fixed.
Subject: Report Generator
Message: Appears not to be working.
Again,
- Almost no information - which report, in which application, in which version of pERP?
- Ambiguous - "Appears not to be working" can mean so many things.
Subject: Purchase Order
Message: I made a PO but it doesn't look right.
Give us a break!
- What browser are you using?
- Exactly what doesn't "look right"? A screen shot might help here.
- What was the supplier? (name or number)
- What was the PO number?
- Despite its funny looks, did everything work properly? Amounts and stock items correct?
Good Examples
Now for an example of a good bug report:
Subject: Errors in USD A/R payments
Message:
Blue Falls in Internet Explorer.
Payments in US dollars are not being processed correctly. Payments in Canadian dollars appear to work. I have a printout for each step at my desk. The steps I did were as follows:
- Created USA Client UTA001
- Invoiced # UTA001-1 $ 300,000.00 USA
- Paid Inv. # UTA001- $ 300,000.00 USA and the dollars appear on General Ledger Entry # 9 going into the CAD account $ 360,000.00 CDN
- The Receipt ID # 5 shows this was paid in USA Dollars
- The Bank Reconciliation Shows that $ 360,000.00 in the CDN Account.
So after I did that transaction I tried it a second time to see if the same thing happens with the payment (being switched from USD to CDN) - Invoiced # UTA001-2 $ 300,000.00 USA - Paid Inv. # UTA001-2 $ 300,000.00 USA (This time the payment appears on the General Ledger Entry # 12 going into the USA account as $ 360,000.00 USA - The Receipt ID # 7 shows this was paid in USA Dollars - The Bank Reconciliation Shows that $ 360,000.00 in the USA Account.
This report lists a single issue, and details what was going on, what went wrong, and the steps taken to discover the problem. The specific client number and all document or transaction numbers are given as well as specific dollar amounts. The report also narrows down possibilities by saying that Canadian payments work. This level of detail means you will not need to be questioned to clarify the issue, which will result in a faster fix.
A good report doesn't always have to be long, either. Here's another example:
Subject: Incorrect totals on PO-12454
Message: Test Company 1 in IE
Created PO-12454 for Dynacore. Ordered five items. Line (extended) totals are correct, but subtotal is incorrect (should be $1945.86, reads $945.86). Sales tax correctly calculated on incorrect total. Grand total incorrect.
Note: for more information about how to submit a really GOOD, helpful, efficient report, take a few minutes to read this.
What to do With Your Bug Report
Bug reports, as well as any other questions or comments you may have, should be sent here. A good subject line can help get a timely response. If there are questions about your bug report, please give the answers in a reply to the email. Unanswered questions result in unfixed bugs as we wait for your answers.
When Will I Get a Response?
Response time is based on workload, how good your report was, and how hard it is to fix. Because you sent your report (or question) here, it hasn't been lost or forgotten.
Note: If you send in your own report, you will be notified when it is dealt with. If you made a feature request, you'll be told when it has been implemented (in Test). If you reported a bug, you'll be told when it has been fixed (in Test). But if you had someone else send in the report on your behalf, that person will receive the notification - and will they remember to tell you? Better to send it in yourself!
Any changes made to pERP will be available to developers, and the public demo site, demo.projecterp.org, will be updated within a day of their completion. You will get a response to your bug report, letting you know that the problem has been fixed, or your suggestion implemented.
While we will test any changes we make, you are responsible for the final check to make sure everything works properly. You have until the following Monday morning to check on the test site and make sure that your requested change or fix was done correctly, and hasn't broken something else. If you discover a problem, we ask you to reply to the response, and report the problem you found. Do not submit a new ticket.
Kudos - When Things DO Work
Because we're concerned with accuracy, you're mostly looking for problems with correctness and security. We want you to find bugs, missing parts or features, things that shouldn't happen or shouldn't be allowed, parts that someone in your job shouldn't be able to get into, and so on.
However, sometimes you'll find something that works great (or that didn't work before, but does now), and we appreciate hearing about that. We need to know that the bug is really fixed.
Feature Requests
Sometimes you'll think of things that would help make the job faster or easier or better organized, and we want to hear about those, too (we'll file them away for evaluation, discussion, and future development, and will work on them between bug fixes). These are called Feature Requests. For example, Align columns in Purchase Order. Follow the criteria for reporting a bug so we know what your suggestion involves. If you are using the ticket form, set the topic from Bugs to Feature Request.
Back to User Documentation
Summary
TESTING
- You are testing to identify the correctness, completeness, security, and quality of pERP
- Start with your normal routine tasks, then try the less usual variations
- Work slowly and carefully, step-by-step
- You are trying to find things that do and don't work
- If something fails or doesn't work quite right, see if following the same steps makes the same thing happen
- Report your findings
- Continue working if you are able to do so.
REPORTING
- Use a meaningful subject line in your report
- Report only one bug in one ticket
- Be as detailed and specific as possible in the body of your report
- File your bug report here
- Please be patient, as it may take a while for a bug to be fixed
FEATURE REQUESTS
- Select Feature Requests from the list of Types
- Use a meaningful subject line in your report
- Request only one feature in one ticket
- Be as detailed and specific as possible in the body of your report
- File your feature request here
- Please be patient, as it may take a while for a feature to be implemented
