Dairyfy user manual

Version 0.1 - 2 November 2026

This guide explains the implemented web console and mobile field workflows. Your role determines which screens and actions appear. Screenshots with synthetic records are training examples, not real balances. Mobile native sign-in and offline recovery still need device acceptance before a mobile production rollout.

1. Before you begin

Use the web console at https://dairyfy.bytecraftre.com/. Have your dairy ID, login account and authenticator available. For Al-Barakah Dairy, the dairy ID is al-barakah-dairy. A dairy ID selects the workspace; it is not a password and does not grant access.

Your administrator must provision your identity and membership. Changing a displayed role in a demonstration is not available in real mode. Never share passwords, OTP codes or authenticator enrollment keys with colleagues or support staff.

2. First sign-in and account setup

1. Open your authorized account setup email. Setup links expire; ask your administrator for a new link if needed.

2. Complete email verification, choose your password, and enroll an authenticator as requested by the identity service.

3. Return to the console. Enter the dairy ID and continue to the identity sign-in page.

4. Enter your account credentials and the current authenticator code.

5. Check the displayed dairy and role before entering records.

Do not enter real data into a screen marked Demonstration or Synthetic. If the dairy or role is wrong, stop and contact the administrator. If your account has no membership, successfully entering a password will still not open the workspace.

3. Navigation and common actions

The console groups work into operations, finance, people and additional administration/reporting areas. Select a module to review its records. Open a record to inspect detail and available follow-up actions. Search and report filters narrow displayed results; they do not change records.

For a new record: choose the named action, fill the displayed required fields, select Review, check the summary, then Confirm and record. Correct input before confirmation. Keep a record's identity/reference when reporting a problem. A disabled or absent action usually reflects role permissions or a missing prerequisite.

English and Urdu presentation are supported in existing workspace interfaces. Some authentication and new support content remain English. Switching language does not change a record's identity, unit or amount.

4. Roles and responsibilities

Owner

Set dairy settings, create or rename money accounts, manage existing memberships, configure pricing, and review authorized financial/operational records. Owners may approve payment requests and manage settlement cycles. Owners now have full operational and financial action access, including collections, deliveries, payments, allocations, returns and credit. Pricing, stock, reference and audit safeguards still apply; full access does not bypass validation. An empty real dairy has no starter prices, parties, opening balances or transactions.

Recommended setup sequence: confirm settings; create money accounts; arrange staff identity bindings; register parties; configure executable prices and terms; enter explicitly reviewed opening balances; configure orders and operational plans. Delegate daily tasks to appropriately limited staff where helpful. Membership editing alone does not create a new identity-provider user or identity binding.

Manager

Register parties, create standing/ad-hoc orders, manage demand changes, configure pricing, record collections/deliveries, blend milk, allocate supply, procure emergency milk, record surplus/loss, manage stock/livestock and enter audited corrections. Managers can approve payment requests, but a cashier executes them. Managers cannot issue a field return or post cashier return credit.

Collection staff

Capture milk collections and review the collection queue. Select the source/farmer, milk type, quantity/unit, quality readings and shift. Record the policy outcome using the displayed workflow. Confirm the capture once and review its sync status. Local capture is not proof that the server accepted a payable.

Delivery staff

Review planned deliveries and allocated quantity, record actual fulfilment, and capture returns against an eligible delivery. Planned, allocated and actually delivered quantities are distinct. A return capture alone does not issue a refund or credit; a cashier performs the financial treatment.

Cashier

Record receipts/payments using the correct money account, allocate amounts to obligations, issue/apply/refund return credits, execute approved payment requests, create receipts, manage terms/advances and settlement cycles within permission. Verify party, direction, account, amount and allocation before confirmation. Sending a receipt and posting a payment are separate operations.

Farmer, customer and supplier

Participant records are restricted to the linked party. Farmers/suppliers can create and cancel eligible payment requests, but cannot approve or execute them. Customer access is limited to authorized own-party views. Do not assume a public self-registration portal exists; real access requires provisioned membership and identity binding.

See the role/action reference for the complete implemented action list and field labels.

5. Parties, orders and demand

Owner quick start: Parties -> Add party (farmer/customer); Pricing -> Schedule price (procurement/selling); Collections -> Record collection; Customer orders -> Create standing order; Supply allocation -> Allocate supply when needed; Deliveries -> Record delivery; Payments -> Record payment. Accepted collections/deliveries generate milk movements automatically. Do not create duplicate movement entries. Collection means milk received from a farmer; payment means money received from a customer.

Web date fields use calendar controls and retain canonical YYYY-MM-DD values. Dairy settings include contact person, phone, contact email, address, registration reference and notification channel preference. Channel selection alone does not activate provider delivery.

1. Register the party with the appropriate farmer/customer/supplier roles. One party may have multiple business roles.

2. A manager creates a standing order for a customer, with its displayed quantity, milk type, unit and effective dates.

3. Record skips, pauses, resumes, extras or permanent demand changes through the demand workflow. Check acceptance/status before expecting the delivery plan to change.

4. For one-off demand, use the ad-hoc workflow and its accept/reject/reschedule actions.

5. Review the relevant delivery date and planned quantity before allocating or capturing delivery.

A party record is business master data; it does not create a login account.

6. Pricing and quality

Configure prices before financial posting that requires them. Flat/quantity and animal-type pricing can execute with valid configuration. Fat-based and rate-table quality methods may be represented as configuration but cannot post amounts while the calculation contract is unresolved. A quality reading is not authorization to invent a formula. SNF conversion is not supplied by this release.

If the application reports configuration required, ask the owner/manager to review the effective price, milk type, side and unit. Do not substitute an approximate rate to bypass the error. Check whether a new price is intended for future activity rather than changing historical records.

7. Collections and milk operations

For collection, select farmer or own-farm source, enter required quality/quantity details, then choose the recorded policy outcome. Review the source, unit and outcome before confirmation. Accepted domain processing can create the associated operational and financial effects; a rejected server command creates no partial committed financial transaction.

Managers review availability and movement records, create blends, allocate available supply, and record emergency procurement, losses or surplus disposition as applicable. Use consistent milk types and units. Record reasons where required. Availability is a derived position; avoid treating a dashboard number as an editable stock field.

8. Delivery and returns

Open the delivery list, confirm customer/date and review planned versus allocated quantity. Record actual quantity delivered. A locally captured delivery must synchronize before a dependent return can be posted to the server. Returns refer to the delivered record; the queue preserves this ordering.

Delivery staff record the returned quantity and reason. The cashier then reviews the authorized credit treatment: issue credit, apply retained credit to an obligation, or refund from the correct account. Verify that the original delivery and party match. Never record a second payment solely because the first response was delayed.

9. Payments, allocation and requests

A payment records money movement. Allocation identifies which payable/receivable it settles. A payment can retain an unallocated remainder. Check that the party and direction match the intended obligations; do not assume a payment automatically clears every balance.

Cashier procedure: review outstanding items; record the correct incoming/outgoing payment and money account; inspect oldest-due allocation suggestions where offered; confirm deliberate overrides; review the remaining payment and obligation balances. Preserve payment references for reconciliation.

For payment requests: a permitted user creates the request, an owner/manager approves or rejects it, and a cashier executes an approved request. Approval alone is not payment. Cancellation and expiry are separate states. Record receipts after reviewing the payment; delivery/send status does not determine whether the payment exists.

10. Settlements, advances and opening balances

A settlement cycle groups eligible activity for a party and period. Review activity, deductions, advance recovery and source-recovery effects before closing. Closed snapshots preserve the settled calculation; reconciliation detail distinguishes settlement position from subsequent payment allocation.

An advance's original issued amount differs from its remaining recovery. Check the advance position before creating further recovery-related activity. Opening balances are carry-in positions and are excluded from ordinary activity. Enter them once, using reviewed references and the correct account/party context.

11. Supporting records, reports and corrections

Purchases, stock receipts/consumption, expenses and livestock are bounded supporting workflows. For stock, a signed quantity distinguishes receipt from consumption; check unit and reason. Cash/immediate and credit expense paths have different consequences.

Reports derive from authorized records. Check date filters, dairy, role and units before sharing. Participant reports remain party-scoped. Profitability and other reports with unresolved inputs should not be treated as approved accounting output.

Use an authorized correction action with a reason rather than trying to overwrite posted history. Inspect the corrected target and resulting effective balance. Auditing preserves original and correction information; never remove a record to conceal a mistake.

12. Mobile and offline work

Install the administrator-provided Android preview APK only after its build is available. This repository currently has a real-mode preview profile, but a JavaScript export is not an installable APK. Initial login requires network access. Native storage requires the SQLCipher-enabled build, not an assumption that Expo Go provides the same environment.

The field app retains captures locally per dairy/account in encrypted native storage. Cached field context can support bounded offline capture after a valid prior session. The current saved session has an eight-hour maximum. Management writes require the service; do not assume every screen is offline-capable.

Queue meanings:

- Pending: captured locally and awaiting a sync attempt.

- Syncing: an attempt is in progress; do not create another copy.

- Synced: a server receipt has been recorded for that operation.

- Failed-retryable: review the error and retry when its cause is resolved.

A rejected capture remains available for review; a rejected business command is not made valid by repeated retries. On authentication failure, sign in again using the same account. Saved captures remain associated with that account. Do not uninstall, clear application data or discard a device with pending captures. Signing out clears active display/access, while encrypted pending captures are retained for that account. Foreground sync exists; continuous OS background sync is not guaranteed.

13. Troubleshooting

Wrong dairy or unavailable membership: check the dairy ID and contact the administrator; do not create another account as a workaround.

Expired setup link: request a fresh authorized setup email. Never forward an enrollment link to someone else.

OTP rejected: check device time and use a fresh code. Lost authenticator access requires administrator-assisted recovery; self-service recovery has not been accepted for release.

Configuration required: record the exact message and ask the owner/manager to resolve prerequisites. Unsupported fat/SNF execution remains blocked deliberately.

Saved locally but not synchronized: check connectivity, session and queue error. Keep the original operation on the device. Retry eligible items; do not re-enter the same transaction.

Sign-out revocation unverified: local display/access has been cleared, but provider revocation could not be confirmed. Avoid using shared devices until the administrator checks the session.

Notification or receipt not delivered: distinguish a committed payment from the delivery attempt. Production notification transport remains outstanding; do not treat a visible event as proof of recipient delivery.

14. End-of-shift checklist

Review the active dairy/account; inspect pending and failed captures; verify expected server receipts; reconcile delivery/return exceptions; hand financial questions to the cashier; report unresolved discrepancies using record IDs and timestamps; sign out on shared devices. Do not include passwords, OTPs or enrollment keys in screenshots sent to support.

15. Support information to collect

Provide dairy ID, role, screen/action, record or operation ID, approximate time and timezone, device/app version, connectivity state, exact error and a redacted screenshot. State whether the item was captured locally, synchronized, or rejected. Administrators should preserve audit evidence and investigate before requesting a duplicate entry.