Discussion about the former topic only.
Table of Contents
What is Open Order¶
Open Order is often used for two different meanings:
- An order which repeats the same request with some interval (e.g. monthly).
- An order which takes inputs from a customer from time to time to adjust shipping amounts, based on some agreement.
The nature of Open Order¶
Open Order is different from usual Order in the following aspects:
- Open Order spans over a (more or less) long term, while Order is one-time. So, in most cases, you don't know when an Open Order is terminated.
- Open Order itself may not always be linked directly with any invoices, because invoices can be created, based on how much used instead of how much provided, and you don't know how much used until it is really used.
- Invoicing is not always caused by shipping. Usually, with normal orders, if shipped, you are invoiced. But in some services it is very casual that they are effective for some time after closed. For example, many companies provide services until the end of a month, even if a subscription is canceled at a middle of the month.
The design of Open Order¶
We have spent a lot of time and effort to produce a good design of Open Order, and I think I finally reached an acceptable level. So I would like to describe my idea (confirmed by Yusei).
Contract¶
First of all, the main question in our last discussion was about What represents a contract in ERP5. In case of normal orders, they are sort of contracts. One-time contracts. But in case of Open Order, do they? We don't think so (although we thought so some weeks ago).
The reason is due to pricing. If you decide that Open Order is a contract, order lines contain prices. But if you want to change the prices on the same contract, how would you do? If you modify the order lines (e.g. by resetting the prices), you lose the traceability, because the order lines do not remember past pricing. If you create yet another Open Order to make price changes, Open Order is no longer a contract, because you have two documents for a single contract, and this is contradictory.
That is why we must have something else that represents a contract. Thierry suggested that Trade Condition was a contract, but I didn't agree initially, because Trade Condition is not capable of making minor changes in a contract, except for price changes, because Trade Condition itself has many properties.
However, I was wrong. This misunderstanding was only because the current implementation of Trade Condition is partly wrong. Basically, we must use a predicate-ready structure for most properties/categories, just like Supply in Trade Condition, except for properties which may not be changed, once a contract is signed (e.g. information on signing parties).
Once this is corrected, Trade Condition is a perfect place to put information on a contract.
What should be in a contract¶
The next question was what must be recorded inside a contract. For clarity, here are elements required for Open Order:
- Periodicity¶, which defines how often resources will be delivered or invoiced.
- Forecasting Period, which defines how far the future should be simulated.
- Resources, which are services or products delivered, based on an Open Order.
- Quantities, which are the amounts of Resources delivered.
- Dates, which define a term of a service delivered.
In our understanding, a contract only says the conditions of trades, if happens. A contract does not say, at least not always, if it happens. For example, I can make a contract that I can buy one product with 80 EUR from Nexedi. But this is not the same as I will buy 30 items of this product in next month. So, this kind of information must be handled with Open Order. rather than Trade Condition
For now, I think that Periodicity¶ must be defined in Trade Condition, but the others must be in Open Order. Forecasting Period is clearly different from a contract, because it will be used only internally. What is really sold should be in Open Order, so Resources, Quantities and Dates should be in Open Order.
However, I am still not so sure about Periodicity¶. This could be in Open Order. Maybe it could be in both. I don't know.
Dates of Open Order¶
Unfortunately, Open Order is quite complicated, because what is provided is not always what is invoiced (see the above). So dates must be carefully applied:
- start_date is the date of starting a service physically.
- stop_date is the date of stopping a service physically.
- effective_date is the date of officially starting a service.
- expiration_date is the date of officially stopping a service.
However, Yusei has found a serious problem in the current ERP5, because we have no way to distinguish what is really invoiced. For example, think about the following case:
- You want to issue an invoice from the beginning of a month, always.
- A customer came at the 25th of February.
- In your representation, start_date is the 1st of February.
- In your representation, effective_date is the 25th of February.
- But the customer does not like to be invoiced for one entire month, only for a few days remaining in February.
- So you agree that you will not issue an invoice for February.
- Then, the invoice date is the 1st of March.
But what is this invoice date? Obviously, we lack such a property in the current system. For now, the only way is to cancel an invoice manually in the system after generated. Not quite clean.
Simulation¶
Previously, I thought of expanding an Order Line to multiple Simulation Movements, so that we could simulate repetitions. I think this is good, but, after that, not so good. I thought that Open Order. should generate Packing Lists, but probably this was wrong.
One reason is pricing again. If we share a single Open Order for past and future Packing Lists, we lose information about decisions, once pricing changes in the Open Order.
So, for full traceability, we must generate usual Orders from Open Order. So this is a matter of Order Builder instead of Delivery Builder. This way, the user can see how decisions have been made, thanks to saving past Order Lines, as they were.
Nevertheless, the idea of expanding one movement into multiple simulation movements is good. So we don't need to change this part. But the implementation by Rafael has a scalability problem, because it tries to expand all Open Orders to all possible Simulation Movements. This kind of algorithm will get broken, as the number of Open Orders and Simulation Movements increases.
So the right implementation must ignore as many simulation movements as possible when expanding.
Basically, when an alarm triggers such an expansion, there is no need to look at already expanded simulation movements, because nothing in the Open Orders must have been modified, so no need to update existing simulation movements.
Next, when something is modified in an Open Order, an expansion happens, but, in this system, simulation movements which have been used to generate orders (e.g. Sale Orders) must not be modified any longer, since we must assume such simulation movements are immutable (otherwise we have no condition to make them immutable, and this is a big problem!).
So, we need to have a quick way to check what are still mutable. If we look at all past simulation movements, this is too heavy. Probably this could be inspected, in a somehow heavy way, by an SQL.
Periodicity¶
The current implementation of the periodicity mixin has some shortcomings in the feature. For example, we don't have a way to specify the end of a month. Or, every 10 days after start_date (note that you can say the days which can be divided by 10 instead). These are easy to fix.
Non-resolved issues¶
Usage-based invoicing¶
I believe that the current design of ERP5 Trade is not quite suitable for business that requires continuous services. In this case, invoices are often generated with how much really used rather than what can be used. For instance, if you provide a network service in a certain period, you must provide the service, but this is not always linked with any invoice. Instead, you might want to count how many times the user really accessed your service.
In Open Order, you can define what you will provide, but you cannot specify how much it will be used. So the result of the simulation is, after all, only about the vendor side. Logically speaking, there is no way to simulate how much used, so this is not a target of Open Order directly.
Nevertheless, the user can use your service, because you set up the service, and make it ready to use. So how much used should have the causality from the packing list at the vendor side. And, what is invoiced must be defined by following the causality links (from a packing list about how much used to a packing list about what is provided, then to an Open Order).
Unfortunately, this kind of distinction is very ambiguous at the moment in ERP5, I think. In this case, the user might want to invoice a customer, against the provided service. Or, partly. Or, not at all. The user is sometimes invoiced, based on how much used, sometimes not.
These are very essential, but we often use a single resource to represent both (or just ignore the fact that the service has two aspects). Theoretically, the beautiful way is to have both, and distinguish the resources used for them.
Continuous vs. Continual¶
In case of intangibles, services are actually classified into two categories:
- continuous services, which keep active all the time basically. For example, hosting services are mostly of this type.
- continual services, which get active only when really provided. For example, training services are mostly of this type.
This distinction is not so important in usual orders, but in case of Open Order, this is very important, because the simulation need to calculate start_date and stop_date correctly.
But who should say the information? Probably, this distinction itself should be stored in Services. But in case of continual services, we also need to specify how long it would take, because stop_date may not be defined automatically (note: in case of continuous services, stop_date can be just right before next start_date, so this is trivial).
Who should specify how long a service can take to be provided? The service itself? Or, order lines?
Related Articles¶