Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Electronic catalogues #396

Closed
duncandewhurst opened this issue Oct 13, 2016 · 21 comments · Fixed by #1223
Closed

Discussion: Electronic catalogues #396

duncandewhurst opened this issue Oct 13, 2016 · 21 comments · Fixed by #1223
Assignees
Labels
discussion Focus - Documentation Includes corrections, clarifications, new guidance, and UI/UX issues Schema Relating to other changes in the JSON Schema (renamed fields, schema properties, etc.)
Milestone

Comments

@duncandewhurst
Copy link
Contributor

duncandewhurst commented Oct 13, 2016

The original issue description below has been copied to #897 (Purchase orders). Purchase orders outside the context of electronic catalogues are somewhat easier to discuss. The two issues might be re-integrated at a later date, but for now the split allows a separation of concerns, from this comment onward: #396 (comment)

This issue is now focused on electronic catalogues.


Original issue description

On today's upgrade community call we started a discussion on purchase orders, in relation to catalogue buying and framework agreements.

We're seeking feedback from the community on:

  • Should purchase orders fall within the scope of OCDS?
  • How should purchase orders be modelled in OCDS, e.g. should these be modelled using contract.implementation.transactions or do they represent a contract in themselves?
  • What are the use cases for disclosure of purchase order level data?
  • Is data on purchase orders typically captured in the same information systems as data on contracts (framework contracts in particular) or does it exist in separate systems?
@chrisalexsmith
Copy link

chrisalexsmith commented Oct 15, 2016

I would expect catalogue buying to becoming more prevalent with the increasing adoption of e-procurement and the requirement to capture purchase order data will be enabled through the increase popularity of Amazon type transactions as it offers many benefits to the procuring government entities. Although the individual value of such catalogue buying transactions will be small the volumes of such transactions will be high.
I think that in principle they should fall under OCDS as disclosing the parent framework contract only gives part of the picture and what also matters is the utilisation of that framework.
Would suggest that purchase orders do represent contracts but are linked to the head contract.
E-catalogues are increasingly becoming an integral feature of e-procurement systems being offered in the market and I would expect data from all procurement transactions including frameworks and their purchase orders to be increasingly held in a single system.

@georgneu
Copy link

Just flagging that purchase orders (orden de pago) is information that Argentinean civil society would be looking for. They see this as the key document that provides them with the information on who and what.

A brief look at a purchase order seems to indicate that most of the information is covered in the contract data so it could be integrated there.

@jpmckinney jpmckinney changed the title Purchase orders Purchase orders (and/or electronic catalogues) Sep 18, 2018
@jpmckinney jpmckinney added the Focus - Extensions Relating to new or proposed extensions, or the governance and maintenance of extensions label Sep 18, 2018
@jpmckinney
Copy link
Member

jpmckinney commented Oct 19, 2018

Given that the number of purchases from a single catalog can be very high, I suggest that details of catalog purchases should be disclosed separately from the details of the contracting process that establishes the catalog.

We have some guidance on framework agreements, which is applicable to catalogs.

In the case of catalogs, purchases would refer to the contracting process establishing the catalog through relatedProcesses. Most information about the purchase would go under contracts. Some information would need to be filled in under awards, e.g. suppliers.

@jpmckinney
Copy link
Member

Having learned more about how these processes work, I reverse my above position; purchase orders and catalog purchases are part of the same contracting process and should therefore be disclosed under the same OCID.

See #784 (comment)

@jpmckinney jpmckinney added Focus - Documentation Includes corrections, clarifications, new guidance, and UI/UX issues Schema Relating to other changes in the JSON Schema (renamed fields, schema properties, etc.) and removed Focus - Extensions Relating to new or proposed extensions, or the governance and maintenance of extensions labels Jul 11, 2019
@PaulBoroday
Copy link

@jpmckinney just one practical question here (generally sounds great): let's assume we have eCatalogue where 50 positions are presented and covered by offers from 100 suppliers (quite a possible situation for laptops, for example). And during the catalogue's lifecycle, we will have like 2-3K of purchase orders or more - each as a separate 'contract' with own lifecycle of implementation (short one but still). Describing all this within one ocds-release (im not even talking about the record) - imagine the size of this json :)

@jpmckinney
Copy link
Member

Yes, I'm not sure of the right balance. Having one large JSON document might be harder to work with, whereas having many thousands of small JSON documents might be easier to work with (I'm not sure if this is true for all users). But if the large document better represents reality, then I think it's the right approach, and we should instead look into how to make the data easier to use.

If we proceed with the "large JSON" option, there will still be smaller JSON documents; for example, if each purchase is a separate release, then those will be small and easy to work with. The compiled release will be large, though.

@PaulBoroday
Copy link

Things here depends on what is considered as “contract setting up the relationship”. If for FAs it’s more or less clear, for DPSs and especially for eCatalogues, where usually number of categories (nodes) described for some general CPV-code, it is not...

For example we have an eCatalogue of “machines for processing with data” and 3 nodes included: notebooks, mainframes, desktops. For each node we have a number of Metaproducts (profiles) and a number of SKUs (described or selected by CA/CPB). On another hand - a number of suppliers who confirmed their readiness to deliver different items under different profiles for predefined (offered and awarded) prices and conditions...

The questions is what is the scope of contract here at this stage before particular orders? Should it be some general agreement on delivery of “machines for processing with data” with all qualified suppliers or sort of combination of such general one for all + separate specification for each node where each specific supplier is qualified and awarded to deliver according to the scope of his offer? The former is too general FMPV. And second approach looks more convenient for market and it is more realistic to cover it with one single ocid not dealing with “undoible” volume of data

@jpmckinney jpmckinney changed the title Purchase orders (and/or electronic catalogues) Electronic catalogues Jul 25, 2019
@jpmckinney
Copy link
Member

I think I need to better understand how e-catalogues are set-up and operated from the procurement perspective. Purchase orders (at least traditional ones outside the context of an e-catalogue) seem easier to model, so I separated this issue into two. This one is now about e-catalogues (since most of the comments are about them). Purchase orders are now in #897

Regarding your question about separate contracting processes for different nodes, I will need to know more about the procurement procedure. When setting up the catalog, is there just one competition / qualification for all suppliers for all nodes? Or are there separate competitions / qualifications for each node? If the latter, then it is easier to say that there are separate contracting processes.

@PaulBoroday
Copy link

The point is that this is first option - common qualification for all nodes under common CPV. It makes no sense to qualify suppliers for notebooks and desktops separately - these are same companies (at least set of selection criteria looks same)

@jpmckinney
Copy link
Member

@PaulBoroday I'm having trouble reconciling your older comment:

The questions is what is the scope of contract here at this stage before particular orders? Should it be some general agreement on delivery of “machines for processing with data” with all qualified suppliers or sort of combination of such general one for all + separate specification for each node where each specific supplier is qualified and awarded to deliver according to the scope of his offer? The former is too general FMPV. And second approach looks more convenient for market and it is more realistic to cover it with one single ocid not dealing with “undoible” volume of data

With your newer comment:

It makes no sense to qualify suppliers for notebooks and desktops separately - these are same companies (at least set of selection criteria looks same)

Earlier, you were suggesting "separate specification for each node where each specific supplier is qualified and awarded to deliver according to the scope of his offer" but now you are saying "It makes no sense to qualify suppliers for notebooks and desktops separately."

Can you clarify?

@PaulBoroday
Copy link

@jpmckinney sorry for being a bit unclear... let me try one more time

IMG_8315

My question was whether CA and supplier conclude some general (framework) contract setting up the relationship once a supplier is qualified (scene 6) for certain CPV (in our case - "machines for processing with data" without distinction for specific subclasses like notebooks, tablets, etc) and afterwards they have separate delivery-contract for each formed purchase order. Or separate contract should be concluded for each subclass of common CPV, where CA is interested to be supplied with goods?

As I said, the latter doesn't make sense because usually qualification of suppliers done for common CPV-class and generally qualified suppliers are invited to submit their catalogues for everything which is under this common CPV. And the certain details required separate contract rises only when a purchase order is confirmed by the quoted supplier. With the last paragraph of mine above comment I meant exactly the same... sorry if it was not clear.

If so, does it mean that everything related to both pre-award catalogue requests and relevant supplier's responses (catalogues) can be considered as "out of scope" of OCID for DPS (for example) and could be executed with separate OCID for each pair "pre-award catalogue request + qualified suppliers responses) and DPS' OCID will include only stuff related to initial general forecast and specs of needs, qualification requirements, CAN + contract setting up the relationship (where all selected suppliers are specified) and all the delivery-contracts caused by confirmed purchase orders?

@jpmckinney
Copy link
Member

jpmckinney commented Aug 2, 2019

It's clearer to me now, thanks! (Do you have any more procurement comics?)

Having now read Article 36 in 2014/24/EU and based on how catalogues are expressed in eForms, my understanding is that catalogues are just a technique/instrument for electronic procurement (they are under "Chapter II: Techniques and instruments for electronic and aggregated procurement" of that directive).

Let's say a contracting authority is setting up a DPS for 'data processing machines' (panel 3). That DPS is one contracting process according to OCDS (and the EU). It might specify in its submission terms that tenderers are required to submit an electronic catalogue. At a later date, when the CA is ready to make a purchase (panel 8), the CA might ask candidates to complete their catalogues based on more specific requirements (panel 9). The CA can then make the purchase (panel 13).

Update: In terms of OCDS modelling, the first stage of the procedure (request for participation in the DPS) is modelled in tender. The second stage (request for tender, like in other two-stage procedures like restricted procedures) doesn't have a good model in OCDS, but I've proposed a new model in #440 (comment) The proposal is to model this in a secondStage array. Each request for tender in a framework agreement or DPS would have an entry in that array. There would then be awards and contracts that result from that request for tender. The awards would need a new field to identify which request for tender in secondStage they relate to (this and other details should be discussed in #440).

@jpmckinney
Copy link
Member

jpmckinney commented Aug 2, 2019

Bringing it back to the subject of the issue, I would consider purchases from an electronic catalogue to be different from purchase orders (#897). In the case of purchase orders, the quantity or value of items are generally known in advance by the time the contract is signed, and the purchase orders are just an implementation detail. In the case of a DPS with catalogues, the quantity and value is generally not known (generally, only the maximum value is known, like in a framework agreement). As such, catalogue purchases belong in contracts.

@jpmckinney
Copy link
Member

According to The Law and Economics of Framework Agreements, framework agreements with direct call-offs can take the form of an electronic catalogue.

@jpmckinney jpmckinney added this to the 1.2.0 milestone Jan 19, 2020
@jpmckinney jpmckinney changed the title Electronic catalogues Discussion: Electronic catalogues Jul 17, 2020
@JachymHercher
Copy link
Contributor

JachymHercher commented Oct 29, 2020

Electronic catalogues were discussed at length during the negotiations of the EU's 2014 directives and the conclusion was quite elegant (and put, somewhat unintuitively, only in Rec. 68 of Directive 2014/24/EU): "Electronic catalogues are a format for the presentation and organisation of information in a manner that is common to all the participating bidders and which lends itself to electronic treatment."

Being simply a tender format (usually based on a buyer-specific or generic template), I think catalogues have two implications for OCDS. First, their use needs to be mentionable - which is already covered by electronicCataloguePolicy from the EU extension.

Second, there is a general question at which granularity we want to publish information about purchases. As far as I understand, some information (most prominently value) can be published only at contract/lot level, while other information (in particular item) can be more detailed. The question is, whether we shouldn't be able to provide more granular information in general (e.g. value at item level). However, this is not linked to catalogues per se, but is more general - perhaps worth a new issue or discussing elsewhere, e.g. in #1050.

That being said, the definition of a catalogue as simply a format is not in line with https://standard.open-contracting.org/latest/en/guidance/map/catalogs/.

@jpmckinney
Copy link
Member

@JachymHercher Thanks for the clarifications!

I notice the PR #974 that created that guidance didn't link to this issue, but to #911 (which links to this issue).

Is the problem on that page mainly the first paragraph? Could you either prepare a PR, or copy the text into a Google Doc, update it with track changes, and then share it back?

Once that's fixed, I think we can close this issue (which I think should have been closed when closing #974) and remove the note at the bottom of the guidance, as I don't think there remain any issues specific to electronic catalogues.

@jpmckinney jpmckinney modified the milestones: 1.2.0, Worked examples Oct 29, 2020
@jpmckinney
Copy link
Member

jpmckinney commented Oct 29, 2020

I don't think I had read that "whereas" clause (68) about electronic catalogues before, and it is indeed quite clear. (I sometimes skip matches in that initial section of the directive, but now I know to spend more time there!)

@JachymHercher
Copy link
Contributor

It depends. Yes, the minimalistic scenario is just the first paragraph.

Alternatively, I would argue that since catalogues do not have any implications for data structure (they are just a format for a tender), they thematically don't fall within the "awards_contracts_buyers_suppliers" chapter and they don't really need to be covered at all. This would imply:

That being said, if questions about catalogues arise often, then they could still be worth highlighting in the guidance. However, instead of awards_contracts_buyers_suppliers, I'd put it directly in "Mapping the hard cases" or just add a sentence or two in "Frameworks and related processes". The main message being: "catalogues go often hand in hand with FAs and that's why they look complicated, but when you take the FA out, catalogue on its own is just a format and looks exactly the same as any other FA".

Also, are electronic catalogues defined somewhere "normatively"? The definition is currently in standard.open-contracting.org/latest/en/guidance/map/awards_contracts_buyers_suppliers/#electronic-catalog, but shouldn't it rather be in https://extensions.open-contracting.org/en/extensions/submissionTerms/master/ ?

@jpmckinney
Copy link
Member

jpmckinney commented Nov 12, 2020

I agree with the proposed set of changes: specifically, the option where some guidance is kept/added to explain how catalogs don't need special treatment in the data. And catalogs should be defined somewhere clearly (and repeated or referenced from the submission terms extension).

@jpmckinney
Copy link
Member

As part of #1223, the worked example for electronic catalogs has been removed.

The reason is that (1) an electronic catalog is just an electronic format for describing items for sale, which is not represented in OCDS, and (2) a purchase of an item from an electronic catalog is no different from a purchase from a supplier in other cases, and as such it does not require an explicit example.

As @JachymHercher wrote in #396 (comment), if there are many questions about electronic catalogues, we can restore some version of the guidance, though with greater emphasis on how it is not dissimilar from other purchases.

@jpmckinney
Copy link
Member

Note: A follow-up issue has also been created here: open-contracting/ocds-extensions#159

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Focus - Documentation Includes corrections, clarifications, new guidance, and UI/UX issues Schema Relating to other changes in the JSON Schema (renamed fields, schema properties, etc.)
Projects
6 participants