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