ENTRY POINTPublished

MA261LIN

MA261LIN( <PARAMIXB> ) --> lRet

Validates each transfer line entered in the MATA261 browse.

Entry pointsInventoryTransfersMATA261ValidationLinhaOkProtheus 12

01 · OVERVIEW

Overview

MA261LIN is an entry point of the Transfer Model 2 routine (MATA261), located at the end of A261LinOk(). It allows additional validations to run for each transfer line entered in the browse. When it returns .T., the line is accepted; when it returns .F., validation fails and the user should correct the issue before continuing.

02 · SYNTAX

Syntax

MA261LIN( <PARAMIXB> ) --> lRet

Parameters

PARAMIXB[1]

NumericRequired

Number of the aCols line currently being validated.

Default:

Return value

lRet, logical. Return .T. to allow the transfer line to be included. Return .F. to reject the line and prevent continuation until the issue is corrected.

03 · PRACTICAL EXAMPLE

Minimum MA261LIN structure

#Include "TOTVS.ch"

User Function MA261LIN()
    Local lRet  := .T.
    Local nLine := PARAMIXB[1] // aCols line number

    // Additional user validations.
    // Example: inspect fields from nLine before allowing the transfer.

Return lRet

Expected result

The function receives the line under validation through PARAMIXB[1], runs additional rules and returns .T. to accept or .F. to reject the line.

04 · PRACTICAL EXAMPLE

Didactic controlled rejection example

#Include "TOTVS.ch"

User Function MA261LIN()
    Local lRet  := .T.
    Local nLine := PARAMIXB[1]

    If Empty(nLine)
        MsgAlert("Unable to identify the transfer line.", "MATA261 validation")
        lRet := .F.
    EndIf

Return lRet

Expected result

The example shows the return logic: when the rule finds an inconsistency, it displays a message and returns .F. to stop validation of the line.

BEST PRACTICES

Initialize the return value as .T. and change it to .F. only when a validation rule fails.
Store PARAMIXB[1] in a clearly named local variable, such as nLine.
Move larger rules to helper functions to keep the entry point readable.
Test inclusion, changes and multiple-line scenarios in MATA261 before releasing to production.
Document in customization comments which aCols field or position is being validated.

COMMON PITFALLS

Do not persist data inside the validation unless it is really necessary; the main purpose is to approve or reject the line.
Do not assume aCols field positions are identical across releases, customizations or scenarios.
Avoid excessive messages in per-line validations.
If the rule depends on specific fields, document exactly which positions/fields were considered.