How could a visitor picture their own work in a company-specific ERP? On 20 October 2026, adding staff and owner views to the homepage turned that question into a detailed public experience.
I connected layout, wording, fictional calculations, partial delivery and cancellation, record review and recovery in one explanation. This is my account of the decisions and code behind that experience, using no actual company information.
Different questions inside the same company
After adding company-specific ERP to the homepage, I was asked to show both the screen used by staff and the overview used by an owner. Sales, purchases and outstanding receivables were then added to the brief. I started with the different questions people ask of the same records.
Staff need to know which order to handle and which document to prepare. An owner needs to know what has been traded, what remains unpaid and who should check the next issue. I placed items, quantities, suppliers and the next task on the staff side, and amounts, status and follow-up priorities on the owner side.
This article concerns the public experience built to explain those questions. It is a new synthetic example, not a copy of a company’s operational ERP or a report on actual transactions. The earlier ERP field notes discuss decisions in the original business workflow; here I record the design and behavior of the public demonstration.
An overview first, a separate place to explore
On the homepage I placed the staff and owner views side by side, with a vertical sequence on narrow screens. Changing quantities and suppliers, then preparing example requests, updates the order status on the owner side. A short action explains how one entry can support the next task.
Expanding transaction details, partial delivery, role-specific menus and record review on the homepage would lengthen the reading path for a first-time visitor. I gave the detailed experience a separate page, with direct routes into the owner overview, connected work, configuration and existing-record review.
Korean and English share the same experience structure and calculations. A language change should not alter a quantity or the meaning of a balance. I designed the location of the information and the order of the interactions together, so the reader can choose how deeply to explore.
From an amount to its entries and next action
The owner view begins with a synthetic monthly example: ₩48,000,000 in sales, ₩31,200,000 in purchases, ₩12,600,000 in receivables and ₩8,400,000 in payables. Collections total ₩35,400,000 and payments total ₩22,800,000. After reading an amount, the owner should be able to continue to the issue needing a check.
The receivables detail contains ₩7,200,000 for sample customer A and ₩5,400,000 for B. A’s transaction is ₩24,000,000, with collection entries of ₩10,000,000 and ₩6,800,000. The card and the remaining balances come from the same ledger. Manually maintaining separate figures for the overview and its detail would create opportunities for them to drift apart during edits.
The follow-up list adds a team member, due date and next action. All receivables and overdue receivables remain distinct. The synthetic reference date is 15 April 2030; it does not represent an actual company’s current position. The example concerns transactions in that month and omits opening balances, taxes, payroll and other costs. It does not present sales minus purchases as net profit.
Explore the implementation
An excerpt from the current public experience model. The shared file below includes the supporting functions.
export function ledgerRows(key){
if(!['sales','purchases','receivables','payables'].includes(key))throw Error('Unknown example ledger');
const ledger=syntheticLedger(),source=['sales','receivables'].includes(key)?ledger.sales:ledger.purchases;
return source.map(row=>({...row,settled:row.receipts.reduce((n,v)=>n+v,0),balance:row.amount-row.receipts.reduce((n,v)=>n+v,0)})).filter(row=>!['receivables','payables'].includes(key)||row.balance>0);
}Build the public records separately
I created sample customers, items, dates and amounts for the public experience. The original company’s ledger was not an input. Changing names alone can leave a business identifiable through transaction patterns or document structure, so I constructed the relationships needed for this explanation separately.
Synthetic records still need rules. Collections plus receivables must equal a transaction amount, and the sum of its outstanding entries must match the card. Supplier payments and the remaining payable need the same consistency. I established these relationships before putting the figures on screen.
The monthly financial example and the staff workflow demonstration are independent. Preparing a request on the staff side changes the order status. It does not increase the monthly sales figure. The page explains the scope of each demonstration.
Change state, then read the calculation from it
The workflow starts with a small state: quantity, stage and situation. It moves through quote, order, request preparation, delivery check and collection check, while keeping a prepared document distinct from an actual send. Advancing the example does not save a document to an operational system or execute a transaction.
A calculation function reads that state and the interface displays its result. Changing a quantity or situation resets the stage. Keeping a completed label after editing a quantity that had already been checked for delivery would create a misleading expectation. I wanted the model to include which checks must be repeated after an edit.
If a quantity is temporarily empty or outside the permitted range, the example retains the input and blocks progression. It accepts whole quantities from 1 to 20. Its fictional unit price and delivery-based amount are explanatory rules, not a company’s quantity limits or an implementation of accounting recognition requirements.
Explore the implementation
An excerpt from the current public experience model. The shared file below includes the supporting functions.
export function editJourney(s,key,value){
if(key==='quantity'&&typeof value==='string')return {...s,quantity:value,phase:0};
if(key==='scenario'&&scenarios.includes(value))return {...s,scenario:value,phase:0};
throw Error('Unsupported synthetic edit');
}Let the reader change partial delivery and cancellation
A normal completion path leaves unfinished work unexplained. I made the same order available as normal progress, partial delivery with partial collection, a one-unit return, or cancellation. The chosen situation changes the calculation.
At a fictional unit price of ₩100,000 and a quantity of six, the quote is ₩600,000. In the partial-delivery situation, advancing to delivery shows three units delivered and a delivery-based amount of ₩300,000. At collection, ₩150,000 has been received and ₩150,000 remains outstanding. The three units still awaiting delivery are visible separately.
With six units and a one-unit return, the delivery-based quantity becomes five and the amount becomes ₩500,000. Cancellation stops at the order stage, preventing further request preparation or collection progression. Even a small example should show remaining units, returned units and collected amounts together so the reader can compare it with their own work.
Make company fit visible in menus and fields
I wanted the phrase company-specific to have a visible meaning. Choosing staff, coordinator or owner changes the items left in the view. Staff focus on today’s orders and items, coordinators on requests and due dates, and owners on financial summaries and next checks.
Due dates, site notes, stock checks and approval status can be added as needed. Customer-led, site-led and project-led contexts illustrate different ways to group the same work. The configuration can grow as further questions arise.
Role selection here reconfigures a public synthetic view. It does not demonstrate that a production authorization server has blocked costs or personal information. A real implementation needs authentication and data-access rules, with separate checks for hiding a field and refusing its retrieval through an API.
Put review into the existing-records story
A new system raises questions about existing spreadsheets and documents. I included four predefined synthetic rows: a repeated record ID, a missing quantity and rows ready for review. Mapping the wrong column to quantity leaves no ready candidates.
This is not an Excel importer reading an actual file. It is a model of the review needed before migration. The page states that no file is uploaded and no records are saved after review. I did not want one completion label to promise both review and migration.
Another example starts with orders and an overview, then adds stock checks or approval when needed. Selecting a module changes the described sequence. A real scope depends on existing records, workflow and access rules; checking a box does not install a function in a production system.
Leave a model that can be inspected and continued
In the final implementation I separated the synthetic ledger, workflow state, validation and calculations into a model, with the interface displaying its results. The same calculation supports Korean, English, initial HTML and later interactions. It also gives wording changes and calculation changes a clear place to live.
The workflow can back up its state in page memory and restore that point. Back up a stage, reset the workflow and restore it: quantity, situation and stage return together. A JSON download contains only the synthetic workflow state.
Restore checks the format marker, synthetic-data marker, permitted fields and value boundaries. The memory backup disappears on refresh. Its scope differs from durable service storage or restoring company files. The shared model exposes the calculations and state transitions for inspection.
Keep the action consistent with the button’s promise
An enquiry begins with a problem: repeated input, visibility of receivables and upcoming payments, or connecting staff work with owner reporting. The choice prepares a draft for the visitor to review and send through their own email app. The experience does not collect company records and send them externally.
During public-response checks, the email presentation differed from the reviewed HTML. The existing email-protection layer had transformed the address and link. I kept that protection, compared the intended destination and draft contents, and explicitly regenerated the draft link at initialization. Those checks did not verify email receipt.
Analytics distinguishes experience interactions, movement into field notes and email-writing intent. It counts predefined function labels instead of quantities or draft contents. Opening an email app is not counted as an enquiry received. The instrumentation prepares a way to review explanations; it does not establish improved understanding or enquiry outcomes.
Record what I actually checked
I compared 400 model combinations: quantities from 1 to 20, four situations and five workflow stages. Checks covered collections plus receivables matching the delivery-based amount, nonnegative quantities and amounts after a return, and stopped progression after cancellation. Event wiring was checked separately using minimal DOM adapters.
Public checks covered bilingual content, static assets, experience links and routes into field notes. I compared earlier content for unintended changes, backed up content, media and source, and performed a local restore check. Local synthetic fixtures also checked analytics ingestion and event order.
This work did not include interaction testing in a live browser or on a physical device. Responsive rules and checks of markup, calculations and event wiring are different from operating a phone with its keyboard visible. I keep that distinction in the record because correct figures and usability both deserve evidence.
Give the reader a starting point for their own questions
I do not expect every company to want the same configuration after seeing this page. I wanted a starting point for comparing it with their own work. Seeing the relationship from an owner’s numbers to the next staff task, and from existing records to a new configuration, makes the next questions easier to discuss.
If you build your own version, start with one question the owner asks daily and one task staff repeat. Use a small synthetic example to check whether the same records connect them, whether the overview reconciles with its details and whether unfinished work remains visible after partial completion. Additional menus can be considered after those relationships are clear.
I want the decisions and calculations to remain open in enough detail to be useful. Readers can adapt the reasoning themselves, and a tailored implementation can begin with a conversation about what is currently difficult. This experience is a page I can continue refining to make those questions easier to ask.