Crystal Reports → BI Publisher. B1 Studio dashboards → OTBI. Query Manager → OTBI analyses. Excel reports → Smart View. Inventory, classify, rebuild, validate, train — the reporting layer SMBs forget until cutover week.
SMB project plans usually allocate 80% of effort to data migration, 15% to integrations, and 5% to reports — then discover at cutover that the 5% is what stakeholders actually use every day.
When SMBs scope a SAP Business One → Oracle Fusion migration, the visible work is the data: OCRD business partners, OITM items, OJDT journals, OINV invoices, OPCH AP invoices. That's what gets the project-plan rows, the budget, the steering-committee attention. The reporting layer — the Crystal templates that print invoices, the B1 Studio dashboards the CFO opens every morning, the saved queries that the finance manager runs at month-end — is treated as an afterthought, often relegated to a single line item called 'rebuild reports in Fusion' with a one-week placeholder.
Then go-live arrives. The first invoice prints in Fusion's stock template — not the customised layout customers have received for five years. The first AR statement goes out with different column widths and stakeholders complain. The CFO logs into Fusion expecting their B1 Studio dashboard and finds OTBI with no equivalent built. The finance manager's month-end saved query is gone. What was supposed to be a quiet cutover becomes a reporting fire-drill that lasts weeks.
Proper SAP Business One report migration prevents all of this. The work is unglamorous — inventorying Crystal .rpt files, classifying B1 Studio dashboards by actual usage, rebuilding RTF templates in BI Publisher with the original layouts preserved — but skipping it is what turns a successful data migration into a perceived-failure go-live. Syntra ETL treats the report layer as a first-class migration deliverable with its own backlog, its own UAT, and its own sign-off gate before cutover.
Each B1 reporting artefact type maps to a specific Fusion reporting tool. Getting the mapping right up front prevents months of rework.
Invoice, PO, delivery, AR statement, remittance templates rebuilt as BI Publisher RTF templates with the original layout preserved. Same logos, columns, footer disclaimers, payment instructions. Bursting for email distribution to customers/vendors.
Analytical dashboards rebuilt as OTBI dashboards using Fusion subject areas (Financials, Procurement, Order Management, Inventory). Drill-through to transaction detail. Mobile-friendly. Replaces the morning CFO B1 Studio routine.
Saved SQL queries rebuilt as OTBI ad-hoc analyses or, for power users with SQL fluency, BI Publisher data models with SQL preserved. Original B1 SQL retained as inline documentation.
Finance Excel models switched from B1 ODBC to Oracle Smart View. Pre-built Smart View functions hit Fusion ledgers, AR/AP balances, inventory positions. Refresh-on-open updates working papers.
Stock B1 print layouts (delivery notes, picking lists, GR notes) rebuilt as BI Publisher templates triggered by Fusion ESS jobs. Same paper sizes, same logos, same field positions.
B1's customer-statement mail-merge cycle rebuilt as BI Publisher bursting from a scheduled ESS job. Same monthly cadence, same email template, same recipient list.
Six phases from discovery to user training. Locks reports before cutover so go-live doesn't trigger a reporting fire-drill.
Discovery scan across Crystal repo, B1 Studio, OQUR/QURY, Excel models. Each artefact classified by business domain, usage frequency, customisation depth, and Fusion target tool. Backlog prioritised by customer/supplier-facing first, then internal analytical, then ad-hoc.
Wait for the data-migration UDF and DFF/EFF mapping to lock. Then build the BI Publisher data models and OTBI custom subject-area extensions that the reports will consume. This is the gate that prevents premature template work.
Highest priority: invoice, AR statement, delivery note, PO, vendor remittance templates rebuilt in BI Publisher. Side-by-side PDF comparison with the original Crystal output. Sign-off from CFO and customer-service lead before move to dashboard work.
B1 Studio dashboards rebuilt as OTBI dashboards. UAT with the actual dashboard consumers (CFO, sales director, ops lead). Drill-through paths configured. Mobile rendering tested. Subscription-based email PDF delivery configured for executive consumers.
Recurring shared Query Manager queries rebuilt as OTBI ad-hoc analyses. SQL-fluent power users get BI Publisher data-model access. Smart View setup for finance Excel users. Original B1 SQL archived alongside Fusion equivalents.
Role-based training: customer-service on the new invoice/statement layouts, CFO on OTBI dashboards, finance manager on Smart View and OTBI ad-hoc, power users on BI Publisher data models. Sign-off gate before cutover. Crystal runtime decommission scheduled for first week post-go-live.
What Syntra ETL hands over at the end of the reporting workstream — the concrete artefacts that make Fusion reporting feel familiar to B1 users.
Complete spreadsheet of every Crystal .rpt, B1 Studio dashboard, saved query, and Excel model — with usage classification, customisation depth, Fusion target, priority, and effort estimate. Becomes the executable backlog.
RTF templates for every customer/supplier-facing document: invoice, AR statement, delivery note, PO, vendor remittance, dunning notice. Layout-preserving — recipients shouldn't notice the change.
Rebuilt B1 Studio dashboards as OTBI dashboards. Drill-through configured. Subscription email delivery configured for executive consumers.
SQL-based data models that power both reports and BI Publisher direct queries. Used by SQL-fluent power users who need to write their own ad-hoc against Fusion.
Pre-built Smart View Excel workbooks for trial balance, AR aging, AP aging, inventory valuation, sales analysis. Refresh-on-open. Finance team's day-one Excel productivity preserved.
Customer-service, finance, sales, ops, exec — each gets a tailored training pack: how to find the equivalent of their old B1 report, how to ad-hoc in OTBI, when to use BI Publisher vs OTBI vs Smart View.
SAP Business One report migration is the systematic conversion of the reporting layer that SMBs built on top of B1 — Crystal Reports invoice/PO/statement templates, B1 Studio dashboards, query manager queries, and any embedded Excel-based reporting — into Oracle Fusion's reporting stack: OTBI (Oracle Transactional BI) for ad-hoc analytics, BI Publisher for pixel-perfect documents, and Smart View for finance power users. Unlike data migration, which moves OINV/OPCH/OJDT records, SAP Business One report migration moves the queries, layouts, parameters, and distribution rules that turn that data into the printed invoices, AR statements, sales dashboards, and management packs SMB stakeholders actually consume. Skipping this layer is the #1 cause of post-go-live reporting chaos in B1 → Fusion projects.
Syntra ETL's discovery scan inspects the source B1 system across four locations: (1) the Crystal Reports repository — typically a SAP B1 Server folder of .rpt files used for invoices, deliveries, purchase orders, and customer/vendor statements; (2) B1 Studio dashboards and KPIs stored in the company database; (3) Query Manager queries saved in the OQUR/QURY tables; (4) any external Excel workbooks pulling B1 data via DI API, Service Layer, or direct ODBC. Each artefact is classified by business domain (AR, AP, Inventory, Sales, Production), usage frequency (active daily, monthly, never), customisation depth (stock B1 vs heavily customised), and target equivalent in Oracle Fusion. The inventory becomes the SAP Business One report migration backlog with prioritisation already baked in.
There's no single one-to-one mapping. Crystal invoice/PO/statement templates → BI Publisher (RTF or XSL-FO templates driven by data models that query Fusion's reporting tables). B1 Studio analytical dashboards → OTBI dashboards with subject-area-based reports and visualisations. Query Manager ad-hoc queries → OTBI ad-hoc analyses or, for power users, BI Publisher SQL data models. Excel-based reports → Smart View for Excel, which gives finance users a direct connection to Fusion and replaces the manual ODBC-into-Excel pattern that dominated B1 SMB reporting. SAP Business One report migration done well doesn't replicate every artefact one-for-one — it consolidates duplicates and routes each report to the Fusion tool that fits its actual purpose.
Crystal .rpt templates are parsed to extract three things: the data source query (rewritten to hit Fusion's GL_JE_HEADERS / AR_INVOICES / AP_INVOICES subject areas instead of OJDT/OINV/OPCH), the layout (header, body, footer with grouping/sorting), and the parameters (typically Doc Num, Doc Date range, Customer/Vendor). Syntra ETL produces a Fusion BI Publisher data model and an RTF template per Crystal report — the layout is reconstructed from the original .rpt file so the printed invoice/PO looks substantially identical to what stakeholders are used to. Logos, footer disclaimers, payment instructions, multi-language labels, and bilingual layouts (common in Quebec, Catalonia, Belgium, Switzerland B1 deployments) are all preserved. Test runs compare PDF output side-by-side before sign-off.
Saved queries in B1's OQUR/QURY tables are the secret reporting layer of most SMB B1 deployments — power users (finance managers, ops leads) write SQL that pulls custom views the official Crystal reports don't cover. SAP Business One report migration inventories every saved query, classifies it (one-off vs recurring, individual vs shared), and converts the recurring shared ones to OTBI ad-hoc analyses or BI Publisher data models. The original SQL is preserved as documentation alongside the new Fusion equivalent so the original author can verify the translation. One-off and personal queries are typically archived rather than rebuilt — but the SQL is kept in the archive so the author can reference and re-create in Fusion if needed.
User-Defined Fields (UDFs) in B1 — added to OCRD, OITM, OINV, OPCH, etc. — are frequently used in custom Crystal reports and B1 Studio dashboards. During SAP Business One report migration, each report referencing UDFs gets a Fusion-side mapping decision: the UDF either (a) maps to a Fusion DFF (descriptive flexfield) and the report references the DFF, (b) maps to a Fusion EFF (extensible flexfield) for entity-attribute scenarios, (c) maps to a custom field on a custom Fusion object, or (d) is retired because the UDF was never used meaningfully. The report's data model is updated to pull from the mapped Fusion field. This requires the data-migration UDF mapping to be locked before report migration starts.
Yes — and this is one of the highest-stakes parts of the project for SMBs. Customer AR statements and vendor remittance advices are the customer-facing and supplier-facing documents that an SMB's business partners are used to receiving in a specific format. Changing the layout abruptly post-go-live causes payment delays, customer support volume spikes, and supplier confusion. SAP Business One report migration rebuilds AR statements and vendor remittances as BI Publisher templates with the original B1 layout intact — logo position, columns, ageing buckets, payment instructions, footer text all preserved. Email distribution rules (statement-by-email cycles from B1's mail merge) are re-implemented as Fusion ESS scheduled processes with BI Publisher bursting to deliver to the same customer/vendor contact lists.
For a standard mid-market SMB B1 deployment (20–60 Crystal reports, 5–10 B1 Studio dashboards, 30–80 saved queries, 5–10 Excel reports), a complete SAP Business One report migration is typically 6–10 weeks running parallel to the main data migration. Weeks 1–2 inventory and classification. Weeks 3–6 rebuild the high-priority customer/supplier-facing documents (invoices, POs, statements, remittances) in BI Publisher with side-by-side PDF comparison sign-off. Weeks 5–8 rebuild analytical dashboards in OTBI with finance-team UAT. Weeks 7–10 user training and parallel-run validation. The work is parallel to data migration because the report data models only finalise after the data mapping locks — but the layout work, parameter analysis, and dashboard wireframing happen earlier.
Crystal templates rebuilt as BI Publisher with layouts preserved. B1 Studio dashboards rebuilt as OTBI. Query Manager and Excel models routed to the right Fusion tool. Six- to ten-week parallel workstream that locks reports before go-live.