OpenPapyrus: [yet another] Open Source ERP System
Good afternoon. We published Papyrus enterprise management system in source code under the name OpenPapyrus . The project is also published on the sourceforge server .
I will describe the technical aspects in a separate article, and here I will briefly talk about what OpenPapyrus is and why this system is worth it to familiarize yourself with and start using it.
OpenPapyrus is an infrastructure business management system that we have been working on for over 20 years (since 1996), having developed an extensive functionality for managing a business in a wide range of segments.
Until now, we sold the Papyrus system only as a proprietary product. In the future, we will develop both products at the same time - proprietary and open (especially since they are almost the same thing).
We consider (Open) Papyrus one of the best systems of this class in the Russian market. The statement, of course, is strong and subjective, but now that
Here is a possibly not complete list of business segments in which OpenPapyrus works great:
- Retail
- Pharmacies
- Wholesale
- Cafes and restaurants
- Beauty Salons
- Fitness clubs and sports centers
- Small production
OpenPapyrus can do very, very, very much everything and almost everything, a lot of it, does well. An attempt to list the functionality of the system lies there on github . We tried to classify all the functionality and make a list by which we could compare the system with competing solutions. But in my opinion, the attempt was not very successful (although we, as far as possible, keep this document up to date).
A very abstract column of functional blocks is as follows:
- Accounting
- Procurement management
- Sales management
- Account Management
- Retail sales management
- Point-of-sale
- Manufacturing control
- Personal Events Management
- Project and task management
- Infrastructure Functionality
It will probably be appropriate to note that we have a solution for mobile sales agents (StyloAgent), a mobile waiter for restaurants (StyloWaiter) and a module for data collection terminals (BHT). So far, we are not posting these products in open access, but not because it is a pity, but because of technical obstacles.
The system is developed and developed in accordance with several not complicated principles, which, basically, determine its appearance:
- Conceptual integrity and consistency. If it’s human, it means, for example, that we don’t make patches in order to satisfy any client’s request, but we apply and (or) expand existing concepts for this. If the development of a new concept is still necessary, then we plan and work it out with a view to future use.
- Maximum unification. It is a pity that the term "Occam's principle" was exhausted by applying to a place and not to a place, otherwise it would have come up here. But in general, the idea is the same: if a certain entity can be reflected in the system once and then reused, then there is no need to multiply it.
A simple example: personalities, as subjects of civil law, are represented by the data object of the same name, and not by a set of “buyers”, “suppliers”, “physicists”, “lawyers”, etc. The issue of classification in use is a technical problem.
Similarly, the concepts of “warehouse”, “address”, “warehouse cell” and “organizational unit” are all represented through a single functional object “location”.
Similar approaches are also used in the development of system code - most of the blocks are built according to template methods with extremely unified interfaces. The result is easily noticeable in the size of the distribution kit - it is very modest. - The primacy of reducing the cost of support. To put it in Russian: if two or more clients contacted for the same reason, then it is cheaper to change something in the system than to respond to the same calls in the future.
- The elimination of defects has the highest priority over all other problems and is carried out without any conditions. With this, everything is more or less clear. Obviously, this principle is tightly connected with the previous one.
Given the age of the system and the fact that some companies use it for 10-20 years, it can be assumed that these principles work. They also have a side effect: the system in the end was not very obvious in the setup, which, however, was blocked by the ease of use for end users.
There are no functional differences between Papyrus and OpenPapyrus. True, we do not yet fully understand how these two options will coexist from a marketing point of view.
Support remains paid, but we very much hope that there will be enough people and companies who themselves will be able to figure out what and how, and, moreover, will be able to sell their consulting services to other companies.
There are installation instructions on both github and sourceforge. Installation for review is very simple. There are no assembly instructions from the source code yet, but the clone of the source code is definitely going to - we have carefully checked this.
Documentation (large, but still not complete) is there.
Before you round, I will give a couple of interesting facts:
- Papyrus can manage web content. We do not position this feature as replicated, but the content of the Petroglyph website and the Universe-HTT website (for example, there is one of the best barcode directories on the network) is controlled by the Papyrus server, which is covered with Java bindings from etc.
- The protocol version of Papyrus has been going on since its birth. In a digestible form, it is available on the Petroglyph website. Conversion to html is done automatically by the same Papyrus. In github releases, we give the appropriate link.
And finally. For what? The main reason is existential: it’s worth sharing what we have been doing for more than 20 years with the rest of the world, especially since we ourselves use the results of the open source community. The remaining reasons are small and boring - you yourself know about them.