A/P-A/R accounting > Inquiries > Customer aged bal. to date 

This function is used for a given reference date to retrieve the accounting balance for this reference date.
The reference date therefore plays an important role because the accounting information is retrieved how it was on that date.

This inquiry can also be a useful work tool in the tracking of customer open items. It can be accessed in two ways:

  • via the menu < P/L and S/L accounting \ Inquiries \ Customer aged balance at date >
  • from the customer or supplier record via <Tool bar\Inquiries\Customer aged balance to date>.

SEEWARNING This function enables the retrieval of the balance to date, but does not process every case.The historization of the open items is based on the flows in the modules upstream of the Financials module; the exclusively accounting events such as manual matching/unmatching, do not strictly fulfill the historization criteria.
That is the reason why an invoice manually matched with two not-posted payments at different dates will be considered as closed on the earliest date of the two, not successively and gradually on the date of the two payments.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

This inquiry is carried out on a single tab.

Update technical principles for the open item Historization Table.

The historization table for open items HISTODUD is used by the inquiry functions of aged balance at date (CONSBAH and CONSBAHF) and by the report of the aged transaction balance BALAGEHIST.
This table is updated at each open item creation, and then at each open item update.

Not all fields defining an open item, are historized. Actually, updates for the payment method, the PA level and the data linked to reminders are not traced.

In the HISTODUD table, the main fields to be used are:

  • the event date (DATEEVT) that corresponds to the accounting date at which the event took place.
  • the open item status (DUDSTA) which specifies whether an open item is linked to a posted document or just to an entered document (for example, an entered invoice that was not posted).
    • DUDSTA=2 if the open item is associated with a posted document,
    • DUDSTA is different from 2 if the open item is associated with a not-posted document. the BP and the open item control accounts (BPR and SAC) that include the BP and the control account on which the open item is posted.
  • The Closed field (FLGCLE) defining the open item with respect to its closing, can take the following values:
    • if FLFCLE=1 or 0, the open item is not paid/closed or partially paid/closed,
    • if FLGCLE=2, the open item is permanently paid/closed (AMTCUR open item amount = PAYCUR and AMTCUR posted paid amount<>0; or AMTCUR=0 and open item amount AMTLOC = PAYLOC posted paid amount),
    • if FLFCLE=3, the archived open item is deleted,
    • if FLGCLE=4, the open item is temporarily paid/closed (AMTCUR open item amount = PAYCUR posted paid amount + paid amount not yet posted TMPCUR).

Details on the Event Date area

A - Regarding invoice posting, the event date corresponds to the invoice accounting date.

B - Regarding partial or complete matching of open items (via the direct posting of open item payment or the accounting matching), for the paid open item(s), the event date corresponds to the most advanced accounting date of the group documents at the time of matching.

Example:
Let us consider:

  • a prepayment occurred with T1 as accounting date,
  • the posting of an invoice with T2 as accounting date,
  • the posting of the prepayment recovery on the accounting date T3.

The group documents will be regarded as closed on DATEVT= most advanced accounting date of the group documents, hence T3.

Regarding partially or totally closed open items (hence associated with an entry line using lower or upper case matching code), the event date kept for each matching, corresponds to the most advanced accounting date of the group documents at the time of matching (hence on MTCDATMAX of GACCENTRYD).

SEEWARNING Depending on the matching method, the updates of the HISTODUD table and of this event date can vary.

Example:
Let us consider a 1.000 € invoice posted on T1 date, followed by two payments on T2 and T3 dates:

  • one payment for 600 € with T2 as accounting date,
  • an other payment for 400 € with T3 as accounting date.

Two different cases should be considered:

  • the invoice is first partially paid for 600 (payment posted on T2), then closed with the 600 payment (posted on T3),
  • the three documents are separately posted and matching is performed later on, via the accounting matching (LETTRAGE or LETTRAUTO functions).

In the first case, the history mentions the matching processes:

  • for T1 reference date, the invoice is displayed with its total amount,
  • for T2 date, the invoice is displayed with a 400 € balance,
  • on T3 date, the invoice is not displayed.

In the second case, since it is manual matching for three accounting documents, the event date is also the most advanced date, but the result is slightly different:

  • for T1 reference date, the invoice is displayed with its total amount,
  • on T2 date, the 1000 € invoice with its total amount, as well as the 600 € payment are displayed,
  • on T3 date, the invoice and payment do not appear anymore.

SEEINFO  The outcome of the first scenario is the same via the accounting matching, if the invoice and the 600 € payment are matched in a first step.The matching group of two documents with the 400 € payment are then matched in a second step. 
These steps are made possible as the matching history can be retrieved by the user via the hierarchy of manual matching steps.

C - Regarding control account transfers, no record is created, since the previous ones are updated for the control account code and that the event date remains the same.

D - Regarding BP fusions, the principle is the same as for the control account transfer: no record is created in the HISTODUD table, but the existing records are simply updated and the event date remains the same.

Header

Presentation

In the header, specify the necessary fields, this information will be displayed in the Aged balance grid. You must at least enter the BP field.

Close

 

Fields

The following fields are present on this tab :

Selection

The information to be shown on screen are refined by entering a Company / Site or a group of Companies. The site is optional.

  • The field Company can include a homogeneous or heterogeneous group of Companies.
  • If the field Company is left empty, the search will be carried out on all Companies.

Enter or a site or a group of sites to narrow down the research. If you do not specify a site, the research will be performed on all the sites of the specified company.

  • field DAT

This field is used to specify a reference date: the time ranges will be calculated from this date.

  • Function (field FNCCNT)

This drop-down menu is used to select the contact function.
Changing the function makes it possible to display the name and telephone number of the first contact associated with this criteria.

  • Contact (field CNT)

This automatic field indicates the main contact person for the displayed BP, along with its title and telephone number.

  • Telephone (field TEL)

Telephone number.

The format depends on the country.

Other criteria

  • Control (field COLLEC)

When you fill in the Group or Control group field, in order to have useful information, the Aged balance grid displays the Bill-to BP and Pay-by BP information. The cases of compensation between customers and suppliers are excluded from the functional fields of this inquiry.

The groups can be used in account inquiry mode or in certain reports.

 

You must necessarily enter the BP. The field Payment BP field is then automatically filled according to the customer record setup.

This field is populated if you have entered the BP.

Close

 

Tab Aged balance

Presentation

This tab is used to view all the columns that are used to display the open items balance. Following the screen setup, the totals are displayed in either transaction currency or local currency. Only the "Total in local currency" column (or "Total in transaction currency") cannot be set up and is always displayed in the exchange value. For example, for a Aged balance screen where the open items are presented in "local currency", this column will display the open item total in "transaction currency"; conversely, the Aged balance screen where the open items are presented in "transaction currency", will display this column the open item total in "local currency".

Open item display

The reference date is the date from which the BP situation should be fixed. It is the date from which the amounts of the open items not closed on this date, are dispatched into the interval columns based on their due dates.
Example
Creation of an invoices for 01/07/04 for an amount of 1000 EUR.
Creation of a credit note matched to the invoice for : 05/07/04 for an amount of € 200.

CASE 1: Inquiry on the reference date 30/06/04

Document no.

Amount

Paid

None

-

-

 

 

 

CASE 2: Inquiry on the reference date 02/07/04

Document no.

Amount

Paid

Invoice

1000

 

 

 

 

CASE 3: Inquiry on the reference date 06/07/04

Document no.

Amount

Paid

Invoice

1000

200

 

 

 

"Total" block

This block contains: 

  • a total amount
  • a total by interval
  • the part in % for each interval

Only the totals for the first seven intervals are displayed. The general total takes into account the totals from the nine interval columns set up in the general parameters STRINT1 to 9.

Close

 

Fields

The following fields are present on this tab :

Grid Details

Choice of the expenditure type: there are 3 types of expenditures in the Integrale documents.

  • Freight: LPV_POR table associated with a product with a "PO" nature.
  • Miscellaneous expenditures: LPV_FRA_DIV table associated with a product with a "FR" nature.
  • Fixed expenditures: LPV_FRA_FIX table associated with a product with a "FR" nature.

  • Order no. (field NUM)

Invoice number.
This number is used to identify the invoice in a unique way. It is entered upon each creation or automatically generated depending on the counter associated with the invoice type.

This code is used to identify the currency for a site, BP, etc. It is managed in the currency table.
The currency proposed by default is that of the budget.
The exchange rate type applied is based on the BUDTYPCUR - Budget conversion rate type (BUD chapter, CMM group) parameter setting.

SEEINFOIt is recommended to use the ISO coding during the creation of a new currency.

  • Due date (field DUDDAT)

Open item payment due date.

If the MAXPD - Maximum period (companies) activity code is activated, a blocking message is displayed if the last due date is greater than the period specified, depending on the case, at the level of the following parameters or of the Contractual period possibly specified at the BP level.

Code identifying the BP that can have various roles based on the context:

Paying customer loaded by the bill-to customer.

  • Accounting date (field ACCDAT)

This date represents the accounting date of the original transaction.
The accounting date makes it possible to determine the posting period of the accounting entries. It is initialized by default to the current date and it can be changed depending on the value of the PIHACCDAT - Accounting date modification parameter (ACH chapter, INV group).
This date is systematically controlled in order to verify that it belongs to an open and existing fiscal year.
If a problem occurs during the control, the user will need to enter a new date, irrespective of the parameter value.

 

  • Source document (field BPRVCR)

It is the number printed on the supplier invoice. A check accompanied with a warning message is carried out so as to avoid entering the same number several times. This field can be deactivated by the entry transaction.

  • Document date (field BPRDATVCR)

 

 

  • Internal number (field ACCNUM)

 

  • Paid (field PAYCUR)

Amounts of the payments or equivalent (matching) having gone through the first posting phase, expressed in transaction currency.

  • Company paid (field PAYLOC)

Amounts of the payments or equivalent (matching) having gone through the first posting phase, expressed in the bookkeeping currency.

Enter the site code.

  • field AMTCUR1

 

  • field AMTLOC1

 

  • field AMTCUR2

 

  • field AMTLOC2

 

  • field AMTCUR3

 

  • field AMTLOC3

 

  • field AMTCUR4

 

  • field AMTLOC4

 

  • field AMTCUR5

 

  • field AMTLOC5

 

  • field AMTCUR6

 

  • field AMTLOC6

 

  • field AMTCUR7

 

  • field AMTLOC7

 

  • field AMTCUR8

 

  • field AMTLOC8

 

  • field AMTCUR9

 

  • field AMTLOC9

 

  • field AMTCUR10

 

  • field AMTLOC10

 

  • Transaction currency amount (field AMTCUR)

Amount expressed in the selected transaction currency.

  • Local currency amount (field AMTLOC)

 

Totals

  • field LIBTOT1

 

  • field AMTTOT1

 

  • field PER1

 

  • field POUR1

 

  • field LIBTOT5

 

  • field AMTTOT5

 

  • field PER5

 

  • field POUR5

 

  • field LIBTOT2

 

  • field AMTTOT2

 

  • field PER2

 

  • field POUR2

 

  • field LIBTOT6

 

  • field AMTTOT6

 

  • field PER6

 

  • field POUR6

 

  • field LIBTOT3

 

  • field AMTTOT3

 

  • field PER3

 

  • field POUR3

 

  • field LIBTOT7

 

  • field AMTTOT7

 

  • field PER7

 

  • field POUR7

 

  • field LIBTOT4

 

  • field AMTTOT4

 

  • field PER4

 

  • field POUR4

 

  • field LIBTOTLOC

 

  • field AMTTOTLOC

 

  • field POURTOT

 

 

Close

 

Action icon

Document

Displayed in the dialogue box are the contents of the "Original document" column. This right click makes available information without scrolling or without integrating the "Original document" column to the inquiry.

Invoice Inquiry

It is possible to pass to the original invoice: BP, sales or purchase invoice.

Journal Inquiry

This right click makes it possible to zoom on the associated accounting document.

Payment inquiry

This click choice only appears if the open item has been the object of a payment. Makes it possible to zoom to the original payment.

 

Close

 

Menu Bar

Gives access to other inquiry criteria that are in part displayed at the top of the inquiry screen :

  • the company and the site as well as the Reference date. Checkboxes are used to refine the inquiry and specify whether simulation documents and/or not-posted payments (payments entered, allocated but not posted yet) should be taken into account.
    As the user generates the aged balance at date (or the report "customer aged balance at date" BALAGEHIST) to cross the results with the auxiliary general balance on control account (or the report "auxiliary general balance" BALGRPAUX), these criteria must be specified to ensure the comparison consistency.
    The documents in active simulation are systematically taken into account for the update of the general balance (whereas the documents in inactive simulation are never taken into account).
    As a consequence, if the results of the inquiry on the aged balance at date must be compared with the BALGRPAUX report, then these entries must be taken into account.
    At the level of the aged balance history, the documents in active simulation are systematically taken into account (whereas the documents in inactive simulation are never taken into account).
    So, if the aged balance at date (inquiry or report) must be compared with the auxiliary general balance (inquiry or report), the criterion to take into account the not-validated payments is not kept.
  • Two sorts are submitted (by Open item date or by accounting date) as well as the display order of the information (Ascending/Descending).
  • Possibility to call another Aged balance screen via the field Screen code.
  • The Intervals table is used to define or modify on the fly the interval ranges for the aged balance, expressed in numbers of days. The fields are only accessible based on the interval range number declared at the level of the setup of the inquiry screen. The ranges submitted by default are recovered from the STRINT1 to STRINT9 parameters.

Menu Bar

Tunnel/Payments

Via the Tool Bar it is possible to directly access the Payment entry function. If the user setup TRANSREG is assigned, the tunnel takes the user directly to this transaction; conversely, if the setup is empty, the transaction selection screen is displayed.

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation