Factoring company

The voucher type that is used for exchange rate variations on payments when Currency no 2 is used, and you do not want to use standard agio/disagio general ledger accounts which are defined in the agio voucher type.

To be able to load OCR transactions from several bank accounts for a client, you must define which bank account is to be used.

This field is used when importing incoming payments from Visma.net AutoPay, and by some external EFT systems.

If this field is filled in, the CID is filled in with preceding zeros. This field is only read by some EFT systems. On invoices,Transfer to debt collection and List debt collection related transactions the company number must come first in the CID code; otherwise the cust. no, invoice number and check digit must come first.

How many digits the cust. no. part of the CID code is to consist of. The cust. no. part may be up to 10 digits. If the cust. no. is shorter, leading zeros are inserted. If it is longer, the digits are counted from the back and the internal OCR routine will not work to find the cust. no. The field is used by some EFT systems.

How many characters are to be used from the Factoring ID field between the customer and reference number parts of the CID code which is produced with the CID code macro in order documents, reminders and interest forms. See the description of the @CID macro in the chapter on order documents in the system specification for logistics, or the chapter on reminders and interest calculation in the system specification for accounting.

The field is used by some EFT systems.

How many digits the reference number part of the CID code is to consist of. The reference number part may be up to 9 digits. If the reference number is shorter, leading zeros are inserted. If it is longer, the digits are counted from the back and the internal OCR routine will not find the invoices that are to be matched. The field is used by some EFT systems.

Valid values are:

• 2. Has agreement without notification
• 3. Has agreement with notification

In the print dialog box for invoicing and In the dialog boxes for processings Factoring, Transfer to debt collection, List debt collection related transactions you only bring up valid values on the basis of what you have selected in the Fact. processing field.

This information is also used by EFT systems. When the row shall be used as a CID definition for incoming payments, OCR Definition must be selected in the Fact. processing dialog.

Type

Factoring company

OCR Definition

Must be set if the row is a CID definition that shall be used when importing incoming payments.

Debt collection list

Debt collection list changes

Autogiro

Avtalegiro

Generate voucher at Direct debiting receipt

If you have selected the Autogiro or Avtalegiro in the Fact. processing dialog box, the fields under Generate voucher at Direct debiting receipt in the same dialog box become activated.

Do not create voucher before payment of agreement

If you select this field the voucher for Autogiro/AvtaleGiro is created before payment agreement. This selection can be used for example for debiting of voluntary memberships.

Look for new payment agreements

This selection can be used when payment agreements are generated for the bank. Only special formats open for this option. Function for sending new Autogiro agreements, this selection does not apply to AvtaleGiros.

Create payment file from payment agreements

If you select this field, a dialog box appears for selecting the date for which agreements will be imported into transfer funds when exporting.

Ask for number of days at next payment

If you select this field, you will be asked about the number of days at next payment agreement.

Generate CID exchange file

The definition in this field is used by the @CID macro in order documents when factoring is selected in the order document dialog box.

The default CID code is Customer no. + Factoring ID + Invoice no. + Check digit.

Field length

In the same way as with the macro functions in the Form element table, you can, before the right bracket, include a vertical line (|) followed by an integer which indicates the number of characters the field is to have.

• If the number of characters is less, leading zeros are added.
• If the number of characters was less, the characters are kept from the back.

This applies regardless of whether the macro function returns numbers or text.

@Modulus ()

This macro function returns a modulus 10 check digit, or a modulus 11 check digit. If 11 is entered as the parameter for the function. The check digit is calculated from numbers that comes earlier in the field.

For factoring the factoring company is entered as a customer and you refer to this customer in the Factoring customer field. This cust. no. will be used in the voucher lines for orders. The field can also be used in debt collection routines to upload information to the debt collection agency from this cust. no. in the EDI file.

Only used by processings Factoring, Transfer to debt collection and List debt collection related transactions.

You can also use the field for a different fixed value that is to be included in the CID code and that is not defined elsewhere.

Please refer to the ConvertX documentation for the syntax.

This field has no function in Business NXT.

The default files are in the Program files/imp folder. The import file is the file that describes the format in which data is to be saved. Select the import file that has been set up for the factoring company or debt collection company that you are to send the data to. This field is only used by processings Factoring, Transfer to debt collection and List debt collection related transactions.

The date is set by the system.

The date is validated using the regional settings in Windows.

This field is automatically updated.

In this field you can define another length for the invoice number than the one defined in the CID ref. no. digits field.

The system displays this name in the dialog box when you run the factoring routine. The field is used by some EFT systems.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When importing incoming payments from Visma.net AutoPay, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the bank account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

Through the dialog box you can override the parameters found in EFT processing field in the EFT information table.

CID code generating

No leading zeros in customer/supp. no.

The customer/supplier number parts in the CID codes will not be completed with leading zeros when the number of digits is less than that stated in the CID cust./suppl. chars. field. This is normally used together with the Length digit check box in Swedish payment transfer.

Length digit

A length digit will be included before the check digit which shows the last digit in the total number of characters in the CID code (including the length digit and check digit). (The length digit is also included in the check digit calculation.) This is used in Swedish postal giros, among other things.

Finnish CID calculation

Modulus 10 check digits will be replaced by the algorithm for Solo reference payments. This is used in Finland.

Invoice no. first

The default CID code will be generated with the invoice number first. The order will then be as follows:

Invoice reference + Factoring ID + Customer number + Control digits.

The system will then produce a reversed CID code in connection with invoice printing and on importing OCR files. This enables the CID code to be imported in other accounting systems which expect an OCR with invoice number + customer number or receive OCR produced from accounting systems which have the invoice number before the customer number.

Note:

You must not use this parameter together with No leading zeros in customer/supp. no.

This field is also included in the Factoring company table and is activated when using Def. Factoring companys/CID code def.

Use customer no. as CID

You will only get the customer number and check digit in the CID code when you print invoices, interest notes and reminders.

Use Invoice no. as CID

You will only get the invoice number and check digit in the CID code when you print invoices, interest notes and reminders.

Payment suggestion

Payment if giro no.

Create payments only for transaction where Bank account or Postal giro is specified in Associate table, or Bank account is specified on the Open supplier entry.

Use bank partner from supplier/customer

Used as default value for the corresponding field in the Create payment suggestion processing dialog.

Processing when importing from EFT system

Prepayment

Some external EFT system processes OCR transactions for a specified series of advance payments that do not have open entries, but only advance orders that have not been invoiced. The order will be looked up and the suspension on the advance payment will be lifted when this payment is updated. You will find more about advance payments in the section about Advance payment.

Update bank account

Some EFT systems updates the bank account/postal giro for suppliers/customers if the format contains sufficient information to find suppliers/customers with an advanced search.

Generate batch/vouchers for settlement

The batch is created by the EFT system when the settlement is returned, and you cannot use the Create account batch processing in the Payment line table.

Control EFT system at payment

Control CID when importing

The CID code will be checked during data import.

Control if invoice no. is in the CID field

This field is used when the CID code field does not contain a complete CID code. This is common for payments from Sweden.

Only show CID sum

Only the sum per account is shown on the CID report.

Look up in open entries table

Search in open customer entries

Used by some EFT systems. Search for transactions will be done in the Open customer entry table.

Search in customer transactions

Used by some EFT systems. Search for transactions will be done in the Customer transaction table.

Search in open supplier entries

Used by some EFT systems. Search for transactions will be done in the Open supplier entry table.

Search in supplier transactions

Used by some EFT systems. Search for transactions will be done in the Supplier transaction table.

Matching rules

Invoice no. = one invoice

A search will be performed for invoice numbers in the invoice number field or the CID field in the file, and a row will be entered with the amount that has been paid.

Transaction info = Sum invoice

A search will be performed for invoice numbers from the text field in the file, and rows will be entered for the invoice numbers that are found. The outstanding amount will be entered as a separate row without a reference.

Customer no. + Amount = One invoice

A search will be performed for invoice numbers based on customer number in the customer number field or the CID field in the file. This rule will only add a row if the amount paid is equal to an open entry.

Transaction info + Customer no. + Amount = Sum Invoice

A search will be performed for all available invoices for customer numbers found in the text field in the field, and all the invoices will then be settled with the amount that has been paid.

Account no. + Amount = Sum Invoice

A search will be performed for all customers which have specified account numbers and open entries. The EFT system will then begin to settle the invoices that are found from the oldest invoice onwards.

Posting

Bank transaction per date

The bank transactions will be posted per date.

Bank transaction per Archive reference/batch

The bank transactions will be posted per archive reference/batch.

Bank transaction per transaction reference

The bank transactions will be posted per transaction reference.

Post rest amount in own customer record when invoice reference is missing

The outstanding amount will be posted if no references are found. If you have not selected this field, the outstanding amount will be settled against open entries according to the oldest date first.

Post difference record per processed record

Difference record per payment with a payment difference is produced.

Use open entries table for difference record

This field is not in use.

Use Cross reference table when paying

The Cross reference field is not used on the voucher line, but the Cross reference table is used instead when you are creating payments.

Use cross reference table when receiving payments

The Cross reference field is not used on the voucher line, but the Cross reference table is used instead when you retrieve OCR data.

For example CustNo <> 12345. This means that you omit all customers aside from cust. no. 12345. It is only cust. no. 12345 who will be automatically reconciled.

We refer to the documentation from Z Data which uses this field.

To be able to load OCR transactions from several bank accounts for a client, you must define which voucher series the OCR transactions are to use. This field has no function in Business NXT, but is used by some external EFT systems.

With longer text messages, the text will be wrapped on specified words.

With longer text messages, the text will be wrapped on specified words.