A purpose-built SAP Business One data extraction tool with three extraction paths (Service Layer REST, DI API, direct HANA/SQL Server). Parallel, restartable, audit-evidenced. Output to Parquet, CSV, JSON, Avro, or Oracle FBDI ZIPs.
Hand-coded SQL and Service Layer scripts can move B1 data — but only the first time, only if nothing breaks, and only if no one ever asks for the audit trail.
Every SAP Business One customer eventually needs to extract data at scale: for a Fusion migration, for a data warehouse load, for a compliance archive, for a BI dashboard, for an M&A integration. The first instinct is to write SQL against the HANA or SQL Server backend, or to script Service Layer REST calls. That approach gets you 60% of the way there in week one — and then runs into the operational reality of B1: 600+ delivered tables, customer-specific UDFs and UDOs that aren't in the schema documentation, Service Layer session timeouts, paging quirks, rate limits, and patches that change column types and break downstream consumers.
A real SAP Business One data extraction tool handles this. Syntra ETL's extractor reads the B1 catalog dynamically (so UDFs and UDOs are picked up automatically), picks the right extraction path per table (Service Layer for low-volume master data, direct SQL for high-volume OJDT/JDT1/OINM), parallelises by year/period/branch, restarts cleanly on failure, throttles to avoid impact on live users, and emits every extract with row counts, hash signatures, and a signed audit manifest.
The same tool serves the one-time migration extract, the ongoing data warehouse feed, the nightly archive pull, and the compliance retention staging — without having to maintain three different code bases for three different use cases.
Every B1 module, every delivered table, every customer-specific UDF and UDO.
OCRD (customers + vendors + leads), OCPR (contacts), CRD1 (addresses), CRD2 (groups), CRD3 (extensions), OCRG (BP groups), OPYM (payment methods). Full CardType-aware extraction with split-ready output.
OITM (item master), OITB (item groups), OITW (item-warehouse), OINM (inventory postings), OBTN (batch numbers), OSRN (serial numbers), ITT1 (BOM components), OPLN (price lists). Full costing-method context preserved.
OJDT (journal entry headers), JDT1 (journal entry lines), OACT (chart of accounts), OBPL (branches), OFPR (financial periods), OADM (company config), OACG (account segmentation). Multi-currency, multi-branch fully supported.
OINV/INV1 (AR invoices), ORIN/RIN1 (AR credit memos), ORCT/RCT1-4 (incoming payments), OPCH/PCH1 (AP invoices), ORPC/RPC1 (AP credit memos), OVPM/VPM1-4 (outgoing payments). Full payment-matching context preserved.
ORDR/RDR1 (sales orders), OQUT/QUT1 (sales quotations), ODLN/DLN1 (deliveries), OPOR/POR1 (purchase orders), OPDN/PDN1 (goods receipt PO), ORDN/RDN1 (returns). Full document-chain extraction.
CUFD (UDF metadata + auto-included UDF_xxxx columns on every base table), OUDO (UDO metadata + child UDO data tables), SBO-COMMON catalog. Every customer-specific extension included automatically — no manual schema work.
Whether you're doing a one-shot migration extract or standing up an ongoing data feed, the workflow is the same.
Configure connection (Service Layer endpoint + B1 user, or HANA/SQL Server JDBC string + DB user). Tool crawls SBO-COMMON, CUFD, OUDO, OACT to discover full installed schema including UDFs/UDOs and customer-specific extensions.
Select tables, fiscal years, branches, and companies in scope. Pick output format (Parquet, CSV, JSON, Avro, Oracle FBDI). Configure extraction path per table (Service Layer, DI API, or direct DB). Set parallelism and throttling. Schedule (one-shot, nightly, hourly, sub-hourly).
Parallel extractors pull configured tables. Direct-DB path used for OJDT/JDT1/OINM/OINV history; Service Layer used for OCRD/OITM/OACT master data. Each table chunked by year/period/branch, checkpointed for restart, throttled to keep B1 impact minimal.
Per-table row counts, sum totals (debit, credit, qty, amount where applicable), and SHA-256 row hashes computed. Manifest written alongside data files. Schema drift versus prior runs flagged. Variance reports surfaced if numbers don't match prior extracts.
Output delivered to configured target: cloud object storage (S3, GCS, Azure Blob, OCI Object Storage), data warehouse (Snowflake, BigQuery, Redshift, Databricks), Fusion FBDI staging area, or Syntra archive store. Signed manifest accompanies the payload.
The same tool covers the full B1 extraction workload — not a different product for each use case.
The extract path inside a full B1 → Fusion migration. FBDI-ready output emitted directly; downstream Syntra ETL pipeline picks it up for transform and load.
Nightly or incremental feeds into Snowflake, BigQuery, Redshift, Databricks, Synapse for cross-company SMB-group reporting. Type-mapped DDL emitted alongside data.
One-shot or continuous archive of closed-period OJDT/JDT1/OINV/OPCH/OCRD into queryable cloud storage for IRS, HMRC, GoBD 7-yr retention without keeping a live B1 instance alive.
Direct feed to Power BI, Tableau, Looker — bypassing B1's Crystal Reports / B1 Studio bottleneck, giving SMB finance modern self-serve analytics without paying for B1 reporting add-ons.
When an SMB roll-up acquires another B1 user, the extraction tool pulls both companies' data into a common staging layer for harmonisation before consolidation onto the parent ledger or Fusion tenant.
Periodic full snapshots of the entire B1 company schema for disaster recovery, point-in-time audit reconstruction, or pre-upgrade safety captures before B1 PL upgrades or partner-applied patches.
A SAP Business One data extraction tool is software that reads data out of a live B1 instance — running on either SAP HANA or Microsoft SQL Server — and lands it in a target format suitable for downstream use: a migration pipeline, a data warehouse, an archive, a BI tool, or a compliance retention store. Syntra ETL's SAP Business One data extraction tool pulls from B1 via three paths: the Service Layer REST/OData API, the DI API (.NET COM-based), and direct database queries against the company schema. It supports OCRD (business partners), OITM (items), OJDT/JDT1 (journal entries), OINV/INV1 (AR invoices), OPCH/PCH1 (AP invoices), ORDR/RDR1 (sales orders), OPOR (purchase orders), OWHS/OINM (warehouses and inventory postings), plus every UDF/UDO extension. Output formats: Parquet, CSV, JSON, Avro, Oracle FBDI-ready ZIPs.
Three reasons. Operational: a dedicated SAP Business One data extraction tool handles parallelism, restartability, rate limiting, and Service Layer session management automatically — none of which you get from hand-written SQL or single-threaded Service Layer scripts. Schema fidelity: B1 has 600+ delivered tables plus customer-specific UDFs and UDOs; a real extraction tool reads the catalog dynamically and produces output that matches actual installed schema, including custom extensions. Audit evidence: every extract emits a manifest with row counts, hash signatures, partition layout, and a signed timestamp — the evidence package audit and regulators expect. Hand-written scripts produce none of that. Customers who try the build-it-yourself path usually spend 4–8 weeks getting to feature parity with a real tool, and 30%+ of the resulting scripts break on the next B1 patch.
Yes — both. SAP Business One ships on either SAP HANA (the modern in-memory column-store option SAP has been pushing since 2014) or Microsoft SQL Server (the original RDBMS, still very common especially in older partner-installed instances). Syntra ETL's extractor is backend-aware: on HANA it uses the HANA JDBC driver and column-store-optimized queries; on SQL Server it uses SQL Server JDBC with row-store-optimized parallelism. The Service Layer path works identically against either backend because Service Layer is a REST abstraction. For multi-company B1 setups where one company runs HANA and another runs SQL Server (common in M&A roll-ups), the extractor orchestrates across both backends within the same extraction job.
OJDT/JDT1 (journal entries) and OINM (inventory postings) are the highest-volume tables in most B1 instances — a 10-year-old B1 install can carry 50M–500M rows in JDT1 and 100M+ in OINM. Syntra ETL extracts these tables via direct database (HANA or SQL Server) because Service Layer paging is too slow at that volume. Parallelism is by year, period, and branch — typically 8–16 parallel extract workers — with checkpointing so a failed extract resumes from the last completed partition. Output is staged as Parquet partitioned by fiscal year and period. A typical 100M-row JDT1 extract completes in 2–4 hours on a modest HANA or SQL Server source without contention with B1 online users.
Yes. Beyond one-time migration extracts, the tool runs scheduled incremental extracts using B1's UpdateDate columns (on OCRD, OITM, OJDT, OINV, etc.) or — for HANA-based B1 — via HANA replication into Syntra's CDC channel. Common schedules: nightly full master-data refresh into a data warehouse, hourly incremental transactional pull for near-real-time reporting, sub-hourly for high-velocity sales order feeds. Scheduling supports per-table cadence so OACT (chart of accounts — changes rarely) might refresh weekly while ORDR (sales orders — changes constantly) refreshes every 15 minutes. Schedule definitions are versioned alongside extract logic.
Native: Parquet (default — columnar, compressed, queryable from Athena/BigQuery/Snowflake/Spark), CSV (legacy tooling), JSON (REST integration), Avro (Kafka pipelines). Oracle-specific: FBDI-ready ZIP bundles for direct Fusion load (Supplier Import, Customer Import, Item Import, Journal Import, AP Invoice Import, AutoInvoice). Data warehouse: pre-shaped tables for Snowflake, BigQuery, Redshift, Databricks, Synapse — including type-mapped DDL and partitioning recommendations. Archival: signed, hash-manifested Parquet with JSON Schema sidecar for long-term compliance storage. Every output format includes the same audit manifest so downstream consumers can verify lineage and integrity.
The extractor reads B1's CUFD metadata table at the start of every extraction run to enumerate every UDF defined on every table — UDF_xxxx columns on OCRD, OITM, OJDT, OINV, etc. — and includes them automatically in the extract output. UDOs (User-Defined Objects) are similarly enumerated from OUDO and their data tables extracted. This is important because most B1 partner customisations rely heavily on UDFs and UDOs to extend the schema, and a naive extractor that only knows about delivered tables will silently drop critical business data. The output schema for each table includes the full UDF complement, with type metadata preserved so downstream tooling renders them correctly.
Designed to be invisible. The extractor runs with throttling configured to keep CPU and IO impact below a configurable percentage of source-system capacity (default 20%). Database-path extracts use read-uncommitted isolation (SQL Server) or read-only column-store reads (HANA) to avoid lock contention with B1 online users. Service Layer extracts respect SAP-recommended rate limits and session timeouts. For high-volume historical extracts, customers commonly point the extractor at a HANA system replication target, a SQL Server log-shipped standby, or a nightly database snapshot — eliminating any production load entirely. B1 sales clerks keep entering orders, the warehouse keeps shipping, finance keeps posting journals — extraction runs in the background.
30-minute call. We'll connect to a sample B1 instance (HANA or SQL Server), enumerate your installed schema including UDFs/UDOs, run a representative extract, and show you the output and audit manifest — live.