Align with standard RfQ / Quote flow

[michielbdejong]

Each 'ask' edit would be an RfQ message from buyer to seller
Each 'product stock' edit and each 'product unit price' edit would be a Quote message from seller to buyer.

I think in general quotes are considered binding (at least until they expire), but RfQ's are not.

The purchase order would come after the quote, and would also be binding. That is basically a way for the buyer to close the collaborative invoice composition process and take a binding final snapshot.

[michielbdejong]

@gsvarovsky any thoughts on this?

[gsvarovsky]

Right now, my mental model for this corresponds to the 'baseline live' viewpoint that I spoke about this morning on the NLnet Next Generation Internet webinar.

Start with 100% live-shared data. The m-ld web-starter project is ready to look at – let me know what you think.

Now layer on some authorisation. Is some identity allowed to do some operation? (I'm still working on writing up our discussion from last week related to securing live shared information.)

Now add 'agreements' (or some such word, we didn't yet agree). These are points in which the current state of the information is:

1. agreed by one or more parties
2. non-repudiable by those parties (strongly – with cryptographic signatures or such)
3. exported to other formats ("Quotes", "RfQs", "Invoices", "Shipping notes")

The last point doesn't have to be tied to the previous ones, but in many cases you'd want to be able to relate the exported documents to something signed.

Finally, if these steps are technically lightweight, you could actually generate 'agreements' frequently, even during what looks like a really dynamic negotiation. Imagine each bid in an auction being recorded like this.

[michielbdejong]

Right! I think to some extent the 'business documents are snapshots' view is compatible with the 'business documents are state-changing operations' view, but there are some differences.

in the 'documents are snapshots' view, each document must describe the full state. This is not how quotes and bids currently work.

For the 'documents are operations' view, the match in content seems closer, but the irreversibility is missing.

[michielbdejong]

So the state of the negotiation should probably be an add-only set of bids and quotes?

[gsvarovsky]

Or, in my view, "documents correspond to snapshots". So, the document content does not have the full state. But being able to recover the corresponding full state seems like a useful thing, if there is a disagreement about the limited content of the document.

And, not just "snapshots" but "agreed snapshots". Not every possible snapshot necessarily has a document, especially if the history differs between buyer and seller (due to being offline, or concurrent operations). I like this because it makes explicit the need for some coordination, for a specific purpose, against the background of an otherwise coordination-free, highly-available data structure.

I do think it's useful to hold both models in mind at once. Strong eventual consistency data structures can be modelled as merging state or sending operations; Marc Shapiro's group showed them to be equivalent.

However I think having a strong correspondence our minds between legacy documents and new-world operations could make it really difficult to refine anything about the data structure – we'd be stuck with whatever features, scalability and performance those operations allowed for.

[michielbdejong]

https://github.com/m-ld/m-ld-web-starter is great! Really cool to see the data sync so fast between browser tabs.
I understand the goal there is to show how to use m-ld but let's use it as a strawman to discuss how far off this would be from a usable "CIC" ;) system:

• Entries with the same product code don't merge. You can create two line items which are both for product "a". The "Quantity" may then be interpreted as adding up, but it's weird if they have different numbers for "Stock" and "Unit price". This could be fixed in the GUI - just prohibit changing the product to one that is already used on another line. But wait, what if I change line 3 to product "b" and you change line 2 to product "b" concurrently?
• Quantity, Stock and Unit price can all go below zero. I first thought that's probably because you used an inc/dec counter for those, but I don't think that's the case, right?
• I created Do arrows really inc and dec? m-ld/m-ld-web-starter#2 to discuss more deeply how the data works. From what I understand:
  • moving items up and down will commute with editing those items, that's great.
  • delete trumps edit, that makes sense.
  • it's possible for one party to edit quantity and the other party to simultaneously edit stock on the same item, that's great.
  • it's not possible for both parties to simultaneously edit the same field on an item, that makes sense.

[michielbdejong]

having a strong correspondence our minds between legacy documents and new-world operations could make it really difficult to refine anything about the data structure – we'd be stuck with whatever features, scalability and performance those operations allowed for.

Right! We probably don't want to follow the exact structure of a 'purchase order' because indeed it would be quite a restrictive format. But I think bids and quotes are pretty basic, and we can model the sending of a purchase order as bidding "if you deliver [product codes, quantities, max delivery date] then I promise to pay [amount, currency, max payment date]"

[michielbdejong]

maybe we shouldn't think of CIC as editing a shopping cart, but editing the state of a negotiation.
The negotiation state is naturally described by a list of offers that were made and a list of bids that were made. Inside an offer or a bid, there are further details linking to invoice items and their details.

We could even have a two-level structure, where at the "invoice items level" you collaboratively compose an invoice item (e.g. you're designing a kitchen with a kitchen architect) and then assign a URI to the snapshot (a specific kitchen design), and then at the "deal negotiation level" you bid and offer "ok if you can do this (hyperlink) kitchen design as discussed then i'll pay 10,000 euros for that".

[gsvarovsky]

• Entries with the same product code don't merge. You can create two line items which are both for product "a".

In the starter project I wanted to demonstrate using Lists. I suspect a better approach for proper CIC would be, effectively, a Map of product code to [quantity, stock, price]. I don't think the ordering really matters (for example, it could be presented in alphabetic order).

To do this you could embed the product code in the @id of the item. That would force the graph to 'merge' items with the same product code. If that makes it a bit ugly to recover the product code, you could have it as a property as well. Note that this kind of data modelling is not really different to what you would do with RDF anyway.

If the order really does matter, then we could choose whether to construct a "Mappy-List" or a "Listy-Map", and maybe think about a constraint to enforce its semantics.

• Quantity, Stock and Unit price can all go below zero.

As discussed in the linked ticket, these guys are all just numbers, and there's no constraints on them.

Your list of observations are all accurate, except this one:

• it's not possible for both parties to simultaneously edit the same field on an item

As discussed in m-ld/m-ld-web-starter#3, all that's happening here is the app is catching the apparent conflict (the value has become an array) and is making a (pretty lame) attempt to alert the user and wait for them to reset the value. From m-ld's point of view the concurrent edit is perfectly fine.