Why do this at all
APEXREST is a plugin for Claude Code and Codex that lets an agent work with Oracle APEX as code: write the application in APEXlang, check it with Oracle’s real compiler and import it into a development environment. It works well on small examples. I wanted to test it on something that looks like a real accounting system.
In Ukraine, for many companies that system is 1C (BAS). “What do we replace it with?” comes up every day, and the answer usually runs into the cost and time of moving the business logic. So the test task picked itself: can an agent with the plugin build, in reasonable time, the skeleton of a trade configuration on Oracle APEX — with catalogs, documents, posting, registers and reports?
What I used
- Oracle APEX 26.2 on Oracle AI Database 26ai Free — locally, in Docker.
- Claude Code with the APEXREST plugin — the agent that writes the code.
- Linear — the task manager: function catalog and statuses.
- The standard 1C 8.3 “Trade Management” configuration — as the reference for functions, terminology and the familiar “Taxi” interface.
My part was a few hours: describe what is needed, answer the agent’s questions, look at the result and say “next”. The agent wrote the pages, tables, packages and tests.
What came out
The application is called Trade. It deliberately looks familiar: a section panel on the left, open forms in tabs, yellow command buttons, document lists with posting icons. The interface is in Ukrainian, as it would be for its users.
Catalogs
Products are a hierarchical catalog: a group tree on the left, a list on the right. The product card holds the SKU, unit of measure, VAT rate, customs classification code, weight and dimensions, characteristics, and batches with expiry dates. Counterparties come with their company registration code, IBAN (with checksum validation) and contracts.


Sales and purchasing
A customer order reserves stock. A sale is created from it: the price comes from the price type, discounts are calculated automatically, and the system will not let you sell more than is in the warehouse. On the purchasing side there are supplier orders, goods receipts and payments. Documents are posted and move registers; unposting reverts everything. There is create-from, copying and printed forms.




Warehouse
Balances, turnover and movements for every product, transfers, write-offs, stock counts with surplus posting, reservations and free stock, cost by moving average. For warehouses with an order-based scheme there are receipt and issue orders and storage bins.


Finance, VAT and retail
Cash desks and bank accounts, cash receipt and disbursement orders, bank statements, settlements, reconciliation statements. VAT in documents and tax invoices under the first-event rule. Exchange rates are loaded from the National Bank of Ukraine. For retail there is a cashier workplace with a scanner, and receipts.




Reports
ABC sales analysis with a Pareto chart, receivables aging, inventory turnover, slow-moving stock with markdown recommendations, product card, gross profit.




Integrations and service
Order exchange with retail chains over EDI (ORDERS, ORDRSP, DESADV, INVOIC, RECADV), catalog import from CSV and XLSX, a user activity event log, access roles.


By the numbers
Plus 64 object passports (requirement descriptions) and about 270 tasks in Linear, of which roughly 70 are closed.
How it was built
1. Passport first, code second
For every catalog, document and register the agent first writes a passport: structure, form behaviour, business logic and the 1C counterpart. It is plain Markdown in the repository — you can read and correct it before a single line of code exists.
# Passport: “Goods sale” document
- 1C:Trade Management counterpart: Document.РеализацияТоваровУслуг
## BLOCK C. BUSINESS LOGIC
- An empty line price is filled on the server from the price type at the document date
- Posting: RegStockBalance −quantity; RegCounterpartySettlement +totalAmount
- Negative stock balance is not allowed
2. Tasks live in Linear
The function catalog of the standard configuration is broken into tasks by stage: operational accounting, money, extensions, integrations. The agent picks a task, does it and closes it. I see progress the same way I would see a team’s work.
3. An APEX application is text
APEXlang describes pages, regions, buttons and processes as ordinary files. The agent does not click around the builder — it edits code, and the changes are visible in git.
page 110 (
name: Реалізація товарів
alias: GOODS-SALES
security { authorizationScheme: @role-sales }
region list (
type: interactiveReport
source { type: sqlQuery ... }
)
)
4. What APEXREST does here
- Reference and recipes. Oracle definitions and compiler-checked component examples are available to the agent offline — it does not have to invent syntax.
- Local preview. Pages render right on the laptop with the real APEX theme. It is a tool for quickly checking the look, not a substitute for verification in Oracle.
- Oracle compiler. APEXlang is checked by the real compiler before import, so errors are caught earlier.
- Import into DEV/TEST only. With an exact plan, a backup and a check of the result. The plugin does not deploy to production — that is always a human decision.

5. Server-side logic and automated tests
Document posting, registers, cost and VAT live in PL/SQL packages. Every revision is closed by a test scenario; if even one check fails, the task is not closed.
OK Invoice total 2,500×12.34 + 10.00: 40.85 (expected 40.85)
OK Accounts payable: 40.85 (expected 40.85)
OK Movements after unposting: 0 (expected 0)
OK VAT rates 20 / 7 / 0 / exempt / no VAT: 5 (expected 5)
Honest limitations
- About 70 of roughly 270 tasks are closed: CRM, delivery, planning, budgeting and most integrations are still in the backlog.
- The fiscal cash register (PRRO) runs in simulation mode, EDI uses file exchange and a stub provider; nothing is sent to the tax authority or external services.
- Documents and settlements are kept in hryvnia; there is no general ledger and no payroll.
- The application has only run on demo data in a local development environment. Load, security and real data migration have not been tested.
- Code written by the agent needs human review before any real use — just like code from any developer.
Conclusion
You cannot replace 1C in one evening — and I am not claiming that. But the main cost driver in such projects — moving hundreds of forms, documents and rules — becomes noticeably cheaper and faster with an agent and the right tools. Oracle APEX provides ready-made lists, forms, permissions and reports; APEXlang turns the application into code; APEXREST gives the agent a reference, a compiler and safe import. The human keeps the most important part: deciding what the business actually needs, and checking the result.
Try APEXREST on your own project
The plugin is open source (Apache-2.0) and works with Claude Code and Codex.
claude plugin marketplace add apexrest-dev/apexrest
claude plugin install apexrest@apexrest
APEXREST on GitHub ↗ · Documentation ↗ · Questions on LinkedIn ↗
