-
Notifications
You must be signed in to change notification settings - Fork 46
Concepts and Names
The concepts in the valuenetwork valueaccounting app are based on the REA economic model.
REA stands for Resource, Events and Agents. You can read about it on the inventor's website.
REA was originally designed in 1982 for internal accounting in a single company. However, in the 1990's it was expanded to cover economic interactions among many companies in supply chains, and now in value networks.
This wiki page is a bare beginning of documenting the REA concepts, how they are used in the valueaccounting app, and how they are applied by real value networks like SENSORICA.
We will first deal with the three levels on which the REA model works: Types, Plans and Events. The reason for starting here is to discuss names for these concepts. The REA names are often too abstract for normal people, so we need some feedback from prospective users (e.g. SENSORICA members, although anybody else is welcome to join by raising issues on this github project).
Here's an overview of the REA levels:
All of those levels and their relationships are necessary, but the names may not communicate.
Economic Resource Types are definitions of resources. For example, the definition of a product, like the definition of a SENSORICA sensor.
An Economic Resource is an instance of a type: for example, one tangible sensor.
An Economic Event is a change in the quantity or ownership of an Economic Resource performed by Economic Agents (for example, the production or sale of a SENSORICA sensor). Each of those events would be defined by an Event Type (production or sale).
The Plans level contains Commitments, which are promises for events that have not happened. The Plans level will also contain schedules, orders, etc.
So, do you understand the concepts? If not, please raise questions. If so, please suggest names that would make sense to you (or respond that you are ok with the abstract names).
To help you think about it, here is a version of the upcoming user interface for maintaining Extended Bills using the abstract names. Does it communicate to you?
(And by the way, the Extended Bill might need a new name, too...)
The Extended Bill is a structure that lives at the Type level. When SENSORICA gets a commitment from a customer for product delivery, the Extended Bill will be used to generate manufacturing process schedules, commitments that members can take for making the required products, requirements to suppliers for the required components, etc.
Then the participants will perform the actual manufacturing events, which will produce the products for the customer.