Customer category

This is the category associated with the customer.
A customer category makes it possible to:

• have an additional customer classification,
• have default values upon creation,
• and assign an automatic numbering to customers according to a counter associated with the customer category.

A customer category can also be associated with a BP or a prospect, since prospects can become customers at a later stage.

This code is used to identify amongst other things, the Country of a BP.
This is important information, associated with a number of characteristics useful for performing controls on other linked information, in particular:

• the telephone number format,
• the format of the number that identifies a company or an activity (site tax ID number, NAF in France), and whether its entry is mandatory or not,
• the postal code format of the town and also the code of the geographic subdivision, and whether their entry is mandatory,
• whether the VAT number of this community is mandatory,
• the Bank ID code format.

This code is used to identify the currency of a site, a BP, etc. Is is controlled in the currency table.
 It is recommended to use the ISO coding upon creation of a new currency.

The customer type can take the following values: Normal or Miscellaneous.
The Miscellaneous type is used to cause the automatic opening of an address entry window for all the commercial documents (it is considered that these are 'cover-all' customers that are not distinguished in accounting).
The default category is Normal.

This field is controlled by a modifiable local menu and can take the following values: daily rate, monthly rate, average rate, DEB rate.
It is necessary to choose the exchange rate type that will be used to convert the amounts in currency.
The rate type suggested is that of the header.

Select the type of control that you want to apply on the customer credit amount:

• Controlled: The control is carried out in real time when creating the order, during the allocation and during the delivery, based on the authorized credit level. The customer can be delivered if their credit level is lower than their authorized credit level. This control can be performed:
• By company or by folder, based on the value of the general sales parameter OSTCTL - Credit control level (TC chapter, OST group).
• With an archived or updated (revised) rate, based on the value of the general Common Data parameter: OSTCHGTYP - Rate origin WIP ctrl. (TC chapter, OST group).
  If the control is performed based on an updated rate, the rate type to be used is the one set by the OSTTYPCUR - Rate type updated rate ctrl parameter (TC chapter, OST group).
  When the control on credit is done at the 'Folder’ level, the control is always applied based on the updated rate, regardless of the value of the OSTCHGTYP - Rate origin WIP ctrl. parameter.

The WIP is controlled with respect to the risk BP of the customer. If the risk BP is shared by several customers, it means that the WIP of each customer will be controlled the same way with respect to the risk BP by cumulating the total of the different customers movements.
When the customer is associated to a different risk BP, the amount of the authorized WIP cannot be accessed. It can be viewed on the risk BP record. The displayed WIP is the risk BP,

• Free: the customer can always be delivered.
• Blocked: the customer can no longer be delivered.

Maximum credit amount authorized for this customer. It is used if the customer is declared as ‘Controlled’ in the WIP control field. This amount is expressed in the currency of:

• The folder when the control is at folder level;
• The Common Data site of the user when the credit control applies at the company level.

Code making it possible to identify the ABC category of a business partner.
The ABC category is designed to classify business partners according to their importance in the turnover, for example.
Values between 'A' and 'D' can be entered. At the time of creation, the BP, having no statistical data available, is classified in category "D" by default.

Minimum tax excl. amount, expressed in folder currency, below which customer orders cannot be saved.

This information, initialized by the sold-to customer, is used to authorize or not the closing of a line or the order. This information is modifiable on order entry if the transaction allows this.

This information, initialized by the sold-to customer, is used to prohibit the grouping of several orders in the same shipment. This information is modifiable on order entry if the transaction allows this.

This information, initialized by the sold-to customer, is used to specify how the order is delivered. There are three possible values:

• Authorized means that the order can be partly delivered. 
• Complete line means that the order can be partly delivered if the complete line is delivered.
• Complete order means that the order must be delivered in full (a single delivery).

This also means that a partial allocation cannot be performed on an order line or order if the stock is insufficient to cover the full line or order: the Partial Allocations option must be displayed on the order or in the mass allocation options.When entering the quantity to be allocated to the line or when performing a Manual allocation on the line, a warning message displays if the delivery is partial.

Note: When you select Complete line or Complete order, you can ignore this warning message and force the partial delivery.

The value of this field (Ex-tax or Tax-incl.) is defined by the general parameter SALPRITYP - Price/Amount type (TC chapter, INV group).

When the general parameter NOTATI - Ex-tax and tax-incl. amount/price (TC chapter, INV group) is set to No you cannot modify this information.

Flag used to specify if freight must be charged to the customer or if the latter does not have to bear these charges. This exemption can be linked to no conditions at all or to a tax excl. or tax incl. threshold.
The freight calculated from the carrier price and integrated when delivering via a dedicated invoicing element.
 For more details, see the general setupFRENUM.
The thresholds are defined in the carrier record.

This information is initialized by the sold-to customer and is used to define the customer's invoicing mode. This invoicing mode is used subsequently to invoice the delivery notes or the direct invoicing orders by regrouping or splitting them. This information is used in the automatic invoicing processes and in the manual invoicing function (where a control is performed with respect to this information).

The available invoicing modes and their impact on the delivery invoicing are as follows:  

• 1 invoice / DN: This invoicing mode requires the existence of a separate invoice for each delivery created.
• 1 invoice / completed order: This invoicing mode only authorizes the invoicing of the deliveries associated with an order if said order is completed and all the invoices associated with this order are validated and all the deliveries belong to the automatic invoicing selection. A single invoice will then be generated grouping all the deliveries for the order.
• 1 invoice / order: This invoicing mode is used to create an invoice for all the deliveries of the order that are validated when the invoicing process is run. A single invoice will be generated grouping all these deliveries.
• 1 invoice / ship-to customer: This invoicing mode is used to create an invoice for all the deliveries concerning the same ship-to customer on a single invoice when the automatic invoicing process is run. There also is a control performed upon manual invoicing of the deliveries.
• 1 invoice / period: This invoicing mode is used to create an invoice for all the deliveries based on the invoicing frequency defined by the customer. For instance, if the frequency is weekly, all the deliveries during week 32 (relating to the shipment date or delivery date based on the INVREFDAT - Origin date for invoicing setup) are grouped on a single invoice. There is a specific feature linked to the invoicing frequency when the chosen value is upon request.Deliveries with this kind of frequency will be grouped together. A control is also carried out in manual delivery invoicing mode to only enable the grouping together of deliveries with an invoicing mode by period and a manual invoicing mode.
• Manual invoice: This invoicing mode is not considered in the automatic invoicing processes. Invoicing will be manual on invoice entry.

Impact of the invoicing mode on delivery generation: orders with an invoicing mode 1 invoice/order or 1 invoice/completed order will never be grouped on a same delivery.

Beside these invoicing modes, there are pieces of information that, if varying from one delivery to the next, prohibit the grouping together of two deliveries. Please refer to the automatic delivery invoicing.

The impact of the invoicing modes on the direct invoicing orders is as follows:

• 1 invoice / DN: This invoicing mode requires the existence of a separate invoice for each direct invoicing delivery. On the other hand, an order can be only partly invoiced by the automatic invoicing function from the moment that the order delivery mode is not Complete order.If the order delivery mode is Complete order,all the order lines will need to be invoiced (the stock-managed order lines will need to be allocated), otherwise the invoice will not be generated. On manual invoicing of an order of this type, there are no constraints with respect to the delivery mode, and it will be possible to draw up a partial invoice even if the delivery mode is Complete order.
• 1 invoice / completed order: This invoicing mode requires the existence of a separate invoice for each direct invoicing delivery. An order will have however to be fully handled in order to be invoiced using the automatic invoicing function. There will thus be only one invoice for this order. In manual invoicing it isn't necessary to follow this rule; it is possible to partially invoice an order of this type.
• 1 invoice / order: For the orders with direct invoicing, this invoicing mode corresponds to the invoicing mode previously described: 1 invoice / DN. 1 invoice / DN:
• 1 invoice / ship-to customer: This invoicing mode is used to create an invoice for all the orders with direct invoicing concerning the same ship-to customer on a single invoice when the invoicing process is run. If order lines concern various ship-to customers within a single order there will be as many invoices as there are delivery addresses on the lines. There also is a control performed upon manual invoicing of the orders.
• 1 invoice / period: This invoicing mode is used to create an invoice for all the orders based on the invoicing frequency defined by the customer. For instance, if the frequency is weekly, all the orders during week 32 (relating to the requested delivery date in the order header) are grouped on a single invoice. There is a specific feature linked to the invoicing frequency when the chosen value is upon request.The orders with this kind of frequency will be grouped together.
• Manual invoice: This invoicing mode is not considered in the automatic invoicing processes. Invoicing will be manual on invoice entry.

Beside these invoicing modes, there are pieces of information that, if varying from one order to the next, prohibit the grouping together of two deliveries. Please refer to the automatic order invoicing.

Flag used to define the customer invoicing frequency.
This invoicing can take place every day, every week, every 10 days, every fortnight, every month or upon request.

Use this field to specify the Invoicing term. This information is optional.
This filed initializes the entered invoicing term on the customer order, when the order is linked to a Service or Generic product with a Sold and not Deliverable flow type.

Code of the sales representative associated with the customer and controlled in the sales representative table. The sales representative of the sold-to customer has priority over the sales representative of the ship-to customer.
An activity code is used to define the number (maximum of 2) of sales representatives submitted as the default value upon order.

The values relate to the invoicing footer. This information can directly come from the parameters of the invoice footer or from the customer record.
 Refer to the Invoicing elements documentation for more information.
The values of the footer elements can be modified. The ex-tax and tax-incl. amounts of the document are directly impacted by these values.
Intercompany specificities
If the order has been generated from an inter-company or inter-site purchase order, and the inter-company setup stipulates that the invoicing elements come from the Purchase module, these will be initialized with the values entered in the original purchase order.

This field is used to indicate the reference of a print template listing the reports to use in priority (and the number of copies) with the documents used in commercial management. It is thus possible to specify the reports and to reserve them to some BPs.

To enable an electronic invoicing for Portuguese legislation, you must select a PDF print template code or invoice report compatible with Portuguese legislation. The archive destination for the template in PDF format is determined by the EFATPRT – Default destination for EFAT (LOC chapter, POR group) parameter setting.

Use this field to specify the accounting code of the site.
The accounting code is a default value used in the setting up of accounting entries.
It refers to a table that lists a certain amount of elements (collective accounts, accounts or parts of accounts) that can be used for the determination of the documents that will be posted.

The account structure is not compulsory data.
If a structure is loaded, it is submitted to be applied upon the creation of a customer invoice (once the invoice tax excl. amount has been entered).

Code checked in the tax rule table and designed to mention the default tax rule associated to the BP.
On the record of this BP, on the BP/Company tab, it is possible to define a different default tax rule by default according to the company. When there is an existing value for a company, it is proposed in priority.

If the invoices of the group of customers should be passed to a factor, indicate the factor code that is asked to recover them.

Code associated by default with the current BP, used to define the payment conditions.
This code defines the payment method, open item type, as well as the payment schedule (one or several open items cash, 30 days, end of month etc.).
When managing this table, it is possible to simulate the calculation rules that will be applied in entry mode.

Code used by default for the current BP to identify a series of early discount and late charge rates (up to 12) to be applied to a payment according to a number of days early or days late with respect to the open item date.

If this field is entered, the automatic payment proposal processing will automatically assign this bank account to all the payments for this BP.
 Code controlled in the table of bank accounts.

Reminder group with which the customer is associated.

The reminder group is used to define a group of management rules that are applicable during the launch of the reminder letters.
The Type of reminder and the Reminder threshold is by default recovered from the reminder group during the creation of the record (but not re-initialized if allocated to a different group of characteristics).
However it is the values from the customer record that prevail over those of the group or the category for these two fields (if they are different ).
A customer that is not attached to a reminder grouped is not considered.

Type of reminder process for the customer.

 The reminder type, and reminder threshold, taken into account by the reminder report are those of the customer record (and not those of the reminder group which are only used upon initialization).

• This field is controlled by a local menu and can take the following values : 
  No reminder:
  The customer is never reminded.
• Reminder by invoice:
  The customer receives as many reminder letters as invoices that are late for payment.
• Global reminder:
  A single reminder level is addressed to the customer for all the late invoices.
• Global reminder by level:
  The open items are grouped by identical level and the customer receives a reminder letter by level. Each reminder level contains all the open items overdue for a given level.
• Global by lead-time: The open items are grouped by late open item ranges (for example, all open items that are overdue by 30 to 60 days).

The customer receives one reminder letter per late open item range (or more, depending on the reminder group).
Each reminder letter contains all the overdue open items for a given late range. The values for the late range can be modified via the parameters.
In this way, it is possible that for a given customer to pass from a reminder letter for level 1 to a level 3 reminder letter if the number of days variance justifies it.

Minimum amount below which reminder letter is not issued for this customer.
This amount is expressed in the common currency defined in the CURSHRFLD setup.
This minimum amount means the minimum amount of the due date or the global minimum amount of the reminder letter. One of these options can be selected when setting up the reminder groups.

This field displays the currency of the reminder threshold, based on the value of the CURSHRFLD - Common field currency parameter.

Flag used to determine the frequency of the open item statements for this customer.
The frequency of these statements can be every week, every 10 days, every fortnight, every month or upon request.

The "Analytical" table is preloaded based on the setup of the default dimension views and depending on the entity (customers, suppliers, products, etc.)

The setup determines if the analytical dimensions can be modified. They are initialized based on the setup of the default dimension.

In creation mode, if no order line has been entered and the project code is modified, the analytical dimensions are reset based on the setup of default dimensions.

In creation mode, as in modification mode, if an order line is entered and the project code is modified, the analytical dimensions are not reset.

Code of the sales representative associated with the customer and controlled in the sales representative table. The sales representative of the sold-to customer has priority over the sales representative of the ship-to customer.
An activity code is used to define the number (maximum of 2) of sales representatives submitted as the default value upon order.

This is the storage site code from which the customer is generally delivered. This site, which is controlled in the site table, must be identified as a warehouse.

This information can only be accessed if the order is of the inter-company or inter-site type. It is used to indicated which shipping site will be used by the sales company that the inter-site/inter-company supplier identified. It will then serve to initialize the shipment site for each line of the purchase order. It is mandatory in this context.

The shipment site is initialized by order of priority, as follows:

• usual shipment site defined in the delivery address identified by the receiving site previously calculated is used. It must belong to the supplier's company,
• site identified by the supplier if it is a warehouse site.

If after this search, the site is still not identified, you must then manually enter it. A control is applied to check if the entered site belongs to the same company as the supplier site and if the site is a storing site. The Actions icon is used to view all the sites available for selection.

Specificities linked to automatically-generated purchase orders: if the shipment site is still not identified after the execution of the previous steps, the shipment site is initialized using the first warehouse site found, in alphabetical order, in the list of storage sites for the company identified by the supplier.

When generating the corresponding sales order, the shipping site of the sales order header is equal to the site defined here.

Enter the code used to define the information related to the transport and delivery. This code is managed in the table of delivery methods.

This field indicates the code that identifies the Carrier liable for the transportation of the goods.

The Incoterm codes, set by the International Chamber of Commerce, seek to standardize the terms the most used in the international commerce by defining the respective responsibilities of the seller and the buyer agreed upon on establishement of the sales contract by a unique word similarly understood throughout the world.

The Incoterm code, controlled in Incoterm table is used in the INTRASTAT file (Exchange of goods declaration). It can also be used to define the price lists.

A transport location must be specified in the EU exchange declaration. It is combined with the Incoterm code in order to determine the delivery conditions referring to the sales contract terms that specify the respective obligations of the buyer and seller.

This information is not used in the French declaration.

This field is subject to the Exchange of goods declaration (Intrastat).

This conversion factor is used in the Intrastat declaration for the exchange of goods. It is used in supplier invoices and applied to the fiscal value of the product line to obtain the statistical value.
It is initialized by either the increase conversion factor entered on the product-supplier record or the supplier record.

This indicator is used to identify which days of the week are work days for the customer.
If a day is declared as a work day, the customer can receive delivery on it.
If the calculation of the delivery date results in a day that is not worked, this date is automatically postponed to the first available work day.

Code controlled in the unavailability period table and used to specify the periods during which the BP is not available (for instance, holidays). This unavailability code is used, on order, to automatically transfer the delivery date to the first available date.