Simplify the process of creating an Exchange in work app

[bum2]

Now in the project-planning branch we have this exchange creation feature (now testing in testocp), but i think it can be improved:

In the project editor page (work/agent/x) we go to the exchanges page (work/agent/x/exchanges) and there we can choose the 'exchange type' to create a new exchange (step 1). When you click there you go to another page (exchange-logging-work) that asks for a date, a link and a comment (step 2). After saving, the form appears finally, but the left data is always the same.

My proposition will be to join step 2 and 3 in the same page, because now makes no sense (because the context agent is already known?) to have that in separate steps... Please correct me if i'm wrong and is needed like this for other reasons.

[fosterlynn]

Background: 2 and 3 are actually one page, but the transfer side doesn't show up until the exchange is saved because it won't work for people to enter transfer information with no exchange. (The exchange is the left side; the transfers that are part of the exchange are on the right side.) But partly it is also left over from when the context agent and the exchange type were entered on that left side and it needed that to lookup what is needed for the right side.

So that is the background. And I hope that it can in fact be improved. Maybe just save the exchange whenever transfer info is entered, if there is no exchange? Might be kind of messy though. Will require more thought.

[bum2]

I know why is needed, but I think the fast solution is to autosave the exchange when entering the page, just with the actual date (the required field) and a note like 'please set and save the right exchange date here' next to the date field. This way the transfers part in the right side will show up from the beginning. Is not perfect but i think is better than now and fast to do.

[bum2]

About the Exchange system I have some still some doubts that @fosterlynn or @bhaugen can answer:

• The separation in 'incoming', 'internal' and 'outgoing' exchange types is strange to fit in some cases. Nearly always there's both incoming and outgoing resources from the project in the same exchange. If we only account as resources whatever but not money, then is ok, incoming products-services and outgoing prods'n'servs of each project, and the money usually goes the other way around. But then, what about a real exchange or trade without any money? is it incoming or outgoing exchange type? is both.

I'm proposing a set of common exchange types (see testocp), based on tree kinds of economy: Gift economy, Exchange economy, and Monetary economy. For the gift economy is easy, donations are outgoing and receivement of donations is incoming. For the Monetary economy can be easy thinking about money not as a resource, sells are outgoing and buys are incoming. For the Exchange economy i'm setting them as 'internal' exchange types, but i think is wrong anyway. I'm trying to test how it can be putting the different coins as resource types, so now we have FairCoin as a testocp resource type and also we can set other digital or physical currencies as resource types (for example to permit the management of the exchange offices), what you think about this? ... What you think about the 'incoming-internal-outgoing' concept? I know they produce what's called Supply and Demand, but that's also not very clear for me in this multi project, multi sector platform we're doing. I'm thinking about them as: Supply are products offered outside OCP by any project, like a marketplace (connect to fairmarket?) and about Demand are only customer orders for any work to be done by any project or team in OCP. This way all other exchage types will be internal. Another way to think about them, more advanced, is like: Supply is all the offered stuff by productive projects, both inside and outside OCP (also with a browsable internal marketplace), and Demand is whatever needs of any project, so internally can be matched with another ocp project supply (to cover this needs). That can happen as a gift, as an exchange or as a monetary buy-sell. This demand section can be for projects to place needs and see other needs, and it can have this part of external work orders by external companies (with a defined budget or asking for it), but then, which ocp project will take and do the job? If more than one project can do the requested job-order, what criterias should apply to give the job to one or the other? ... One idea can be to make the customer always choose which ocp project is asking for the job or budget-proposition, but anyway there's no any such 'customer' role yet, pending to think about how can it be and why. In this OCP we are confronting all the time the old business concepts of buy-sell with new economy concepts, all together in a multi scope resource management platform.

• The other doubt i have is about normal tranfers and 'reciprocal' transfers: in a buy, the reciprocal is the payment? in a sell, the reciprocal is the selled resource? what about an exchange without money? what about donations in or out? which transfer should be 'reciprocal'?

[fosterlynn]

I think the incoming, outgoing, internal exchange types separation doesn't make any sense for OCP - as you pointed out, all are part of the network. When I put them into the work app, I just combined them so nobody sees the difference. Some day we can fix up the admin side.

The question about transfers and reciprocal transfers: we do need this, but if it unclear because it is straight barter for example, just pick one. For most exchanges, I think of the transfer as the main reason for the exchange, irrespective of what came first. So if you are selling or purchasing (just flip sides of the same thing) something for faircoin, faircoin is the reciprocal transfer. It also probably doesn't matter a lot, I think the only thing it really does is put transfers on top of reciprocal transfers on the exchange screen and report.

I'm proposing a set of common exchange types (see testocp), based on tree kinds of economy: Gift economy, Exchange economy, and Monetary economy.

This should be discussed with the admins i think. Anyway, that is all data, so can be tweaked over time. But perhaps we should do the training on exchanges, we never got to it earlier. And discuss at the same time.

[fosterlynn]

what about donations in or out?

Donations probably only have a transfer, no reciprocal transfer, unless you are offering some prizes for crowdfunding or something.

[bum2]

Ok! I've pushed more developments in the project-planning branch and is again deployed in testocp for all you to test and give feedback.

The Exchanges page is working (maybe not with old types) but also I've added a Resouces page for projects (work-in-progress, it filters but still not adds resouces or resource types)... As soon as i can finish the 'add new type' form and a way to manage the trees easily, then we can start the open process of building a common ontology of types in OCP. More coming this new year... my best wishes for you all!

[bum2]

About the creation of new exchanges, it can be avoided the need of creating custom exchange types for every project's context (and use a set of common kinds of exchange) as long as we have another way of setting the main exchanged resource type (or a whole branch in a tree), even custom, in order to have the resource-types pre filtered before setting the exchange transfers and commitments.

Now the model is to attach facetvalues to each transfer of a single exchange type, but my proposition is to let the user choose two things before creating a new exchange (in the exchanges_all page): the exchange type (give, receive, exchange, buy, sell, rent, etc) and also a main sector (tree-branch = facetvalue) or a specific resource type.

That way the exchange types remains as such, not directly related the resources types, and they can then be common. When studing the platform and developing from it, i'm learning that the main model we need to relate to a context is the ResourceType, and the exchange types don't really need a context if they can be transformed the way i said. I'm not sure if that transformation is possible or if it's too hard to adapt the rest of the code (perhaps is not too much? you know!).

As we have it now, i'm only separating resources in 3 groups (the facets) and making triple exchange types (eg. give material, give non-material, give service time), but that will lead us to open really the new exchange type creation system for projects... (in order to filter in smaller chunks the dropdowns).

I think all that part about creating custom exchange types, transfers and so on, can be avoided for users and make it more simple with predefined transfer sets, only getting the types scope from the initial resource type or sector chooser. The transfers related money will be predefined as such (showing only money related types), and so on... only the main resource type exchanged filtering is inherited from the initial chooser in exchanges_all page (in the case of trades another full resource type chooser will be needed when setting the transfer in exchange_logging_work page, or a double resource type chooser appears initially when a trade type is selected).

Another small thing very useful that will be good to add in the Exchanges page, even if the transformation I'm suggesting is doable or not (you'll say) is to autosave the exchange automatically (with the actual date) when entering first time to the exchange_logging_page ... i think is very easy and don't breaks nothing, making things clearer.

[bhaugen]

I think you need to get some concrete use cases from some collectives and individuals about what they want to do with exchanges. What they want to trade for and with, etc. And then figure out what is the simplest way for them to do what they want to do.

[fosterlynn]

@bum2 to make sure I understand: The exchange types can be global because the user would pick a resource type branch whenever they actually create an exchange? Or perhaps for each transfer within the exchange?

[fosterlynn]

Another small thing very useful that will be good to add in the Exchanges page, even if the transformation I'm suggesting is doable or not (you'll say) is to autosave the exchange automatically (with the actual date) when entering first time to the exchange_logging_page ... i think is very easy and don't breaks nothing, making things clearer.

I think this would definitely be simpler and more clear for the users, and I don't think it breaks anything.

Now we already know the context agent and the exchange type, so good to go.

[bum2]

@bum2 to make sure I understand: The exchange types can be global because the user would pick a resource type branch whenever they actually create an exchange? Or perhaps for each transfer within the exchange?

I was thinking on the first: one of the transfers of the selected exchange type will not be defined like the other transfers (in coop admin), because it will get the resource type subset from this new chooser i'm proposing in the Exchanges page, next to the exchange type chooser, in the create new exchange form box. The 'special transfer' inheriting the types preselected will be always the main transfer, and the other transfers will be common with resource types like money, bill, quote, recipe, etc... for the selfemployed it can appear also 'invoice', etc. The other way you say, transfer by transfer, is of course better and more flexible, but I think it will be too complex for users to start with. Maybe in a future release we can offer that level of detail too...

I think you need to get some concrete use cases from some collectives and individuals about what they want to do with exchanges. What they want to trade for and with, etc. And then figure out what is the simplest way for them to do what they want to do.

I have some use cases in mind (mainly dezentrale, local nodes, exchange offices), but the point is that the projects needs everything, so if we offer to set exchanges in ocp, they will try to manage their exchanges here, if we offer to manage an inventory they can use it for their stuff, if we offer to add customers or suppliers they will set their needed ones to track buys and sells, etc. Every project has resources, skills, suppliers, makes buys and exchanges, etc. The main issue is to offer asap the Plan Work system, but that includes exchanges, resources and resource types, locations, skills, patterns, orders, processes and every one of these is a big thing itself and i think all them need a deep revision (to make them simplier and multi-context-aware) and sometimes need redefinition of the UI or small changes of the structure (from my point of view). Once i get + o - ready with the resource types creation flow, then i can go again to the exchanges part or the planwork part and adapt all to the new resource-types system. After that we still have to adapt somewhat the skill system, the locations system and sure i'm forgetting some parts, all included in this super-release.... Will be marvelous to split in smaller releases, but really I can't find a clear way to publish only one or two of these things... they go together, don't you think?

[bhaugen]

I have some use cases in mind (mainly dezentrale, local nodes, exchange offices),

Let's get some of them engaged in this discussion, and in the design and testing. Otherwise we have a circular design argument between you and me and Lynn. We will just back out of that sooner or later, because we are too far from the action. But if you design this out of your own mind, without early feedback, you could easily paint yourself into corners that it will be difficult to code your way out of. We've been there and done that.

[bhaugen]

@bum2 what dezentrale exchange use cases do you have in mind? When Lynn and I talked to Chris Zumbrunn, it seemed like they would have a very small number of very simple exchanges that could be easily handled by custom exchange types, like Rent Room. If I understand correctly, they had a small number of room rental options. The Exchange Type could be called Rent Room, and the selection list could include only dezentrale exchange types, so would be very small, and the Rent Room exchange resource type selections would be a small number of room options. No confusion, very small number of decisions to make, and all self-explanatory to them.

I tried to do something similar with their meal reporting. You can see an example here:

• here's the recipe: https://testocp.freedomcoop.eu/accounting/xbomfg/44/
• here's a work order generated automatically from the recipe for a week of meals: https://testocp.freedomcoop.eu/accounting/process/24/

I'm not sure that was simple enough. Chris never got back to me on it. But that's the direction they wanted to go in: really simple. People would report what percentage of the cooking and cleaning they did for the week, and how many meals were served.

[zumbrunn]

That is correct, and the intentions/requirements for this haven't changed, although during the last weeks, I've been trying to wrap my head around how mutual credit accounting at a larger scale, for our local needs beyond the Décentrale will connect with what bumbum has been working on.

Moving forward with the config and practical use of OCP for Decentrale in the way you described is VERY, VERY high on my priority list.

[bhaugen]

@zumbrunn thanks for responding to the call. @bum2 is doing a lot of work to improve project configuration in OCP, and has a lot of ideas. It would be a great time for him to discuss them with actual projects and get some feedback.

[bum2]

Of course @zumbrunn lets talk whenever you like, just ping me... Here my last update text from tgr (please take a look on testocp and say something!) ... i'm trying to finish many pending things still, but i need to know if the exchanges interface is going in the right direction or not, what you miss or what you think is too much, rewordings, etc:

I want to propose a change in the ocp exchange interface, which intends to hide some layers of complexity to the users, and let admins make whatever config we need in the transfer-types as predefined sets (tree branches) as common exchanges types, with one of the transfer-types inheriting the resource-types from a ocp_artwork_type item (one2one of resource_type, but can behave as parent of sub types, like categories) setted at the exchange-type level (ocp_record_type in this case, another one2one)...

That is forcing a grouping and automating of the transfer-types options (fields), to keep tree branches to the minimum. The idea is + or - is: depending on the choosed branch of exchange type, the transfer options and sequence are preselected one way or the other. Also some check can be added later in the new exchanges page to custom-set things like 'value_equation' or 'distributable' (let's think how is best), but only for the 'main' transfer type in the sequence. I've added a bool in the TransferType model ('inherit_types')...

I know is a lost in flexibility at user level but i think can be an increase of easiness of the UI, and later we'll see. Also it intends to open the creation of common trees of types, and also is able to manage the smaller-scope of types by context agents inherited, so some branches or types can be hidden for regular projects, only shown to some of them if they are members of certain groups, etc. In testocp, as a test example, only projects related faircoop (local nodes, etc) can see the 'exchange currencies' branch of exchange types (not shown to regular FreedomCoop projects)...

What it worries me a bit is that still now we are creating a bunch of transfer types for every exchange type or subtype (now copying options from parent exchange type) and some transfer types can be mostly clones (just different id and related exchange_type), so a question will be if the transfer types can be somewhat shared among diferent exchange types or not at all. Now is a FK but I don't know if it can work a M2M in this and all the other structures of the platform...

As you will see, i also get rid of the ocp_material and non-material models, because they was not making sense due that resource-types in ocp and artwork_type in 'general' app are conceptually "the same" level.

Another think it worries me is to split this huge 'release' in smaller releases of the code, and the only way i can think of now is to postpose a bit the 'plan work' features and release 1st only the exchanges and the resources (which is huge enough). Then 2nd with improved skill system around and fix bugs. Then 3rd the whole project-planning features, with the new resource types choosers and so on...

And even another structural thing is pending to decide together: is it a good idea or not to manage a 'faircoin' resource_type like other ocp types? and if so, is it a good idea or not to account as exchanges the wallet page behavior and history? if we can mix all together, when creating an exchange, if the transfer involves faircoins, then the wallet can be linked somewhat to make really the transfer, and see in history if is done or not, etc.

[fosterlynn]

I've been trying to wrap my head around how mutual credit accounting at a larger scale, for our local needs beyond the Décentrale will connect with what bumbum has been working on.

@zumbrunn I started a new issue for this, pinging you here because I don't know how much you keep up with the github stuff..... https://github.com/FreedomCoop/valuenetwork/issues/209.

[fosterlynn]

I have a question:

Do you think @bum2 that collectives using OCP will do a lot of trading with each other? If so they will need to share exchange types (and exchanges).

@zumbrunn do you think Decentrale will do some trading with other collectives who are using OCP, and if so, in what time frame?

[bum2]

Do you think @bum2 that collectives using OCP will do a lot of trading with each other?

Not really at the beginning, but I see that 'exchanges' are an easy entry point to OCP, where you can start placing the initial project resources and tools (perhaps as donations from members) and start tracking external exchanges like renting spaces (dezentrale), currency exchanges (local node offices), paying of fees (selfemployed), etc. Of course they need to share resource types, but you said they also must share exchange types and exchanges... is it really? the exchange types i'm trying to let them related a general parent context, so they can be used by many projects, and only the very special types of exchange are reserved for smaller contexts, like the selfemployed tools and fees stuff. About an exchange, if the coordinator involves another agent in the exchange, that needs to appear somewhat in the other agent's view. If is a transfer, for sure a new resource will appear in the receiver's view, but not sure about commitments... If the exchange is a buy or sell, perhaps is needed an Order to make everybody involved aware of the operation? what about givings or exchanging? perhaps a simple notice of gift arrival to the receiver (in the giving type) and a pending task to transfer resources in return of an exchange placed by the other agent (in the swap type)...

That practical part of the exchanges workflow will be defined as soon as we see which kinds of exchanges are being used first. The first use case is going to be the fees payments, because will be between ocp agents. The space renting will be the second case because we need to figure-out how to add agents that are not necessarily ocp users, like any client, or when buying to random providers... In this regard I want to propose the adding of needed entities and companies as a common shared repository of existent entities, and if one day the 'userless entity' gets closer and became a member or a simple ocp user, then the agent is already created from before and only a collective-user or a coordinator will be set for them to manage the agent in ocp.

The feature to "find and add if missing" a client or provider name, creating a common userless agent, is still missing nowadays. Let's think how can it be the process and how later the agent is reclaimed and a real user is created, if the person or a company representative comes to use ocp...

[fosterlynn]

Testing: Added an exchange using existing exchange type Donating Non-Material Resources. The exchange was created. I added a transfer, which was not created, no error message. As part of the transfer, I created a new resource, resource type Document.

Another one: I added a skill, it gave me an error of no parent, even though I did choose a parent.

[fosterlynn]

Question: Is there any provision for having more than one transfer or more than one reciprocal transfer in an exchange type? We have seen this done.

[bum2]

Question: Is there any provision for having more than one transfer or more than one reciprocal transfer in an exchange type?

I think is good to have more transfers in some exchange types: for example in monetary economies you usually get a ticket or a bill, or in a design work there's a initial proposal+budget document to client, client payments to worker, and for selfemployed there are invoices or bills around... so i think most of the other transfers (apart from the one with the 'main' resource type) will be 'documents' of some kind (a defined sub-category of resource types). I was thinking to make exchange type branches for these options (eg. accounting or not, etc)...

Another one: I added a skill, it gave me an error of no parent, even though I did choose a parent.

Most of the types are still not connected to real resource types in ocp (only the types with '<' are linked)... yes it is a hard config job to start a starting set of types, all 'connected' (available), but once we have a starting set, then the child types will inherit from parents the transfers structure, facet-values, etc.

I added a transfer, which was not created, no error message.

i look on this asap...

[bhaugen]

Strictly speaking, from an accounting point of view, invoices or bills are not transfers. They are just documents representing claims for payment.

[fosterlynn]

One example in Sensorica of 2 transfers is for purchases, where they separate the receipt of the things that were purchased from the shipping, which is a different transfer type. Then there is also a reciprocal transfer type for the payment for both things purchased and shipping. So 3 transfer types in one exchange type.

[bum2]

Strictly speaking, from an accounting point of view, invoices or bills are not transfers. They are just documents representing claims for payment.

I know they not transfer value, but a paper or a doc is exchanged between agents, and can be related other doers or other days, etc. I thought was good to track as a separate transfer each movement, but you are the ones that know really if makes sense or not.

The sequenced example i was thinking, related docs, was when doing a design job (sell non-material): you transfer a proposal to client, the client payments (probably in parts), and transfer of the final goods to client.

About the renting exchanges, for the same transfer type will be many transfers for each month (day or whatever) to place there, also if there's a bill to make and give each time can be tracked (who commits or does the giving of a bill).

[fosterlynn]

Yes, I think we should separate out all the documents and paperwork that surround economic activity. We can create all of that from commitments and events. Proposals, invoices, purchase orders, etc. are just reports of what is going on.

I just wasn't sure from running in testocp that we could now support more than one transfer type and one reciprocal transfer type for an exchange type. It sounds like we can?

[bum2]

yes Lynn, we can make exchange types with many transfer types if needed...

I'm going to report a bit what we have now in the Exchanges page (and what is missing) in the project-planning release: The exchange process is explained in two sentences:

"Choose a previously used Exchange Type to copy the model [selector] ... ...or search an available exchange type [search] ...or make a new one: [show but]"

and if you unfold, then:

"...choosing a use case: [tree of exchange types] ...and/or to narrow your options, choose a main Resource Type branch: [tree]+[search] (...if nothing fits: [new type]) ...or choose a related Skill Verb (service time): [tree+search] (...if no one fits: [new skill])"

This interface creates a new Exchange Type on the fly when creating an Exchange, if the resource types are narrowed for that exchange.

• So if we choose a general exchange type and that fits for our operation: no new exchange type is created but the Exchange is created and the exchange logging page is showed.
• But if we choose a smaller branch of resource types or skill types, then a new exchange type is created (and ordered as a child of the parent exchange type) together with the new exchange, and directly goes to the exchange logging page.

In this unfolded block to narrow the resource types options of an exchange is possible also to create and edit (if you are the creator) new Resource Types and new Skill Types:

When creating a new Resource Type we need to set:

• a unique name,
• a parent type or branch,
• a context (defaults to OCP general but can be narrowed the context to a smaller project, ancestors of the agent)
• if is substitutable or not Optionally can be set:
• a unit type or branch and a faircoin price per unit (if is common one day)
• a related resource type for the cases of direct and unique relations with another type, like the relation of a musical artwork (non-material) and a CD with that music (material), etc.
• a recipe inheritance from another resource type (which has a recipe)
• a related url, photo url or the description of the resource type

When creating a new Skill Service Type, the idea is to grain it a bit more, separating the action verb from the related resource, and in the form is needed:

• a unique name of the Skill type (normally the 'name' form of the action verb)
• the verb of the action, infinitive and gerund
• the parent skill verb type
• a context (same as above, ocp or smaller) Optionally can be set:
• the main resource type the action is related to. If choosed, this becames part of the shown name in the tree (like in 'repairing machines', you set the verb 'to repair' and choose 'machines' from the resource types)
• a unit of Time measure and a fixed faircoin price per unit (if common). Hours by default.
• a related url, photo url or the description of the skill type

TO DO:

• 1. Multi unit-type Totals block for this page, searching the total values of the project exchanges, incoming and outgoing (from the project's view), with the used Unit Types in the recorded exchanges. Normally FairCoin for values but can be added easily Hours currency, Social currency or Fiat currencies as needed, and this Totals must show them separate in rows (the columns are 'incoming' and 'outgoing'). We can even track kilos, liters or whatever used Unit type (not only value) if needed.
• 2. Integrate the project's fairaccount 'wallet' history and behavior in the exchanges page (as they already are) and when a transfer involves Faircoins, the ocp wallet page should be linked or showed, and the real payment makes the transfer done in the exchange. Also track any real Faircoin using the FairCoin resource type, so they are resources of the project or the user agent (shown at resources page).
• 3. When choosing an Agent for a commitment or a transfer, we need to be able to search for common agents and create a new agent if needed, all them from a common repository of companies, agents and agent types. These economic agents will not have a user or coordinator member but are needed in the system. Must be defined a provisional process for the cases that the provider, customer or friend becames a ocp user, to make him/her the user related and coordinator of such an agent pre-created by other users (like claiming their company or identity).
• 4. From the Exchange logging page, incoming transfers or resources permit the creation of new resources (of the choosed type), maybe that is ok, but for the outgoing tranfers in a exchange maybe is needed a text and button to 'Make a Resource' that goes to a Work Plan for creating or producing the Resource (show recipes if there are or create new). Also at the Resources page must be shown the button to create a new resource, defining the recipe to produce it in the process.

I will continue with the 4th but 1, 2 and 3 are pending... if some one wants to help in any of them will be marvelous! Also is many other pending stuff in other pages...

[fosterlynn]

yes Lynn, we can make exchange types with many transfer types if needed..

:+1:

@bum2 The main problem I have with this is that we still don't have what I understand the minimum requirement to be, which is the ability for a project or collective (or the nodes) to create exchange types only for themselves and not bother anyone else. Since you have some sort of inheritance implemented for exchange types, why not take it all the way down and give people the option. Then collectives that are managing their own operations rather than exchanging with others can just do what they need to do and it is very simple for their users. It wouldn't get in the way of your vision of a grand taxonomy for such things that covers the whole network and people can use to trade with each other.

I'm fine with waiting on this until we have more discussion with Decentrale and hopefully others, and just verify what is needed.

On another topic, I don't think we should implement exchange types inheriting from other exchange types, way too complicated for the benefit. There just aren't ever going to be that many, either for the whole coop or for any collective or project. Nobody will be able to figure out how to do it. It will be worse than the facets, which are pretty hard for people to figure out.

The TODOs i, ii, iii are good. Although iii, maybe we should double check is needed now?

From the Exchange logging page, incoming transfers or resources permit the creation of new resources (of the choosed type), maybe that is ok

It can be a new resource from the context agent's perspective, especially if coming into the system from the outside. But even if it is a resource already in the system, it is likely that the context agent will define it differently, like the Id for example. Or that the incoming items will just increment an existing stock resource under management of the context agent.

Also, whether to provide the option to create a new resource in a transfer is part of the definition of the exchange type, so people can define what they need.

but for the outgoing tranfers in a exchange maybe is needed a text and button to 'Make a Resource' that goes to a Work Plan for creating or producing the Resource

Right now, a transfer assumes the resource is already made. I suppose if all you are doing is creating the requirement or commitment, you could add that link. in the current NRP, this functionality is done for customer order, which checks for inventory and creates a plan if there is no inventory and there is a recipe to create the plan from. If there is inventory, it just creates the commitment. But for work orders it assumes that you are making things for your own reasons, like for stock, or because you need it for the context agent's own purposes. Maybe a little more thought is needed for this one, I can help if you like. But for sure, check the customer order code and steal from there, because it is pretty involved.

[bum2]

@bum2 The main problem I have with this is that we still don't have what I understand the minimum requirement to be, which is the ability for a project or collective (or the nodes) to create exchange types only for themselves and not bother anyone else.

I've added the option to edit the newly created exchange type to change the context, so it can be only for the project or common in sector or in whole ocp.

On another topic, I don't think we should implement exchange types inheriting from other exchange types, way too complicated for the benefit. There just aren't ever going to be that many, either for the whole coop or for any collective or project.

The definition part about the sequence of transfer-types of an exchanges type is now only done via admin side, creating a set of common 'sequences'. The user project then creates customized 'childs' of this common models, related their desired branches of resource types 'for the main transfer'.

My main concerns are: Why are exchange types related the resource types (at the name level)? only for later filtering of the resource types? ... i think they can be' types of exchange' with the peculiarities of the operation (record type) but not linked to the type of resource for the main transfer (which is another kind of data). That creates a huge amount of innecessary exchange types only differenced by the related 'main' resource type branch or facetvalue... I think that the Exchange itself ('the instance') is the one who should relate resource types for the main transfer, but not the ExchangeType ('the class'). I'm talking only about the 'main' transfer in the sequence (the others are ok to be defined at the Type level). The other concern is about the TransferTypes: Why cannot they be shared between exchanges? They hold the facetvalue/resource_type_branch relation, so we can be using a set of unique combinations of transfer-type options with resource types branches (facetvalues) and share them across exchanges and agents.... now are just created a new set for every exchange type, with very similar functions and names, and the list will grow fast... Is like trying to separate the concepts there into: a) the 2 'record_types' (ExchangeType and TransferType), nestable in a sequence and using context (as they are) but let only the TransferType relating the resource types via facets (when not the 'main' transfer, which inherits) and shared with other ExchangeTypes. This way the ExchangeType don't need a facetvalue in its name, and then it can instead wear names about the options of the transfers inside it, like: 'fiat buy distributable', 'fiat buy non-distributable' or 'fiat sell invoicing', etc. b) the 3 basic 'records' (Exchange, Transfer, Commitment) which hold the agents and resource types information, c) the 'relations' class TransferTypeFacetValue which can be small (because TransferTypes can be shared).

And then, to make an exchange, you'll pick the exchange type (which relates to the contained transfer types) AND the main resource type (for the main transfer, the one which inherits the resource type branch or 'facetvalue' from the Exchange). This way is much easier to create new exchange types (only refering the transfer internal options, and naming from that), and keep the selection (or creation) of resource types 'for the main transfer' separated from the exchange types.

Anyway I'm trying to finish something usable even without resolving this structural issue... The only problem is that exchange types and specially transfer types will grow soon.

In the current NRP, this functionality is done for customer order, which checks for inventory and creates a plan if there is no inventory and there is a recipe to create the plan from. If there is inventory, it just creates the commitment. But for work orders it assumes that you are making things for your own reasons, like for stock, or because you need it for the context agent's own purposes.

That's exactly what is needed:

• When placing an outgoing 'sell' exchange it should create an order if it is not created, and show the link to the order (or show a create Order button) in the exchange logging page.
• When placing a 'buy' incoming exchange, if the provider agent is a ocp user, an order should be created (perhaps when doing the first commitment?) and can be seen for both agent's.

A place to choose the other agent (provider in a buy or customer in a sell) is here in the same Exchanges page (new exchange block, a contexts trace is already shown for admins). If we do it this way, in the case when doing one exchange with various agents or participants in a group, you should choose the group as 'other context' for the exchange (even if is the self project agent, for internal distributions), and the related agents will appear as options for the transfers-steps logging.

[fosterlynn]

I've added the option to edit the newly created exchange type to change the context, so it can be only for the project or common in sector or in whole ocp.

I don't see the one I created earlier (edited in admin) for my LynnTest group on the dropdown to pick it when I create an exchange..... what am I missing? Should the dropdown be a combination of recently used and the ones designated for the project only?

I'll take a look at the edit feature later, sorry no time this weekend.

Why are exchange types related the resource types (at the name level)? only for later filtering of the resource types?

Exchange types are not related to resource types. The facet-values are related to resource types, and they are assigned at the transfer type level, as you note later in your post. So, I'm missing what you are looking at.

I think that the Exchange itself ('the instance') is the one who should relate resource types for the main transfer, but not the ExchangeType ('the class'). I'm talking only about the 'main' transfer in the sequence (the others are ok to be defined at the Type level).

I'm not following your distinction about the main transfer and the others. And all of the relation to resource types and resources happens at the transfer level. And not totally sure what the main transfer is, since multiple transfer types can be defined for both the "main" side and the "reciprocal" side of an exchange type.

The other concern is about the TransferTypes: Why cannot they be shared between exchanges?

That is to keep it simple. I don't think they will grow by leaps and bounds, especially if individual collectives can define their own. I don't think any group (even if trading with others) will need more than 20 say. And they are set up very infrequently. It adds a ton of complexity to allow exchange type to transfer type to be a many-to-many, I think not worth it for the number and frequency.

'fiat buy distributable', 'fiat buy non-distributable' or 'fiat sell invoicing',

I don't think this kind of generalization is very useful, and in fact won't work when facet value filtering is used, which it needs to be to keep the lists small and relevant, and which can be very particular. I think it is more useful to let groups define their small set of exchange types, and make them very customized for their needs, and not see all those general options, most of which won't apply to them.

(Sorry, gotta go, will reply to the rest probably tomorrow afternoon.)

[fosterlynn]

@bum2 By the way, thanks for the detailed discussion!! We'll figure it out!

[bum2]

Exchange types are not related to resource types. The facet-values are related to resource types, and they are assigned at the transfer type level, as you note later in your post. So, I'm missing what you are looking at.

I'm refering the name of the exchange type. It has reference to the resource type or facetvalue (like in 'fair rental Space', or 'give Material resource', etc.

I'm not following your distinction about the main transfer and the others. And all of the relation to resource types and resources happens at the transfer level. And not totally sure what the main transfer is, since multiple transfer types can be defined for both the "main" side and the "reciprocal" side of an exchange type.

I'm seeing the exchanges more like having defined transfer types in a sequence (inherited from the parent exchange type) with defined filtered resource types (small dropdowns of say documents or currencies), and one transfer type which behaves as the 'main' one and transfers the user choosed resource types for the exchange. This special transfer type in the sequence is without predefined facetvalues assigned for it in the exchange type but is 'inheriting types' (new boolean) from the exchange, as will show the resource type branch choosed by the user when creating the exchange. The problem we have here is that the related type branch is holded now in the ExchangeType model (indirectly: it is at the connecting model, with a one2one with exchange-type) and perhaps will make more sense in the Exchange model, what you think about this?

The graphical separation of Reciprocals and non-reciprocals in the exchange logging page don't makes much sense for me. I will prefer the show the sequence (1, 2, 3) and use the 'reciprocal' boolean internally to mark 'incoming' transfers (any type) and 'outgoing' transfers (no 'reciprocal'), from the project's perpective. What you think about this? should it be renamed?

I don't think this kind of generalization is very useful, and in fact won't work when facet value filtering is used, which it needs to be to keep the lists small and relevant, and which can be very particular. I think it is more useful to let groups define their small set of exchange types, and make them very customized for their needs, and not see all those general options, most of which won't apply to them.

The users only sees their used exchange types as a first option and all other stuff is hidden. But when defining their own exchange types they'll need to dig into choosing from common models, search from all resource types, etc.
Facet value filtering is still used behind, but is needed to maintain and automate some parts (i'm on it now) to have all branches 'faceted' (maybe the type you've tested was not yet related any facetvalue, nor their parents...)

[fosterlynn]

I'm refering the name of the exchange type. It has reference to the resource type or facetvalue (like in 'fair rental Space', or 'give Material resource', etc.

Got it. So the rental space example came from Decentrale, and in fact it might be useful to them to have more than one, for their quite specific needs. The material resource one came as part of the General App I think, I don't know of any requirement for it.

If you look at Sensorica's exchange types, you will see a number of general ones, like Sale, Purchase, Donation, Material Contribution; and a few specific ones like 3D Printer Usage, FabLab Membership. A lot of groups will have a mixed bag like this.

Bottom line, I don't think there is or should be an assumption of relationship between Exchange Type and Resource Type.

I'm seeing the exchanges more like having defined transfer types in a sequence (inherited from the parent exchange type) with defined filtered resource types (small dropdowns of say documents or currencies), and one transfer type which behaves as the 'main' one and transfers the user choosed resource types for the exchange. This special transfer type in the sequence is without predefined facetvalues assigned for it in the exchange type but is 'inheriting types' (new boolean) from the exchange, as will show the resource type branch choosed by the user when creating the exchange.

This seems unnecessarily complex to me. The original model is pretty simple. I think your complexity arose from trying to map to the General App?

The graphical separation of Reciprocals and non-reciprocals in the exchange logging page don't makes much sense for me. I will prefer the show the sequence (1, 2, 3) and use the 'reciprocal' boolean internally to mark 'incoming' transfers (any type) and 'outgoing' transfers (no 'reciprocal'), from the project's perpective. What you think about this? should it be renamed?

Actually I think the transfers and reciprocal transfers separation is key to exchanges, since they are all about reciprocity. The sequence number was put there just to give visually logical order on the UI.

The concept of 'incoming' and 'outgoing' is different from reciprocal and non-reciprocal. It means the exchange will be made to bring resources into or out of the whole network (installation), while 'internal' means the exchange will be between agents in the network (installation). When I first put the exchange types into the work app, I got rid of 'incoming' and 'outgoing' concepts because in Freedom Coop, I thought everything would be 'internal'. Now I understand collectives might need to define agents who are not in the network, so maybe we need that again, I don't know. But when I did that work, it was confusing people so I dropped it from the UI.

But when defining their own exchange types they'll need to dig into choosing from common models, search from all resource types, etc.

Yes very true. We will need some way to give an option for groups to use the same exchange types, so they can trade and form supply chains. And maybe the GA ontology is a good way to let people search, if it works to just assign something to each exchange type without making the exchange type structure more complex.

[fosterlynn]

Continuing replies from posts up the thread. :)

That creates a huge amount of innecessary exchange types only differenced by the related 'main' resource type branch or facetvalue...

The only thing that created a huge amount of unnecessary exchange types was the requirement to put them into the General App ontology. Otherwise there is no huge amount (Sensorica has 14, for example). The alternative I would support is to let them grow organically as people need them. Besides all the unnecessary exchange types cluttering up the list, I don't think we collectively know enough yet to do that. These economic forms are experiments, and we need to let people do their experiments freely before we know if or what is required for this. (IMO of course.)

That's exactly what is needed:

• When placing an outgoing 'sell' exchange it should create an order if it is not created, and show the link to the order (or show a create Order button) in the exchange logging page.
• When placing a 'buy' incoming exchange, if the provider agent is a ocp user, an order should be created (perhaps when doing the first commitment?) and can be seen for both agent's.

Yes, this would be good. Right now in the admin app (old NRP), you start with the customer order, and it creates the exchange. (But note the customer order code hasn't been used much and is probably a little buggy. On the other hand, it probably does have some useful code to steal from, because it will create both the exchange and the plan to make whatever is ordered, if it is not already in inventory.)

Doing something like that for purchases would also be good.

These could be separated into a different release if we want to get some things going.

[bum2]

The only thing that created a huge amount of unnecessary exchange types was the requirement to put them into the General App ontology. Otherwise there is no huge amount (Sensorica has 14, for example). The alternative I would support is to let them grow organically as people need them.

There was not any predefined ontology about exchange types, and i just used the record-type tree to invent a proposal for organisation of the exchange types, trying to cover all kinds of economy, etc. To start in production we may only need to show the already working types of exchanges (linked to ocp exchange types, facetvalues, etc), and keep other branches to a testing context...

We can start just with Gift economy (give'n'take) and Fair economy (fair buy, sell and rent), and after add the Fiat economy branches and the Selfemployment exchange types.

In future releases maybe we can open the Swap economy (needs some study) and some monetary economies like the Social currencies (mutual credit, perhaps connected to integralces api), Timebanking, other Cryptos, Exchange currencies in exchange-offices, etc.

[bhaugen]

I'm still missing my exchange type defined for my context agent when I try to create an exchange.

Context agent: https://testocp.freedomcoop.eu/work/agent/96/ Exchange type: https://testocp.freedomcoop.eu/accounting/change-exchange-type/20/ Trying to create a new exchange: https://testocp.freedomcoop.eu/work/agent/96/exchanges/ The exchange type defined by my context agent does not appear.

[fosterlynn]

I'm still missing my exchange type defined for my context agent when I try to create an exchange.

General question about that page - the top dropdown has anything you have used; then there is a way to search for an available exchange among everything attached to the GA taxonomy (is this right?); then you can create a new one. Is it possible that the exchanges Bob and I are looking for are not showing up in the second one because they are not attached into the taxonomy or the taxonomy is not attached into the facet values or something like that? (How does it work?)

[bhaugen]

Is it possible that the exchanges Bob and I are looking for are not showing up in the second one because they are not attached into the taxonomy

I don't want to see my context agent exchange type buried in the taxonomy tree, I want to see it simply and clearly. Maybe another selector with context exchange types, if any exist: as the first selector, because those should be the easiest to find and use.

[bum2]

I don't want to see my context agent exchange type buried in the taxonomy tree, I want to see it simply and clearly. Maybe another selector with context exchange types, if any exist: as the first selector, because those should be the easiest to find and use.

If they are created using the coop admin app they are not connected to the trees. Only when using the work app the things work as intended, because the trees connections are in the work app. Anyway, if you created any exchange for the project, the first options you find for a new exchange type are the used types, in a simple first dropdown as you say (the first step). Is pending to mark somehow the orphaned exchange types in the coopadmin app (now there's only a parenthesis when editing the exchange type, showing the related tree name if any). And also is pending to show a clear alert to users when using a 'not yet connected' type... they should not be any when going in prod.

[bhaugen]

If they are created using the coop admin app they are not connected to the trees. Only when using the work app the things work as intended, because the trees connections are in the work app.

Ok, got it. I'll make a new one over there.

[bhaugen]

Ok, I created a new exchange type in the work app. It does appear in the second selection box as being selected, but when I try to create a new exchange using the new exchange type I just created, nothing happens. Just a page reload. https://testocp.freedomcoop.eu/work/agent/96/exchanges/

If I reload the page, I don't see my new exchange type at all. Did not seem to be registered in the tree.

If I look in django admin, my new exchange type does not appear. I conclude it was not saved, and does not exist. https://testocp.freedomcoop.eu/admin/valueaccounting/exchangetype/

[bum2]

Ok, i forget to explain, that was because the parents are not yet connected. For the exchange types we can make sub types of the exchanges already 'connected' (with a '<' symbol)... Also the service-time new exchange types were not totally solved... now they work good.

I've worked a bit the config part in testocp and now we have more ready types to test with, and also i've changed the context of some branches of exchange types (to a particular project you can join) so we face the initial 'economies' we will offer.

The actual status and ToDo's for this branch are in the pad i've shared in telegram, please add whatever you find it's missing, or take any task.

[bhaugen]

For the exchange types we can make sub types of the exchanges already 'connected' (with a '<' symbol)...

Way too cryptic. Is that your intended design for the future, or just a temporary limitation?

I think that specific exchange types for context agents will be a major requirement, but I could be wrong. Let's try to get some help from Chris Zumbrunn and others and see how that requirement balances against people who want to pick from the whole tree of exchange types as-is.

I added your pad here, because in Telegram it is already lost: http://techs.sandcats.io:6080/shared/TxFu8F5xKxQZTEJpI7Key3-SqhpRBhQW-Ns9AIH76xv

Was that it, or did you have another pad as well?

[bum2]

it has changed a lot the exchange types tree in testocp, when hiding whole branches to a smaller 'Ontologic Team' context... we can start with just Gift economy and Fair economy branches...

yes the pad is this one

[bum2]

This days i'm deploying often in testocp, so when you see new commits in the branch, in few minutes they are deployed in testocp. I'm trying to solve all the issues you are finding as fast as i can... Is better to check first if the issue is solved in testocp, but if the issue is a different one please post it here or in the pad.

Way too cryptic. Is that your intended design for the future, or just a temporary limitation?

That was just pending config work... now the common exchange types (which act as models) are in place (for the showed 'economies'), so i hope you don't find 'config holes' when using the work app. If you find one, please report.

I think that specific exchange types for context agents will be a major requirement

It is implemented, but the main doubt here is what context use 'by default' when creating a new exchange type:

Actually the context for a new exchange type is derived from the context of the related resource type branch or skill branch (if any), if that fails then it gets the context related the parent exchange type (if any) and if all fails it gets the project context agent.

As the resource types are still very common, the new exchange types are getting this general OCP context, and they became 'common by default'. After you've created both the Exchange and the new ExchangeType in one click and you're at the exchange logging page, if you need to change the context of the exchange type, you can go back again to the Exchanges page, choose the new exchange type you've created and edit it, changing its context to a smaller one. That task can be facilitated is some way, but the main point here is inheriting the context from the resource type or skill type selected for narrowing the options. If the resource type or skill are defined for a particular context, then that becames the context of the custom exchange type also. Also can be said: If you want to create a 'project only' new exchange type by default, first choose or create a 'project only' new resource type (or branch) or a new skill type (or branch) to narrow the options in the exchange.

If we put the project context by default, it is automatically hidden for everybody else, which is good for the exchange types (keeping only the common ones shown when doing a new exchange type), but will require lot more admin work to gather exchange types useful for other projects (and broader their context), or deal with many semi-duplicates around...

To avoid having many common exchange types in the showed tree i'm thinking other options, like the sector groups (contexts grouping projects) to assign the context of some exchange types to that 'intermedium' group, so they are common only amongst the sector (not general and not particular).

Another big question i have for you is about 'the other side' of an exchange:

• If a transfer goes to another agent he can see the income by looking the inventory. We can make something more evident.
• If a commitment or transfer refers another agent, the same exchange appears in the other agent's list of exchanges (this already happen in testocp).

That's ok but is not enough, because the correct will be to 'reverse' the exchange names for the other agent view, showing the opposite direction of each transfer type. So I'm thinking about how can be defined the 'opposite' of an exchange type, eg. to show Give blabla in one side and Receive blabla in the other side... I know the transfers are events and they are REA but the 'exchange' concept (with a set of transfer types) is not 'reversible' (viewable related the other agent), or is it?

One fast way can be just placing a new FK field (opposite_type) in the Ocp_Record_Type model (which can match an entire exchange type with another opposite exchange type, so the internal transfer types should match). With the set of common exchange types we have now, that can be done easily because each one has an exact mirror exchange type (simply not linked). But what about custom exchange types? if their 'parent' exchange type was good linked to their opposite, the custom child can have the same good links and the mirror custom exchange type can be derived, creating both sides as two exchange types in one request. The exchange instance (not the type) can remain single (related the original exchange type, but showing 'reversed' thanks to the linked opposite type info) or it can be also duplicated (one exchange record for each side).

Another way, much more flexible, is to start using the triplet relations of General app but between Types (a new many2many 'rel_type_types' table is already coded, ready to go live when needed), so a type can be related another type through the relation 'opposing', 'swapping' or better 'mirroring' (and use that relation to discover the opposite of any type)... The main issue with this second approach is that the ocp TransferTypes are not yet in the general tree of Record_Type (only the exchange types are now), and the transfer types are NOT shared between exchange types, which makes it much harder. The TransferTypes are the ones that need to be 'mirrored', and this is not just a 'naming' issue.

A third approach to solve this can be to work only on the autonaming unicode function of the Exchange and of the TransferTypes, so it's all viewed as a buying exchange from one side and as a selling exchange from the other side, also with the internal transfer type names reversed. That means going in detail about the words used in the name, and also set a table of 'opposite verbs' somewhere, to flip the action, etc. This approach is more REA because the exchange record is one instead of two and the exchange type record can be one instead of two (more like a transfer or commitment), but requires a re-estructuration of the naming part of all them, and the list of opposites anyway.

Your feedback is very welcome

[fosterlynn]

Actually the context for a new exchange type is derived from the context of the related resource type branch or skill branch (if any), if that fails then it gets the context related the parent exchange type (if any) and if all fails it gets the project context agent.

Shouldn't this be the opposite, or an explicit choice? Default to the chosen project. There is no reason to think that some other project wants what you are creating, it could easily be just spam.

If you want to create a 'project only' new exchange type by default, first choose or create a 'project only' new resource type (or branch) or a new skill type (or branch) to narrow the options in the exchange.

There is still some misunderstanding here I think. There will be many many more resource types than exchange types. If will be much more normal for an exchange type to cover a lot of resource types, even if you are only thinking of one transfer type. For example, a group might often have "Sale" as an exchange type, and all the various resource types that they have for sale would be appropriate.

From my experience, I think it is a fundamental mistake in the data model to drive exchange types by resource type.

If a commitment or transfer refers another agent, the same exchange appears in the other agent's list of exchanges (this already happen in testocp).

Nice! :+1:

That's ok but is not enough, because the correct will be to 'reverse' the exchange names for the other agent view, showing the opposite direction of each transfer type. I know the transfers are events and they are REA but the 'exchange' concept (with a set of transfer types) is not 'reversible' (viewable related the other agent), or is it?

Actually, the exchange and transfers should be fine as is for both agents, nothing needs to be reversed. The primary transfer(s) goes from agent A (give event(s)) to agent B (receive event(s)), the reciprocal transfer(s) goes from agent B (give event(s)) to agent A (receive event(s)). The view should be accurate for both, what is called the "independent view". The choice of what is reciprocal is not per agent, it is what is the secondary side of the transfer. For example in a Sale, the main transfer(s) will be the items for sale; the reciprocal transfer will be the $ or whatever is asked in return. The exchange happens because of what is for sale, not because the seller is primarily asking for money and by the way will send some items in exchange.

Let us know if this isn't clear, we can look in more detail at the code if you like.

[fosterlynn]

The primary transfer(s) goes from agent A (give event(s)) to agent B (receive event(s)), the reciprocal transfer(s) goes from agent B (give event(s)) to agent A (receive event(s)). The view should be accurate for both.

A further note: If it is an internal exchange, both Give and Receive events are created for the Transfer; if it is incoming or outgoing, only the appropriate internal event will be created. So if an external agent is transferring something to an agent in the network, there will be only a Receive event for that Transfer. Etc.

[bhaugen]

[edit] this was a question to @bum2

The swaps are gone?

[bum2]

The swaps are gone?

They are just hidden for all projects except OntologyTeam (you are a participant, i've renamed my old test project) along with many more hidden branches to simplify the testing.

Shouldn't this be the opposite, or an explicit choice? Default to the chosen project. There is no reason to think that some other project wants what you are creating, it could easily be just spam.

The default context for new resource types can be the project, but anyway they choose it explicit in the form. The default context for new exchange types i think is not bad to inherit the resource types branch context.

There is still some misunderstanding here I think. There will be many many more resource types than exchange types. If will be much more normal for an exchange type to cover a lot of resource types, even if you are only thinking of one transfer type

I understand this and is what i look for. The misunderstanding i see is: the resource types are now in a tree, and that means they act sometimes also as branches (facetvalues) and sometimes simply as leaf resource types. They can be both: if you choose a branch type (with childs) it can be a generic ocp type of resource and operate with that, and also it can act as a 'facetvalue' of the descendant resource types. That can be automated: when a resource type gets childs and grandchilds it can create automatically a facetvalue with the same name, and group all descendants with that new facetvalue.

From my experience, I think it is a fundamental mistake in the data model to drive exchange types by resource type.

I also think is a fundamental mistake, and that's the reason for so many comments about this subject since long ago. The relation of exchange types with the resource types is something i've simply found as is in ocp, even at the 'name' level, so in the best cases we just find the main facetvalue name in the exchange type name, as a reminder of the facetvalues we've choosed for the main transfer type. To mention a facetvalue in the exchange type name is the same as putting the related resource type 'branch' name on it.

My first idea to solve this now was to let only choose big branches when creating new exchange types, so the exchange type name only contains 'facetvalues' and never a leaf 'resource type' name. We can hide exchange types (when making a new one) if they are related a single resource type for the main transfer.

I think the best approach will be to break any relation between exchange types and resource types nor facetvalues. Then we can stick the exchange types naming to the options of the contained transfer types, but not their facetvalues. I dream about exchange types names like 'fair buy without bill', 'fair sell invoicing', 'give accounting', 'receive distributable', etc. All names related the options and sequence they hold but not the facetvalues or resource types.

That is my dream, conceptually clear, but the reality is that an exchange type in ocp has particular transfer types (not shared) and each transfer type has related facetvalues to filter the resource types. That means an indirect but straight relation from exchange types to their 'contained' resource types. So the naming connection remains.

Once i've realised this fact, and having to bring a usable release asap, i've assumed there's no easy way to re-structure this (only with lot of help and feedback from you!) and also that transfer types are not easily shareable. Meanwhile i've placed a few FKs in Ocp_Record_Type to track directly (not indirectly) the related branch of resource or skill types for the main transfer in a exchange type.

As a roadmap for solving this, i think the crucial point is making the transfer types shareable between exchange types one day. Then some transfer types will have predefined attached facetvalues (like now), and some other transfer types (the main ones in each exchange) will not have any defined facetvalues because they will inherit a resource type 'branch' from the Exchange. This way the exchange types and the transfer types can be mainly common.

Nowadays it's the ExchangeType which hold the resource type branch information (via the connector model) and affects the name, but i think it has more sense to record the RT branch FK in the Exchange model (the record, not the record-type), and keep the ExchangeTypes more common and unaware of the choosed branch for the main transfer type.

[fosterlynn]

@bum2

From my experience, I think it is a fundamental mistake in the data model to drive exchange types by resource type.

I also think is a fundamental mistake, and that's the reason for so many comments about this subject since long ago. The relation of exchange types with the resource types is something i've simply found as is in ocp, even at the 'name' level, so in the best cases we just find the main facetvalue name in the exchange type name, as a reminder of the facetvalues we've choosed for the main transfer type. To mention a facetvalue in the exchange type name is the same as putting the related resource type 'branch' name on it.

To clarify: facet values often do not have anything to do with resource type trees themselves. They can be things like "for sale", which is useful to show everything you wish to trade in an exchange or customer order. Be careful of implying things from the experiments in OCP for facet values, which have not involved a lot of analysis and thought, lacking an admin group who can spend some time on it. :(

If you think of facet values as they are often used on the web for filtering, you find they are often about aspects or attributes of resource types. Like "show me all the shirts (resource type parent or category) that are color: red and size:14".

Another example, in Sensorica, the first use of facet values was to tag the domain: electrical, optical, mechanical, etc. - which gave them good base control over dropdowns of resource types as related to their specific work.