Include in report

Overview

The includeinreport field on voucher rows controls whether a transaction appears in reports. Its value is not always determined by what you explicitly pass — the Next Project backend applies business logic that can override your input under certain conditions.

Three fields interact to drive this behavior:

• includeinreport - Whether the row appears in reports (true / false)
• voucherid - Attachment linked to the voucher row
• scannedurl - Document link

The key rule: the backend can promote false → true, but never demotes true → false.

POST /voucher/row — Creating a Row

• Scenario 1 - No includeinreport, no voucherid, no scannedurl → Resulting includeinreport = false (default)
• Scenario 2 - voucherid or scannedurl present; includeinreport omitted or false → Resulting includeinreport = true (backend overrides)
• Scenario 3 - includeinreport: true (regardless of other fields) → Resulting includeinreport = true

Key point for POST

If you include an attachment (voucherid or scannedurl), the backend ignores your includeinreport: false and sets it to true instead.

PUT /voucher/row — Updating a Row

• Scenario 1 - includeinreport present (any value) → Resulting includeinreport = Exactly what you passed - no override
• Scenario 2 - voucherid and/or scannedurl present; includeinreport omitted → Resulting includeinreport = true (backend overrides)
• Scenario 3 - None of the three fields present → Resulting includeinreport = Unchanged - whatever was on the row before

Key point for PUT

If you explicitly include includeinreport in the body, it is written as-is - the backend does not override it, even if voucherid is also present.

Non-Intuitive Behavior: POST vs PUT with Conflicting Values

This is the most important difference to understand:

Scenario: Body contains includeinreport: false and voucherid: 123

• POST - includeinreport = true (business logic overrides the false)
• PUT - includeinreport = false (explicit value wins; no override)

The same request body produces opposite results depending on the HTTP method.

Decision Guide

Do you want includeinreport = true?

You can guarantee this by:

• Passing includeinreport: true in either POST or PUT
• Passing voucherid or scannedurl without an explicit includeinreport: false in POST
• Passing voucherid or scannedurl without includeinreport in PUT

Do you want includeinreport = false?

• POST: Pass no voucherid and no scannedurl, and either omit includeinreport or set it to false.
• PUT: Explicitly pass includeinreport: false in the body. This overrides any backend logic, even if voucherid is present.

Do you want to leave the existing value unchanged?

• PUT only: Omit all three fields (includeinreport, voucherid, scannedurl) from the request body.

Summary of Business Logic

POST:
explicit true → true
no explicit + (voucherid OR scannedurl) → true (backend promotes)
no explicit + no attachment fields → false (default)

PUT:
explicit value present → use it as-is (no override)
no explicit + (voucherid OR scannedurl) → true (backend promotes)
none of the three fields → no change (row keeps existing value)

Note: The backend only promotes false → true. Once a row has includeinreport = true, no API call will set it back to false unless you explicitly pass includeinreport: false in a PUT request body.