Home | SourceForge.net | OpenSwing | More documentation

Sales

Customer definition includes private customers (used for retails and sale contracts) and organizations (used for sale orders). It is possible to define contacts and use them for creating offers/estimates. Contact to customer conversion is provided too. JAllInOne provides customer and contact hierarchies definition.

Customer creation includes the definition of some data: default pricelist, bank, agent, default vat, accounts to use to record in accounting credits and selling proceeds. The same form includes the definition of customer references, customer discounts, links to customer hierarchies, destinations. A search panel to show scheduler activites related to the customer is provided too.

 

 

The contact form is simpler: it does not provide discounts definition and destinations. No pricelist, bank, agent, vat or accounts are required while defining contacts: the contact process creation is very fast.

Agents definition is also provided.

Sale process is integrated with accounting and payment dues to guarantee an up to date and reliable data for the finance department.

When adding items to a sale document, the item code can be specified at hand and validated or selected by a tree+grid window; if the specified item supports variants, then a variants matrix is showed and the user is not allowed to directly specify a quantity in the "Qty" numeric field: user can specify multiple quantites, for the desided variants combinations and save more items with a single save click!
Qty field is calculated as the sum of quantities specified in the variants matrix and the price is determined using the pricelist defined in the sale header: if a price was defined for the specific combination of variants, then this price is used instead of the one defined at pricelist+item level.
Note that it is not allowed to specify quantities for item variants having different prices: ony item variants having the same unit price can be specified, otherwise the "price unit" numeric field would be inconsistent, as the discounts and row amounts.

 

Sale documents allows to define customer discounts and item discounts: item discount (line discount), hierarchy item discount (line discount), customer discount (header discount) and hierarchy customer discount (header discount).

A new discount can be created by defining the following data: values or percentages interval, a validity date interval, a minimum qty required to apply the discount.

A multiple qty flag is also provided to constraint discount usage as a combination of minimum qty and multiple qty flag; e.g. a minimum qty equals to 3 and a multiple qty equals to true and a discount expressed as 33.33% involve a 3x2 discount. Discounts are applied sorted by discount code and discount code is unique for all kind of discounts: in this way it is possible to define a discount sorting policy, according to discount code name.

Several type of sale documents are available: sale orders, sale contracts, retails, offers/estimates.

  • A sale order allows to sell items and/or activities to organizations. When adding an item it is possible to define discounts too (item and hierarchy item discounts). The same form allows to define header discounts and charges (as percentage or value). A report is available to print the sale order. That document can be confirmed to block further changes and to allow the delivery note creation.
  • A sale contract allows to sell items and/or activities to private customers. When adding an item it is possible to define discounts too (item and hierarchy item discounts). The same form allows to define header discounts and charges (as percentage or value). A report is available to print the sale contract. That document can be confirmed to block further changes and to allow the delivery note creation.
  • An offer/estimation allows to sell items and/or activities to customers (organizations or people). When adding an item it is possible to define discounts too (item and hierarchy item discounts). The same form allows to define header discounts and charges (as percentage or value). A report is available to print the offer/estimation.
  • A retail sales allows to sell items to private customers. When adding an item it is possible to manually define item discounts too. Typically a unique “default” customer is defined and after that used for all retail sales. A report is available to print the retail sale. That document can be confirmed to block further changes and to allow immediate items unload from the specified warehouse and update accounting data. An invoice can optionally be created.
  • The retail can be accomplished also in a separate window named "Point of sale", expecially useful for PCs POS having limited screen resolution (designed for 800 x 600 pixels) and optimized for fast data input operations: operations can be performed using the numerical keys and the Escape key; available commands are all located in the bottom of the window.
    POS functionality also provides information about items sold in the past to other customers that have purchased also the items currently in the list of selling items: these tips can be useful to propose to the customer additional items to sell!



    Before using the "retail sales" or "Point of sale" functionalities, some settings must be defined in the "User parameters" functionalities:
    • a default customer must be defined; this customer represents an "anonimous" person to use on all retail sales
    • a default warehouse must be defined; this warehouse represents the shop where items are available for sale; all these items should be identified by a barcode; in this way each item can be recognized by the barcode and istantly inserted into the POS window or into the retail sale window
    • a "Receipt manager" program must be defined; this is a full path including an application (e.g. a .bat file or a .sh file) that will be automatically invoked when the sale is completed (i.e. when the user press the "Close sale" button in the POS funtionaliy or when the user close the retail sale). Before invoking this program, a file named "receipt_yyyy_progressive.txt" is created in the same folder where the external program is located; this file contains all information about the retail sale (items, quantities, row amounts, discount, total amounts, etc.) and after that, the external program is invoked wtih the .txt file as argument: in this way it is possible to connect a fiscal printer to JAllInOne system; in fact the .bat/.sh could include an algorithm to convert the .txt in a format readable to a specific fiscal printer.


For all this documents the form provides a search panel to enquiry item availability (booked items, available items and future item availability).

In a sale document header, the user has to define the customer involved in the sale, warehouse where unloading pawned items, pricelist and payment conditions.
When the document definition is completed, a confirmation button is provided in order to confirm the document. After the confirmation, an out delivery note can be created, in order to process the items/services to provide to the customer. When all items have beenun loaded from the warehouse, the order state changes from confirmed to closed.

There are several tables referred by sale documents:

  • Customers hiearchies
  • Contacts hiearchies
  • Agent types and agents
  • Charges
  • Pricelists
  • Customer hiearchies discounts
  • Item hiearchies discounts

 

Several sale invoices are available: immediate, from delivery note, from sale document. Credit notes are provided too. A sale invoice is identified by three fields: sectional (optional), doc number and year. Sectional field is defined per company through company parameters feature.

A report is available to print the invoice.

A due register functionality is provided to show, search and manage payment dues.

JAllInOne allows to manage the whole selling process: each document in the process is based on data defined in the previous document, therefore avoiding repetitive introduction of data and human errors.

It is possible in this way to create different documents related to the same flow (sale document, delivery requests, out delivery notes, invoice, payments) and manage them according to their document state (opened, confirmed, closed, etc). After confirming an sale order or a contract, the system automatically creates a collection of (read only) delivery requests, one for each distinct delivery date reported in some item row. In this way, a warehouseman can retrieve the list of delivery requests ordered by delivery date, customer, etc. and use them to create out delivery notes. Each time an out delivery note is closed, its out quantities are reported in binded delivery requests and binded sales order/contract. When all items referred in binded delivery requests and binded sales order/contract have been processed by out delivery notes, the orginal documents are automatically closed. Retail sale does not require delivery request/out delivery note management, since sold items are already available in the shop (i.e. the warehouse...) and removed directly from it when the retail sale is completed.

Therefore, for sale order/contracts, it is possible to create one or more delivery requests; starting from one or more delivery requests it is then possible to create one or more delivery notes; a delivery note can be related to a part of one delivery request (a part of one order/contract) or can include many delivery requests, related to many orders/contracts. The order tracking feature allows to collect all this links and show the realation among documents in a simple way.

Sales Pivot table

A pivot table is available in order to analyze data related to tota amounts and item quantities in sale documents: data can be aggregated according to several dimensions: year, quarter, warehouse, item, customer; data to analyze can be filtered according to the document type, document state (closed, confirmed...), year, customer code, item.

In this way it is possible, for instance, to analyze the trend for each shop (warehouse), using the total amount for retail sale documents, or analize the trend for a specific customer or item.

 

 

 

<< Previous Chapter | Next Chapter >>