{"id":17919,"date":"2026-01-28T10:13:45","date_gmt":"2026-01-28T10:13:45","guid":{"rendered":"https:\/\/tenthplanet.in\/idempiere\/?p=17919"},"modified":"2026-09-11T12:13:57","modified_gmt":"2026-09-11T12:13:57","slug":"how-rfq-topic-works-in-idempiere","status":"publish","type":"post","link":"https:\/\/tenthplanet.in\/idempiere\/how-rfq-topic-works-in-idempiere\/","title":{"rendered":"How RFQ Topic Works in iDempiere"},"content":{"rendered":"\n

RFQ Topics, Subscribers, and Restrictions<\/strong> together control RFQ distribution in iDempiere. Topics define what is requested, while subscribers and restrictions determine eligible vendors. This ensures quotations go only to relevant suppliers, keeping procurement focused, auditable, and efficient without manual filtering.<\/p>\n\n\n\n

Process Flow Diagram<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

RFQ Topic \u2013 Central Definition<\/strong><\/h2>\n\n\n\n

An RFQ topic represents a procurement requirement<\/strong> grouped under a single purpose, such as a bulk purchase or annual sourcing cycle. It acts as the anchor for supplier subscriptions.<\/p>\n\n\n\n

The topic defines:<\/p>\n\n\n\n

    \n
  • The overall sourcing intent<\/li>\n\n\n\n
  • The scope of products or categories<\/li>\n\n\n\n
  • Whether the RFQ is active and available for use<\/li>\n<\/ul>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    Once created, the RFQ topic does not send anything by itself. It becomes operational only when subscribers are added.<\/p>\n\n\n\n

    Subscribers \u2013 Who Receives the RFQ<\/strong><\/h2>\n\n\n\n

    Subscribers link business partners<\/strong> to an RFQ Topic. Each subscriber represents a vendor who is eligible to receive RFQs for that topic.<\/p>\n\n\n\n

    This layer answers who should be invited<\/em>.<\/p>\n\n\n\n

    Key behavior:<\/p>\n\n\n\n

      \n
    • A subscriber is tied to one business partner and location<\/li>\n\n\n\n
    • Active subscribers are considered during RFQ generation<\/li>\n\n\n\n
    • Opt-out date allows temporary or permanent exclusion without deleting history<\/li>\n<\/ul>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      Subscribers alone do not limit what<\/em> the vendor can quote. That control comes from Restrictions.<\/p>\n\n\n\n

      Restrictions \u2013 What the Vendor Can Quote<\/strong><\/h2>\n\n\n\n

      Restrictions define product-level or category-level eligibility<\/strong> for each subscriber. This ensures vendors receive RFQs only for items they actually supply.<\/p>\n\n\n\n

      This layer answers what each vendor is allowed to quote<\/em>.<\/p>\n\n\n\n

      Key logic:<\/p>\n\n\n\n

        \n
      • Restrictions are defined per subscriber<\/li>\n\n\n\n
      • Can be based on product<\/strong> or product category<\/strong><\/li>\n\n\n\n
      • Multiple restrictions can exist for one subscriber<\/li>\n\n\n\n
      • Only matching RFQ lines are sent to the vendor<\/li>\n<\/ul>\n\n\n\n
        \"\"<\/figure>\n\n\n\n

        End-to-End Workflow Logic<\/strong><\/h2>\n\n\n\n
          \n
        • RFQ topic defines the sourcing context<\/li>\n\n\n\n
        • Subscribers define eligible vendors<\/li>\n\n\n\n
        • Restrictions filter products per vendor<\/li>\n\n\n\n
        • RFQ creation checks all three layers before sending<\/li>\n\n\n\n
        • Vendors receive only relevant RFQ lines<\/li>\n<\/ul>\n\n\n\n

          Outcome<\/strong><\/h2>\n\n\n\n

          This design creates a precise, scalable RFQ process<\/strong> where the right suppliers receive the right requests\u2014no noise, no manual filtering, and no procurement errors<\/p>\n\n\n