ERPNext Tutorials

Enterprise Resource Management (ERP) was born from a manufacturing need, but a modern ERP today includes accounting and financials, sales, product lifecycle management (PLM), customer relationship management (CRM), human resource management (HRM), and other core business systems. However, modern ERP systems have also become complicated and expensive, and a successful implementation often requires the business more conform to the ERP than vice versa. A new type of ERP is emerging, called Postmodern ERP. Postmodern ERPs are designed from the ground up to be simple and flexible, more capable of modelling a business than imposing conformity, and available to organizations of even modest requirements or means.

ERPNext is a postmodern ERP. Rushad and his team created not only an incredible open-source software application, but also an entire eco-system, including a community of users and independent consultants, a supportive peer-to-peer help forum, and a recent addition, the ERPNext Foundation for project stewardship.

I will be taking a somewhat chronological journey through ERPNext, from an engineering perspective. Starting with the engineering team creating a prototype, then continuing through general customer release, the journey continues with changes to enhance quality, satisfy new customer needs, and reduce cost.

I will be following the Swift Construction Company’s development of the Aircraft Wireless in this tutorial, documented in the Maestro project. Also this list will be updated with links to the tutorials as they are published.

#1. Installing ERPNext

I started with the virtual machine image provided by ERPNext.org, hosting the vm using VirtualBox on FreeBSD.

#2. Product Lifecycle Management (PLM) using ERPNext

All the parts needed to build the initial Aircraft Wireless prototype will be created, including sub-assemblies with bills-of-materials (BOMs). Purchasing and supplier data will be entered for bought-in items, and appropriate documents will be submitted for custom or manufactured items. Revision levels will be used to assist in managing inevitable change.

#3. Purchasing using ERPNext (not yet published )

The parts needed to build a sub-assembly of the prototype (a custom inductor) will be purchased, received to stock, and paid for, with the development project bearing the costs. Initially, purchasing will be driven by the engineering project, then later by manufacturing scheduling after the Aircraft Wireless reaches production status.

#4. Manufacturing using ERPNext (not yet published )

Similar to the Purchasing tutorial, manufacturing will initially be driven by the engineering project, then later by manufacturing scheduling after the Aircraft Wireless reaches production status. Work orders will be created to manage work and collect cost.

#5. Managing projects using ERPNext (not yet published )

The concept of a project was first introduced in the Purchasing tutorial, when prototype costs were allocated to the Aircraft Wireless engineering project. Here project management will be explored further, including capturing time spent by engineering staff on the development project, and using Kanban project management (equivalent in many ways to the agile scrum process).

Other topics being considered include:

  • Purchasing from a BOM using ERPNext.
  • Managing Controlled Stock using ERPNext.
  • CRM using ERPNext.
  • Managing a Production ERPNext Site (keeping an ERPNext site up to date and QA considerations for business-critical software infrastructure systems).
  • Receiving  serialized stock items.
  • Serialize certain non-serialized stock when received (serialized with either vendor or local serial number).
  • Manufacture serialized stock in the form of sub-assemblies and final assemblies, using serialized and non-serialized stock.
  • “Un-manufacture” serialized product to sub-assemblies,  returning sub-assemblies to inventory following a QA re-verification process.
  • Reporting serialized sub-assemblies included in a serialized product (current and historical).

Please leave a comment if any of these topics are relevant to you, or to suggest other topics of particular interest.

Dale

webERP Tutorials

Here are the currently available webERP tutorials. 

#1. Installing webERP

Install webERP on Apache 2.4 and MariaDb 10.0.

#2. Product Lifecycle Management (PLM) using webERP

Create parts, identify vendor, configure unit-of-measure, create bill-of-materials.

#3. Purchasing using webERP

Issue purchase order, receive stock, make payment.

#4. Manufacturing using webERP

Create work order, receive output goods, close work order.

#5. Managing projects using WebERP (not completed)

Comparison of manufacturing and contract-based project management and configuration for following the manufacturing strategy, but a complete project workflow is not presented.

Topics being considered for new tutorials include Stabilizing webERPPurchasing from a BOM using webERPManaging Controlled Stock using webERP, and CRM using webERP. Please leave a comment if you are interested in any of these topics, or if you would like to suggest any other topics.

Dale

Recent Outage

You may have noticed dalescott.net suffered a minor maintenance glitch recently. Thank you for your patience and understanding if you were affected, and we sincerely regret any inconvenience as a result.

Update – all demos are now available!

The dalescott.net server had to be taken off-line to add additional RAM for the best possible demo performance, but also the operating system needed upgrading to make use of the memory. Content on dalescott.net had been temporarily re-hosted on a cloud vps for continuity, but unfortunately there were issues and the expeditious solution was to put up a static maintenance page and get on with the upgrade. However, all content is now available and the demo applications will be available again shortly.

Dale

Legal Cred for an Open-Source Project

I am not a lawyer. The information here is not, not is it intended to be, legal advice. 

Many open source projects unfortunately don’t concern themselves with presenting a clear legal perspective, which could be costing them community!

An open source project must present legal credibility to be considered seriously by a commercial enterprise.

I recently attended the iTech 2017 convention in Calgary, where the luncheon keynote was Digital Transformation Leaders Are Few and Far Between from Snehanshu Shah, SAP Global VP Customer Innovation. Shah purported that leading companies in digital transformation will use next-generation technology to continuously improve core infrastructure, while quickly incorporating new technologies for competitive edge, and that technologists who can apply inexpensive technology to solve these business problems will have value. Open-source software is now a proven development model with communities of essentially independent developers, collaborating in a non-competitive environment and sharing the development labor. It is inevitable that the business transformation spoke of by Shah will be aided by open-source software technologies, driving down the cost of infrastructure and providing sources of competitive advantage in a digital age.

It is in the nature of a young open-source project team to organise itself loosely. This should not be surprising, considering project members are typically volunteer developers donating their time to scratch their own personal itch, and more interested in writing code then in documentation or project process. A mantra of the open-source community is Talk is cheap. Show me the code. However, this is not to disparage project teams because it is hard to have value without working code.

Unfortunately though, this behavior is in contrast with a commercial enterprise’s typical need for security and stability to operate in the best interests of its owners. An enterprise must be absolutely confident that their adoption of a particular open-source software application cannot be jeopardized later, for example through misunderstanding or lack of appreciation for legal concepts by the project team, or a falling-out within the team leading to a disagreement over code ownership. A commercial enterprise requires confidence of longevity.

Ownership (Copyright)

The fundamental aspect of credibility is clear ownership of source code and other assets. Major projects often require contributors to sign a Copyright Assignment Agreement (CAA) or a Contributor License Agreement (CLA), which for all intensive purposes transfers ownership of the contribution to the project. However, this requires creation of a legal entity to assign or license contributor rights to, which is often beyond the need or ability of a smaller project team.

Simpler approaches are possible. For example, the Maestro project includes a legal statement in one of the project’s source code files – in the README.md file. The statement specifies the license under which the software can be used, that contributors retain individual copyright to their work as recorded in the repository commit log, and that contributions are accepted with the assumption they were provided under the terms of the same license. The legal statement was committed to the project repository before any contributor contributions were accepted. This approach was deemed sufficient considering the project potential and risks, and ultimately a business decision.

License

The second-most fundamental aspect of credibility is the license, and the license terms that control use of the software. To have value, the license must be be legally binding and enforceable. Well understood and even legally tested licenses exist, but many open-source developers still write their own license, based on how they would like their software to be used. For example, Anuko Time Tracker, a popular web-based timesheet system, uses its own Liberal Freeware License, which appears to address the same concerns as more established and tested licenses such as the BSD, MIT, and Apache licenses. To an enterprise, not using a well-known and understood license can easily prevent an application from being considered further. Enterprises must be concerned with potential liability, and a well known and tested license will provide greater credibility. 

Permissive vs Copyleft

The anticipated use of the software must of course be compatible with the terms of the license, but also potential future use should be considered. There are two basic types of open-source licenses, permissive and copyleft. The two have very different goals and different implications for a commercial enterprise.

The goal of a permissive license is to encourage use through as few restrictions as possible, while the goal of a copyleft license is to ensure source code remains available even if modified by a third party. Commercial enterprises generally prefer a permissive license to a copyleft  license because it reduces risk of the license constrain the business at some point in the future. 

The original copyleft license was the GNU GPL, which required that source code be provided to everyone the application was distributed to. When remotely served web applications became popular, it was realized that GPL-licensed web applications hosted remotely did not have to make source code available, because the application wasn’t being distributed according to the GPL. This was against the philosophy of the copyleft community and became known as The ASP Loophole. As a result, the GNU Affero General Public License (AGPL) has become the popular copyleft license for web applications, requiring that source code be available to anyone who accesses the application. However, having to make source available should not be the greatest concern to a commercial enterprise for a copyleft license. The greatest concern should be whether the copyleft license could constrain future business direction or opportunities because of how the license extends itself to integrated – or integrating – applications to also apply to the end result. 

To explore this using an example, first assume an engineering department within a commercial enterprise is trying to improve project management, and starts using Anuko Time Tracker as an electronic timesheet system to record time spent by employees on projects and tasks. If use of  Time Tracker proves successful, the enterprise may expand use to other departments as well. Eventually the enterprise may make minor customizations as well as provide access to contract staff for entering their time, and to clients for reviewing their project’s dashboard. Assuming Time Tracker continues to be successful, the enterprise may want to integrate it with other internal systems, such as a vacation database or ERP system.

Because Time Tracker  uses the permissive Liberal Freeware License, there will be no practical constraint on how the enterprise can use, modify and integrate Time Tracker –  ever. However, if Time Tracker had been licensed using the AGPL, not only would customizations have to be shared with clients, subcontractors, and possibly competitors, but integrations with other applications may be impossible due to incompatible licensing. While it may be possible to perform an integration without the copyleft license becoming “viral” (a popular metaphor, implying that a copyleft license “infects” everything it touches), careful review of both the specific licenses and of the software architectures involved will be necessary to establish business viability.

In Conclusion

If you want to attract enterprise users to your open-source software project, then remove obstacles from their path. It doesn’t matter what you think, it’s what they think. Perception may not be reality, but it’s perception that matters. Make it easy for outsiders to understand the legal position of your project, and what the implications and options are.  

There is a plethora of legal advice on the internet, some useful, some less useful, and some absolutely wrong. Laws are specific to a jurisdiction, and much will simply not even apply to you. There are also subtleties and implications that only an expert can competently advise on. If it’s important, seek professional guidance!

For more anecdotal information, TWIT.tv‘s FLOSS Weekly podcast interviewed several project teams that had to deal with legal issues.

  • Roberto Rosario had to develop Mayan EDMS in a way that would permit GPL licensing although he was working as an employee of the Porto Rico government, and also deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.

 

Remember, if it’s important, seek professional guidance!