Batch Processing

Everything batch-like that a user can trigger from the client, plus the visible traces of background processing. All client-triggered runs execute inside the user's session, single-threaded, row by row (loops with yield() calls and progress bars — e.g. u_progressbar in provider/w_hcn_enrollment_dump); there is no in-client job scheduler.

Important scope limit: any DB-server-side scheduled jobs (Oracle jobs, cron, a dedicated batch workstation) are invisible to this client-code analysis. Several subsystems clearly depend on such jobs — see the open questions.

Client-triggered batch runs

Claims / payments

Run	Trigger screen	What it does	Citation
Outbound claim EDI extract	clmutils/w_edi_outbound_edi_processor, button "Outbound EDI Process"	Loops all staged claims (d_edi_outbound_claims_to_process), explodes each into outbound_edi_* staging tables, then writes per-partner fixed-width files and purges staged rows; commits between phases	clmutils/u_edi_outbound_edi::of_load_claim/of_create_file
Inbound claim EDI (repricing responses)	Same window, "Inbound EDI Process"	Reads a user-selected fixed-width response file line by line, applies repricing, sends failures to hold/corrections (RFCP), writes a .bad error file	clmutils/w_edi_outbound_edi_processor::wf_process_file/wf_process_claims
Check/EOB reprint batches	reprint/w_reprint ("print queue manager"), reprint/w_reprint_maintenance	Selects sets of stored report_hist outputs (checks, EOBs, worksheets) and prints them in a batch	reprint/n_cst_reprint_func::of_print
Manual check + register archive	funding/w_fund_manual_check	Writes a single check, records it to report_hist, archives the register text to archive_dir\YYYYMM\	funding/w_fund_manual_check lines ~198, 274-310
PPACA letter generation	clmrpt/w_ppaca_letters	Generates a chosen letter for a claim/report selection	clmrpt/w_ppaca_letters

Billing

Run	Trigger screen	What it does	Citation
Bill run submission	billing/w_bill_run_def_maint ("Billing Run Maintenance. Submit/Maintain billing runs and definitions.")	Marks selected bill definitions for a bill date with status SUBMITTED (or DELAYED via checkbox); re-submission deletes previously produced charges and voids reports	billing/w_bill_run_def_maint lines ~382-390, 520-527, 771-777
Bill computation	(no in-client trigger found)	billfunc/n_billproc ("Functions for billing process, including computing bill, group, and member rates", of_bill(bill_run, bill_def, bill_dt)) contains the full rating/charge engine, but nothing in client source calls of_bill	billfunc/n_billproc line ~83; grep across _re/src
Bill output print	billing/w_bill_queue	Prints/deletes queued bill-run reports from the bill_reports store	billing/w_bill_queue line ~168

Enrollment / eligibility

Run	Trigger screen	What it does	Citation
HCN enrollment dumps	provider/w_hcn_enrollment_dump (submit button, progress bar, optional six-month scope)	Builds CIGNA file client-side; runs Aetna extract stored procedures (sfpidba.sp_aetna_enrollment / P_BUILD_AETNA) then writes AETNA<timestamp>.TXT; runs SP_MMO_ENROLLMENT on the warehouse connection	provider/w_hcn_enrollment_dump lines ~152-194, 279, 534
Group eligibility export	enroll/w_enroll_group_export	Writes a fixed-format eligibility file for one master group to enrolldump_path	enroll/w_enroll_group_export line ~149
PBM member transfers	drugplan/w_drugplan_report_transfer	Generates PCS / CVS-Caremark / RxBenefits member eligibility files (whole plan population per run)	drugplan/w_drugplan_report_transfer events ue_create_pcs_*
PBM accumulator flag files	provider/w_provider_caremark_flag_transfer, w_provider_optum_flag_transfer	Loops divisions/groups producing deductible/OOP flag files plus an audit report	provider/d_caremark_flag_file*, d_optum_flag_file*
Matria (disease mgmt) dumps	funding/w_burns_enrollment_dump, funding/w_burns_claim_dump, enrolrpt/w_dep_audit	Create Matria enrollment/claim files from the d_burns_* extract family	window comments; base/d_burns_*

Mass letter / document generation

Run	Trigger screen	What it does	Citation
HIPAA certificates — generate	enroll/w_enroll_hipaa_generate	For each pending row in hipaa_transactions, renders the certificate, saves it as a blob in report_hist (report_hist_seq.nextval, UPDATEBLOB), marks the transaction PROCESSED	enroll/w_enroll_hipaa_generate lines ~467-566
HIPAA certificates — print	enroll/w_enroll_hipaa_print	Batch-prints stored certificates, sets prt_flg = 'Y', supports purge of printed items	enroll/w_enroll_hipaa_print lines ~199-424
Custom termination letters	enroll/w_enroll_custom_term_generate / w_enroll_custom_term_print	Same generate-to-history-then-batch-print pattern (incl. USFHP variant)	enroll/w_enroll_custom_term_generate lines ~312-418
COBRA letters	cobra/w_cobra_printqueue ("Main Print Queue Screen for Printing of letters"), errors surfaced in cobra/w_cobra_letter_errors	Prints queued COBRA letters by letter type/group; unavailability letters generated by cobradw/n_cst_cobra_unavailability_letter_gen	cobra/w_cobra_printqueue; cobradw
FSA notices	enrollutils/w_fsa_notices	Flexible-spending notices and summary listings	window comment
Annual statements	enrolrpt/w_annlstmt	Generates annual employee statements for a group	window comment
USFHP ID card requests	idcard/w_enroll_idcard_usfhp	Processes ID card requests, generates request listing and accompanying letters	window comment

Banking

Run	Trigger screen	What it does	Citation
Positive-pay export	funding/w_pospay	Exports check-issue CSV files for the bank	funding/w_pospay lines ~275, 427, 694
Bank reconciliation import	funding/w_fund_bank_reconciliation_file	Reads the bank's reconciliation file and matches cleared checks	line ~359

Visible traces of server-side/background processing

• Background claims adjudication: clmutils/w_bkgd_monitor is a live monitor with panes for throughput, last claim processed, current locks, and claim status counts, each on a refresh interval — clear evidence of a continuously running adjudication engine outside this client (the engine itself does not appear in the 53 libraries). Confirmed by the user guide (User Guide ch. 22): claim lines created by the background process carry create_user_id = 'SFPIBACK' ("Rollback Claims Status" — rolling a claim back to RFCP requires deleting those lines), and the engine claims work by stamping CLAIMS.LOCK_SEQ_NO with a per-run lock sequence number ("Claims Locking During Background Processing", which also records the required LOCK_SEQ_NO IS NOT NULL predicate for index use). SFPIBACK appears in client code as a filter value (clmutils/d_bkgd_current_locks, clmshare/n_cst_return_claim_to_corrections), matching the guide.
• Bill runs: the client only sets SUBMITTED/DELAYED status; the computation engine (billfunc/n_billproc) has no in-client caller, implying a separate runner executes submitted runs and fills bill_reports.
• Check runs: report_hist rows carry check_number and batch_id, and the chkrundw library holds the check/EOB layouts (d_checkrun_eob*), but no client screen creates a check run batch — only reprint/copy paths use these layouts (clmprint/n_check_copy, reprint/w_reprint_maintenance). Confirmed as background processes by the user guide (User Guide ch. 22, "Altering Register/Check dates on Checkruns"): there is a "checkrun background process window" with an override date (used as Register Date, Check Date, Applied Date, First Register Date and Paid Date), and "the Funding routine and the register background process DO NOT look at dates on claims — they only look at today's date to decide which groups should be part of the run." Operating rule: a checkrun's check date may not be overridden to a date earlier than any existing committed register — the later run must be backed out first, then re-run.
• Batch report registry: batch_reports.allow_run_events/allow_times (maintained by homersys/w_batch_reports) describes event- and time-driven report execution with no corresponding client runner.
• Aetna / MMO extract builds run as database stored procedures invoked from the client (provider/w_hcn_enrollment_dump) — the procedure bodies are in the database only.

Guide-documented background jobs and separate executables

The user guide (ch. 22/23) names the background layer that the client-code analysis could only infer. The programming-standards chapter confirms the deployment shape: Resource\Background Processes on the network share holds "Executables for background processes" — separate PowerBuilder builds, not part of the 53-library extract (User Guide ch. 23, "Production Environment"). Known members and scheduled jobs:

Process	Runs where / when	What it does	Citation
Background claims adjudication	Continuous background process (separate executable)	Locks claims by LOCK_SEQ_NO, creates claim lines as user SFPIBACK, advances claim status; monitored by w_bkgd_monitor	(User Guide ch. 22, "Claims Locking…", "Rollback Claims Status")
Claims delete ("claims delta") process	Background process, once a day	Removes claims marked for deletion that are 60+ days old, deleting from 39 claim tables in a fixed referential order, nulling claim_eob_info_details.claim_id and setting dw_claim_trans.action_ind = 'D'; optional log delete_proc_log.txt gated by homer.ini flag claims_deleter_logging	(User Guide ch. 22, "Claims Delete Process")
Terminated-client claim purge	Automatic, 6 months after term/runout date	"System begins deleting claims for terminated clients six months after the termination date (or runout end date) is reached"; before that, claims are flagged "should be returned"	(User Guide ch. 22, "Terminating Clients")
Funding routine + register background process	Background processes	Select groups for the run by today's date against the funding/register schedule (not claim dates)	(User Guide ch. 22, "Altering Register/Check dates on Checkruns")
Checkrun background process	Background process window with date override	Produces the check run; override date becomes Register/Check/Applied/First-Register/Paid dates	(User Guide ch. 22, same section)
Warehouse procedural sync	cron on the Oracle server (dwall_night.sh 17:00-21:30 M-F claims; dwall_morn.sh 03:00-09:30 M-F claims+groups+members; dwall_sat.sh Sat 03:00-21:30), self-checking with e-mailed error reports	PKG_DW_SYNC reads DW_*_TRANS rows queued by TDW* triggers and pushes claim/group/member data to the SFPW warehouse over DB links; claims are locked during refresh; commit-count / row-count / end-time parameters	(User Guide ch. 22, "Data Warehouse Contents and Processing")
Warehouse snapshot refresh	cron on the warehouse server, Mon-Sat 05:00 (refresh.sh)	Oracle snapshot replication of lookup/reference tables	(User Guide ch. 22, same section)
Claim-ID counter reset	"Nightly cycle or … a Cron job on the Unix box"	Resets each claim-source's starting claim ID daily; claim IDs otherwise assigned from Oracle	(User Guide ch. 22, "Claim Numbering Scheme")
EDI Claim Processor	Separate PB application newedi.exe, run on demand	Loads translated EDI flat files and creates claims; submitter log; archive via arcfile.bat	(User Guide ch. 22, "EDI Processing"; see Integrations §10)
Address standardization batch	Separate executable Resource\Background Processes\Standardize Addresses\std_addr.exe, run on demand (e.g. before provider loads); guide also prescribes nightly batch address checking "on a machine specially designated to run nightly processes and timed to avoid the oracle backup cycle"	Standardizes address batches (option "Temp" for the provider-load work table)	(User Guide ch. 22, "Provider Updates", "Addresses")
Provider update load	Server-side SQL*Loader + SQL scripts (std_prov.sql, std_hosp.sql) with procedures Add_new_record, Report_error, Insert_provider_panel; restartable via LAST_SEQ_NO_TBL	Loads HCN provider files into STD_PROVIDER staging and applies add/match/consolidate rules	(User Guide ch. 22, "Provider Updates")
Nightly production print cycle	Nightly	Prints QMCSO and HIPAA letters from a request table. Neither the request table nor the job exists in the extracted client — letter production is external, as it is for COBRA notices	(User Guide ch. 1)
Nightly Wang enrollment transfer	Nightly (historical — Wang retired)	Enrollment changes queued by triggers into WANG_MEMBER_TRANS plus pending ID-card requests were written to a text file and FTP'd to the Wang	(User Guide ch. 22, "HP-to-Wang Synchronization", "Temporary Homer-Wang ID Card Printing")
Test-database refresh	On-request Unix scripts + Oracle procedures	Table-driven full/partial copy of production to test (REFRESH_* control tables, SP_POPULATE_REFRESH, full_refresh package)	(User Guide ch. 22, "Refresh Test Database Processing")

Requirements

• BAT-1 Long-running extract/import runs shall be executable on demand by authorized users, show progress, and report completion or per-row errors without terminating the whole run (w_edi_outbound_edi_processor, w_hcn_enrollment_dump progress bar, .bad error files).
• BAT-2 Batch runs that change claim state shall commit in phases and roll back the affected unit on error, leaving already-processed rows intact (w_edi_outbound_edi_processor — of_commit/of_rollback per phase).
• BAT-3 Bill runs shall be defined, submitted (optionally deferred), and re-submitted; re-submission shall void prior outputs and remove prior charges for the run (billing/w_bill_run_def_maint).
• BAT-4 Submitted bill runs shall be processed asynchronously from the submitting user's session, with outputs delivered to a reviewable queue (bill_reports / billing/w_bill_queue; processing engine external — see open questions).
• BAT-5 Mass document generation shall be a two-stage pipeline — generate into durable report history, then batch-print with printed-flag tracking and purge of processed source transactions (w_enroll_hipaa_generate/_print; hipaa_transactions.lock_cd = 'PROCESSED').
• BAT-6 Operations staff shall be able to monitor background adjudication health: throughput, last processed item, current locks, and queue/status counts, auto-refreshing on a configurable interval (clmutils/w_bkgd_monitor).
• BAT-7 Partner extract runs shall be idempotent per staging row (a claim can be staged only once; files only include rows not yet marked file_created) (claims/w_claim_editor dup check; u_edi_outbound_edi::of_create_file filter isnull(file_created)).
• BAT-8 The migrated platform shall provide a first-class scheduler to replace the implicit external mechanisms (check runs, bill run processing, background adjudication, time/event-driven batch reports), whose current implementations are outside the client codebase.
• BAT-9 Claims marked for deletion shall be physically removed by a daily background purge only after an ageing period (60 days), deleting all dependent claim rows in referential order and propagating the deletion to the reporting warehouse; the purge shall support optional per-machine logging of removed claims (User Guide ch. 22, "Claims Delete Process").
• BAT-10 Claims of terminated clients shall be retained through the termination/runout date plus six months, with claims received after term/runout flagged for return rather than processed, before automatic deletion begins (User Guide ch. 22, "Terminating Clients").
• BAT-11 Reporting-warehouse synchronization shall run on a schedule (nightly/morning/weekend windows), be bounded by commit count, row count and end time, lock each claim while refreshing it, self-check for errors and notify operators, and be runnable on request between scheduled windows (User Guide ch. 22, "Data Warehouse Contents and Processing").
• BAT-12 A committed check run shall block later runs from using an earlier check date; producing an earlier-dated run shall require backing out and re-running the later run (User Guide ch. 22, "Altering Register/Check dates on Checkruns").

Open questions

• Where do check runs, bill-run processing, and background adjudication actually execute today? — substantially resolved. The user guide (ch. 22/23) confirms they run as separate PowerBuilder executables deployed under Resource\Background Processes on the network share (plus Unix cron jobs on the Oracle server for warehouse sync and, per the guide, the claim-ID reset) — see the table above. The client-side monitor screen, status columns, and report layouts correspond to these. Still required before migration: inventory the actual executables in Resource\Background Processes (their source libraries are not in this extract — e.g. the adjudication engine, checkrun/register/funding processes, newedi.exe, std_addr.exe) and the live crontab on the database server.
• Volumes: client code gives no row counts; the only volume hints are UI affordances (progress bars, six-month limiter checkbox on the HCN dump, per-phase commits), suggesting runs large enough to need them. Obtain production volumes (claims/day, checks/run, letters/run) from operations.
• w_open_windowname / base library one-off DataWindows (e.g. d_in_ticket_1094, d_cvs_troubleshoot) look like ad-hoc support extraction tools; confirm which are still operationally required.
• Whether DELAYED bill runs are picked up by time (scheduler) or manually re-flagged is not visible in code.