System Requirements Document for report-penjualan-harian

1. Introduction

report-penjualan-harian is a website for recording, reviewing, and exporting daily sales reports (laporan penjualan harian). The product exists so that a shop operator can capture each day's takings — with line-item detail and photographed evidence — and so that a supervisor or colleague can later open that same day's report and read the figures, the detail, and the images without altering them.

The product intent, taken directly from the authoritative requirement thread, is threefold and equally weighted:

1. Daily sales reporting — a website that holds a report for each day of selling.
2. Image storage (penyimpanan gambar) — the report must be able to store images, so photographed receipts, shelf shots, and product photos live with the day they belong to.
3. Excel export (export excel) — the recorded report data must be exportable to Excel.
4. Detail (detail) — the report is not a single number; it carries detail that can be inspected.

Audience. The primary audience is the person who keeps the ledger: the Sales Report Author, typically a small-shop operator who records the day's figures, adds line items, attaches images, and produces the Excel export. The secondary audience is the Sales Report Viewer, typically a supervisor or colleague who opens the daily report to review the recorded figures, the per-day detail, and the attached images.

The register of the product is deliberately that of a well-kept ledger: legible early in the morning before the shop opens and late at night when the day's figures finally balance. It is infrastructure, not a marketing surface.

2. System Overview

report-penjualan-harian is a web application with a first-party custom interface and a durable backend. It provides:

• A public Landing page that explains the daily sales report website, its detailed reports, its image storage, and its Excel export before any identity is established.
• First-use Sign Up and returning Login so that a person's daily sales reports, their details, and their stored images remain bound to the correct participant across sessions and devices.
• A Reports destination that lists recorded daily sales reports and lets a person continue into a report's details or into authoring a new one.
• A New Report workspace where the Sales Report Author records a daily sales report with detailed fields and attached stored images.
• A Report Details destination where a selected daily sales report, its sales details, and its stored images can be inspected.
• An Export destination where daily sales report data and details are selected and exported to Excel.

Actors. Two accepted human personas operate the product: the Sales Report Author and the Sales Report Viewer. The backend is a non-persona system actor that owns durable storage of reports, details, and images, and the generation and delivery of Excel exports.

Ownership. All accepted human-facing behavior is owned by first-party application pages. Durable report, detail, and image state, and Excel file generation, are owned by the backend system process; the human interaction that initiates and completes each of those outcomes is owned by a first-party page.

Narrow exclusions. This document does not introduce inventory management, point-of-sale terminal integration, accounting ledgers, payroll, multi-branch consolidation, customer relationship management, payment processing, or analytics forecasting. None of these were requested. The product records a day's sales, stores its images, shows its detail, and exports it to Excel.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a first-party web application with a custom user interface and a backend that persists data. The user asked for a website, so the delivery surface is the browser; no native mobile application, no provider-owned reporting surface, and no headless-only delivery is established by the source.

Access ownership. The Planning Scope establishes application-owned identity: durable daily sales reports, their details, and their stored images must remain bound to the correct participant, and the two accepted roles have different work to do. Access is therefore reconciled as follows:

• Landing, Login, and Sign Up are anonymously reachable. A protected destination cannot own the interaction that establishes access to itself, so first-use enrollment and returning verification live on their own anonymous surfaces.
• Reports and Report Details require a signed-in identity, because they expose durable, participant-bound report state.
• New Report and Export are restricted to the Sales Report Author role, because recording a day's report and producing its Excel export are the author's accepted responsibilities, while the Sales Report Viewer's accepted responsibility is to browse and inspect without editing.

This is the minimum identity continuity and role distinction required by the accepted journeys. It does not introduce adjacent account-management capabilities such as team administration, billing, or permission editors.

Current and future boundary. Everything described in sections 2c, 3, and 5 is current. No future-horizon requirements were stated by the user; section 11 records the assumptions that keep the current scope narrow.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

The page inventory below is the supplied final page contract, preserved exactly and in order.

Landing

• Information and state. Anonymous public entry. Explains what the daily sales report website is, that reports carry detail, that images are stored with the report, and that report data can be exported to Excel. No participant-specific data is shown.
• Primary action. Continue to Sign Up to begin recording daily sales reports; continue to Login for returning participants.
• Supporting actions. Navigate to the two identity surfaces; read the explanation of detail, image storage, and Excel export.
• Domain entities. None persisted. The page describes the daily sales report, its detail, its images, and its Excel export as concepts.
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Oversized headline Laporan penjualan harian stacked flush-left in three lines.
  • One sentence of body copy at a maximum measure of 46 characters per line.
  • A 1px-ruled table fragment showing three sample day rows — date, item count, total in tabular figures — with today's row marked by a 2px red left bar and its total set at 32px.
  • A stack of two photographed receipt thumbnails, slightly rotated, bleeding off the right viewport edge, each with a small-caps filename caption.
  • A small amber Ekspor Excel button pinned beneath the table fragment.
  • Entry controls to Sign Up and Login.
• States. Loading: none required, the page is static content. Empty: not applicable. Success: the visitor understands the product and can reach Sign Up or Login. Error: if the identity surfaces are unreachable, the entry controls remain visible and legible with an inline message. Recovery: the visitor can retry the entry control or reload the page.

Login

• Information and state. Anonymous returning-verification surface. Collects the credentials of an existing participant and establishes the signed-in session that unlocks Reports and Report Details.
• Primary action. Verify identity and continue into the signed-in product.
• Supporting actions. Move to Sign Up if the visitor has no identity yet; return to Landing.
• Domain entities. Participant identity (email address and password).
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Labelled credential fields as strict label/value pairs.
  • Primary submit control in signal red.
  • Inline link to Sign Up.
  • Inline error region.
• States. Loading: submit control shows a determinate busy state while verification runs. Empty: fields start empty with labels visible. Success: the participant lands on Reports with their role applied. Error: unrecognised credentials or an unreachable backend produce an inline message that does not clear the entered email. Recovery: the participant corrects the field and resubmits, or moves to Sign Up.

Sign Up

• Information and state. Anonymous first-use enrollment surface. Establishes a new participant identity so that daily sales reports, their details, and their images can be privately owned and resumed.
• Primary action. Create the identity and enter the signed-in product.
• Supporting actions. Move to Login if an identity already exists; return to Landing.
• Domain entities. Participant identity (name, email address, password) and the participant's role.
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Labelled identity fields as strict label/value pairs.
  • Role selection distinguishing Sales Report Author from Sales Report Viewer.
  • Primary submit control in signal red.
  • Inline link to Login.
  • Inline error region.
• States. Loading: submit control shows a determinate busy state while the identity is created. Empty: fields start empty with labels visible. Success: the participant is signed in and lands on Reports with the chosen role applied. Error: an already-registered email, a missing required field, or an unreachable backend produces an inline message naming the field. Recovery: the participant corrects the field and resubmits, or moves to Login.

Reports

• Information and state. Signed-in browse and overview destination for recorded daily sales reports. Shows the recorded days with their identifying values and provides continuation into a report's details or into authoring a new report.
• Primary action. Open a recorded daily sales report to inspect it in Report Details.
• Supporting actions. Continue to New Report (Sales Report Author only); continue to Export (Sales Report Author only); move along the date rail to reach a specific day.
• Domain entities. Daily sales report (report date, item count, day total), attached image count per report.
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Horizontal scrollable date rail of day chips; today's chip filled red with ink text; each chip carrying a tiny amber bar whose height encodes that day's sales volume.
  • Report list rendered as ruled rows, not cards, with a 2px left-edge colour bar marking the active row.
  • Per-row values: report date, item count, day total in tabular figures, image count badge in amber.
  • Continuation controls into Report Details, New Report, and Export.
• States. Loading: ruled placeholder rows hold the list's rhythm while reports are fetched. Empty: a ruled empty state states that no daily sales report has been recorded yet, with a continuation into New Report for the Sales Report Author. Success: recorded days are listed and openable. Error: a failed fetch shows an inline message with a retry control; the date rail remains usable. Recovery: retry the fetch, or continue to New Report if the failure persists.

New Report

• Information and state. Signed-in, author-restricted focused workspace for recording one daily sales report: its date, its detailed line items, and its attached stored images.
• Primary action. Save the daily sales report with its detail and images.
• Supporting actions. Add and remove line items; attach images; reorder attached images by drag; discard the draft; return to Reports.
• Domain entities. Daily sales report (report date, day total), sales detail line item (item name, quantity, unit price, line amount), stored image (file, filename caption, display order).
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Report date field as a labelled value pair.
  • Line-item table with small-caps column headers, ruled rows, and 0px row radii.
  • Running day total rendered as the largest number on the screen in tabular figures, with a red left-edge bar and a count-up that runs as line items are added.
  • Image attachment control and a ruled strip of bordered 4:3 evidence thumbnails with small-caps filename captions, reorderable by drag.
  • Unsaved-state indicator as a red dot.
  • Primary save control in signal red.
• States. Loading: the workspace opens with the date pre-filled and an empty line-item table. Empty: no line items and no images yet; the day total reads zero and the empty image strip states that no images are attached. Success: the report is saved and the author continues to Report Details for the saved day. Error: a missing report date, an invalid quantity or price, an unsupported or oversized image, or an unreachable backend produces an inline message naming the field or the file; entered line items and successfully uploaded images are preserved. Recovery: correct the named field or file and save again; the unsaved-state indicator remains until the save succeeds.

Report Details

• Information and state. Signed-in focused destination for one selected daily sales report: its date, its day total, its sales detail, and its stored images.
• Primary action. Read the selected day's figures, detail, and images.
• Supporting actions. Move between days; continue to Export (Sales Report Author only); return to Reports.
• Domain entities. Daily sales report (report date, day total), sales detail line item (item name, quantity, unit price, line amount), stored image (filename caption, display order).
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • The report date as a full-width ruled section header.
  • Strict label/value pairs separated by 1px hairlines rather than cards.
  • Day total as the largest number on the screen in tabular figures with a red left-edge bar.
  • Sales detail table with small-caps column headers and ruled rows.
  • Ruled strip of bordered 4:3 evidence thumbnails with small-caps filename captions.
  • Continuation control into Export for the Sales Report Author.
• States. Loading: ruled placeholder pairs hold the ledger rhythm while the report is fetched. Empty: a report with no line items or no images states that plainly in the corresponding section rather than showing a blank area. Success: the day's figures, detail, and images are readable. Error: a missing report or a failed fetch shows an inline message with a retry control and a return to Reports. Recovery: retry the fetch, or return to Reports and select another day.

Export

• Information and state. Signed-in, author-restricted focused destination for selecting daily sales report data and details and completing an Excel export.
• Primary action. Generate and download the Excel file for the selected daily sales report data and details.
• Supporting actions. Choose the day or day range to export; include or exclude the sales detail; return to Reports or Report Details.
• Domain entities. Daily sales report (report date, day total), sales detail line item (item name, quantity, unit price, line amount), generated Excel file.
• Component responsibilities.
  • Numbered section header with a full-width 1px rule.
  • Selection controls for the day or day range and for including sales detail.
  • A ruled preview of what the export will contain, in label/value pairs.
  • Primary export control in signal red with a determinate progress bar while the file is generated.
  • Pending-export state marked in amber.
• States. Loading: the selection controls populate while available days are fetched. Empty: with no recorded reports, the page states that there is nothing to export yet and offers a continuation to New Report. Success: the Excel file is generated and delivered as a download, and the page confirms which day or range was exported. Error: a failed generation or an unreachable backend shows an inline message with a retry control; the selection is preserved. Recovery: retry the export with the same selection, or adjust the selection and export again.

3. Functional Requirements

Each requirement below is a distinct story point with its provenance, lifecycle facts, and observable acceptance.

FR-01 — Daily sales report website (explicit) As a Sales Report Author, I should be able to use a website that holds a daily sales report for each day of selling, so that each day's takings are recorded in one place.

• Trigger/input: the author opens the product and chooses to record a day.
• Observable result: a daily sales report exists for that date and is listed on Reports.
• Access state: signed in as Sales Report Author.
• Failure/recovery: if the save fails, the entered data is preserved and the author can retry.
• Continuation: the author continues to Report Details for the saved day, or records another day.

FR-02 — Image storage with the report (explicit) As a Sales Report Author, I should be able to attach and store images with a daily sales report, so that photographed evidence lives with the day it belongs to.

• Trigger/input: the author attaches one or more image files while recording a report on New Report.
• Observable result: each stored image appears as a bordered 4:3 evidence thumbnail with a small-caps filename caption in the report's image strip, and the report's image count is reflected on Reports.
• Access state: signed in as Sales Report Author.
• Failure/recovery: an unsupported or oversized file is named in an inline message; already-uploaded images are preserved and the author can retry with another file.
• Continuation: the author reorders the thumbnails by drag and saves the report.

FR-03 — Excel export (explicit) As a Sales Report Author, I should be able to export daily sales report data to Excel, so that the recorded figures can be used outside the website.

• Trigger/input: the author selects a day or day range on Export and starts the export.
• Observable result: an Excel file containing the selected daily sales report data is generated and delivered as a download, and the page confirms which day or range was exported.
• Access state: signed in as Sales Report Author.
• Failure/recovery: a failed generation shows an inline message with a retry control and preserves the selection.
• Continuation: the author exports another range or returns to Reports.

FR-04 — Report detail (explicit) As a Sales Report Author, I should be able to record detail for a daily sales report, so that the day's total is backed by its line items.

• Trigger/input: the author adds line items on New Report, each with an item name, quantity, and unit price.
• Observable result: each line item appears as a ruled row with its line amount, and the day total updates as the largest number on the screen in tabular figures.
• Access state: signed in as Sales Report Author.
• Failure/recovery: an invalid quantity or price is named in an inline message and the other line items are preserved.
• Continuation: the author saves the report and continues to Report Details.

FR-05 — Detail inspection (explicit) As a Sales Report Viewer, I should be able to open a daily sales report and read its detail, so that I can review the recorded figures without editing them.

• Trigger/input: the viewer selects a day on Reports.
• Observable result: Report Details shows the report date as a full-width ruled section header, the day total as the largest number on the screen, the sales detail as ruled label/value rows, and the stored images as captioned thumbnails.
• Access state: signed in as Sales Report Viewer or Sales Report Author.
• Failure/recovery: a missing report or failed fetch shows an inline message with a retry control and a return to Reports.
• Continuation: the viewer moves to another day or returns to Reports.

FR-06 — Image inspection (explicit) As a Sales Report Viewer, I should be able to see the images stored with a daily sales report, so that I can check the photographed evidence for that day.

• Trigger/input: the viewer opens a report that has attached images.
• Observable result: the report's image strip shows each stored image as a bordered 4:3 thumbnail with its filename caption in small caps.
• Access state: signed in as Sales Report Viewer or Sales Report Author.
• Failure/recovery: if an image cannot be loaded, its thumbnail area states the failure and the rest of the strip remains readable.
• Continuation: the viewer continues reading the report's detail or returns to Reports.

FR-07 — Report browsing and continuation (explicit) As a Sales Report Author or Sales Report Viewer, I should be able to browse recorded daily sales reports, so that I can find the day I need and continue from there.

• Trigger/input: the participant opens Reports.
• Observable result: recorded days are listed as ruled rows with date, item count, day total in tabular figures, and an amber image count badge; the date rail shows day chips with today's chip filled red and each chip carrying an amber volume bar.
• Access state: signed in.
• Failure/recovery: a failed fetch shows an inline message with a retry control while the date rail stays usable.
• Continuation: the participant opens a day in Report Details, or the Sales Report Author continues to New Report or Export.

FR-08 — First-use enrollment (required_inference) As a Sales Report Author or Sales Report Viewer, I should be able to establish my own identity on first use, so that my daily sales reports and their images remain mine and can be resumed.

• Trigger/input: a visitor on Landing chooses to begin and completes the identity fields and role selection on Sign Up.
• Observable result: the identity is created, the participant is signed in, and the chosen role is applied.
• Access state: anonymous entry on Sign Up.
• Failure/recovery: an already-registered email, a missing required field, or an unreachable backend produces an inline message naming the field, and the entered values are preserved.
• Continuation: the participant lands on Reports.

FR-09 — Returning verification (required_inference) As a Sales Report Author or Sales Report Viewer, I should be able to verify my identity on return, so that I can reach my durable reports again.

• Trigger/input: a returning participant submits credentials on Login.
• Observable result: the session is established and the participant lands on Reports with their role applied.
• Access state: anonymous entry on Login.
• Failure/recovery: unrecognised credentials or an unreachable backend produce an inline message that does not clear the entered email; the participant can correct and resubmit or move to Sign Up.
• Continuation: the participant browses Reports.

FR-10 — Role distinction between author and viewer (required_inference) As the product, I should distinguish the Sales Report Author from the Sales Report Viewer, so that recording and exporting stay with the author while reviewing stays open to both.

• Trigger/input: the role is chosen at Sign Up and applied to the session.
• Observable result: New Report and Export are reachable by the Sales Report Author; Reports and Report Details are reachable by both roles; the Sales Report Viewer's experience of Reports and Report Details is read-only.
• Access state: signed in.
• Failure/recovery: a participant reaching a destination outside their role is returned to Reports with an inline explanation rather than a blank screen.
• Continuation: the participant continues with the work their role owns.

FR-11 — Durable storage of reports, details, and images (required_inference) As the product, I should persist daily sales reports, their sales detail, and their attached images durably, so that a recorded day survives beyond the session in which it was entered.

• Trigger/input: a successful save on New Report.
• Observable result: the report, its line items, and its images are retrievable on Reports and Report Details in a later session.
• Access state: backend system process, initiated by the signed-in Sales Report Author.
• Failure/recovery: a failed write leaves the previously stored state intact and reports the failure to the author, who can retry the save.
• Continuation: the author or a viewer opens the stored report.

FR-12 — Backend generation and delivery of the Excel export (required_inference) As the product, I should generate the Excel file on the backend and deliver it to the requesting author, so that the export reflects the stored report data and detail.

• Trigger/input: a confirmed export request from Export.
• Observable result: a generated Excel file is delivered as a download containing the selected daily sales report data and, when included, its sales detail.
• Access state: backend system process, initiated by the signed-in Sales Report Author.
• Failure/recovery: a failed generation reports the failure to Export, which preserves the selection and offers a retry.
• Continuation: the author exports another range or returns to Reports.

4. User Personas

Sales Report Author

Product context. The Sales Report Author is the person who keeps the ledger. In a small shop this is often the operator themselves, closing the day after the last customer, or opening the tool the next morning to record yesterday's takings. Their work happens at the boundary between the physical shop and the record: money counted, receipts photographed, items listed.

Primary goal. To end each day with a complete, exportable daily sales report — a date, a set of line items that add up to the day's total, and the photographed evidence attached to that same day.

Distinct accepted responsibilities.

• Recording a daily sales report for a given date (FR-01).
• Entering the report's detail as line items with item name, quantity, and unit price, and watching the day total update (FR-04).
• Attaching and storing images with the report, and reordering them (FR-02).
• Producing the Excel export of the recorded data and detail (FR-03).
• Browsing recorded days to find one to continue from (FR-07).

Relevant inputs and decisions. The report date; each line item's name, quantity, and unit price; which image files to attach and in what order; which day or day range to export and whether to include the sales detail.

Interactions with other accepted participants. The author's recorded report is what the Sales Report Viewer later opens. The author does not need the viewer's approval to save a day, but the report the author saves is the artifact the viewer reads, so the author's detail and images are the viewer's evidence.

Observable success. The saved day appears on Reports with its item count, its day total in tabular figures, and its image count badge; opening it on Report Details shows the same figures with the line items and captioned thumbnails; and Export delivers an Excel file for the selected day or range.

What makes this role different. The author is the only role that writes. Every field, line item, image, and export in the product exists because the author put it there. The viewer's entire experience is a read of the author's work.

Sales Report Viewer

Product context. The Sales Report Viewer is the person who checks the day rather than records it — a supervisor, a co-owner, or a colleague who needs to see what was taken and what backs it up. They arrive with a question about a specific day, not with data to enter.

Primary goal. To see a day's sales figures, its per-day detail, and its attached images, without altering any of them.

Distinct accepted responsibilities.

• Browsing recorded daily sales reports to find the day in question (FR-07).
• Opening a report and reading its detail as label/value pairs and ruled line-item rows (FR-05).
• Inspecting the images stored with that report (FR-06).

Relevant inputs and decisions. Which day to open; which report to move to next. The viewer makes no data-entry decisions and commits no changes to the record.

Interactions with other accepted participants. The viewer reads what the Sales Report Author recorded. The viewer's experience is entirely downstream of the author's save, and the viewer never edits, deletes, or exports the author's report.

Observable success. The viewer opens a day on Reports, sees the report date as a ruled section header, the day total as the largest number on the screen, the sales detail as ruled rows, and the stored images as captioned thumbnails — and leaves the record unchanged.

What makes this role different. The viewer's work is inspection under a read-only boundary. Where the author sees entry fields, a running total that counts up as items are added, and an unsaved-state dot, the viewer sees settled values and evidence. The same Report Details page serves both roles, but only the author's version of the product carries the recording and export continuations.

5. Core User Flows

Flow A — Sales Report Author records a day's sales report with detail and images

1. The author arrives at Landing and reads what the daily sales report website does: it holds a report per day, it stores images with the report, it carries detail, and it exports to Excel.
2. The author chooses to begin and moves to Sign Up.
3. On Sign Up, the author enters their name, email address, and password, and selects the Sales Report Author role.
4. The identity is created and the author lands on Reports, which is empty and states that no daily sales report has been recorded yet, with a continuation into New Report.
5. The author continues to New Report. The workspace opens with the report date pre-filled, an empty line-item table, an empty image strip, and a day total of zero.
6. The author adds a line item: item name, quantity, and unit price. The line appears as a ruled row with its line amount, and the running day total counts up to the new figure as the largest number on the screen.
7. The author repeats step 6 for the rest of the day's items. The day total keeps counting up with each addition.
8. The author attaches the day's photographed receipts. Each file appears as a bordered 4:3 evidence thumbnail with a small-caps filename caption in the ruled image strip, and the image count badge on the report reflects the addition.
9. The author drags the thumbnails into the order they want the evidence read in.
10. The author saves the report. The unsaved-state dot clears.
11. Observable result: the saved day appears on Reports as a ruled row with its date, item count, day total in tabular figures, and amber image count badge; the date rail shows the day's chip with its amber volume bar.
12. Continuation: the author opens the saved day on Report Details to confirm it, or returns to New Report to record another day.
13. Failure and recovery: if the save fails — a missing report date, an invalid quantity or price, an unsupported or oversized image, or an unreachable backend — an inline message names the field or file, the entered line items and successfully uploaded images are preserved, and the unsaved-state dot remains until a save succeeds.

Flow B — Sales Report Author exports a day's report to Excel

1. The author is signed in and on Reports, where the recorded days are listed.
2. The author continues to Export.
3. On Export, the author selects the day or day range to export and chooses whether to include the sales detail.
4. A ruled preview shows what the export will contain, in label/value pairs.
5. The author starts the export. The primary export control shows a determinate progress bar while the file is generated, and the pending-export state is marked in amber.
6. Observable result: the Excel file is generated on the backend and delivered as a download, and the page confirms which day or range was exported.
7. Continuation: the author exports another range, or returns to Reports or Report Details.
8. Failure and recovery: if generation fails or the backend is unreachable, an inline message appears with a retry control and the selection is preserved; the author retries with the same selection or adjusts it and exports again. If no reports have been recorded at all, Export states that there is nothing to export yet and offers a continuation to New Report.

Flow C — Sales Report Viewer reviews a day's figures, detail, and images

1. The viewer arrives at Landing and reads what the daily sales report website does.
2. The viewer moves to Sign Up and creates an identity with the Sales Report Viewer role, or moves to Login and verifies an existing identity.
3. The viewer lands on Reports, where the recorded days are listed as ruled rows with date, item count, day total in tabular figures, and amber image count badges. The date rail shows day chips, today's chip filled red, each chip carrying an amber volume bar.
4. The viewer selects the day they need, using the date rail or the list.
5. Observable result: Report Details opens with the report date as a full-width ruled section header, the day total as the largest number on the screen in tabular figures with a red left-edge bar, the sales detail as ruled label/value rows with small-caps column headers, and the stored images as bordered 4:3 thumbnails with small-caps filename captions.
6. The viewer reads the figures and the detail, and inspects the images. The viewer makes no edits; the record is unchanged.
7. Continuation: the viewer moves to another day, or returns to Reports.
8. Failure and recovery: if the report is missing or the fetch fails, an inline message appears with a retry control and a return to Reports; the viewer retries or selects another day. If a single image cannot be loaded, its thumbnail area states the failure and the rest of the strip stays readable.

Flow D — Returning participant verifies identity and resumes

1. A participant who already has an identity arrives at Landing and moves to Login.
2. On Login, the participant enters their email address and password and submits.
3. Observable result: the session is established and the participant lands on Reports with their role applied — the Sales Report Author sees the continuations into New Report and Export, the Sales Report Viewer sees the read-only browsing experience.
4. Continuation: the participant continues with the work their role owns.
5. Failure and recovery: unrecognised credentials or an unreachable backend produce an inline message that does not clear the entered email; the participant corrects the field and resubmits, or moves to Sign Up if no identity exists.

6. Visuals Colors and Theme

Muse and headline. Erik Spiekermann — typographic infrastructure for the daily sales ledger. The product is information made humane: many labelled values, dates, quantities, currency, and image attachments that must stay ordered without becoming cold. Wayfinding logic — numbered systems, signal colours used like transit lines, warm neutrals — replaces the default blue-on-white admin template.

Colour tokens

Contrast rules. Red on white is always at 16px or larger, or bold. Amber is never used as a text colour on the paper ground; it appears only as a fill with ink text on top.

Typography

• Headings: Fira Sans, 700, -0.01em tracking, sentence case for page titles; all-caps small labels at 600 with +0.08em tracking for column headers and field groups.
• Body: Fira Sans, 400 at 16px with 1.6 line-height. Nothing lighter than 400 anywhere.
• Numbers are the hero: daily totals set in Fira Sans 700 with tabular figures at display scale.
• Scale: 1.25 modular on a 16px base, mobile-first — 40/32/24/20/16/14/12 at 375px; 72/48/32/24/18/16/13 at 1280px.
• Display numerals: clamp(40px, 7vw, 72px) with font-variant-numeric: tabular-nums.
• Line items and table rows: 14–16px at every viewport.

Shape language

Squared and purposeful. 6px radii on inputs, buttons, and cards; 2px on badges and image thumbnails; 0px on table rows and section rules. 1px hairlines in #DCD6CA everywhere. 2px left-edge colour bars in red or amber mark the active row or the current day. No shadows except a single 0 1px 2px rgba(26,24,21,0.08) on floating menus. Iconography is drawn on a 2px stroke grid, geometric and diagrammatic, matching the type weight.

Layout

A 12-column grid with a persistent 72px left rail on desktop carrying numbered sections — 01 Hari Ini, 02 Laporan, 03 Gambar, 04 Ekspor — exactly like a transit line diagram. On mobile the rail collapses into a sticky top bar with the same numbers. Report pages are strict label/value pairs in a two-column table at 1280px, collapsing to stacked pairs at 375px. The date rail is a horizontal scrollable strip of day chips. Every page opens with a numbered section header and a full-width 1px rule, then content — a printed-ledger rhythm with generous 32–48px vertical margins, never a card wall.

Imagery

Photography is evidence, not decoration: photographed receipts, shelf shots, and product photos uploaded by the author, presented as 4:3 thumbnails with a 2px border and a filename caption in muted small caps. Supporting visuals are diagrammatic — a schematic of the day's sales split drawn as flat bars, a pictogram set for categories (makanan, minuman, lainnya) on a 2px stroke grid. No stock people, no 3D, no gradient art.

Avoid

Blue or indigo primary buttons on white; card grids with hover-lift shadows; gradient blobs, glass panels, or blurred backdrops; rounded pill buttons and 16px+ radii; playful illustration or cartoon characters; decorative entrance animations and parallax; icons drawn in a soft filled style that fights the 2px stroke grid; amber used as a text colour on the paper ground. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The working ledger as the public entry. The Landing page is not a marketing banner; it is a ledger page that happens to be the front door.

The composition is asymmetric and data-led. The left two-thirds carries an oversized headline — Laporan penjualan harian — set in Fira Sans 700 at clamp(40px, 7vw, 72px), stacked in three flush-left lines on the warm paper ground #F4F1EA, with a single sentence of body copy beneath at a maximum measure of 46 characters per line. Directly under it sits a real 1px-ruled table fragment showing three sample day rows — date, item count, total in tabular figures — with today's row marked by a 2px red #C8102E left bar and its total set at 32px. A small amber Ekspor Excel button is pinned beneath the table fragment, carrying the export promise in the accent's fill-only role.

The right third holds a stack of two photographed receipt thumbnails, slightly rotated at -2deg and 1.5deg, bleeding off the right viewport edge, each with a small-caps filename caption in muted #6E6A62. They are evidence, not ornament: the same 4:3 bordered thumbnails the author will see in a real report's image strip.

There is no centred headline, no subtext-plus-button-plus-blob composition. The dominant element is the numbered data itself. The page opens with a numbered section header and a full-width 1px rule, and the entry controls into Sign Up and Login sit as labelled, ruled continuations rather than floating calls to action.

The concept recomposes only accepted content and controls: the product's own explanation, its own sample day rows, its own image-evidence presentation, and its own entry controls. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject: the ruled table fragment of three sample day rows, with today's row marked by the 2px red left bar and its total set at 32px in tabular figures; the two rotated receipt thumbnails bleeding off the right edge are the secondary subject.
• Input → transformation → outcome thesis: the visitor's arrival is the input; the page presents the day's data as already ordered — date, item count, total — with the evidence beside it; the outcome is that the visitor understands this is a ledger tool and reaches Sign Up or Login. No accepted behavior is invented to animate this.
• Motion vocabulary: restrained and functional only — 120–180ms ease-out on state changes. The red left bar slides to the selected row, the running total counts up when a line item is added, image thumbnails fade in after upload, and the export button shows a determinate progress bar. No entrance animations, no parallax, no hover lift.
• Composed first frame: the headline stacked flush-left in three lines, the ruled table fragment beneath it with today's row already marked red, the amber Ekspor Excel button pinned below the fragment, and the two receipt thumbnails rotated and bleeding off the right edge — a complete, legible ledger page at rest.
• Reduced-motion state: prefers-reduced-motion removes the count-up and shows the final figure immediately; the red bar and thumbnails appear in their final positions with no transition. The first frame is unchanged and fully readable.

No user 3D or WebGL request was made, and the direction's hero dimensionality is flat, so no Canvas, R3F, or Drei scene is required.

9. Non-Functional Requirements

NFR-01 — Legibility at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit. No other element may cover any part of them. Imagery and decoration may be cropped, bled off an edge, rotated, or overlapped as the direction asks, provided they cover no readable text or control. Rationale: the product is read at 7am before the shop opens and at 11pm when the figures balance; a clipped total is a wrong total.

NFR-02 — Moving and scrollable content (explicit, from the creative direction) The date rail and any other horizontally scrollable row may cross the viewport or container edge by design. Every item must become fully readable as it passes. With prefers-reduced-motion, movement stops and whole items are shown, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling. Rationale: the date rail is a wayfinding device; a chip that can never be read is not wayfinding.

NFR-03 — Numeric legibility (explicit, from the creative direction) Daily totals use font-variant-numeric: tabular-nums at display scale. Line items and table rows stay at 14–16px at every viewport. Rationale: figures must align in columns the way a printed ledger's do.

NFR-04 — Colour contrast discipline (explicit, from the creative direction) Red on white is always at 16px or larger, or bold. Amber is never used as a text colour on the paper ground; it appears only as a fill with ink text on top. Rationale: the signal colours carry meaning — active line, day total, pending export — and lose that meaning if they become unreadable or decorative.

NFR-05 — Durable persistence (required_inference) Daily sales reports, their sales detail, and their attached images must survive beyond the session in which they were entered and remain bound to the participant who owns them. Rationale: the accepted journeys require a viewer to open a report the author recorded earlier, which is impossible without durable, participant-bound storage.

NFR-06 — Excel export fidelity (required_inference) The generated Excel file must contain the selected daily sales report data and, when the author includes it, the sales detail. Rationale: the user asked for export of the report with detail; an export that drops the detail does not satisfy the request.

NFR-07 — Image handling (required_inference) Attached images must be stored with the report they belong to and presented with their filename caption and their author-chosen display order. Unsupported or oversized files must be rejected with a message naming the file, without discarding the rest of the report. Rationale: image storage is an explicit requirement, and a partial upload failure must not cost the author the day's work.

NFR-08 — Role boundary integrity (required_inference) The Sales Report Viewer's access to Reports and Report Details must not permit editing, deleting, or exporting the author's report. Rationale: the viewer's accepted responsibility is to browse and inspect without editing.

NFR-09 — Failure transparency (required_inference) Every failed fetch, save, upload, or export must produce an inline message that names what failed, preserve the participant's entered or selected values, and offer a retry or a continuation. Rationale: the accepted journeys require material failure and recovery to be usable, not silent.

10. Tech Stack

No technology choices were specified by the user. The following are the minimum coherent defaults for the accepted delivery shape — a first-party custom web interface with durable backend storage and backend-generated Excel files.

• Frontend: React (web), built as a single-page application with the numbered left rail and the date rail as described in the creative direction. [Default — not specified by user]
• Backend: Python with FastAPI, owning identity, durable report/detail/image storage, and Excel file generation. [Default — not specified by user]
• Storage: a relational database for participants, daily sales reports, and sales detail line items, plus object storage for attached images. [Default — not specified by user]
• Excel generation: a Python spreadsheet library producing the export file on the backend. [Default — not specified by user]
• Containerisation: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any stated deployment constraint and is therefore not included. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions.

• A-01. The product is delivered as a website, per the user's wording. No native mobile application is assumed. (narrow, labeled)
• A-02. A daily sales report belongs to one date, and a date identifies the day being reported. (narrow, labeled)
• A-03. Sales detail line items carry at minimum an item name, a quantity, and a unit price, from which a line amount and the day total follow. (narrow, labeled)
• A-04. Attached images are files the author uploads; the product stores them and shows them with their filename. (narrow, labeled)
• A-05. The Excel export covers the daily sales report data and, when included, its sales detail. (narrow, labeled)
• A-06. Identity is application-owned, established by self-service enrollment, because no invitation, provisioning, provider, or pre-existing-account boundary was established by the source. (required_inference)
• A-07. Two roles exist — Sales Report Author and Sales Report Viewer — because the accepted journeys require recording and exporting to stay with the author while reviewing stays open to both. (required_inference)

Constraints.

• C-01. The product is a daily sales report website with image storage, Excel export, and detail. No adjacent capability — inventory, point-of-sale integration, accounting, payroll, multi-branch consolidation, CRM, payment processing, or forecasting — is in scope.
• C-02. New Report and Export are restricted to the Sales Report Author role. Reports and Report Details require a signed-in identity. Landing, Login, and Sign Up are anonymously reachable.
• C-03. The Sales Report Viewer's access to Reports and Report Details is read-only.
• C-04. The visual direction in sections 6–8 is binding: the palette, Fira Sans typography, squared shape language, numbered left rail, ruled ledger layout, restrained motion, and evidence-photography imagery are all required, and the generic indigo/blue-on-white SaaS template is forbidden.
• C-05. Readable text and controls stay whole at 375px, 768px, and 1280px, per NFR-01.
• C-06. No future-horizon requirements were stated by the user. Nothing in this document is deferred.

12. Glossary

• Daily sales report (laporan penjualan harian) — the record of one day of selling: its date, its sales detail, its attached images, and its day total.
• Sales detail (detail) — the line items that make up a daily sales report, each with an item name, quantity, unit price, and line amount.
• Day total — the sum of a daily sales report's line amounts, rendered as the largest number on the screen in tabular figures.
• Stored image (penyimpanan gambar) — an image file attached to a daily sales report, presented as a bordered 4:3 thumbnail with a small-caps filename caption and an author-chosen display order.
• Excel export (export excel) — the backend-generated spreadsheet file containing selected daily sales report data and, when included, its sales detail, delivered as a download.
• Sales Report Author — the accepted persona who records daily sales reports, enters their detail, attaches images, and produces the Excel export.
• Sales Report Viewer — the accepted persona who browses and inspects daily sales reports, their detail, and their images without editing them.
• Date rail — the horizontal scrollable strip of day chips at the top of Reports, with today's chip filled red and each chip carrying a tiny amber bar whose height encodes that day's sales volume.
• Numbered left rail — the persistent 72px desktop rail carrying numbered sections 01 Hari Ini, 02 Laporan, 03 Gambar, 04 Ekspor, modelled on a transit line diagram and collapsing into a sticky top bar on mobile.
• Unsaved-state dot — the red indicator on New Report showing that the current report has changes not yet saved.