Task 5 — Medicine Store Network

Objective

Create a network of medicine stores.

Each medicine market contains its own medicine inventory.

The system must support:

medicine information queries
filtering by medical purpose
filtering by effectiveness
filtering by price
direct medicine lookup
medicine purchases
multi-item purchases
price comparison between markets
stock updates
partial-order behavior
out-of-stock reporting

Medicine Model

Each medicine contains:

ID
Medicine Name
Purpose
Level of Effectiveness
Price in Pounds
Availability

A possible model is:

type Medicine struct {
    ID            int
    Name          string
    Purpose       MedicinePurpose
    Effectiveness int
    Price         float64
    Availability  int
}

Medicine Purpose

Six purpose types exist:

Type 1 — Flu
Type 2 — Throat Infection
Type 3 — Nose Drops
Type 4 — Stomach Virus
Type 5 — High Pressure
Type 6 — Headache

The market tables use:

A typed model is recommended. For example:

type MedicinePurpose string

Effectiveness

Effectiveness is an integer from:

1
2
3

The implementation must reject values outside this range when validating market data.

Medicine Market

A possible market model is:

type MedicineMarket struct {
    ID        int
    Medicines []Medicine
}

Medicine Market 1

Use the following data:

ID | Name | Purpose | Effectiveness | Price | Availability

1  | N13 | T1 | 2 | 14 | 10
2  | M10 | T4 | 3 | 12 | 8
3  | K21 | T6 | 2 | 10 | 7
4  | PL1 | T3 | 3 | 18 | 7
5  | TR1 | T2 | 2 | 14 | 6
6  | D10 | T5 | 1 | 11 | 4
7  | Q15 | T6 | 3 | 20 | 3
8  | L20 | T3 | 2 | 15 | 8
9  | GF1 | T1 | 1 | 12 | 9
10 | BC1 | T5 | 2 | 14 | 5
11 | ZC1 | T4 | 1 | 14 | 6
12 | MGS | T2 | 2 | 12 | 12
13 | W15 | T5 | 3 | 20 | 4
14 | H25 | T2 | 2 | 15 | 7
15 | AF1 | T6 | 1 | 12 | 6
16 | DFC | T3 | 2 | 14 | 7
17 | KP1 | T4 | 3 | 14 | 9
18 | TUP | T1 | 2 | 12 | 8

Medicine Market 2

Use the following data:

ID | Name | Purpose | Effectiveness | Price | Availability

1  | FR2 | T1 | 2 | 15 | 10
2  | FT3 | T4 | 3 | 13 | 6
3  | QE1 | T6 | 1 | 11 | 9
4  | GH1 | T3 | 3 | 19 | 7
5  | TY2 | T2 | 2 | 13 | 5
6  | V10 | T5 | 1 | 12 | 6
7  | AD3 | T6 | 3 | 21 | 5
8  | LP2 | T3 | 2 | 16 | 10
9  | BK1 | T1 | 1 | 13 | 6
10 | ML2 | T5 | 2 | 13 | 7
11 | DV1 | T4 | 3 | 12 | 8
12 | MG2 | T2 | 2 | 11 | 10
13 | WR1 | T5 | 3 | 19 | 3
14 | HR2 | T2 | 2 | 14 | 4
15 | AU1 | T6 | 1 | 10 | 6
16 | DF2 | T3 | 2 | 15 | 7
17 | ZR3 | T4 | 1 | 16 | 6
18 | MFR | T1 | 2 | 14 | 5

Query Types

Two major query forms exist:

Information Query
Purchase Query

An information query searches medicine data without changing stock.

A purchase query selects medicine, creates an order, and updates stock.

Information Queries

Information queries must not modify medicine availability.

Alex

Alex wants information about all medicines where:

Purpose = Flu
Effectiveness = 3
Price <= 15 pounds

This is an information-only request.

No inventory may be changed.

Purchase Queries

Ben

Ben wants to buy any medicine matching:

Purpose = Throat Infection
Effectiveness = 2
10 <= Price <= 13
Quantity = 2 boxes

The implementation must find the best solution based on price.

David

David wants to buy any medicine matching:

Purpose = Nose Drops
Effectiveness = 2
Price <= 16
Quantity = 2 boxes

Elena

Elena wants to buy any medicine matching:

Purpose = Stomach Virus
Effectiveness = 2
Price <= 16
Quantity = 1 box

Fred

Fred wants to buy medicine matching:

Purpose = High Pressure
Effectiveness = 3
Price <= 19
Quantity = 3 boxes

Direct Medicine Purchases

Some buyers request medicines directly by medicine name.

Kyle — Direct Order 1

Kyle wants:

AU1 — 3 boxes
AD3 — 3 boxes

Merry

Merry wants:

K21 — 2 boxes
W15 — 4 boxes

Partial Order Case

Kyle also submits another order:

Q15 — 3 boxes
AD3 — 3 boxes

with the rule:

If one medicine is found, execute the purchase anyway.

This means the order explicitly allows partial completion.

Selena

Selena wants to buy medicine matching:

Purpose = Stomach Virus
Effectiveness = 3
Excluded medicines:
    DV1
    KP1

Price = irrelevant
Quantity = 3 boxes

The implementation must not return either excluded medicine.

Search Query Model

A flexible query model may be used.

For example:

type MedicineSearch struct {
    Purpose           *MedicinePurpose
    Effectiveness     *int
    MinimumPrice      *float64
    MaximumPrice      *float64
    IncludedNames     []string
    ExcludedNames     []string
}

Optional fields allow the same model to represent different search combinations.

Purchase Item

Direct orders may use:

type PurchaseItem struct {
    MedicineName string
    Quantity     int
}

Purchase Request

A possible model is:

type PurchaseRequest struct {
    Buyer               string
    Search               *MedicineSearch
    Items                []PurchaseItem
    AllowPartialPurchase bool
}

The exact design is left to the implementation.

Selecting the Best Purchase

For every purchase made through search criteria, find the best solution for the buyer based on price.

This means the implementation must compare matching and sufficiently stocked medicine across markets.

When equivalent medicines satisfy the request, prefer the solution producing the lowest final purchase price.

Stock Requirements

A medicine is purchasable only if its availability is sufficient for the requested quantity.

For example:

Requested quantity = 3
Availability = 2

is insufficient.

The purchase must not cause:

Availability < 0

Stock Update

After a successful purchase:

newAvailability = oldAvailability - purchasedQuantity

Information-only queries must never change availability.

Out of Stock

After updating inventory, the system must report when a specific medicine becomes out of stock.

For example:

Availability before purchase = 3
Purchased = 3
Availability after purchase = 0

The result should include:

medicine is now out of stock

Medicine Not Found

If the requested medicine cannot be found, the system must report that condition.

This applies to both:

information queries
purchase queries

Do not silently return an empty successful result.

Multiple Medicine Orders

For orders containing multiple medicines, the request must define whether partial fulfillment is allowed.

All-or-Nothing

When:

AllowPartialPurchase = false

and one required item cannot be purchased, the complete order should not be executed.

Partial Purchase

When:

AllowPartialPurchase = true

available items may still be purchased even when another requested item cannot be supplied.

The Kyle Q15 + AD3 query explicitly requires this behavior.

Order Model

A purchase result should contain enough information to explain the complete order.

For example:

type OrderItem struct {
    MarketID       int
    Medicine       Medicine
    Quantity       int
    UnitPrice      float64
    TotalPrice     float64
    RemainingStock int
}

type Order struct {
    Buyer      string
    Items      []OrderItem
    FinalPrice float64
    Complete   bool
}

Purchase Output

For every completed purchase, print:

Buyer Name
Medicine Description
Medicine Name
Quantity
Selected Market
Unit Price
Item Price
Final Order Price

For a multi-item order, print every purchased item.

Information Result

Information queries should return matching medicines without creating an order.

For example:

type MedicineSearchResult struct {
    MarketID int
    Medicine Medicine
}

Important Search Distinction

Search availability and purchase availability are different concepts.

For information-only requests, a matching medicine may still be useful to display even if the query is not performing a purchase. For purchases, the market must contain enough boxes to satisfy the requested quantity.

Validation

Validate:

medicine purpose
effectiveness range 1..3
price >= 0
availability >= 0
purchase quantity > 0
market ID
medicine identity

Requirements

The implementation must:

model medicine
model medicine purpose
model medicine markets
load both supplied inventories
support information-only queries
support purchase queries
filter by purpose
filter by effectiveness
filter by price
support excluded medicine names
support direct medicine-name purchases
compare prices across markets
select the best purchase solution
verify stock
update stock after purchase
leave stock unchanged for information queries
report medicine-not-found conditions
report out-of-stock conditions
support multi-item orders
support configurable partial-order execution
print completed order information
calculate the final order price

Modeling Goal

The central distinction is between Search & Purchase.

A useful architecture is:

        MedicineMarket
              |
              v
        Search Engine
              |
              +-------------------+
              |                   |
              v                   v
        Information Query     Purchase Request
                                  |
                                  v
                            Order Processor
                                  |
                                  v
                            Inventory Update

Searching should not directly mutate inventory.

Inventory changes belong to successful purchase processing.

Keyboard shortcuts

Scalionix Programming Task Library [ v1.0.0 ]