Skip to main content

Work

These are six production systems and integrations for a global manufacturing group that runs two ERPs. Stillmark’s principal led each one before the firm was founded. Client names are left out on purpose.

01 Payment files

Payment file automation

PAYMENT RUN ILLUSTRATIVE UNEXPORTED CHECKS VENDOR DOCUMENT DUE AMOUNT PREPARED BY RELEASED BY RELEASE THE SYSTEM PREPARES THE FILE. A PERSON RELEASES IT.

Situation

A manufacturing group ran two ERPs, Dynamics NAV and Business Central. Staff built bank payment files by hand from both. Every run depended on someone typing correctly and on one person knowing the process.

Approach

An n8n pipeline that produces ACH and check payment files for JPMorgan Chase directly from NAV and Business Central. The pipeline prepares the file. Finance reviews and releases it. A module of the internal operations portal, described below, later replaced the n8n pipeline.

Result

Payment files are repeatable and auditable. Separation of duties holds: the person who builds the file is not the person who releases it.

Stack

n8n, later Python and FastAPI, Dynamics NAV, Business Central, JPMorgan Chase ACH and check file formats

SOURCE n8n PIPELINE CONTROL DESTINATION export build review release 01 ERP NAV / BC 02 Staging n8n 03 File generation n8n: ACH, check 04 PEOPLE APPROVE Finance approval releases the file 05 Bank JPMorgan Chase

02 Expense to ERP

Expense to ERP integration

NIGHTLY LOAD LOG ILLUSTRATIVE RUNS STATUS ROWS LOADED LOADED LOADED NOT LOADED LOADED LOADED WHAT LOADED AND WHAT DID NOT, FOR EVERY RUN.

Situation

Expense reports lived in SAP Concur. They had to land in NAV, and someone re-keyed them by hand.

Approach

An Apache Airflow pipeline. It picks up SAP Concur exports over SFTP, decrypts them with PGP, and loads them into staging tables before they post to NAV.

Result

No manual re-keying. The pipeline runs nightly and writes a log, so anyone can see what loaded and what did not.

Stack

Airflow, SFTP, PGP, staging tables, Dynamics NAV

SOURCE AIRFLOW PIPELINE DESTINATION export encrypted decrypted post 01 SAP Concur expense export 02 SFTP pickup Airflow 03 PGP decrypt Airflow 04 Staging tables Airflow 05 Dynamics NAV nightly, logged

03 Dual-ERP portal

Dual-ERP portal

ONE VIEW ILLUSTRATIVE SEARCH RECORD A B B A A B B A FROM THE FIRST SYSTEM FROM THE SECOND SYSTEM

Situation

The business ran NAV alongside a second, industry-specific ERP. Users needed information from both and had to switch between two systems to get it.

Approach

A FastAPI and Redis backend that integrates both ERPs, and a web portal on top of it.

Result

One screen instead of two systems.

Stack

FastAPI, Redis, web portal, Dynamics NAV, second industry ERP

A manual step between two systems? Describe it in one email to info@stillmarksystems.com.

SOURCE ERPS BACKEND PORTAL read one view 01 Dynamics NAV ERP 02 Industry ERP second ERP 03 FastAPI + Redis backend 04 Web portal one screen

04 Shop floor

Shop-floor execution system

JOB EXECUTION ILLUSTRATIVE MATERIAL QUALITY OUTPUT LABELS POST LOT QUANTITY PICKED SCAN LOT OUTPUT SCRAP LARGE TOUCH TARGETS. ONE STEP AT A TIME, FROM MATERIAL TO POSTING.

Situation

Machine operators on a manufacturing floor needed to run each production job and have the results reach the ERP.

Approach

A touchscreen web application. An operator scans a badge and sees the job queue for their machines. The operator consumes raw material by lot, records quality and machine parameters, reports output and scrap, prints labels, and posts the journals to Dynamics NAV. A traceability view links the components, operations, and sales orders behind a production order.

Result

One system takes a job from raw material to posted output, with every lot traceable.

Stack

React, TypeScript, FastAPI, SQL Server, Redis, Dynamics NAV, label printers, Docker

OPERATOR ERP sign in pick job record post 01 Badge scan RFID sign in 02 Job queue per machine 03 Materials by lot 04 Output and scrap with quality data 05 Dynamics NAV journals posted

05 Operations portal

Internal operations portal

PRICE UPDATE ILLUSTRATIVE ITEM CURRENT NEW CHANGE STAGED, NOT LIVE REJECT ACCEPT NOTHING REACHES THE PRICING DATABASE UNTIL A PERSON ACCEPTS.

Situation

Pricing, customer service, supply chain, warehouse, and finance each did routine work against the same ERP data.

Approach

One web portal, with the menus each person sees set by an administrator. It handles price files, labels, item lookups, replenishment, delivery-date exceptions, and the ACH and check files that replaced the n8n pipeline. Price updates wait for someone to accept or reject them.

Result

Routine office work for five teams runs from one place, with a clear accept step before price changes take effect.

Stack

React, TypeScript, FastAPI, SQL Server, Redis, Dynamics NAV, Firebase Authentication, Docker

SOURCE PORTAL CONTROL DESTINATION upload review promote 01 Price workbook Excel upload 02 Staging held, not live 03 PEOPLE APPROVE Accept or reject before promotion 04 Pricing database promoted

06 Inventory counting

Blind inventory counting

COUNT SHEET ILLUSTRATIVE LOCATION SESSION ITEM BIN COUNTED EXPECTED SCAN SAVE COUNT THE COUNTER NEVER SEES THE EXPECTED QUANTITY.

Situation

Warehouse counts needed to be accurate without the counter seeing the expected quantity.

Approach

A tablet application. Administrators define locations and open a count session. The system builds count sheets from an ERP inventory snapshot. Counters scan items and record quantity and bin, without seeing the expected figure. Administrators review variances, send items or bins for a blind recount, close the session, and export the results.

Result

Counts are blind by design, variances are reviewed before anything is accepted, and results leave as a file.

Stack

React, TypeScript, FastAPI, PostgreSQL, Redis, Firebase Authentication, Docker

SOURCE COUNT SESSION CONTROL DESTINATION stock scan review export 01 ERP snapshot on-hand stock 02 Count sheets no expected qty 03 Blind count tablet and scanner 04 PEOPLE APPROVE Variance review accept or recount 05 CSV export results file

07 Deliverables

What Stillmark leaves behind

Runbook.

Every system Stillmark touches gets a runbook the next person can follow.

Change log.

Every change is recorded with the date, the reason, and who approved it.

Monthly review.

Retained clients get hours used, open risks, and a review with IT management each month.

Named accounts.

Stillmark works only from accounts in your name, so ending the engagement means disabling them and nothing else.

See what a runbook and a monthly review look like

A manual step between two systems? Describe it in one email.