FRONK OIL — BOOKWORKS CONNECTOR DEMONSTRATION
Prepared for the website proposal, October 13, 2026

VERIFIED SCOPE AND COMPANY-REPORTED SETUP
Fronk reports BookWorks Accounting, version 4.5.152.0. This identifies the
installation; it does not verify API access, licensed Warehouse & Lubes or
MobileConnect functions, or compatibility with the proposed connector.
Fronk reports Bitrix24 storefront and websites, Basey's for current online
customer-account payments, and Tiger Payment Solutions for in-store payments.
Those existing arrangements do not prove a new storefront payment integration.
Paid BookWorks support is OFF LIMITS. Review Fronk's existing internal module,
configuration and integration records first; do not contact paid support.

All BookWorks-side operations below are local concept simulations. Public API
marketing and sample endpoints do not establish support in this installation.
Bitrix24's documented features also require Fronk's actual account mode,
permissions and configuration to be checked before implementation.

DEMONSTRATE THE LIVE WORKFLOW
1. Open /implementation/bookworks/ from Presentation Notes. Open Shop in a
   second tab on the SAME site origin and browser. The staff screen stays out
   of the customer-facing menu and checkout.
2. Select products, open the cart, use sample checkout details, review, and
   Place demo order. A fictional customer order appears automatically in the
   staff feed, including mixed source-code and grade-only selections.
   Open order qty increases immediately. Reservation simulation is OFF by default. To explore it, start
   a separate 10-case example, select Assume reservations for this example,
   then Simulate transfer. This does not verify BookWorks reservation support.
3. Select an order in the staff feed. Enter a quantity and choose Simulate
   shipment, or choose Simulate remaining shipment for that line. On-hand
   decreases only by the filled quantity;
   simulated reservations decrease by that quantity when the assumption is on.
   Shipping does not create an invoice or receivable in this demonstration.
4. The complete inventory table and checkout confirmation update immediately.
   Automatic sync is on by default. Turn it off to demonstrate queued return
   updates, then acknowledge them with Sync preview.
5. Create sample invoice preview for newly filled items. Preview the customer
   document and local email draft, then Print / Save as PDF or download HTML.
   The customer checkout confirmation shows its link after synchronization.
   Later shipments receive a separate invoice for only the new quantities.
   Simulate payment record to show status changes; no stock or real money moves.
6. To demonstrate interrupted acknowledgement, start the 10-case example,
   choose Simulate interruption, and Simulate transfer. Retry simulation acknowledges
   the existing order instead of creating another order or stock reservation.
7. Replay an event, cancel an unfilled remainder, and test a second order for
   the same item. The local model illustrates its own stock checks. Production
   needs a confirmed authoritative, concurrent-stock check: native Bitrix24
   reservations can exceed available stock and do not guarantee no overselling.
8. Clear demo data restores all opening balances and clears orders, leaving
   the shop cart unchanged. Only submitted carts are cleared by checkout.

INVENTORY AND PROPOSED ADAPTER FIELDS
All 429 source package records are visible, preserving material codes as text.
39 grade-only pending-package records support demonstration of unresolved
selections. They have no invented manufacturer code or confirmed package size.
All 429 source codes and 39 grade-only choices are orderable in the local
demo, with automatic fictional item mappings. Reviewed source records keep
their live approval flags; no supplier code, grade or package is approved by
this demo. Older saved inventory adds missing catalog records and recovers
checkout orders held only for mapping without clearing existing records.

Proposed columns: demo BookWorks item ID, source material code, description,
grade, package notation/readable label, provisional unit, warehouse, open order
quantity, on-hand,
reserved, available, review status. These are a BookWorks-style demonstration
layout, NOT the vendor's verified API schema or production import format.
All opening stock is 100 FICTIONAL units per record; quantities count selected
packages, not converted gallons. Prices remain unknown. Warehouse and item IDs
are fictional. The CSV export carries these same limitations and is for review.
Additional 10-case example fixtures are separate from the source inventory.

The demonstration keeps order and inventory state in browser localStorage,
shared by tabs of the same origin. It does not synchronize different devices,
browsers or domains. Contact/address inputs are not stored or transferred;
staff/customer-link examples always use fictional customer information.
The browser ledger has a 200-order demonstration limit and is resettable.
No production API, email, payment, stock movement or accounting record is sent.
This is a working UI/state demonstration, not a hosted production connector.

PROPOSED PRODUCTION ARCHITECTURE — CONFIRM BEFORE IMPLEMENTATION
Host a separate secured background service. Keep credentials server-side.
Use an authenticated event receiver, durable inbox/outbox, retry worker,
business-action ledger, shared references, origin/version markers and periodic
reconciliation. A native store remains the website foundation; the staff demo
is presentation material and is not deployed as a public ERP console.

Confirm Fronk's Bitrix order mode and available REST scopes. New accounts use
CRM Deals; the legacy Deals + Orders mode continues for existing users. Fronk's
mode is unknown. Do not assume sale.* methods match a CRM Deal. Any proposed
sale.shipment.* write path needs verified mode and an actual underlying order.
The crm.item.delivery.* API is read-only and cannot write shipment updates.
Subscribe to the applicable record events, then fetch the complete record.
A saved payment/shipment is not proof of settled funds or completed delivery.
Bitrix online events are not automatically resent after a handler failure;
connector retries and reconciliation must recover missing/uncertain work.
Evaluate supported offline events subject to account permissions and plan.

When authorized, obtain the actual Fronk API contract: authentication,
schemas, limits, error semantics, sandbox, lookup by external reference,
order/line updates, item/customer/location matching, stock reservations, partial
deliveries, cancellation, returns/credits and invoice/payment application.
Advertised sample fuel endpoints do not establish packaged-lubricant support.
Approve the catalog-to-BookWorks item, package/unit, location and customer
crosswalk; do not treat the fictional IDs in this demo as that approval.

Choose the inventory and billing owners from Fronk's supported operations.
BookWorks' advertised fuel-delivery example can post stock and receivables;
that is not evidence that Fronk's Accounting module or packaged-oil shipping
does so. This demo never assumes that shipping creates an AR entry. Establish
the exact inventory and AR transaction triggers before implementing either.
Mirror acknowledged status without a second stock or receivable movement.
Verify native Bitrix inventory behavior does not duplicate the chosen owner's
movement. Bitrix payment-record writes update records; they do not charge a
card. Payment capture, refunds and accounting application need separate,
verified provider operations. BookWorks' public CardPointe/MobileConnect
offering does not verify Fronk's modules or Basey's/Tiger compatibility.

After a timeout, look up the shared external reference before retrying a write
that may already have committed. This requires a verified BookWorks lookup
and uniqueness/idempotency contract; a connector action ledger alone cannot
guarantee no duplicate remote writes. Use stable shipment/payment/action IDs,
not the webhook handler ID, and test lost acknowledgements and concurrent
writes. Cancelling after partial fill
releases only unfilled reservations; delivered stock/billing require an
explicit approved return or credit transaction.

ACCEPTANCE CHECKS
Confirm multiple concurrent orders for one item; package/unit conversions;
insufficient stock; missing/ambiguous mapping; partial fill/backorder; repeat
shipment and payment events; lost acknowledgement after commit; stale/out-of-
order events; reservation release/expiry; cancellation races; returns/credits;
native Bitrix stock behavior; invoice/AR ownership; reconciliation and alerts.
Approve this workflow against Fronk's actual environment before live launch.

PRIMARY REFERENCES
https://apidocs.bitrix24.com/api-reference/sale/events/index.html
https://apidocs.bitrix24.com/api-reference/events/index.html
https://www.keyinfotech.com/services/custom-software

INVOICE DELIVERY PREVIEW
The invoice uses fictional $100/package amounts solely for demonstration.
It is generated by this browser-local prototype, not retrieved from BookWorks
or produced by an integrated Bitrix24 invoice service.
Actual catalog prices remain unknown; tax/freight are not calculated and no
payment is due. Integer-cent calculations avoid rounding drift. Copies retain
the demo notice; generated, synchronized and emailed are separate milestones.
The current email button only previews a message to customer@example.com.
No mail is sent, no delivered status is fabricated, and no customer PII is read
from checkout. A staff preview can inspect an unsynchronized invoice; normal
customer links use only acknowledged customer documents.

The production invoice layout/numbering, billing date/terms, rates, taxes,
freight, partial billing, credits and payment application require approval.
Bitrix24 supports native invoice documents and email with the required account
configuration and connected mailbox. This does not establish invoice transfer,
BookWorks PDF retrieval, or customer delivery through Fronk's integration.
Use the confirmed billing owner and supported document operations. If the
verified transaction already creates AR, do not create a second AR entry.
Deliver approved PDFs or protected links through the authenticated customer
portal and configured transactional email, with actual delivery monitoring and
retry handling. The public demo route is not that secure production service.

Additional official references for the verified limits
https://helpdesk.bitrix24.com/open/13727858/
https://helpdesk.bitrix24.com/open/18642276/
https://apidocs.bitrix24.com/api-reference/crm/universal/delivery/index.html
https://apidocs.bitrix24.com/api-reference/sale/shipment/index.html
https://apidocs.bitrix24.com/api-reference/crm/document-generator/documents/crm-document-generator-document-add.html
https://helpdesk.bitrix24.com/open/25904635/
https://apidocs.bitrix24.com/api-reference/crm/universal/payment/index.html
https://www.keyinfotech.com/solutions/warehouse-lubes
https://www.keyinfotech.com/solutions/mobileconnect
