SAP Business One RPA via the accessibility tree, not the Screen Scraper Wizard.

No. SAP GUI Scripting is a COM API exposed by the SAP GUI for Windows frontend (saplogon.exe) and is gated by the sapgui/user_scripting profile parameter on the application server. That entire surface is specific to ECC and S/4HANA classic GUI. The SAP Business One client is a separate Win32/.NET application, and there is no equivalent scripting API. Any RPA tutorial that begins with 'enable scripting' is talking about ECC, not B1. The UiPath community-blog tutorial for B1 explicitly notes the lack of a dedicated connector and points readers at the Screen Scraper Wizard, Click Text, and Send Hotkey activities instead.

Run inspect.exe (ships with the Windows SDK) against a live B1 session and you will see the form rendered as a tree of UIA elements. Most editable fields are ControlType.Edit with a Name property pulled from the B1 form definition (Customer, Posting Date, Item No., Quantity, Total LC, etc.). Buttons are ControlType.Button. The line items grid is ControlType.Table where each cell exposes ValuePattern. Tabs, comboboxes, and the matrix all populate Name and AutomationId for most controls. The reason this works is that the B1 client uses standard Windows controls under the hood, and Windows publishes the accessibility tree for those controls automatically. Mediar reads from that tree the same way a screen reader would.

The Screen Scraper Wizard plus Click Text plus Send Hotkey path resolves controls by visible pixel content (OCR), by visible text label search, or by a fixed sequence of key presses. All three break in predictable ways. OCR breaks when the user changes DPI or the theme changes. Click Text breaks when a form translation flips Customer to Cliente, or when an add-on relabels a field. Hotkey sequences break the moment any popup steals focus. Reading the UIA tree resolves elements by AutomationId first, then Name plus role, then position relative to a parent window, then visible label as a fallback. Three of those four strategies survive a label rename, a theme change, or a DPI shift. The fourth is essentially the Click Text approach, used only as a last resort.

The DI API is the cleanest answer when you have it. It is COM-based, single-threaded, and requires the SAP Business One client install on every machine that runs the integration. For a steady-state batch process that posts a few hundred documents an hour, that is fine. For a workflow that spans multiple desktops, that includes a non-B1 step (open a PDF, validate against an Excel file, then post into B1, then write the result into a Slack channel), or that has to be auditable as a UI-level recording, accessibility-API automation is more honest. The Service Layer is the modern HTTP API but it is only available on the HANA edition of B1. Customers running B1 on Microsoft SQL Server (still the majority of mid-market deployments) cannot use it. That leaves the front-end as the universal surface.

Yes, in almost every case we have shipped. B1 add-ons hook the SAPbouiCOM event model and render their own forms into the same UI host process. Because UIA reads the host's window tree, custom screens added by Boyum, Beas, and Produmex Food show up as additional ControlType nodes with their own Name and AutomationId values. We have automated F&B chain workflows that cross between native B1 forms and Beas production work orders inside one workflow file, and the line item entry inside a Beas screen looks identical to UIA as the line item entry inside a native A/R Invoice. The runtime does not need to know whether a node is core B1 or an add-on.

Open inspect.exe (it ships with the Windows SDK at C:\Program Files (x86)\Windows Kits\10\bin\10.0.x.x\x64\inspect.exe), set the mode to Tree View or Hover Mode, launch SAP Business One, and walk through the form you want to automate. Hover the Customer field on an A/R Invoice. You should see ControlType: Edit, Name: Customer (or the B1 translation of it), and a populated AutomationId on most builds since B1 9.3. Hover the Add Row button. You should see ControlType: Button, IsKeyboardFocusable: true, and a real BoundingRectangle. If the elements you care about are populated, you can drive them with any UIA-based runtime. If a specific element shows as Unknown ControlType (it happens on some matrix cells in older B1 versions), the runtime falls back to the parent grid plus row/column index.

The number we publish is from an LG-customer F&B chain that moved off UiPath onto Mediar for their B1 workflows. The CFO told the board they are saving 70 percent on costs. The arithmetic is straightforward: Mediar bills $0.75 per minute of runtime against the workflow, with no per-seat licensing, no Studio licenses, no Orchestrator. The $10K turn-key program fee converts to credits with a bonus, so it is effectively prepaid usage. UiPath at the equivalent volume runs unattended-bot licensing plus Orchestrator plus Studio plus implementation services, and the comparable annual cost is several multiples of the runtime number.

The execution layer is. The Terminator SDK that performs the UIA calls and the locator resolution lives at github.com/mediar-ai/terminator under MIT. It exposes the MCP tools (type_into_element, click_element, set_value, get_text) the workflow file references. You can drive a SAP Business One window with Terminator alone, no Mediar cloud, no orchestration, just the UIA primitives. The recording pipeline, the cloud orchestrator, and the no-code workflow builder at app.mediar.ai/web are commercial. Teams that want to wire B1 directly into their own queue or message bus can build on Terminator without paying for the SaaS layer.

Most of the time, yes, because UIA properties are stable across B1 patches more often than pixel positions are. The cases where the workflow has to be re-recorded are usually when SAP renames a field across a major version (B1 9.3 to 10.0 reflowed the line item grid, for example), or when a B1 add-on inserts a new screen step in the middle of a recorded path. The runtime emits structured failures with the parent window title and the unresolved step id, so a human can open the recording app on the failing step and capture the new branch. Silent retry is disabled by default for B1 workflows because posting half an A/R Invoice is worse than not posting it.

The other SAP pages on this site cover SAP GUI for Windows (the ECC and S/4HANA classic frontend), where automation can lean on the SAP GUI Scripting COM API as a fast path. SAP Business One does not have that fast path. The runtime tools are the same (Mediar drives both through UIA), but the trade-offs are different: ECC has at least one official scripting interface, B1 does not. That is why the B1 deployment story leans harder on the accessibility tree, and why most B1 RPA projects fail when they try to copy the ECC playbook.