Bid Proposal Manual¶

Introduction¶

Welcome to the Bid Proposal team!

We are the sharp blade of an axe. We amplify the efforts put in and crack open hard deals. We are always at the front line, taking initiatives, sharp, alert, focused and quick to respond.

Bid Proposal Process¶

ITB: Invitation To Bid (From Customer)
RFQ: Request For Quotation
RFI: Request For Information
BP: Bid Proposal
SS: Sales Support
VQ: Vendor Qualification (Require when the supplier is new and the value is substantial.)

(A) Bid Initiating Phase¶

flowchart TB
    a(["(A) Start"])
    itb([ITB])
    evaluate{"Evaluate<br/>ITB"}
    itb-registered{"ITB<br/>Registered"}
    register-itb("Request to Register/<br/>Register ITB")

    a --> itb
    itb --> evaluate
    evaluate --> |Go| itb-registered
    itb-registered -->|No| register-itb
    register-itb --> itb-registered

    initiate("Initalize Project<br/><tt>bid init</tt>")
    organize("Organize<br/>ITB Documents")

    itb-registered -->|Yes| initiate

    evaluate -->|No-go| Inform
    Inform --> End([End])

    b2((B))
    b((B))
    study(Study Deatiled<br/>Project Requirements)
    enough-partial-info{"Enough Partial Info to<br/>Liaise with Suppliers"}
    required-clarification{"`Require<br/> **Initial** Clarification<br/>or Additional Info`"}
    send-rfi("Send RFI/Clarification<br/>to Customer")

    initiate --> organize
    organize --> study
    study --> required-clarification
    required-clarification --> |Yes| enough-partial-info
    enough-partial-info --> |Yes| b
    enough-partial-info --> |Yes/No| send-rfi
    send-rfi --> required-clarification
    required-clarification ---> |No| b2

(B) Supplier RFQ Phase¶

flowchart TB
    b(("B"))
    b2((B))
    b3((B))
    drop([Drop])
    send-rfq("Send RFQ/RFI to Suppliers<br/>or Price Negotiation with Suppliers")
    require-clarification-s{"Require<br/>Clarification<br/>or Additional<br/>Info"}
    received-rfq{"Received<br/>Quotation or<br/>Information"}
    meet-specs{"Meet<br/>Requirement<br/>Specs"}
    try{"Tries <= 3"}
    is-critical-supplier{"Is Critical<br/>Supplier"}
    inform("Inform<br/>Sales/Customer")
    inform2("Inform<br/>Sales/Customer")
    chase("Chase<br/>Supplier")
    End([End])
    End2([End])
    drop2([Drop])
    negotiate{"Right Time to<br/>Negotiate Price"}
    new-supplier{Is New Supplier}
    require-vq{Require VQ}
    vq(Engage Purchasing<br/>for Vendor Qualification)
    price-negotiated{Price<br/>Negotiated}
    make-request("Make Request<br/> & Negotiate")
    c((C))
    has-alternate-s{"Has Alternative<br/>Supplier"}
    is-critical-requirement{"Is Critical<br/>System<br/>Requirement"}

    b --> send-rfq
    send-rfq --> received-rfq
    received-rfq --> |Yes| require-clarification-s
    require-clarification-s --> |Yes| send-rfq
    received-rfq --> |"No<br/>Not In-Time"| is-critical-supplier
    is-critical-supplier --> |Yes| try
    is-critical-supplier --> |No| drop
    try --> |Yes| chase
    try --> |No| inform
    inform --> End
    chase --> received-rfq
    require-clarification-s --> |No| meet-specs
    meet-specs --> |No| is-critical-requirement
    meet-specs --> |Yes| new-supplier
    new-supplier --> |No| price-negotiated
    new-supplier --> |Yes| require-vq
    require-vq --> |Yes| vq
    require-vq --> |No| price-negotiated
    vq --> price-negotiated
    negotiate --> |No| c
    price-negotiated --> |Yes| c
    price-negotiated --> |No| negotiate
    negotiate --> |Yes| make-request
    make-request --> b2
    is-critical-requirement --> |No| drop2
    is-critical-requirement --> |Yes| has-alternate-s
    has-alternate-s --> |Yes| b3
    has-alternate-s --> |No| inform2
    inform2 --> End2

    click vq "https://egg.posonekyu.com/bid-proposal/jason-vendor-qualification-form-r4-2023-07-14.docx"

(C) Bid Compilation Phase¶

flowchart TB
    c((C))
    compile-proposal("Compile Into Main Proposal")
    proposal-completed{"Proposal Completed"}
    has-enough-time{"Has Enough Time"}
    has-historical-data{"Has Historical Data"}
    request-extension("Request ITB Extension")
    allow-partial-submission{"Partial<br/>Submission<br/>Allowed"}
    seek-consensus("Seek Internal Consensus<br/>to Drop ITB")
    send-review("`Internal Review`")
    approved{"Approved"}
    revise-proposal("Revise Proposal")
    extension-granted{"Extension<br/>Granted"}
    prepare-docs("Generate & Prepare<br/>Necessary Docs")
    inform("Inform<br/>Sales/Customer")
    c1((C1))
    c11((C1))
    d((D))
    b2((B))
    End([End])
    b((B))
    project-phase{"Porject Phase"}
    e1((E1))

    c --> compile-proposal
    compile-proposal --> proposal-completed
    proposal-completed --> |Yes| c1
    c1 --> send-review
    send-review --> approved
    approved --> |Yes| prepare-docs
    prepare-docs --> project-phase
    project-phase --> |Submission| d
    project-phase --> |Clarification| e1
    approved --> |No| revise-proposal
    revise-proposal --> send-review
    has-enough-time --> |Yes| b
    proposal-completed --> |No| has-enough-time
    request-extension --> extension-granted
    has-historical-data --> |Yes| compile-proposal
    has-enough-time --> |No| has-historical-data
    has-historical-data --> |No| request-extension
    extension-granted --> |No| allow-partial-submission
    allow-partial-submission --> |Yes| c11
    allow-partial-submission --> |No| seek-consensus
    extension-granted --> |Yes| b2
    seek-consensus --> inform
    inform --> End

(D) Bid Submission Phase¶

flowchart TB
    d((D))
    send-for-commercial("Send for<br/>Commercial Review")
    %% Sales, BP, SS
    submission-by{"Submission By"}
    %% Direct, Portal
    submission-mode{"Submission Mode"}
    submit-via-email("Submit Via Email")
    submit-via-portal("Submit Via Portal")
    inform("Inform Customer")
    include-pdf("Include Required Files<br/>in Commercial Review Itself<br/>or Give These Separately<br/>to Submit")
    e((E))

    d --> send-for-commercial
    send-for-commercial --> submission-by
    submission-by --> |BP| submission-mode
    submission-mode --> |Direct| submit-via-email
    submit-via-email --> e
    submission-mode --> |Portal| submit-via-portal
    submit-via-portal --> inform
    inform --> e
    submission-by --> |SS| include-pdf
    submission-by --> |Sales| e
    include-pdf --> e

(E) Bid Clarification Phase¶

flowchart TB
    e((E))
    receive-response{"Receive Customer Response"}
    proposal-type{"Proposal Type"}
    pass-time{"Sufficient Time<br/>Has Elapsed"}
    wait("Wait")
    response-type{"Response Type"}
    work-with-sales("Work Together<br/>with Sales")
    require-clarification-s{"Required<br/>Clarification<br/>with Suppliers"}
    prepare-docs("Prepare<br/>Necessary Docs")
    b((B))
    d((D))
    mark-lost("Mark Project Lost")
    End1([End])
    tries{"Tries <= 3"}
    End2([End])
    chase("Chase<br/>Sales/Customer")
    f((F))
    e1((E1))
    e2((E))


    e --> receive-response
    tries --> |Yes| chase
    receive-response --> |No| pass-time
    wait --> pass-time
    pass-time --> |Yes| proposal-type
    pass-time --> |No| wait
    proposal-type --> |Budgetary| End1
    proposal-type --> |Firmed| tries
    tries --> |No| mark-lost
    mark-lost --> End2
    chase --> e2
    receive-response --> |Yes| response-type
    response-type --> |Lost| mark-lost
    response-type --> |Commercial<br/>Clarification| work-with-sales
    response-type --> |Tecnical<br/>Clarification| e1
    e1 --> require-clarification-s
    require-clarification-s --> |No| prepare-docs
    require-clarification-s --> |Yes| b
    work-with-sales --> prepare-docs
    prepare-docs --> d
    response-type --> |PO<br/>Contract| f

(F) Bid Handover Phase¶

flowchart TB
    f((F))
    check-po(Check PO or Contract)
    po-correct{PO Correct}
    highlight-discrepancies(Highlight Discrepancies in<br/>PO or Contract Document)
    inform(Inform Sales, SS or Customer)
    mark-won(Mark Project Won)
    handover("Handover Project by Following Handover Checklist")
    attend-internal(Attend Internal KOM)
    attend-external(Attend External KOM)
    End([End])

    f --> check-po
    check-po --> po-correct
    po-correct --> |No| highlight-discrepancies
    highlight-discrepancies --> inform
    inform --> check-po
    po-correct --> |Yes| mark-won
    mark-won --> handover
    handover --> attend-internal
    attend-internal --> attend-external
    attend-external --> End

    click handover "https://egg.posonekyu.com/bid-proposal/sample_handover_checklist_r3.pdf"

Proposal File Versioning¶

Budgetary: As long as the client we are quoting to does not have the project in hand themselves, it will be treated as budgetary.
Firmed: The client has the project in hand and is looking for actual purchase.
VO: Variation Order for the project we have already won.
Major Revision: It means there is any kind of change in selling price. If in doubt, use major revision. Major revision requires updating changes in color that correspondances to the revision number.
Minor Revision: It means there is no change in price and that the change is only technical or re-arrangement of items. The color for the changes remains as per the current revision number.

flowchart TB
    s([Start])
    proposal-type{Proposal Type}
    budgetary("`Code **B** Suffix<br/>File Name with B0, B1, B2...
    **B** code starts count from **0**`")
    revision-type{Revision Type}
    first-submission("`Code **R** Suffix<br/>Very First Submission<br/>**R0**. if VO, **V1-R0**`")
    major-revision("`Update **R** number<br/>e.g. **R1, R2**...,<br/>if VO, **V1-R1, V3-R1**, ...
    Revision Color Update Required`")
    minor-revision("`Append '.' & sub-number after major-revision e.g. **R0.1, R2.2** ...,
    if VO, **V1-R0.1, V2-R1.2**,...
    Revision Color Update **Not** Required`")
    vo("`Code **V** Suffix<br/>File Name with V1, V2, V3... followed by hyphen**(-)**
    e.g. **V1-, V2-**
    **V** code starts count from **1**<br/>`")
    End([End])

    s --> proposal-type
    proposal-type --> |Budgetary| budgetary
    proposal-type --> |Firmed| revision-type
    proposal-type --> |VO| vo
    revision-type --> |First| first-submission
    revision-type --> |"Major<br/>(Selling Price Change)"| major-revision
    revision-type --> |"Minor<br/>(No Selling Price Change)"| minor-revision
    vo --> revision-type
    budgetary & first-submission & major-revision & minor-revision --> End

The revision without the minor revision number, e.g. R0, V2-R1, etc., is implicitly considered to be of minor revision "0". This means R0=R0.0, V1-R0=V1-R0.0, etc. Therefore, when a minor revision is carried out, the count starts from 1.

For MODEC/OFS Budgetary Proposals

They do not accept if we put in as Budgetary Proposal in the cover page. In this case, in the cover page we can put in Commercial Proposal. However, file version to remain Code B.

Removing vs. Crediting Items¶

Overview¶

There are two different things a revised proposal might need to express, and they are not the same and not interchangeable:

Removing an item (REMOVED) — the item is simply no longer part of the deal. Nothing was ever charged for it, and nothing is owed back. Its price and cost disappear from every total, as if it had never been quoted.
Crediting an item (negative quantity) — the item was previously quoted, ordered, or delivered, and the client now needs money back for it (e.g. they've swapped to a different model after placing the order). The item's full value is subtracted from every total — cost, BUC, selling price, and profit all move into negative territory for that line.

These produce different numbers — always pick the one that matches what actually happened

REMOVED makes an item contribute zero. A negative-quantity credit makes an item contribute a negative value equal to its full price. Using the wrong one on a real lot will make the sheet subtotal wrong by exactly that item's value — this has happened before and is the reason this section exists. If you're not sure which applies, ask: "is the client owed money back for this, or did it just never happen?" Owed money back → credit. Never happened → REMOVED.

Removing an Item — `REMOVED`¶

When to use¶

Use REMOVED when an item is being dropped from the scope of the proposal and no money changes hands either way — e.g. it was included in an earlier draft and is being taken out before the client ever saw pricing for it, or it's genuinely out of scope now.

How to apply¶

Set the Scope column to REMOVED. Leave the Qty at its normal, positive value — REMOVED works the same regardless of quantity sign, so there's no need to negate anything.

Full lot/set removal¶

Set the Title row's Scope to REMOVED. Leave the sub-items exactly as they are — they don't each need their own REMOVED tag; the Title's REMOVED covers the whole lot.

9   PROGRAMMING KIT    1   lot   ...   Scope: REMOVED
  1   Programming USB Cable For R7Ex    6   ea
  2   Programming USB Cable For DM      6   ea
  3   Programming USB Cable For DP      6   ea

The lot's Title-row price, cost, BUC, and profit all go blank/zero, exactly as for a single-item REMOVED row — it's the same mechanism, just applied to the row that aggregates the whole lot. The sub-items' own individual price cells stay blank too (lot sub-items never show their own price — only the Title row does), so nothing further needs to change on them.

Partial removal — one sub-item within a retained lot¶

Set the sub-item (Lineitem) row's Scope to REMOVED. Leave the Title row and other sub-items untouched.

9   PROGRAMMING KIT    1   lot   ...
  1   Programming USB Cable For R7Ex    6   ea   Scope: REMOVED
  2   Programming USB Cable For DM      6   ea
  3   Programming USB Cable For DP      6   ea

The lot Title's price and cost figures reduce automatically to reflect only the remaining sub-items — the removed sub-item contributes nothing to the lot total.

Financial impact¶

Column	Effect
Price / Unit Price cells	Blank — nothing is shown, nothing is charged
Cost, BUC, Selling Price, Profit	Zero contribution at every level (line item, lot, sheet subtotal)

REMOVED items are excluded from every total as if they were never on the sheet at all.

If both the lot and one of its sub-items are marked REMOVED¶

Marking the Title row REMOVED already zeroes out the whole lot — the sheet only looks at the Title row's own Scope to decide whether to blank the lot's price/cost/profit, regardless of what any individual sub-item is set to. So additionally marking a sub-item REMOVED has no further effect while the lot stays removed — it's redundant, not wrong, but it doesn't do anything the Title-level REMOVED wasn't already doing.

The real risk shows up later: if someone un-removes the lot (clears the Title's Scope) without noticing a sub-item was separately marked REMOVED, that sub-item will silently stay excluded from the lot total from that point on — a leftover flag nobody remembers setting. Avoid the confusion by only marking REMOVED at one level at a time: either the whole lot via the Title row, or specific sub-items, not both.

Crediting an Item — Negative Quantity¶

When to use¶

Use a negative quantity when the client needs a credit against something already charged — most commonly a post-order model swap (old item credited back while the new model is added as a normal line), a return, or any other case where money is actually owed back.

How to apply¶

Enter a negative quantity in the Qty column and leave the Scope column blank. Do not combine this with the REMOVED keyword — a negative quantity paired with a blank Scope is what makes the sheet compute it as a real subtraction; REMOVED would zero the row out and no credit would show at all.

Full lot/set credit¶

Set the Title row Qty to negative. Leave all sub-items at their original positive quantities.

9   PROGRAMMING KIT    -1   lot   ...
  1   Programming USB Cable For R7Ex     6   ea
  2   Programming USB Cable For DM       6   ea
  3   Programming USB Cable For DP       6   ea

The lot price and all financial columns (TCDQL, TSPL, TP, TM) automatically go negative, correctly reflecting the credit back to the client.

Partial credit — one sub-item within a retained lot¶

Set the sub-item (Lineitem) row Qty to negative. Leave the Title row at its original positive quantity.

9   PROGRAMMING KIT    1   lot   ...
  1   Programming USB Cable For R7Ex    -6   ea   ← credited
  2   Programming USB Cable For DM       6   ea
  3   Programming USB Cable For DP       6   ea

The lot price adjusts downward by the credited sub-item's full value — the credit is subtracted, not excluded. The credited sub-item shows as a line with a negative number (it remains in Lumpsum format like the other sub-items).

Set-based items¶

Same rules apply. Negate the Title row to credit the whole set, or negate a sub-item to credit that one component of a retained set.

Financial impact¶

Full lot/set credit (negative Title qty)¶

All financial columns on the Title row go negative:

Column	Effect
G (Subtotal Price)	Negative — the credit amount shown to the client
TCDQL	Negative — material cost credit
BTCQL	Negative — base cost credit
TSPL	Negative — selling price credit
TP	Negative — profit credit
TM (GM%)	Shows the item's original margin % (informative — signals what was given up)

The sheet Subtotal row aggregates all of these correctly. The project-level GM recalculates to reflect the net position after the credit.

Sub-item credit (negative Lineitem qty)¶

The lot Title's financial figures reduce by the credited sub-item's full value:

Column	Effect
G (Subtotal Price, lot Title)	Reduced by the credited sub-item's value
TCDQL, BTCQL, TSPL, TP	Reduced accordingly
TM (GM%)	Recalculates based on the revised lot figures

Rules and Constraints¶

Never mark an item both REMOVED and negative-quantity at once. REMOVED zeroes the row regardless of quantity, so a negative quantity on a REMOVED row has no financial effect — it's just confusing to read. Pick one.
Never negate both the Title and a sub-item within the same lot. If the Title is already negative (whole lot credited), negating a sub-item within it is meaningless — the sub-item's credit is already folded into the Title's. The result is undefined and should be avoided.
Don't mark both the Title and a sub-item REMOVED within the same lot. The Title's REMOVED already zeroes the whole lot, so a REMOVED sub-item does nothing extra while the lot stays removed — but it's an easy-to-forget leftover flag that only bites later, if the lot is ever un-removed. See If both the lot and one of its sub-items are marked REMOVED.
REMOVED and negative-quantity are not financially equivalent. REMOVED contributes zero. A negative quantity subtracts the item's full value. On the same item, these produce different sheet subtotals — the difference is exactly that item's price. Choose based on whether money is owed back (credit → negative quantity) or not (never happened → REMOVED).
Positive sub-item quantities are not affected. When you negate a sub-item, all other sub-items in the same lot continue to contribute normally to the lot price.
A credited sub-item reduces the lot price by its own value; it does not make the lot price negative on its own. Only negating the Title row can drive the lot total negative — that's intentional and represents crediting the whole lot.

Gross Margin on Credited Items¶

When the Title row is negated (full credit), the TM column shows the same margin percentage as the original item. This is correct: the percentage reflects the item's inherent profitability, which is unchanged by crediting it back. The sheet-level subtotal GM is the figure to watch — it recalculates to the correct net margin across all remaining and credited items.

When a sub-item is negated (partial credit), the lot's TM recalculates based on the revised lot figures.

Summary of Scope Keywords¶

For reference, all scope keywords and their effect on pricing:

Scope	Price shown	Included in totals
(blank)	Yes	Yes
`OPTION`	Yes	No
`INCLUDED`	No	Yes (cost only)
`WAIVED`	No	Yes (cost only)
`TBA`	No	No
`REMOVED`	No	No — zero, regardless of Qty sign
Negative Qty, blank Scope (Credit)	No (sub-item) / Negative (Title)	Yes — subtracted as a credit

Bid Proposal Manual¶

Introduction¶

Bid Proposal Process¶

(A) Bid Initiating Phase¶

(B) Supplier RFQ Phase¶

(C) Bid Compilation Phase¶

(D) Bid Submission Phase¶

(E) Bid Clarification Phase¶

(F) Bid Handover Phase¶

Proposal File Versioning¶

Removing vs. Crediting Items¶

Overview¶

Removing an Item — REMOVED¶

When to use¶

How to apply¶

Full lot/set removal¶

Partial removal — one sub-item within a retained lot¶

Financial impact¶

If both the lot and one of its sub-items are marked REMOVED¶

Crediting an Item — Negative Quantity¶

When to use¶

How to apply¶

Full lot/set credit¶

Partial credit — one sub-item within a retained lot¶

Set-based items¶

Financial impact¶

Full lot/set credit (negative Title qty)¶

Sub-item credit (negative Lineitem qty)¶

Rules and Constraints¶

Gross Margin on Credited Items¶

Summary of Scope Keywords¶

Removing an Item — `REMOVED`¶