-
Notifications
You must be signed in to change notification settings - Fork 46
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
Comments
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. |
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. |
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 |
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 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 :) |
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. |
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 |
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. |
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) |
@PaulBoroday I'm having trouble reconciling your older comment:
With your newer comment:
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? |
@jpmckinney sorry for being a bit unclear... let me try one more time 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? |
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 |
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 |
According to The Law and Economics of Framework Agreements, framework agreements with direct call-offs can take the form of an electronic catalogue. |
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 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 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/. |
@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. |
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!) |
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/ ? |
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). |
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. |
Note: A follow-up issue has also been created here: open-contracting/ocds-extensions#159 |
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:
The text was updated successfully, but these errors were encountered: