ENTRY POINTUnder review

F060LOOP

ExecBlock("F060LOOP", .F., .F.)

Receivable filter associated with FINA060/FINA061. Listed call, pending contract and an isolated example for checking a selection rule.

F060LOOPFINA060FINA061

01 · OVERVIEW

Overview

The official index classifies F060LOOP as a receivable filter in FINA060/FINA061 and leaves its specific page under construction. (TOTVS, n.d., ref. 1) The call listing records ExecBlock("F060LOOP", .F., .F.) in both routines. (TOTVS, n.d., ref. 2) It does not show the expression consuming the return value, active alias or selection timing. It therefore does not establish that .T. includes a receivable or .F. terminates processing. This page is under review, based on indexed evidence with restricted full access. The example exercises a fictional rule outside the entry point to help check expected results.

02 · SYNTAX

Syntax

ExecBlock("F060LOOP", .F., .F.)

Parameters

Entry point context

UndocumentedContext to confirm

The listed call has no explicit fourth argument. PARAMIXB contents and available aliases are unconfirmed; the example array belongs solely to the exercise.

Return value

The type and meaning of the F060LOOP return are unconfirmed in the sources located. Logical values calculated by the helper do not establish the entry point contract.

03 · PRACTICAL EXAMPLE

Separate the selection rule from entry point integration

#Include "Protheus.ch"

User Function ExF060Loop()
    Local aCases := {{100, .T.}, {0, .T.}, {100, .F.}}
    Local nIndex := 0
    Local lEligible := .F.

    // Fictional rule: positive amount and local exercise authorization.
    // We neither read SE1 nor define the F060LOOP return value.
    For nIndex := 1 To Len(aCases)
        lEligible := aCases[nIndex][1] > 0 .And. aCases[nIndex][2]
        If lEligible
            ConOut("Eligible case in exercise")
        Else
            ConOut("Ineligible case in exercise")
        EndIf
    Next nIndex
Return

Expected result

The first case is eligible; the second and third are ineligible under the fictional rule. This does not demonstrate Protheus receivable selection behavior. Once the contract is confirmed, compare these groups against standard processing in a test environment. The example has not been compiled or run in Protheus.

BEST PRACTICES

Write expected rule results before connecting it to the entry point. Separate the business decision from adaptation to the actual contract.
Check the caller to determine whether it consumes the return per receivable, per set or otherwise. LOOP in the name does not prove invocation frequency.
Prepare scenarios with all, some and no eligible receivables; also check operation cancellation and reopening the screen.
Validate FINA060 and FINA061 separately and record invocation counts for each scenario.
Keep the rule free of writes while testing selection; preserve work areas if future implementation queries aliases.

COMMON PITFALLS

Returning .T. or .F. by analogy with another entry point without confirming caller semantics.
Treating a call without a fourth argument as a guarantee that PARAMIXB is empty.
Changing movements or writing receivables while the filtering hypothesis remains unverified.
Confusing the helper fictional rule with a functional collection batch requirement.