Document Action Effects Report: How NGB Models Business Flows

Most business applications start as CRUD.

Create a record.

Edit it.

Delete it.

Show it in a list.

That works for simple data management.

But serious business software usually needs a different model.

A business document is not just a row in a table.

It represents business intent.

Document → Action → Effects → Report

In NGB Platform, a business flow starts with a document.

The document can represent an invoice, a lease, a payment, an order, or another business event.

The important part is that the document has business meaning before and after the user acts on it.

Then the user executes a business action.

In NGB, documents can move through actions such as:

• Draft;


• Post;


• Apply;


• Mark for Deletion.

These actions are not just CRUD operations.

They represent business boundaries.

Actions create durable business history

A business action may create durable business history.

Depending on the document and the vertical, that history may include:

• Operational Register movements;


• Reference Register changes;


• Accounting entries;


• audit history;


• document relationships;


• reportable state.

But not every document creates every kind of effect.

Some documents create several effects.

Some create one.

Some posted documents create no register or accounting movements at all, but still represent an important business boundary.

That distinction matters.

Posting is not the same thing as “creating accounting entries”.

Posting is a document lifecycle boundary.

Effects depend on the document

In NGB, Operational Registers, Reference Registers, and Accounting are peer platform capabilities.

A document action may produce movements in any combination of them.

Or it may produce no register/accounting movements at all.

The platform should not force every document into the same shape.

A lease, an invoice, a payment, and an operational document can all have different consequences.

The important part is that the system preserves the business meaning of the action.

Reports should stay connected to the source

Reports should not be disconnected from the documents and actions behind them.

When users see a number, status, or result, they should be able to understand where it came from.

That means reports should stay connected to:

• source documents;


• business actions;


• durable business history;


• register movements;


• accounting entries when they exist;


• audit history;


• related records.

This traceability is part of the architecture, not just a UI feature.

The core idea

The core idea behind NGB Platform is simple:

Documents represent intent.

Actions create durable business history.

Reports stay connected to the source.

That is why NGB is built as a document-driven business application platform on .NET and PostgreSQL.

It is not a low-code CRUD generator.

It is not only an accounting platform.

It is a reusable foundation for building vertical business applications with catalogs, documents, actions, Operational Registers, Reference Registers, Accounting, audit history, reporting, metadata-driven UI, and traceability.

Links

YouTube video:

Website: