Event Operations

Event operations are used by staff who record and manage business activities. The available actions depend on the selected event type, event status, and user permissions.

Open Events -> Operations -> Events.

Service workflows may open this same shared event workspace with agriculture, production, asset, inspection, or billing context already narrowed. That does not create a second event ledger; it only helps the user start in the correct business context.

Workspace Reference

Area	What The User Does
Main table	Reviews event number, type, domain, party, start time, duration, status, approval status, and charge state where available.
Schedule Event	Opens the event form. Service-specific screens may rename this action.
View Detail	Opens event detail, child lines, documents, inspections, charges, observations, resources, and activity context.
Start	Moves a scheduled event into progress where the event type and status allow it.
Complete	Marks the activity completed after required data, documents, charges, or inspections are ready.
Cancel	Stops an event that should no longer continue.
Related workspace links	Opens Event Types, Document Types, Pricing, Workflow, Billing, or Resources setup where configuration needs review.

Creating An Event

Click Schedule Event. Users select the event type and then complete the details required by that type. Typical event details include date, service, business unit, location, party, responsible user, description, and supporting information.

If the event type is billable, additional charge-related fields may appear. If the event type supports inspections or documents, the event can also become the starting point for those related records.

The standard event form includes:

Field	Required	Meaning
Event Type	Yes	Reusable activity contract. It controls whether the event can carry items, resources, observations, charges, documents, inspections, or other behavior.
Start Time	Yes	When the activity starts.
Duration (mins)	No	Expected or actual duration where known.
Primary Party	No	Main customer, member, supplier, farmer, student, driver, patient, or other party involved.
Secondary Party	No	Another party involved in the activity where needed.
Location	No	Operational place where the event happens.
Notes	No	Free-form operational context.
Business Unit	Usually derived	Operating unit responsible for the event.

If the event type you need is missing, ask an administrator to review Events -> Setup -> Event Types. Do not use a loosely related event type just to bypass setup.

Managing Event Details

Users can maintain operational context such as:

• Parties involved in the activity.
• Locations, dates, and responsible teams.
• Notes and attachments.
• Related documents.
• Related inspections.
• Charges or operational quantities, where configured.

Events should be updated while the activity is still operationally current. After completion or approval, edits may be restricted.

If the business flow is agriculture-specific, keep the split clear:

• use the event for the activity header and operational context
• use linked document transactions for structured source evidence when required
• use linked inspections for grading, QC, or checklist truth
• use linked payments, stock, billing, reports, or GL only through the owning primitives

Items

Use event item lines when the event consumes, produces, receives, dispatches, or references stock or operational items.

For example, an agriculture field activity may reference inputs used, or a harvest/loading event may reference operational quantities. The authoritative stock consequence should still be reviewed in Inventory if the configured workflow creates one.

Important item fields:

Field	Meaning
Stock item	Item being consumed, produced, received, dispatched, or referenced.
Direction	Whether the line consumes, produces, receives, dispatches, or references the item.
Quantity and UOM	Operational quantity and unit.
Unit cost	Cost value where the event captures cost information.
Warehouse	Location affected by the item activity.
Lot or batch number	Tracking reference where item policy requires it.
Notes	Explanation of the item activity.

Confirm the item is execution-ready, active, approved, and linked to the shared operational item catalog before using it on an event.

Resources

Use event resource lines when the event needs capacity such as staff, machines, vehicles, rooms, equipment, or service slots.

Important resource fields:

Field	Meaning
Operational resource	Person, vehicle, machine, room, workstation, or other resource used by the event.
Capacity slot	Scheduled availability slot where capacity planning is used.
Role	What the resource does for the event.
Capacity quantity	Amount of capacity being used.
Booked from and booked to	Time window for the booking.
Notes	Special instruction or exception.

If a resource is unavailable for the selected time, adjust the booking window or choose another resource rather than overriding the conflict without review.

Charges

Use event charges for billable activity.

Users can add charges manually where allowed or generate charges from the event type and pricing setup.

Important charge fields:

Field	Meaning
Pricing line	Charge definition selected from pricing setup.
Description	User-facing explanation of the charge.
Quantity	Charged quantity.
Unit price	Price per unit.
Tax	Tax amount or treatment where applicable.
Discount	Reduction applied to the charge.
Approval or charge status	Whether the charge is ready for finance follow-up.

Before submitting charges to finance:

• confirm the event type is billable;
• confirm charges are approved or ready for approval;
• confirm no pending child-line approval is blocking posting;
• confirm the charge posting rule is configured;
• check whether charges have already been linked to a finance draft or workflow.

Charges can be waived or removed where permissions allow. Waiving a charge should be used only when the organization intentionally gives up billing that line.

Observations

Use observations for structured readings or findings that do not belong in a full inspection record.

Observation fields:

Field	Meaning
Observation type	Kind of observation being captured.
Observation code	Structured code where setup uses one.
Value	Reading, finding, or observed value.
Unit	Measurement unit where the value is numeric.
Reference low and reference high	Expected range where applicable.
Abnormal flag	Marks a value outside the expected range or needing follow-up.
Notes	Explanation of the observation.

Use inspections instead of observations when the activity needs a reusable checklist, pass/fail logic, scoring, evidence attachments, or formal review.

Approval And Completion

Some event types require approval before they can be completed or used downstream. Approval helps separate data capture from review, especially where events affect billing, inventory, or accounting.

Typical flow:

1. Create the event as a draft.
2. Add details, documents, charges, or inspection links.
3. Submit for review where approval is required.
4. Approve or return for correction.
5. Complete or cancel the event.

Document Transactions

Document transactions provide a structured document trail for events. Operators can use them to capture formal records connected to an event, such as service records, delivery confirmations, attendance sheets, field activity reports, internal checklists, or other domain-specific documents.

Document transaction rows normally show document number, type, domain, date, counterparty, total, status, and approval. Common actions include view detail, edit, submit, approve, and cancel, depending on status and permission.

Inspections

If an event requires inspection evidence, create or link the relevant inspection record from the event or inspections workspace.

Use inspection results to decide whether to accept the activity, return it for correction, trigger rework, adjust price, block stock acceptance, hold settlement readiness, or escalate an exception.

Good Operating Practice

Use events as the single activity record for the business occurrence. Avoid creating separate disconnected notes in multiple modules when one event can hold the activity context and link to the relevant documents, inspections, charges, or downstream transactions.

Do not expect the event itself to replace the downstream record of truth. If the activity leads to a document, inspection, stock movement, payment obligation, billing charge, or reportable outcome, that follow-up record should still be reviewed in its owning primitive.