Every image here is a page produced by one of the 90 example workflows. The companies are made up and the data is sample data. The pages are exactly what KBStudio rendered from it.
Find the example closest to what you do and start from there. Each one is a complete project.
Example companies: Adria Bank d.d., NovaPay d.o.o.
Example companies: Velebit osiguranje d.d.
Example companies: Aurora komunalije d.o.o., Istra Telekom d.o.o.
Example companies: Kvarner Print d.o.o., Aria Arhitekti d.o.o., Bingo Jadran d.o.o., Mediteran Media d.o.o., Grafika Adria d.o.o.
Example companies: Robna kuća Dalmacija d.d.
Example companies: Talent Adria d.o.o., Kvarnerplast d.d.
Example companies: Naklada Kvarner d.o.o.
Example companies: Restoran Lanterna d.o.o., Riva Grupa d.o.o.
Example companies: Klima Jadran servis d.o.o.
Example companies: Osnovna škola Sunčani breg
Example companies: Jadranska logistika d.o.o.
Example companies: Kongresni ured Opatija d.o.o.
Example companies: Tiskara Lipa d.o.o.
Example companies: Dalmacija Opskrba d.o.o.
Every workflow below ships with KBStudio. Filter by industry or search, open the one you need and change it to fit your data.
The letterhead sits in the page background, the address in the envelope window, next to an info block. The transaction table runs over as many pages as needed with a repeating header, then come the closing balance and “Page X of Y”. Amounts use Croatian number and currency format, and every page has a DataMatrix for the inserter.
The same statement goes out through three channels. Customers with e-statements and a valid address get an email with a PDF signed by certificate (.p12, PAdES). Everyone else is printed, one file per branch with a cover sheet up front and a DataMatrix for inserting. Statements from both channels are archived in the DMS as JSON with the fields and the signed PDF in base64.
Each policy has a summary and a product image chosen by type (car, home, life). A green bonus bar appears only from 30 %, and donut and bar charts show the premium structure and claims by year. With several properties the coverage table spans pages; special terms (a PDF background) go to car policies only. Delivery: email with a visible e-signature (.p12), print per branch with a cover sheet, and the DMS as JSON with the signed PDF.
A one-page renewal letter whose text depends on the policy type (car, home, life). A QR code leads to online renewal, a HUB3 barcode lets the customer pay the new premium, and a DataMatrix controls inserting. All letters come out in one print file.
{
"brojTransakcija": 21,
"najvecaTransakcija": 126.24,
"naknade": 17.05,
"nazivTrgovca": "Istra servis obrt",
"promet": 1545.06,
"razdoblje": "2026-09",
"transakcije": [
{
"datum": "2026-09-04",
"iznos": 110.18,
"kartica": "Maestro",
"naknada": 1.05,
"vrijeme": "18:20"
},
{
No layout here, only data. A flat CSV with tens of thousands of September card transactions is filtered to approved ones and grouped by merchant, with transaction count, turnover, fees, largest transaction and merchant name. Each merchant ends up with one JSON file for the DMS or a partner API.
The report opens with a summary of turnover, fees, payout and transaction count. A line chart shows daily turnover, and a donut chart totals the transactions by card scheme on its own. The full transaction table continues over the following pages. Merchants with an email address get a signed PDF, the others a printed copy, and every report goes to the DMS as JSON with the PDF in base64.
The bill has a 12-month consumption chart, an energy-class image from data (A/B/C) and a red reminder only when there is debt. With several metering points the line-item table spans pages; payment goes through a HUB3 barcode. Opted-in customers get a signed e-bill. The rest go to duplex print with DataMatrix and OMR on front pages only (counting sheets), one file per region with a cover sheet. Every bill also goes to the DMS as JSON with the PDF.
PDF Input reads a whole folder of 700 invoices of 1 to 4 pages each. The invoice number is read from the page and carried over to the remaining pages of that invoice. Each page gets a DataMatrix (invoice number / page / C/E) and OMR marks for the inserter, and everything lands in one print file.
The input is one large PDF spool with invoices for 320 customers. The customer number is read from the page, and Page Regroup opens a new document each time it changes. Blank pages are removed before numbering, so every customer gets a separate PDF with a DataMatrix on each page.
The same spool, prepared for duplex printing. Any document with an odd page count gets a blank page at the end, and DataMatrix and OMR marks go on odd (front) pages only, counting sheets (customer / sheet / C/E). The output is a single print file.
A single PDF Page Transform node does the work. It reads the customer number, starts a new document when the number changes and stamps a visible DOC {document number} · PG {page}/{total} · SHEET {sheet}/{sheets} · {customer} line plus a DataMatrix on every page. The output shows at a glance whether each group has the right boundaries.
The spool is read by customer number, and Page Regroup turns each customer's pages into one group. The inserter marks come from a layout that Sheet Mixer lays over every page: DataMatrix (customer / page in group / C/E), OMR marks and a visible CUSTOMER · PAGE x/y line. The overlay takes its values from the page underneath (sheet.groupCounter, sheet.groupCount, sheet.isLastInGroup, sheetnames.kupacBr).
The spool is split by customer, and a cover sheet (a PDF in the client's colours) goes in front of each document. That makes the cover sheet page 1 of the document, so the DataMatrix counts it correctly.
A 20,000-page PDF is streamed through page by page, without loading the whole file. Each page gets a Bates number KP-000001… and a DataMatrix with the same number. The result is one output file.
The simplest case. One PDF, the 12-page General Terms, gets “Page X of Y” and a DataMatrix on every page, ready for simplex printing.
An 85 x 55 mm card with 3 mm bleed. The front has the department colour running off the edge, logo, name, function, department, contacts and a QR code with a vCard contact (MECARD); title and mobile appear only when present. The back shows the logo on a dark ground (copper for the board) and the English function where one is entered. The proof is one A4 page per person, front above back, enlarged, with crop marks.
Each person gets the quantity they ordered (100, 200 or 300). Sheet Padder with Copies repeats front and back as many times as the order says, which is step & repeat driven by data. NUp Imposer places 4 x 5 cards on SRA3 (450 x 320 mm) duplex, each back exactly behind its front, with 3 mm bleed, a 6 mm gap and crop marks. A sheet only ever holds one person's cards.
ime_prezime,odjel,kolicina,araka_SRA3,papir Hrvoje Žagar,Uprava,300,15,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Matej Pavić,Uprava,300,15,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Martina Galić,Uprava,300,15,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Željka Pavlović,Uprava,300,15,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Tihana Grgić,Nadzor gradnje,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Kristina Božić,Interijeri,200,10,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Marija Žagar,Nadzor gradnje,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Sara Vidović,Urbanizam,200,10,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Vesna Tomić,Interijeri,200,10,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Goran Barišić,Interijeri,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Petra Marković,Projektiranje,200,10,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Ante Pavlović,Projektiranje,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Dora Žagar,Urbanizam,200,10,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Dora Filipović,Interijeri,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55" Marko Kovačić,Interijeri,100,5,"Munken Pure 350 g, obostrano 4/4, rezanje 85 x 55"
The same order data produces a work order listing department, quantity, number of SRA3 sheets, paper and finishing for each person. The sheet count (quantity / 20) is calculated in the output contract. The print shop uses it to plan printing and cutting.
Each strip holds six 3 x 9 tickets with all 90 numbers exactly once. Every column has its own decade, every row exactly 5 numbers, and each ticket 1 to 3 numbers per column, sorted top to bottom. An algorithm builds and checks the combinations. The 85 x 210 mm strip has a green full-bleed background (3 mm), a serial number and a DataMatrix. NUp Imposer places 3 x 2 on SRA3 (320 x 450 mm) with crop marks, in cut & stack order BJ-000001, BJ-000002…
An old billing system delivers one PDF containing every invoice. PDF Input and PDF Page Transform read the customer number and look up the channel and email address in master data (CSV), and Page Regroup opens a new document per customer. Paper customers get DataMatrix and OMR marks in one print file. Email customers receive a PDF signed with a certificate (.p12) as an attachment, matched by customer number rather than by position.
A custom 85 x 55 mm format with 3 mm bleed so the coloured band runs off the edge. Every person gets 10 identical cards: Sheet Padder copies the first page up to 10 times (step & repeat). NUp Imposer places them 2 x 5 on an SRA4 sheet (225 x 320 mm) with gutters and crop marks, one sheet per person.
Each 70 x 37 mm label holds one contact. NUp Imposer lays them out 3 x 8 on A4 in sequence, one contact after another rather than as copies. A priority flag is printed only on VIP customers' labels, and the colour of the band shows the region.
The A6 postcard (148 x 105 mm) shows an image picked by the recipient's region (Dalmatia, Istria, Zagreb, Slavonia) and a greeting in their language (hr or en) on the front. The back has segment text (VIP, new, standard), a stamp box and the address. NUp Imposer places 2 x 2 on landscape A4, duplex: four fronts on the face of the sheet and the four backs mirrored on the reverse, each exactly behind its front.
Every store gets its own A5 catalogue. Loyalty-club stores have a Loyalty Club cover and the others the standard one, while the Weekly Offers page only exists when the store has offers. The product table runs over several pages. The Booklet node imposes for saddle stitching: it pads to a multiple of 4, orders pages for folding, puts 2 pages on landscape A4 and applies creep compensation.
One document in three formats: an A4 letter, a DL reply card (210 x 99 mm) and an A6 coupon (105 x 148 mm). The page flow chooses a Croatian or English letter by the recipient's language, and only recipients with 1,000 points or more get the coupon with its QR code. VIP customers get a master page with a background and a VIP KLUB badge, and the letter text depends on the segment.
The PIM XLSX has a title row above the header, which therefore sits in row 3. Each item gets an A4 data sheet with specs only from the columns it has (litres, kilograms, spin speed), with units and Croatian number formatting, and single-cell features split into a list. It also shows price, savings in euros and percent, price excluding VAT, an A-G energy-class scale with the item's class highlighted (where it applies), EAN-13 and a QR code to the product page.
Item master data becomes a 105 x 37 mm label with name, price, item code, origin and unit price (EUR/kg, EUR/l), which a script works out from price and net quantity. Items on promotion get a red band and the old price. The data decides the barcode type (EAN-13, EAN-8 or UPC-A), and the check digit is added automatically. Each A4 sheet holds 16 labels.
A filter lets only sale items through, and a script works out the discount percentage from the old and new price. The A7 wobbler (105 x 74 mm) with bleed carries a large SALE −20 % headline, the new and old price and the date the offer ends. Eight fit on an A4 sheet with crop marks.
The input is deli packs with PLU, weight and price per kg. The workflow calculates the amount (weight × price/kg), a variable-measure EAN-13 (21 + PLU + amount in cents + check digit, with the algorithm in a script) and the best-before date, five days after packing. The label is 70 x 42 mm, 21 on A4.
The 50 x 90 mm hang tag has a punch hole, the size on the front, and name, colour, composition, care, price and EAN-13 on the back. Each item gets as many tags as its quantity says, using Sheet Padder Copies read from a page value. NUp places them 4 x 3 on A4 duplex, back exactly behind front, with crop marks.
Data Group groups items by category, and each category becomes a document with a table. Every row has a product image from data: the image field names a file (p_0007.svg) in resources/proizvodi, and the picture block uses Picture from data = item.slika. The unit price comes from the workflow, promotions are flagged and a cover goes before the first category. It all comes out as one PDF.
The order only says how many vouchers of each value are needed. A script in the workflow creates each voucher with a series number, sequence number and Luhn check digit, and the layout reads them as records (Records from: records.bonovi). The colour depends on the value, and a Codabar carries the voucher number. Vouchers are 210 x 99 mm, three on A4.
A script builds each card number from the member list: 385, the member number and a Luhn check digit. The 85.6 x 54 mm card with bleed is printed in the tier colour (silver, gold, platinum), with ITF (Interleaved 2 of 5) for the tills and a QR code for the app on the back. They go 2 x 5 on A4 duplex, in front/back pairs, with crop marks.
The codes come from client orders (CSV: type, data, expiry, batch). The workflow expands UPC-E to UPC-A and computes its check digit, the GTIN-14 check digit, GS1-128 with AIs (01)(17)(10) and the expiry as YYMMDD, and mod 10 check digits for the 2 of 5 variants. In the symbol cell, each symbology has its own barcode inside a conditional group chosen by row type.
A 70 x 100 mm wine label built from the wine list, 16-up on SRA3. The sheet has crop marks, registration crosses in the middle of each side, a colour control bar (C, M, Y, K, 50 %, R, G, B) and a slug with job name, sheet number and date. The brand blue prints as spot colour PANTONE 286 C (Separation with a CMYK alternate), everything else is converted to CMYK (ISO Coated v2), and the file is tagged PDF/X-4.
Daily orders arrive with quantities: 85 x 55 business cards, 100 x 50 labels and 148 x 105 postcards. The layout picks a page by format, Sheet Padder multiplies each one to the ordered quantity, and NUp in nesting mode packs same-size pieces in rows on SRA3. A full row starts a new row, and when the rows run out a new sheet begins. Every piece has its own crop marks.
Round 60 mm stickers with bleed, 12 to a sheet. The cut line (a magenta circle on the die line) sits in a print group called Štanca, which is off by default. The print output leaves it out, while a second output of the same workflow, the proof for the client and the die maker, includes it.
85 x 55 mm business cards in front/back pairs, 10 on A4 duplex. This press shifts the reverse side 2 mm to the left, so the back-side content is moved 2 mm to the right (Back side offset X). Front and back then line up exactly.
Data comes from the ATS candidate export. Work experience is sorted newest first (sortBy script), and for each job the period (06/2022 to present) and duration (4 yrs 4 mos) are calculated from the dates. Total experience uses correct Croatian plurals. The classic single-column layout runs over several pages with page X / Y, and certificates, projects, interests and driving permit appear only when present. Each candidate gets a separate PDF.
A dark sidebar holds contact details, skills, languages with level, digital skills and, if there is one, the driving permit. The main column has the name, total experience worked out by a script, profile, experience and education, and continues onto the next page when needed.
A script merges work experience and education into one timeline, newest first (sortBy), with years (2019 to present), type (JOB or EDUCATION), title and place. The timeline itself is a table: years, a dot (a data bar with one round segment) and an entry with a rule down its left edge.
A script produces the key figures: years of experience, number of distinct employers, languages and certificates. Skills appear as data bars in a table cell (level / 100), languages as six dots (A1 = 1 … C2 and native = 6), and a pie chart shows years per field, with the script summing months by sector.
A narrow column with plenty of white space, no colour and no achievements section. Portfolio, LinkedIn, certificates and interests only show up when the candidate has them, and every CV fits on a single page.
Initials built by a script sit in a circle, skills are shown as tags and projects go in a side column. The QR code points to the portfolio if the candidate has one, otherwise to LinkedIn. When neither exists, a conditional group leaves it out.
A filter lets through only candidates with publications. A script sorts them newest first (sortBy) and builds a numbered APA citation for each: authors, year, title, journal, volume(issue), pages, DOI. The CV also shows publication count and h-index, the thesis next to the qualification, teaching where there is any, and a running header with the name on every page.
The European CV layout: periods and labels on the left, content on the right. Achievements sit in a nested table, a script picks the native language, and foreign languages get a self-assessment table across five skills (listening, reading, spoken interaction, spoken production, writing). Education shows the EQF level, and the photo comes from data.
One page for the board. The key achievements are the first achievement from each of the last three jobs (take + map), the career section lists the last four jobs, and the highest qualification is picked by EQF level (sortBy). Contact details come as a MECARD QR code that a phone saves straight to its contacts.
The sidebar holds the candidate's photo from data, name and contact details, languages as dots and a LinkedIn QR code, but only when a profile exists. The main column covers experience, education and skills shown as bars.
The manuscript comes from the editorial system (chapters → sections → paragraphs). Chapter and section headings go into the table of contents as levels 1 and 2: a table over document.toc lists them with page numbers, and the engine keeps composing the book until the page numbers settle. Each chapter starts on a new page with a running head (page.runningHeader) and page number. The imprint carries the ISBN with check digit and its EAN-13.
The same book pages, imposed for perfect (softcover) binding. Booklet builds signatures of 4 folded sheets (16 pages), pads each signature separately to a multiple of 4, applies 0.6 pt creep per sheet and adds crop marks. Sheets are landscape A4.
Every model in the PIM (model, features, revision history) gets its own manual. The Wi-Fi, solar collector and app chapters appear only when the model has those features, and the contents list just the chapters present, with page numbers. There is a running head with page number, a revision table showing the current version (latest revision, via script), and PDF title, author, subject and keywords taken from the data.
The input is the item list from the till. A script turns each dish's allergen codes (1,3,7) into icons, images from data in resources/alergeni. Data Group sorts the dishes by category, and a second Data Group without a key collects all categories into one menu. The layout repeats a group with a dish table for each category, plus a conditional vegan leaf and an allergen legend. A4 with bleed.
The kitchen sends a weekly plan with cost prices and margins. A script calculates the selling price and rounds it up to the next €0.50, Data Group groups dishes by day, and the weekday comes from the date. Each day gets an A5 page, and the whole week comes out as one PDF.
A filter keeps only the dishes available for delivery, and icons and categories work as in the menu. The flyer is landscape A4, printed on both sides. The outside has a flap with the allergen legend, a back panel with contact details and an ordering QR code, and the cover. Inside, the menu flows through three linked panels (area chain), with fold marks.
All dishes sit in one table built over the whole dataset, with a column for each of the 14 EU allergens. Each cell evaluates an expression and shows a dot when the dish's allergen codes include that one. The result is a landscape A3 poster.
The input is a CRM property export. The main photo, map and a three-image gallery come from data (a script splits a/b/c into a gallery row), and the workflow calculates the price per m². The energy class is shown in its own colour, garden and parking appear only when relevant, and the agent's photo and contacts are joined from the agent list with Correlate. A QR code links to the listing, and each property gets its own PDF.
A filter takes the vehicles for sale from the fleet export and sorts them by price. A script works out each vehicle's age and the monthly lease payment as an annuity (60 months, 20 % down payment, 6.9 % a year). The landscape A5 card has a photo from data, an electric or hybrid badge where it applies and a QR code, two to an A4 sheet.
The booking system export has passengers and segments nested inside each booking. Every booking gets an itinerary with a passenger table and a segment table (flight or ferry, route, departure), as a separate PDF.
A script turns each booking into a pass for every passenger on every segment. For flights it builds an IATA BCBP string (20-character name, PNR, route, carrier, flight number, Julian day of the year, class, seat, check-in sequence) and encodes it as PDF417; ferries get an Aztec code. Passes are 210 x 99 mm, three on A4.
In the CRM export the devices are nested inside each contract. A script calculates the price per device (package × capacity), the multi-year discount, VAT, the total, the same total written out in Croatian words, and the end date. Clauses depend on package (Basic, Plus, Premium), customer type (company or individual) and term. Annex 1 is the device table; Annex 2 on personal data processing goes to individuals only. Each contract is a separate PDF.
The input is a field app export, with parts nested in the work order and signatures saved as files. A script adds up parts and labour (hours × €38), labour being free when the device is under a maintenance contract, then adds VAT and the total. The technician's and customer's signatures appear as images from data (resources/potpisi). Every work order gets its own PDF.
The till export already holds the JIR and ZKI codes returned by the Croatian Tax Administration. A script calculates the total, the VAT breakdown at 25, 13 and 5 % (base and tax from gross prices) and the receipt verification QR code: JIR, date and time, and amount in cents, as the Tax Administration specifies. Receipts are laid out for 80 mm thermal paper, in one PDF.
Each completed job gets an A5 survey as a PDF form with four questions rated 1-5 (radio groups) and a comment field. Job number, technician and date are already filled in. For print, NUp puts two surveys on A4, and the form fields survive imposition, so the survey can also be filled in on a computer.
Two exports come from the e-register: students and final grades. Data Group groups the grades per student (average, lowest grade), Correlate joins them to the student, and a script determines the overall result and the subjects needing remedial work. A second Data Group passes the class average back to each student. The report shows grades in words, a bar chart and comments based on results and unexcused hours, and Page Regroup produces one print file per class.
Same flow as the school reports (grades per student, result from a script), but a filter only lets through students with excellent results and exemplary conduct. The certificate is landscape A4 with grade average, class teacher and a verification QR code. All certificates come out in one PDF.
Students are sorted by class and surname and grouped by class (class teacher, number of students). A script lays out each class in rows of four, with a photo from data (resources/ucenici) and the name in every cell. A cover comes before the first class, and the A4 pages are imposed on A3 for saddle stitching.
Every student gets a PDF form (AcroForm). Name, class, OIB and parent are filled in from the e-register and locked, and the phone number is pre-filled but can be changed. The parent marks consent (radio), adds health notes, allows photography or not (checkbox) and enters the date and a signature in the signature field. One PDF per student.
Three exports (HR records, timesheet hours, municipal tax rates) are joined through two Data Correlate nodes. A script runs the whole payroll: hourly rate from a 176-hour fund, overtime +50 %, night work +30 %, sick leave at 70 %, seniority, pension pillars I and II, personal allowance with children, tax at the city's lower and higher rates, net pay and health contribution. Each payslip is its own PDF that opens only with the employee's OIB, with a Code 39 for archiving.
The 85.6 x 54 mm card with bleed carries the employee photo from data (foto field, resources/fotografije folder), a band in the department colour, name, job title, number and an expiry date three years after the issue date set as a parameter. The back has MicroPDF417 for the access readers and Code 39 for the canteen. Cards go 2 x 5 on A4 duplex, in front/back pairs, with crop marks.
Each new hire gets one PDF. It contains a welcome letter with paragraphs for their role (production or office) and a first-week plan a script builds from the start date: five working days, weekends skipped, each with the weekday and role-based activities. Production staff also get a health and safety page, office staff an IT access page with a username derived from their name.
The input is the attendance record (employee, course, date, score). A filter passes only those who scored 70 % or more, and Correlate adds course details (name, hours, validity, trainer) and employee data. A script computes a serial number with MOD 97 check digits, and the expiry date is the course date plus its validity in months. Each certificate is a landscape A4 PDF with a verification QR code.
There is one source: chapters tagged with the departments they apply to, texts in Croatian and English, and a list of editions (department + language). For each edition a script picks that department's chapters, takes the texts in the edition's language, numbers them and translates the department name. The layout turns each edition into a document (Records from: records.prirucnici) with cover, contents, chapters and a header on every page. Each edition is a separate PDF.
The WMS order export nests parcels and items in each order. A script builds a label per parcel: SSCC-18 (extension digit 3 + GS1 prefix 3856001 + order and parcel number + GS1 mod 10 check digit), PARCEL 2 / 3, route, weight, dimensions and the destination's postal barcode: Royal Mail 4-State (GB), KIX (NL), UPS MaxiCode (US, structured carrier message), USPS Intelligent Mail and POSTNET (US), Australia Post (AU) or Japan Post (JP). The 101.6 x 152.4 mm label prints on a thermal printer.
Each order gets one PDF with its shipping documents. The pick list is sorted by warehouse location, in walking order. The delivery note lists items, weights and totals (kg calculated by script, parcel count from data) with the order number in Code 39. Destinations outside the EU also get a commercial invoice (HS tariff codes, origin, value), a conditional page whose condition a script sets from the list of EU countries.
The input is a supplier goods receipt where each row is an item with carton count, lot and expiry. A script expands every row into individual cartons: GTIN-14 (indicator 1 + GTIN-13 without its check digit + a new check digit), expiry as YYMMDD, a carton SSCC with check digit and CARTON 3 / 5. The A6 label carries ITF-14 with bearer bars, GS1-128 (02)(15)(37)(10) and SSCC (00), four to an A4 sheet.
The only input is the warehouse layout: zones and the number of aisles, racks and levels. From that a script generates every location (A-01-03-2), its level and check digits for voice picking. The 100 x 40 mm label shows a large location code, check number, Code 128 and level colour (1 red, 2 orange, 3 green, 4 blue), 2 x 7 on A4.
A filter picks the items below minimum stock from the stock list. A script calculates the order quantity up to optimum stock, the amount and the delivery date (export date + supplier lead time). Data Group totals the amounts per supplier, and each supplier gets a purchase order with a table, VAT, total and a Code 93 order number, as a separate PDF.
A6 badges with bleed, made from the registration export. The front has name, company, role, country, a band and label in the category colour (delegate, speaker, VIP, media, organiser) and an Aztec code for the entrance readers. The back lists the valid days, plus the gala dinner for invitees only. Badges are sorted for the desk by category, then surname, and NUp places them 2 x 2 on A4 duplex, front and back paired, with crop marks.
Only invitees get tickets (filter gala = yes), sorted by surname. The workflow assigns ticket number and table: a script counter hands out GV-0001, GV-0002 … in order, and every eight guests start a new table. The 210 x 99 mm ticket has a perforated control stub on the left and Code 128 on both the stub and the ticket. Three fit on A4.
The entrance scanner export has several entries per day. It is grouped per attendee with the number of distinct days and joined with the registrations (Correlate), and only people present on at least two days get a certificate. A script computes the serial number (2026 + code + ISO 7064 MOD 11,10 check digit). The certificate is landscape A4 with a guilloche frame, signature and verification QR code, digitally signed (PAdES), one PDF per person.
The programme arrives as JSON, one session per record, and Data Group groups it by day, so each day becomes a document with a heading and a session table (time, room, title, speaker). Breaks are grey and workshops are marked by cell colour. The cover only appears before the first day and the back cover only after the last. Booklet imposes the A5 pages for saddle stitching.
All attendees are in one table sorted by surname. The document is not split per record: the table covers every record and runs across pages with a repeating header, with columns for category, days, gala dinner and a check box for badge pickup. The header shows the number of attendees and gala guests, calculated in the layout.
Nothing is prepared outside the workflow. Parameters set the year and months, and a script in Data Transform computes each month: Monday-start weeks, ISO week numbers, days from neighbouring months, weekends and Croatian public holidays (Easter by Meeus's algorithm, Easter Monday and Corpus Christi derived from it). The layout reads months as records (Records from: records.mjeseci): a cover, then one A3 page with bleed per month with a seasonal image, day grid (Sundays and holidays in red) and holiday list.
Same calculation, different design and format: a narrow monthly image on the left, a grid without week numbers and holidays in small type. The format is 210 x 105 mm with 2 mm bleed. NUp Imposer puts two months on A4 with crop marks, so a year takes 6 sheets.
The same calculation laid out as a full-year table: one row per month and 31 columns with the weekday letter. Weekends and holidays are highlighted, and days a month doesn't have stay blank. Below the table is a list of holidays by month, all on one landscape A3 page.
Parameters select the year 2026 and months 11,12, so the script calculates only those. The A4 sheet has an image strip, large writing fields (30 mm row height), the holidays (1 Nov All Saints, 18 Nov, 25 and 26 Dec) and lines for notes. Change the parameters at run time and you get any month of any year.
An ERP export (invoices, credit notes, advance invoices) is checked before sending: buyer and operator OIB, IBAN, KPD on every line, totals and the VAT breakdown. Invalid records go to a correction list. The rest become UBL 2.1 Invoice and CreditNote per HR CIUS 2025 with CustomizationID, ProfileID P1-P12, operator OIB, KPD, VAT categories S / E / AE, the packaging deposit as a pass-through line in the HRFISK20Data extension, and credit notes referencing their invoice. Each XML embeds its PDF visualisation (BT-125, base64); the OASIS UBL 2.1, FINA and HR extension schemas ship with the project.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:iwsc="http://f
<soapenv:Body>
<b2g:SendB2GOutgoingInvoiceMsg>
<iwsc:HeaderSupplier>
<iwsc:MessageID>DO-249-VP1-1-9001</iwsc:MessageID>
<iwsc:SupplierID>9934:47193865202</iwsc:SupplierID>
<iwsc:MessageType>9001</iwsc:MessageType>
</iwsc:HeaderSupplier>
<b2g:Data>
<b2g:B2GOutgoingInvoiceEnvelope>
<b2g:XMLStandard>UBL</b2g:XMLStandard>
<b2g:SpecificationIdentifier>urn:cen.eu:en16931:2017#compliant#urn:mfin.gov.hr:cius-20
<b2g:SupplierInvoiceID>249-VP1-1</b2g:SupplierInvoiceID>
<b2g:BuyerID>9934:34808190853</b2g:BuyerID>
<b2g:InvoiceEnvelope>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPEludm9pY2Uge
Invoices and credit notes for public buyers (schools, kindergartens, hospitals, care homes) go to the government eInvoice service. Each document becomes a SendB2GOutgoingInvoiceMsg (9001) SOAP message with a HeaderSupplier header (SupplierID 9934:OIB), a B2GOutgoingInvoiceEnvelope and the UBL eInvoice in base64, matched by invoice number. There is also a GetB2GOutgoingInvoiceStatusMsg (9011) status query per invoice and an EchoMsg (9999) connection check, all following the FINA schemas in the project.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:efis="http://w
<soapenv:Body>
<efis:EvidentirajERacunZahtjev efis:id="DO-FISK-2026-10-01">
<efis:Zaglavlje>
<efis:datumVrijemeSlanja>2026-10-01T20:00:00.0000</efis:datumVrijemeSlanja>
<efis:vrstaERacuna>I</efis:vrstaERacuna>
</efis:Zaglavlje>
<efis:ERacun>
<efis:brojDokumenta>240-VP1-1</efis:brojDokumenta>
<efis:datumIzdavanja>2026-10-01</efis:datumIzdavanja>
<efis:vrstaDokumenta>380</efis:vrstaDokumenta>
<efis:valutaERacuna>EUR</efis:valutaERacuna>
<efis:datumDospijecaPlacanja>2026-10-16</efis:datumDospijecaPlacanja>
<efis:vrstaPoslovnogProcesa>P1</efis:vrstaPoslovnogProcesa>
<efis:datumIsporuke>2026-10-01</efis:datumIsporuke>
The same export produces EvidentirajERacunZahtjev requests for fiscalising outgoing eInvoices, one per issue day (up to 100 invoices). Each has a header, issuer and recipient (OIB), amounts, VAT breakdown and lines with KPD classification. It also produces EvidentirajNaplatuZahtjev payment reports per payment day (paid invoices only) and the outgoing invoice ledger (CSV). The access point signs each request (XAdES) when it is sent.
Customers also get a readable copy of the eInvoice: a PDF visualisation with a HUB3 barcode (only where the customer pays), a verification QR code and the VAT breakdown. The PDF is digitally signed (PAdES) and sent by email. Customers without an email address get a printed copy from a single print file, and invalid ERP records are not sent to anyone.
Kodabit Studio is based in the EU. If you use the form or write to us, we use your details only to reply. This site sets no cookies and loads nothing from other companies. We count visits in a simple way that stores no IP addresses. kodabit.info@gmail.com