FM/QUERY PORTFOLIO

Type help for commands or search nine case studies.

← Work index / Kimia Farma x Rakamin Academy

Project-Based Internship Retail healthcare

Retail Sales Datamart and Dashboard

Designed a sales datamart and dashboard workflow to turn transaction, customer, and product data into clearer commercial reporting.

Kimia Farma sales dashboard showing invoice, sales, product and customer reporting
Organization
Kimia Farma x Rakamin Academy
Role
Big Data Analytics project participant
Timeline
Project-based internship
Stack
SQL · Excel · Looker Studio
My role

My contribution.

Work I directly owned or delivered within the broader team effort.

  1. 01

    Defined a composite sales key and documented base and aggregate table structures.

  2. 02

    Cleaned and analyzed sales data to make product, customer, and invoice performance comparable.

  3. 03

    Produced dashboard-ready outputs for recurring sales reporting.

Analysis frame

Assumptions / constraints

  • The sales source has no single unique column.
  • Reporting requires consistent integration of transaction, customer, and product data.
  • Location and weather enrichment should be used only when analytical purpose and data quality are established.

Technical judgment

Decision log

  1. 01
    Define a composite key from invoice and item identifiers.Why

    No individual sales-table column uniquely identified each sales item.

  2. 02
    Set the base table grain at sales-item level.Why

    Consistent reporting depended on explicit grain and predictable joins.

  3. 03
    Create aggregates by date, customer, and invoice for dashboard views.Why

    Commercial reporting required performance views at multiple useful levels.

Domain referenceMetric dictionaryView definitions +
Datamart
Structured reporting dataset integrating sales-related source data.
Composite key
Combined invoice and item identifiers used to uniquely identify a sales item.
Grain
Level represented by each table row; here, one sales item.
Aggregate
Summarized data grouped by dimensions such as date, customer, or invoice.

Snapshot

This project-based internship designed a reporting workflow across sales, customer, and product data, from a composite transaction key to aggregate views and dashboards.

The situation

Commercial reporting needed consistent integration of transaction, customer, and product data.

The problem

The sales table did not contain one unique column, so reporting grain and joins required deliberate design.

My responsibility

I designed the sales-item data model, aggregates, performance views, and reporting output for the project.

Approach

  • Defined a composite key from invoice and item identifiers.
  • Designed a base table at sales-item granularity.
  • Designed aggregates by date, customer, and invoice.
  • Proposed location and weather enrichment for demand analysis.

Solution

The datamart established a consistent sales grain and fed dashboard views intended to make commercial reporting clearer.

Outcome

The deliverable included table designs, performance views, and dashboard outputs. A supplied claim of 20% reporting-efficiency improvement is not published because its measurement method is undocumented.

What I learned

Reliable dashboards begin with grain, keys, and join behavior. Enrichment should be added only when its analytical purpose and data quality are clear.

Outcome Validated evidence

What changed.

Published outcomes stay within what can be supported by project evidence.

Defined a composite sales key

Designed base and aggregate table structures

Produced sales performance dashboard outputs

Contact Continue the conversation

Want to discuss how this system was built?