A warehouse receives a file of stock movements from several sites. The processing job finishes without a software error, but one site’s file is missing, several records contain unknown product codes, and a retried upload includes movements already applied. Whether the inventory figures are usable depends on how the system handles those conditions, not simply whether the program reached its final instruction.
Electronic data processing, usually abbreviated to EDP, uses computer systems to capture, check, transform, store, retrieve, and distribute information. The term includes familiar operations such as calculating totals, updating accounts, producing bills, and reconciling records. Its enduring purpose is to connect recorded events with dependable outputs that people and other systems can use.
Define the Business Event Before Processing It
For the warehouse, a stock movement needs a product, location, quantity, movement type, and an identifiable event. A receipt, transfer, adjustment, and dispatch have different effects. Treating all positive quantities as equivalent would obscure whether units arrived physically, moved between locations, or corrected an earlier count.
Specify the unit of each value. A quantity of ten could mean individual items, cartons, or kilograms. A date could describe when the movement occurred, when it was entered, or when the file was exported. Those distinctions affect the result even when the fields have valid types.
Inputs can arrive through forms, scanners, instruments, APIs, or files. The collection channel does not determine truth. A scanner can read a valid barcode attached to the wrong package; an API can deliver an outdated value. Processing needs a defined interpretation and an appropriate source of authority.
The production data-strategy article develops this agreement between producers and consumers. For EDP, it establishes what a record means before the system is asked to calculate or change anything from it.
Validate Structure and Business Conditions
Structural checks establish whether required fields exist and values use supported formats. Business checks can establish whether the product is known, the location is valid, and the movement is permitted under the relevant state. These are complementary checks, not interchangeable levels of certainty.
A negative quantity might be invalid for one input contract and valid for an adjustment event. Define that rule explicitly rather than applying a universal test based on appearance. Similarly, a correctly formatted customer identifier still needs to refer to the intended account if later processing will rely on it.
Separate acceptance from correction. A system may reject a malformed record, quarantine it for review, or apply an approved normalisation such as a documented unit conversion. Silently inventing a missing product or replacing an unusual quantity with an average can change the business event rather than repair its representation.
Preserve enough evidence to explain the disposition. A rejected movement needs a reason and a route to resolution. If it is later corrected, connect the replacement with the original without accidentally applying both. Validation reduces known errors; it does not prove that every accepted record reflects reality.
Transform Data With Identifiable Rules
Processing can calculate, classify, match, sort, aggregate, or convert information. The warehouse might apply accepted movements to a balance, calculate daily receipts, or group dispatches by site. Different outputs can use the same source records while answering different questions.
Rules need the context that makes them correct. A financial calculation may depend on currency, rounding, effective dates, and approved rates. An inventory calculation may depend on product units and which movement states count. Record the relevant rule version where a later investigation needs to establish what was applied.
Do not assume a summary is inherently more truthful than its inputs. A total can be calculated correctly while omitting a missing site or counting duplicated events. Useful information comes from a defined transformation over suitable records, with its coverage and limitations understood.
The data-analysis strategy guide explains how interpretation follows those transformations. Routine processing and analysis are connected, but a report showing what happened does not automatically establish why it happened or which intervention will improve it.
Choose Timing and Transaction Boundaries Separately
Batch processing handles a collection of work together, often under a schedule or submission boundary. A warehouse may import movements every evening, while a billing service runs invoices for an agreed period. AWS’s batch-processing explanation describes this grouped approach. It can be suitable when the result is not needed for each individual interaction immediately.
Interactive or low-latency processing serves a different timing requirement. A reservation service may need to respond before a customer can continue. “Real time” should be tied to the required deadline and behaviour when it is missed, rather than used as a general promise that processing happens instantly.
Transaction processing concerns controlled changes to business state. PostgreSQL’s transaction tutorial explains the all-or-nothing behaviour of a database transaction. Related changes can commit together or be rolled back, within the guarantees and scope of that database operation.
These categories overlap. A batch job can use transactions for individual items or groups, and an interactive service can run a transaction before producing a response. A database commit does not automatically include an external email, payment, or another independent service. The application must define how those effects are coordinated and recovered.
Reconcile the Work, Including Exceptions
Suppose an illustrative file contains 10,000 records. The system applies 9,980, rejects 15, and recognises five as duplicates already handled. These dispositions account for the file’s records, but the result is not equivalent to 10,000 newly applied business events.
| Disposition | Records | Follow-up |
|---|---|---|
| Applied | 9,980 | Verify relevant balances and totals |
| Rejected | 15 | Investigate and correct or close |
| Previously handled duplicates | 5 | Retain the link to the original outcome |
Record counts are only one control. Reconcile quantities, monetary totals, expected partitions, or other relevant measures. A missing site file can escape a count check limited to the files that happened to arrive. Distinguish processing completeness from delivery completeness.
Identify who decides whether unresolved work blocks publication. A provisional planning report may be useful with a clear warning, while an authoritative stock commitment may need stronger conditions. The status should reach the consumer, not remain visible only in an operator’s log.
Store Results That Can Be Retrieved and Explained
Persistent storage allows later work to build on earlier events. A system may retain source records, accepted transactions, current balances, and derived summaries. Each representation serves a purpose and needs a clear relationship with the others.
Use appropriate identifiers and integrity controls. An order referencing a product needs a valid relationship, while an event identifier can help recognise a repeated submission. The master-data-management article considers shared identities and attributes across systems. EDP depends on those meanings without necessarily owning every master record itself.
Retrieval also requires access and interpretation rules. A customer service screen may show one account, while a finance process retrieves a period’s transactions. A cached summary can improve access but should not silently be treated as current authoritative state when its update rules do not support that claim.
Outputs include screens, files, receipts, reports, notifications, and API responses. Test that the right recipient receives the right information, with suitable status and confidentiality controls. A correctly calculated result sent to the wrong customer is still a processing failure from the business’s perspective.
Recover Without Repeating the Wrong Effects
A timeout can leave the caller uncertain whether a movement was committed. Retrying the submission safely requires a way to recognise the same logical event and determine its existing outcome. The retry-policy article explains why retries need budgets, suitable errors, and protection against duplicate effects.
Batch recovery needs comparable care. Restarting from the first record may be appropriate when processing is idempotent or earlier changes were rolled back. Otherwise the job may need checkpoints and reconciliation. Define what a checkpoint proves and which effects could have occurred after it.
Backups support recovery from loss, but restoring a database to an earlier point can leave external systems ahead of it. Identify already issued payments, notifications, or transfers before resuming work. Recovery should re-establish a coherent service, not simply a running database.
The data-protection guide connects tested restoration with access, retention, and incident response. Processing records can contain sensitive information, so investigation and recovery should preserve needed evidence without creating uncontrolled copies.
Judge Automation by Its Accepted Outcome
Measure whether the expected events reached a defined result, how much correction was needed, and whether consumers could act appropriately. Throughput and job duration are useful operational measures, but neither establishes accuracy, completeness, or benefit on its own.
Electronic data processing remains recognisable inside modern databases, enterprise applications, queues, and APIs. Its reliability comes from the decisions around those components: what inputs mean, which rules apply, what state changes together, how unresolved work is represented, and how the organisation recovers when processing stops halfway through.
