Odoo Training Drafts

The company settings are already prepared. You will create the customer and opportunity yourself. Use your run code on both records. Select the customer company and the executing office team. Expected revenue is a forecast, not an invoice. Qualification includes a reason and a next action. Reopen the record to check that your changes were saved.

Keep the technical survey on the same opportunity so estimating and the later proposal share one commercial history. Use service survey for this pre-sales survey. C Squared Survey is a different standalone workflow. Do not add D-A-S Deployment yet. Record the technical result before preparing the deployment proposal.

The deployment proposal is separate from the survey quotation, but both belong to this opportunity. D-A-S Deployment creates the job after acceptance. The untaxed training proposal is eleven thousand. Check the executing warehouse. This is a fictional training proposal. We will preview it, not send it to a customer. Acceptance is the next exercise.

Check that this is the deployment quotation, not the survey. Confirm only after scope and acceptance are reviewed. Confirmation creates the sales order and triggers the configured project creation. Wait for the result instead of clicking repeatedly. Close the accepted opportunity as Won and hand the order and project references to the PM.

Open the existing job from its sales order. Do not create another project manually. The job contains eight template work packages. This build also creates one sales-line task, giving nine tasks in total. That extra task is not another project. One customer, one accepted deployment order, and one job folder are ready for operations. Record those references in your evidence log.

Kickoff starts from the job the sales order created. Open the existing Kickoff and requirements task instead of creating a new one. A good handoff note lets operations start without calling sales. Capture the scope, the site contact, the dates, the equipment, and one risk. The owner accepts the handoff before the task closes. Set the status, note the acceptance, and mark it done.

Planning turns the eight work packages into a dated schedule. Give the four key tasks an owner and a target date. The confirmed sales order is the commercial baseline for this job. Note that reference, then start the RF design task. Write down one risk against a milestone, then review the plan. If a milestone view is unavailable, task dates carry the plan.

The facilitator already set up a fictional technician. Open Planning and create a shift for that person. Use the approved time window and check the time zone and duration. This build has no project field on shifts, so name the shift for the job. Publishing is safe here because this is an isolated learning database. Reopen the shift to confirm what was saved.

The DAS job is not set up for field service, so create a single onsite visit in the Field Service project instead of a new job. The visit must carry the same customer and technician as the plan, and it names the job it belongs to. Record what was done onsite, mark the visit done, and then find it in the Field Service task list.

Time is entered against the job, not against a general bucket. Open the timesheet view and add a new line. Choose the existing project and the Installation task, describe the work, and enter two hours. Reopen the entry to confirm it saved. At fifty an hour, two hours is a labor cost of one hundred. That is cost, not customer billing.

Enter the fictional travel expense and attach its training receipt. Keep the amount and date aligned with the exercise evidence. Code the expense to the job using the approved allocation. Preserve required Location and BU values instead of guessing percentages. Submission, approval, posting, and reimbursement are different states. Stop at the state the facilitator authorized and inspect whether job cost is visible.

Separate the project demand from replenishment demand. Keep the two job units and one warehouse unit identifiable throughout purchasing. Use the draft RFQ as the purchasing record and include the sales-order reference where available. A text reference is not a relational link. Do not treat a draft RFQ as an approval lock. Document the facilitator's simulated authorization before any later confirmation.

Keep project and replenishment quantities on separate lines. At 200 each, the three units total 600 before tax. Route the order to New Hampshire and code only the project units to the job. An Origin note alone does not create analytic allocation or an SO-to-PO link. Check quantities, coding, destination, and authorization before confirmation. Stop if this build cannot represent the approved allocation.

Start from the PO receipt so the incoming stock remains traceable. Compare the expected lines and all three units with the packing list. Record what was actually received using the receipt workflow. Do not use an inventory adjustment to force the expected balance. Confirm only after the inspection agrees. If Odoo proposes a backorder, compare ordered and received quantities before deciding.

Inspect the product by location before delivery. Find the New Hampshire stock location and confirm the physical quantity. Reserved stock is still physically on hand. Compare the views and identify which quantity has been committed to an outgoing move. Before changing anything, trace the movements and verify the checkpoint. Never adjust stock just to make the expected answer appear.

Follow the delivery smart link from the deployment order. Verify the two-unit customer demand and its New Hampshire source. Use the warehouse steps enabled in this build. Resolve reservation or availability issues from the stock moves, not with an unrelated transfer. Validate only for the training shipment. Then confirm the completed delivery and the remaining New Hampshire stock.

Move only the replenishment unit. Use the facilitator-approved internal operation so the move stays distinct from the customer delivery. Follow every leg of the configured route. A dispatched unit in transit is not yet available at the destination. Verify the movement from its records and location balances. If the route or locations are missing, stop for configuration rather than substituting a delivery or adjustment.

Create the return from the original delivery so the reverse movement stays linked. Describe the defect as fictional training data. Use the approved return destination, which may be quarantine rather than NH/Stock. Do not create an inventory adjustment or an unrelated receipt. A stock return does not refund the customer. Keep replacement, repair, scrap, and credit as separate authorized decisions.

This alarm card is fictional. Do not open or change live SitePortal alarms; Odoo is not the RF monitoring engine. Explain why the simulated severity fits the evidence. Record findings and a dispatch decision without implying access to the production monitoring system. Pass a concise incident handoff to dispatch. This demonstrates the exercise process, not proficiency in the actual SitePortal interface.

Start from the simulated triage handoff. Create the ticket in the configured training team and keep its subject tied to the mock alarm. Use a validated project relation if one exists; otherwise state the project reference in the description. A mention provides traceability, not analytic cost coding. Use the stages this build actually provides. Record the escalation and resolution as simulated actions; do not claim an untested dispatch integration or SLA timer.

Agree the recurring-work design before creating records. Identify who owns each inspection and how completion will be evidenced. Use recurrence only when this build's behavior has been validated. If it is not configured, keep the exercise in the explicitly labeled tabletop path. A manually duplicated task does not prove recurrence. Do not infer that a maintenance module is installed from a proposed schedule.

Start from the sales order so the invoice relationship is preserved. Use the approved billing policy and inspect invoiceable quantities after the return. Do not assume the original order total remains invoiceable after a return. Check the actual lines and coding against the worksheet. Invoice creation does not post revenue or register payment. Only use a separately approved mock-payment branch with a training journal and no bank connection.

Start the bill from the PO to retain its source relationship. Use only the fictional invoice and facilitator-approved accounting values. Compare the three ordered, received, and billed units at 200 each. Keep the project's two units distinct from the replenishment unit. Escalate mismatches for review. Do not assume Odoo blocks every discrepancy, and do not post or pay without facilitator authorization.

Profitability is on the project dashboard in this version. Open the project's card menu and choose Dashboard. Review expected, invoice, and cost columns separately. Save the reconciliation in a project update. Separate draft, committed, and posted amounts. Keep the replenishment unit outside project cost, and do not double count the purchase commitment and draft vendor bill. Recorded remaining hours are a scheduling baseline, not an approved cost forecast. Request task-owner estimates for unplanned and overrun work, then obtain facilitator sign-off. Do not mark unfinished work complete or archive the project before approval.

This exercise belongs to the software delivery toolchain. Use only an approved training project and fictional issue data. Capture who owns the issue, which release it relates to, and what support needs to know. Keep the external reference intact. Customer service follow-up may belong in Helpdesk; engineering work and release history remain in the software team's system.