Harmonized System code lookup

Prohibitions and restrictions

Denied parties

Landed cost calculator

This call for tenders concerns the provision of the following services and technologies, which are to be inte­grated with existing UPU software (specifically, the Customs Declaration System – CDS) through application programming interfaces (APIs):

i         Harmonized Commodity Description and Coding System (Harmonized System) lookup engine (herein­after “HS Lookup”);

ii          Prohibitions and restrictions lookup engine (hereinafter “P&R Lookup”);

iii          Denied parties lookup engine (hereinafter “DP Lookup”);

iv         Landed costs calculator (hereinafter “LC Calculator”).

 HS Lookup is the core component; all Bidders must offer a solution covering the HS Lookup requirements set out in section 4.1. The three other components are optional and Bidders may offer a solution for all, some or none of the three options (i.e. 2, 3 and 4 above). Bidders offering a solution for some or all of the three optional components must describe in their pricing structure how the prices may vary if the UPU decides to engage the Bidder for all or only some of the components.

 The UPU reserves the right to engage different Vendors for each component.

The deadline for the submission of tenders is 4 August 2023 at 16.00 CEST.

Regarding the following segment from Section 

2.5:

“The use of CDS is billed according to a pay-per-use model and is currently charged at 0.03 CHF per declaration or referral sent through the system, subject to an annual cap (i.e. declarations and referrals are free of charge once the annual cap has been reached). The UPU’s objective is for all four services listed above to be encompassed in an all-inclusive per-declaration fee.”

 Is it also the objective of the UPU that fees for all four services also have an annual cap per UPU member and/or the UPU?

 The CFT indicates (section 4.8) that one of the assessment criteria is: "The prices and pricing structure are compatible with integration into the UPU CDS fees."

 It also says (section 2.5): "Bidders proposing a pricing model that can easily be bundled with the existing CDS fees will have an advantage"

 It means that an annual cap is not mandatory, but will surely help answering the expectations above.

 The current annual cap is per licensee of the CDS (and licensees are the UPU Designated Operators).

 As a clarification question, are you able to share the number of CDS users per GNI class that hit max CDS fees (eg 60 of GNI High income hit max fees, 20 of GNI support income hit max fees, etc). As you might imagine if we are to set our pricing as preferred to align with CDS’s per declaration and cap model, these numbers can help us. 

 We are not able to disclose this information at this stage of the process. 

 We’ll be happy to share more information on our customer base in a later stage, for example after the pre-selection of some bidders and under the proper legal protection (specifically: a Non-Disclosure Agreement). 

 Please indicate in your proposal if you will be willing to revise your initial financial offer when further detailed information on the CDS customer base can be shared by the UPU

 I’m writing to ask if we understood correctly from the call for tender document that you are looking for a custom solution for HS lookup codes or for a off the shelf solution?

 Given the schedule that you provided you are asking to give a working solution until the 1st of October 2023. Is this correct?

 “No later than 1 October 2023 in production mode (i.e. functionalities available to designated operators, for the HS Lookup requirements as a minimum). ”

 The UPU is opened to look at either COTS or bespoke solutions. However we confirm that the timeline provided in the CFT is a very important parameter, as well as the expertise on the subject matter, as specified in section 2.17: “Due consideration will be given to Bidders’ specific backgrounds, qualifications and experience in relation to the required services”. 

 1. Regarding HS2, does the UPU expect to be providing partial HS codes (i.e. `61` or `6101`), 6-digit HS codes (`6101.10`), or full HS codes (`6101.20.0010`)?

 Most likely, the 6-digit HS codes but it depends on the postal organization (and at the end: the customers of the postal organization).

 2. Regarding HS4, not all countries use the 2022 edition of the HS Nomenclature. For example, some posts have not yet transitioned to 2022 and are still using 2017. In such cases, would the UPU prefer a code that is currently accepted by the importing country, or would the UPU prefer a 2022 irrespective of the nomenclature edition in use?

 We prefer to focus uniquely on the 2022 edition and bring all countries/posts to the same compliance level.

 3. Regarding P&R1, what is the UPU’s expected behavior when the provided HS code is invalid?

 We expect the calls to be made in sequence: first to assign a proper HS Code, and second for all other services (P&R, LC). Therefore when the P&R call is made, the HS Code shall be correct.

 If the UPU contracts the HS Code and the P&R to different vendors, and for some reason the HS code provided when placing the P&R call seems erroneous (inconsistency between the description of the goods and the HS Code), the P&R solution can return an error code with the suggested HS Code.

 4. Regarding DP2, does the UPU only want to screen using lists provided by either the importing or exporting countries, or shall 3rd countries’ lists be considered as well?

 Ideally each party (exporting and importing country) shall be able to select the lists to be used for the screening. These lists can be managed by the country’s jurisdiction, or come from other entities such as UN, Interpol or others.

 5. Regarding DP3, does the UPU expect to be able to create custom screen lists, or simply toggle on/off existing lists.

 Only to specify what lists to be used, according to the choice of each country

 6. In section 2.5 it states: “there is an annual cap and once the cap has been reached the declarations and referrals are free".  Is it the expectation that services under this agreement will also be subject to this cap and will be expected to be free once the “cap” has been met?

 The CFT indicates (section 4.8) that one of the assessment criteria is: "The prices and pricing structure are compatible with integration into the UPU CDS fees."

 It also says (section 2.5): "Bidders proposing a pricing model that can easily be bundled with the existing CDS fees will have an advantage"

It means that an annual cap is not mandatory, but will surely help answering the expectations above.

 The current annual cap is per licensee of the CDS (and licensees are the UPU Designated Operators).

 7. Referencing the question above (6), what is the annual cap?  Is it measured by volume or dollars? Does it change by Post, or is it the same for every Post?

 The current annual cap is per licensee of the CDS (and licensees are the UPU Designated Operators). The cap is in monetary value, with of course an equivalent volume of declarations.

 It varies according to the GNI classification (4 levels) of the country where the Designator Operator operates.

 All our IT prices are public on the UPU web site.

 8. In section 3, response format, can the response be in the form of a google document with sub-page links in the Vendor Response box.  To further clarify, can the response to this tender be an electronic document with the detailed responses in individual documents that are linked back to the Vendor Response box?

 We prefer that all bidders reply with a  PDF document, using the tables provided in the CFT. The PDF itself may have links to more detailed information/additional documents, but a clear answer to each question must appear in the tables (links shall only be used to provide additional, detailed information not specifically asked in CFT).

 We note from the wording of the services above; they appear to be quite similar to or the same as product references utilised by some market competitors. 

If xxx (or any other vendor) has differing but obvious product names for the services, which is clearly outlined in definitions, is it acceptable to the UPU that we make reference to our similar product names throughout our submission or does the UPU require we adhere to the description of tender services as referenced above?

 Strange comment. HS Codes, Prohibitions and Restrictions, Landed Costs are UPU terms. We are not referring to product names, but to functionalities. In your answer, it is important to respect the structure that is provided (simply replicate the tables and add your answers in the empty cells), but you can use different terms (specifically: to indicate your product(s) name(s)) if that is necessary.

 The response to our early question regarding HS4 on using 2022 nomenclature codes for countries that have not yet adopted the 2022 nomenclature edition of the harmonized tariff schedule has spurred a follow-up question.

 What does the UPU expect to be returned for the 8+ digit code for situations when the ship-to country has not yet adopted the 2022 tariff schedule?

 Example: The 2022 code for a smartphone is 8517.13, which is a brand new code that didn't exist in 2017. In the 2017 nomenclature edition, smartphones were part of 8517.12, a generic "cellphone" classification. If a classification is requested for a smartphone into Argentina (which hasn't yet adopted 2022),  what is the expected behavior? See attached for the relevant exert of the current Argentina published tariff schedule as published on July 14, 2023. Would it be:

 A) Return the 2022 6-digit code (8517.13) in all cases of an importing country not yet adopting 2022.  This will cause downstream problems when calculating the landed cost of the item, as no tariffs are published for 8517.13.

 B) Return the 2017 full HS code (8517.12.39000N). This will allow for accurate landed cost calculation.

 We suggest to address these questions during the implementation phase. Generally speaking:

–        We would like, as much as possible, to push all UPU member countries to adopt the 2022 nomenclature

–        With the scenario described: by default HS6 codes would be enough for EAD compliance, HS8+ would only be required if the calling Post wants to use the landed cost calculation in addition

 1. Can you please let us know all user types and user journeys for the lookup engine?

We anticipate two major user journeys:

A-Customs Declaration is keyed-in our CDS. Only the description of the goods, in natural language, is captured. A call is made to the HS lookup to return possible (one or more) codes. User validates the proposed code, or selects the most plausible one form the list proposed.

B- Customs Declaration is keyed-in our CDS, with both an HS code and the description of the goods in natural language. A call is made to the HS lookup to check if code and description match. If they don’t, the HS lookup returns a better code and user decides or not to validate the proposed code.

 A variation of the above: CDS may also be interfaced with a local system. In that case, Customs Declarations can be imported in batches into CDS, and the journeys A and B above will then also happen in batches.

 2. Would the user journeys be defined by the client OR the vendor expected to propose?

 Final decision will be by the client (the postal organization using CDS). However the vendor’s expertise/guidance is welcome.

 3. Do you have any technology stack decided or vendor should suggest one?

 Our CDS is a Microsoft-based software. Noting that interfaces with the Vendor’s solution will be through API, that solution can use a different technology stack. Depends as well on the hosting options (your question 6 below). 

4. Do you need multilingual support? 

Yes as per our requirements HS3, HS5, DP4, and P4. 

5. Is there any data archival or migration requirement? If yes, please provide detailed information on the same.

We don’t expect that the vendor’s solution will store any data. If it does, please refer to our requirement I8.

6. Do you have any hosting preference or vendor should suggest one?

See requirement I3. 

7. Can you please let us know the capacity of the application/website in terms of users (eg. 100K users; 5K access requests per day etc.)?

We can only disclose this in a later stage. It will largely depend on the adoption by CDS users, and this adoption will be driven largely by the costs.

 8. Can you please provide us tech stack and hosting details of (the Customs Declaration System) CDS software?

 We will in a later stage.

 9. Regarding integration with CDS software, are the APIs already available or do we need to develop the APIs for integration purposes?

 To be evaluated during the software integration project. 

10. Apart from CDS, do we need to integrate it with any other internal or third-party system?

No. 

11. We are assuming all the HS Codes along with all the descriptions will be provided by the client. Please confirm.

See our answers to question 1 above.