From PERPWiki

The Developer Documentation contains developer or programmer specific information. Most of it is introductory material for new developers who are getting interested in working with pERP, rather than reference material. There are some reference materials toward the end, such as the code level documentation generated by doxygen. Another page to look at is the Developer's_Corner, which contains a list of contributing developers and other useful information.

Contents 1 pERP Overview 1.1 The Core 1.1.1 perp_api 1.1.2 perp_ledger 1.1.3 perp_ap 1.1.4 perp_inventory 1.1.5 perp_manufacturing 1.1.6 perp_ar 1.1.7 perp_orders 1.2 The Others 1.2.1 perp_warranty 1.2.2 perp_logistics 1.2.3 perp_pos 1.2.4 perp_payroll 1.2.5 perp_crm 2 Planning and Direction 2.1 History, Timeline & Status 2.2 Roadmap 3 Contributions 3.1 Code Standards 4 Database Structure 5 Application Programmer Interface

pERP Overview

This is the list of what we want to make, and the order in which we'll be working on them.

The Core

These are the packages required for basic accounting, and will take top priority. Any other modules will wait until these are solid.

perp_api

Common functions, supporting stuff like the ACL editor, the lookup editor, the address validator and Taxes. The API is also where all the common code for Orders, Shipments, Invoices is located, as well as the report framework.

In the near future, support for OASIS UBL universal business language support should be added for inter-system communications. This may belong in api, or the various different sections. Investigation is required, but the UBL looks good, supporting Purchase Orders, Order confirmation, Shipments, Receipts and Invoices. Support for exporting the XML needs to be added. Also, since eGroupWare supports XML-RPC, we should be able to allow other systems to pull the information (subject to ACLs).

perp_ledger

The general ledger, base for all the accounting stuff. This includes GL transactions, as well as accountant type stuff like journal entries, bank account reconciliation, reports.

perp_ap

Accounts payable deals with suppliers, purchasing, incoming stock, and invoices.

Documentation

perp_inventory

Also known as stock. This includes:

• Stock list, a list of items dealt with on a regular basis. This includes raw materials, finished goods, and anything in between. It also includes sub-assemblies used in manufacturing, and can include pseudo-items, such as labour or services.
• Location list, a list of locations stock can be. For example, the warehouse, or the factory.
• Other functions for dealing with stock, such as serial numbers and moving stock.

Uses FIFO costing to calculate direct costs on assemblies

perp_manufacturing

Manufacturing in pERP is the process of turning stock into other stock items. Manufacturing supports assemblies, options on assemblies, options on components used in assemblies. It is tied into the stock_type_flag in perp_inventory, and uses a Bill of Materials to determine what stock is used in the manufacturing process.

perp_ar

Accounts Receivable deals with clients / dealers / customers, and shipping and billing them. Sales orders and pricing have been split into perp_orders.

perp_orders

1. Pricing - You can set up multiple nested Sales Categories (which can be different from stock categories), sales areas (East, West, etc), sales types (Retail, Dealer, Warehouse). You can define a price list for each combination of the above, so you can have a Clothing-East-Retail price list, which is different from you Clothing-West-Retail price list. The clients in the East sales area get one price list, the West gets another.
2. Orders - Enter & edit client sales orders. Pricing on sales orders is based off the price list(s) assigned to the client account.

The Others

These modules are things that we'll work on after the core of pERP is complete and solid.

perp_warranty

If you're making something, chances are it has a warrantee or guarantee. This module will track registered customers, warrantee version, claims, work done, item history (including during manufacturing), and possibly tools for trends (a bad batch / day)

perp_logistics

A more complete module to plan, create and track shipments, schedule shipping & receiving departments, and loading docks. There's a strong opportunity to use various tracking tools for the major shipping companies to track shipments. The core will be re-directed to use this module when it is completed.

perp_pos

A point of sale system. Integrating another, existing open-source POS would be good.

perp_payroll

Payroll system. Hopefully tied into inventory some how so indirect costs like labour can also be added into manufacturing costs.

perp_crm

Maybe tie addressbook / infolog together tightly, or integrate sugarcrm

Planning and Direction

History, Timeline & Status

pERP was started around November 2006 as a front-end upgrade to webERP. That was quickly abandoned as soon as we saw their code, and started from scratch as a set of eGroupWare applications. As of January 2007, most of the core pERP functionality has been written at least once. Some parts could use a rewrite, but that will always be the case.

pERP began testing by "domain experts" shortly thereafter. There will be several rounds of test - fix - repeat as those who use the different parts of the system report bugs and missing functionallity. It will stay in a development status until it has been thoroughly tested by an accountant and any issues are resolved. Any accountants who want to test?

There are no specifications for pERP, so it is impossible to say when it will be completed.

Roadmap

While there are no specifications written down for pERP, there is a general idea of what we'd like to accomplish, as listed in the pERP Overview. We would like to make it so pERP can handle almost everything we do. The Detailed_Roadmap has a list of general tasks to be done, and some of them have been grouped into an order we'd like to do them. The remaining, ungrouped tasks will not necessarily be left until everything else is done, but slotted in when needed or time permits.

Contributions

Contributions are welcome from pretty much anybody, subject to the following:

1. This is a fairly critical system. No lives are in danger except the programmer's when your accounting department gets to you. Do your homework and your testing. That said, pERP is not ready for production at this point (2007/11/30) so nobody's going to be upset when bugs get in.
2. Match the coding guidelines, and try to match coding style.
3. Submit a patch file to the Patch Tracker. If you're fixing a bug, reference the bug with a URL. If you're fulfilling a feature request, reference the feature request with a URL.
4. The patch should be able to be applied to the latest SVN.

Code Standards

pERP is a set of modules for eGroupWare, so much of the eGroupWare documentation applies. Wherever practical, we try to integrate into eGroupWare's existing framework. In general, there are some conventions pERP tries to follow, and contributing developers should too:

1. Formatting
   1. Tabs, not spaces
   2. I personally have no real preferences as to the first brace for functions ({}) being on the same line or the next line, but everything so far has function myFunc($param) { (same line)
2. Developer Friendly - I wanted to keep the code friendly to developers. In some cases this has resulted in slight inefficiencies. I consider this acceptable because at this point in time, processor time is far cheaper than developer time.
   1. Existing functions are called where they exist, eTemplates are imported and reused if possible.
   2. Functionality has been split into appropriately named files.
   3. I've tried to avoid abbreviations and acronyms so that others can get in and read the code.
   4. Documentation - I'm as bad as most developers. The code level documentation is sorely lacking. Improvements gladly taken
3. Naming conventions
   1. Code names should be in the form perp_<application>/inc/class.{ajax|ui|bo|so|hook}_perp_<area>.inc.php For example, perp_inventory/inc/class.bo_perp_stock.inc.php is where to find functions that can be called by other code for interacting with stock.
   2. Function names should be in the form <area>_{list|new|edit|delete|etc. }() or in the short form {list|<area>_new|edit|delete|etc. }() The first is preferred because it is more consistant. PHP doesn't like creating a new() function.
   3. For readability, spelling it out is preferred. That means check_whatever() is preferred over chk_wtv()
   4. Possible exceptions: PO for Purchase Order, SO for Sales Order, BOM for Bill of Materials, because it sucks to write those out. However, writing them out is still preferred.
4. Strict separation - While this is part of the eGroupware specifications, it gets mentioned here too, because not all eGroupWare modules follow this. The web browser goes to ui files. Never to bo files. ui talks to bo, never so. ajax talks to bo. bo talks to so. so talks to the storage layer. Create stub functions that pass the call along if required.

Database Structure

These images have been automatically generated thanks to Thomas Koch

pERP API	General Ledger	Accounts Payable	Inventory
Manufacturing	Accounts Receivable	Orders

Application Programmer Interface

As noted in Code Standards, above, programmers should be interacting with the BO layer of pERP. This includes perp_*/inc/class.bo_perp_*.inc.php.

API via doxygen