Closed fosterlynn closed 9 years ago
Possibly should be a separate issue, or possibly part of this one, we'll see: I assigned a context agent to my sale, and then of course my customer disappeared, because the customer is the customer of the exchange firm.
Either the exchange firm is the context agent of the sale, or context agent does not apply to a sale. But we need to find the sale from the context agent of a distribution. I am now finding the cash receipts by exchange firms from a context agent by looking at the virtual account the cash receipt was posted to. Which, as you mentioned in another place, might fail if the exchange firm uses a more general virtual account. That suggests to me that either the exchange firm must be a context agent and have its own value equation, or the "more general virtual account" needs to belong to some context agent that has a more general value equation and can distribute the income.
Short version: cash receipts must go into a virtual account that belongs to a context agent with a value equation that can distribute the income.
Further discussion:
First decision: is the exchange firm managed inside the installation of the software? I think it should be, so there is openness and accountability - the exchange firm is simply a tool of the network, not someone's property.
Also, I think we can put the exchange firm into the context agent place in sales. Will be useful to have there.
Then, the customer payment goes to the exchange firm. So the cash receipt is logged into the account of the exchange firm, to be accurate. Should the exchange firm run a distribution to the different projects based on the shipments? Does the exchange firm take out something for its expenses?
Or it could be possible to split out the cash receipt by project in the sale, then each project would have its money in its virtual account already.
We can tell the context agent of a shipment, or from a cash_receipt.exchange.order.order_item.
Testing exchange firm as context agent.
I tried making BDan a context agent. (Created a new agent type called Exchange Firm, made that a context agent type. Changed BDan's agent type.) BDan shows up on the Organization page as peer of Sensorica (fine), all associations intact.
Created an order with BDan as seller, processes from recipes are created correctly, using process type context agent. Sale commitments also created correctly, using BDan. But commitment order items are created with BDan as the context agent, this seems wrong, as this is the commitment to produce. The rest of the commitments are correct.
Logged work, logged output produced, logged some other inputs. The output seems to be the only event that showed up with BDan as context agent. I think that is incorrect. The to agent is the recipe context agent, possible should be BDan, but I don't see that this matters anywhere.
Logged the sale - shipment, cash receipt, those showed up in context of BDan, which would be correct.
Tentative conclusion: Reasonable solution is to make exchange firms context agents. We can fix the one problem with output production event. Could fix the order line item commitment if there is a recipe, but not if there isn't. Need discussion on this.
This makes it possible to also manage the exchange firm in the network software.
Made the output event on process logging use the context agent of the process rather than the commitment (which is still the exchange agent).
Made the output commitment use the context agent of the process (from process type), when it has a process.
Orders don't have a context agent, and probably shouldn't, as customers can order things from different projects. If using an exchange firm as the seller, there is really no way to find a context agent. The current code put the exchange firm in as the context agent (uses the seller), and it isn't a context agent, so doesn't show up in the dropdown in the sale exchange.
An exchange firm can be used by many context agents.
Perhaps a context agent for the sale exchange is not a valid concept?
Needs some thought.