- Complete application name, company identity, logo/favicon, address, Asia/Jakarta timezone, currency, tax, and document identity.
- Create roles and permissions around job responsibilities. Enable 2FA and define whether it is optional or mandatory by policy.
- Prepare companies, divisions, positions, accounts, NPWP/NITKU, customers, vendors/suppliers, services, shifts, and required RFID devices.
- Configure SMTP, sender/reply-to, email templates, PDF, payment providers, and workers/cron before go-live.
Start from the work goal, not by guessing a menu.
Each guide shows roles, flow, key steps, and the expected output. If the output does not exist yet, do not force the next stage.
- Ensure customers are not duplicated and the PIC has contact details usable for transactional email.
- Record important requirements and activities so subsequent quotations/projects use the same context.
- Use active services from master data so source changes remain controlled and stale records are not selected.
- Create quotations from the correct customer and service records. The system keeps quotation numbers unique when documents are edited.
- Choose Full Payment, Deposit, or installments. Percentages and amounts must derive from the transaction grand total.
- After quotation approval, create the invoice from the same source so items, tax, discounts, and company identity remain consistent.
- Payment confirmation may only update status after amount, reference, scope, and method are validated.
- Start projects from valid transactions so project codes and Tracking IDs are created from the correct record.
- Assign the correct team members; tasks and work reports should originate from project details so team names do not fall back to a default user.
- Publish only progress and photos intended for the customer. Overall progress must never exceed 100%.
- At completion, issue BAST/final results and keep the Tracking ID active so history remains viewable without login.
- Complete division, position, account, RFID, shift pattern, base salary, and employee user status.
- Use non-shift, 2-shift, 3-shift, or custom presets including schedules that cross midnight.
- RFID and web input must write to the same attendance source; auto checkout is marked as an automatic source.
- Leave, sick leave, time off, overtime, and reimbursements follow request → review → approve/reject before becoming payroll components.
- Choose a period and make sure relevant attendance/leave/overtime records are final.
- Review earnings and deductions before finalization. Avoid source changes after payroll is marked final.
- When paid, financial movement follows the selected account and the PDF payslip is stored as an official document.
- Verify NPWP/NITKU, VAT status, tax office, PIC, signatory, and certificate before recording tax transactions.
- Record VAT/withholding registers, invoices, e-Bupot, returns, billing codes, periods, statuses, and supporting documents.
- One Gate System prepares internal controls; official filing remains through DJP Coretax by authorized parties.
- Every movement must point to the correct source transaction and company account.
- Cash In must not exceed the source transaction value. Cash Out follows payroll, vendors, reimbursements, debt, or valid general expenses.
- Use reconciliation to compare transaction status, provider settlement, and balances formed from the ledger.
- Vendor master contains legal identity, tax, accounts, terms, categories, and supporting documents.
- PO rules define amount limits, minimum comparisons, contracts, budget checks, receiving, and approval requirements.
- Finance pays after PO, receiving, and vendor invoice match or discrepancies have been resolved.
- Invoices, quotations, BAST, POs, payroll, progress reports, and confirmations use consistent transaction templates.
- Official PDFs are stored as physical files and archive metadata before the email worker sends the same attachment.
- If generation fails, emails requiring attachments must not be considered successful; failures are logged and can be retried.
- company_id=0 is reserved for Agent/YTech billing. Tenant gateways must use credentials and settlement accounts belonging to the relevant tenant company.
- Midtrans and Duitku use hosted checkout/provider flows. Visa/Mastercard must use tokenization/hosted checkout; the system does not store full PAN, CVV, PIN, or OTP.
- Direct Bank/Debit requires a bank/acquirer API contract, HTTPS endpoint, signing/API key, callback secret, channel, and settlement account.
- Paid status is accepted only after signature, amount, external reference, scope, destination account, and idempotency are validated server-side.
- Choose the process and sector workflow to control, then define step order and role/user approvers.
- Add amount thresholds, conditions, SLAs, delegation, and revision paths when required.
- Test with non-Super Admin users to ensure they can approve within authority but cannot alter workflow definitions.
- Public accounts are not activated immediately. Identity and requirement data must be reviewed first.
- Approval determines tenant, role, entitlement, and access status. Rejection stores a reason suitable for communication.
- Confirmation email follows the review result so users know the next step without exposing internal details.
- Use monitoring to trace who, when, IP/device, page, and transaction involved.
- Email center displays queue status, retries, attachments, and failure reasons without exposing secrets.
- Reviewer/Tester can inspect data according to policy but cannot alter restricted settings.
- Describe the goal in normal language; Yura handles shorthand, mixed wording, and light typos without forcing you to rewrite the question.
- For plan/workflow/implementation recommendations, Yura performs a short 1–3 question discovery before the final recommendation. Factual questions such as prices are answered directly.
- For errors, Yura guides checks through data/status → roles/permissions → dependencies → PDF/email/payment → logs → support.
- Use user count, required modules, finance/payroll/procurement/payment, workflows, API/audit, storage, and deployment as selection criteria.
- Recommendations do not automatically push the highest plan. A 30-day trial can be used to test real entitlements before activation when available.
- Custom modules/workflows, dedicated integrations, custom limits, or special deployments are directed to Custom after discovery.
Payment setup starts with scope and settlement.
V17 isolates central YTech billing from tenant gateways. Every provider follows fail-closed behavior: incomplete configuration shows Maintenance—not Whoops and not a partially active checkout.
YTech company_id=0 or the correct tenant. No cross-tenant credential fallback.
Select an active account in the same scope before enabling the provider.
Secrets are encrypted and are not displayed again after saving.
The server validates signature, amount, reference, destination, scope, and idempotency.
Midtrans
- Environment: Sandbox → Production
- Settlement account required
- Client Key + Server Key
- Channels enabled by merchant
- Webhook:
/api/payment/webhook/midtrans
Duitku
- Merchant Code
- API Key + Project/Client Key
- Settlement account required
- Payment methods checked from merchant project
- Webhook:
/api/payment/webhook/duitku
Direct Bank / Debit
- API Base URL HTTPS
- Checkout Path + Status Path
- Signing/API Key + Callback Secret
- Bank/Acquirer Code + Channel
- Webhook:
/api/payment/webhook/direct_bank
This is the correct state when destination account, credentials, channels, endpoints, or callbacks are incomplete. Complete configuration and run the readiness test; do not substitute global credentials that do not belong to that scope.
Operational tutorials you can follow directly.
These tutorials combine menu order, validation, and expected results so processes do not stop halfway.
First Go-Live Checklist
Recommended order so operators do not start transactions before the foundation is ready.
- Sign in as Super Admin and complete application/company identity.
- Create roles/permissions and enable the 2FA policy.
- Complete accounts, customers, vendors, services, shifts, employees, and tax data.
- Test SMTP + PDF with an internal dummy transaction.
- Test quotation → invoice → payment → project → BAST and one approval workflow.
- Back up the database and record verified production configuration.
Configure Payment Gateways Through Production Readiness
Use the Payment Control Center. Do not start from checkout; start from scope, settlement, credentials, channels, then callbacks.
- Choose scope: YTech Global/Agent Billing (company_id=0) or a specific tenant company.
- Choose Midtrans Snap, Duitku POP, or Direct Bank/Debit.
- Set Sandbox/Testing first and select an active settlement account in the same scope.
- Enter Merchant Code/ID when required, then save Client/Project Key, Server/API/Signing Key, and Callback Secret in encrypted credential fields.
- For Direct Bank, enter HTTPS API Base URL, Checkout Path, Status Path, Bank/Acquirer Code, channel, and maintenance message.
- Enable only available channels, run Check/Test, then perform an end-to-end sandbox transaction.
- Point provider callbacks to /api/payment/webhook/{provider}; paid status must be proven by callback/server status, never by the browser return URL.
- Only after successful UAT switch to Production and repeat readiness checks. If configuration is incomplete, keep Maintenance mode active.
Configure SMTP, PDFs & Email Automation
Email is considered ready only when official attachments exist and retries are traceable.
- Enter host, port, encryption, username/password, no-reply sender, and reply-to in application settings.
- Save templates for registration, approval/rejection, quotation, invoice, payment, project progress, password reset, and payroll.
- Generate a transaction PDF and confirm it opens before testing email.
- Send a test email, check Email Center/queue, attachment verification, sent status, and failure reason.
- Enable worker/cron and test retry with one intentional failure in the testing environment.
Build a Safe Approval Workflow
Start from the business trigger and output, not from the number of steps.
- Choose the process requiring control: quotation, PO, payroll, reimbursement, or a connected custom process.
- Define trigger, approvers, amount thresholds, conditions, SLAs, delegation, and reject/revision paths.
- Ensure approver roles can make decisions but cannot alter workflow definitions.
- Test approve, reject, timeout/SLA, and audit trail before making the workflow the sector default.
When a process fails, check the safest source of the problem first.
Do not immediately alter the database or credentials. Use data/status → access → dependency → log → recovery validation order.
01Documentation does not open
Open /documentation/status. If status is OK but the page fails, check PHP/opcache cache and deployed view/CSS files. V19.0.0 documentation has a fail-safe view so generic Whoops should not appear.
02Service dropdown still shows old data
Ensure the correct active service record is used, no stale option cache remains, and the form loads current master data. Hard reload and verify the source ID stored on quotation/invoice.
03Editing a quotation rejects a unique number
During edit, unique validation must ignore the quotation currently being edited. Do not create a new number unless reissue is explicitly requested.
04SMTP fails / email is not sent
Check host/port/encryption, credentials, sender domain, writable queue, worker/cron, and Email Center. For emails requiring PDFs, confirm the PDF is stored before the queue runs.
05PDF is not attached
Check generated document/archive, writable folder permissions, and generator view. The system should rebuild from the source transaction if the official archive is unavailable.
06Payment shows Maintenance
This is safe behavior. Complete scope, settlement, credentials, channels, HTTPS endpoint/callback when required, then run the readiness test. Do not bypass fail-closed behavior with credentials from another scope.
07Callback arrives but invoice is not paid
Check external ID/order ID, amount, provider, company scope, destination account, signature/callback token, and idempotency. The browser return URL is not proof of payment.
08RFID does not submit attendance
Check device online status, device endpoint/API key when used, network connectivity, RFID-to-employee mapping, Asia/Jakarta server time, and last request log. Restart the device only after mapping is verified.
09Animations stop on some Windows/browsers
Hard refresh, make sure public-experience-v16.js loads, and check browser/OS reduced-motion settings. V19 uses visibility/pageshow recovery so animations can restart when the tab becomes active again.
Do not know the module name? Describe the outcome you want.
Yura understands formal and informal input, shorthand, and light typos. For plan or workflow recommendations, Yura first runs a short Q&A so it does not immediately push an oversized solution.
Questions that commonly come up before go-live.
Does ID/EN only change the navbar?
No. V19.0.0 uses the same public language across navigation, pages, footer, dynamic chart/demo content, and Yura. Switching language reloads the page with the lang parameter so the entire surface stays consistent.
Does Yura immediately recommend a plan?
Not for decision-oriented requests. Yura first runs a short Q&A about user count, required modules, integrations, workflows, payment/audit, and deployment. Factual pricing questions are still answered directly.
What is the difference between Agent/YTech Payment and Tenant Payment?
Agent/YTech Payment uses central company_id=0 scope for subscription/license billing to tenants. Tenant Payment receives the tenant company’s business transaction payments using that tenant’s own credentials and settlement.
Does One Gate System store card data?
No. Visa/Mastercard is routed through provider/acquirer hosted checkout/tokenization. PIN, OTP, CVV, and raw card data are not stored by the application.
Does documentation require login?
No. Documentation Center is public and includes a fail-safe so core guidance remains accessible even if optional dependencies are degraded.