All About a Topic
 
Library All Articles Selling Common selling features Serial Numbers (selling) Web Browser Selling Advanced Selling More specialised selling Delivery Addresses Product/Case Selling Messages Reminders & Contacts

Backgrounders

Accounts Stock Levels Barcodes MYOB

Configuration

Receipt Formats (sales) Email Purchase Orders Label Formats PreCanned Reports POS Security

Receipt Formats

Information about creating and using receipt formats for sales. A "receipt format" is used generally for all receipt, job docket, quotation or Tax Invoice etc that is printed as part of sale completion.

Main Links

End User Operation

When a sale in rung on, it uses the default receipt format, unless it has been overridden.

Using PastSales to reprint a receipt shows a complete list of all known receipt formats and available printers. You are permitted to select any combination of receipt format and printer for any sale and override the defaults.

Each checkout can configure which printer it is to use and other items by entering the quickcode "setup printer" which displays a configuration page to allow changes

  • The value "Should Print On" shows the printer the receipt is defined to print on in the database.
  • The value "Currently Printing on" shows the printer that the POS has selected for use. This can differ from "should print on" in cases where the defined print queue does not exist or other configuration errors.
  • The value "gawtest from Gawler" for the receipt format is showing which format is being used from the list of all known receipt formats. You can click this to select a different receipt format completely.

Email Receipts - How they work

Receipts defined using HTML format can be emailed to customers. The HTML template is rendered into a PDF document and that document is sent as an attachment to the email. When sending an email, there are 5 components involved.

  1. The target email address we are sending too
  2. The source email address we are sending from. This value is automatically determined by your system setup.
  3. The HTML template to use. ie, which receipt appearance should be used
  4. The email subject line
  5. The email message itself (aka the message body)

If you are using certain web pages or places, the screen may prompt you to provide manual values for all of these. That is, you can enter any text you wish and that will be used. These screens are typically used for exceptions, such as when you are talking to the customer and say you will send a copy of the receipt now.

When an email is being automatically generated to some extent, such as at a selling counter, where you might simply tick a box saying "email receipt" then the following rules are used internally.

Target email

Using the customer on the sale, select their email address

Receipt Template, Subject Line & Email Body

  1. The store definition for the sale is retrieved, and values for subject line and email body are used if present. Most retailers should enter the values they require into each store definition
  2. If the store does not supply a template value, the default "Receipt format 1" is used
  3. For Subject line and Email Body, the System default value is retrieved and used
    1. A layer 51 membership setting is selected and used if present. This allows Head Office to define defaults for stores
    2. The Fieldpine default values are downloaded and used. These defaults vary according to your country of operation and target language required. Fieldpine defaults are intended as catchall values.

Internal Operation

The POS has a collection of all known receipt formats, and maintains a smaller list of actively used formats.

POS« - »Active Receipt Formats
Known by Name
« - »All known receipt formats
Known by Names and Index#
« -- bypass for PastSales / Reprint -- »

When printing a receipt for a sale with a customer, the POS uses the following logic

  1. (From Pos version P2287) Check the Customer record and see if the field "emailtransactions" has a valid looking email.
    • If the email appears valid, send to this email address.
    • If the email is the word "no", skip out of this logic and do not send email receipts
    • If the emailtransactions value is blank or invalid, continue with next step below

    Note. The emailtransactions is not affected by the tickbox "email receipts"

  2. Check the Customer record and verify that "Email receipts" is ticked and "disabled" is NOT ticked
  3. If the field customers.email has a valid looking email address (not something wrong like "no"), then use that as the email address
  4. If the customer has a charge account, then check to see if the account is marked "email receipts" and see if accounts.email field has a valid looking email address. If so, use that as the email address

Defining Receipts using HTML

From Pos Version P2281 receipts can be defined using HTML instead. When using HTML receipts an HTML file is created externally that defines the receipt appearance. When the POS needs to render a receipt it loads this file and replaces symbols the same as with line defined receipt formats.

Click here for instructions on creating or editing a HTML receipt.

  • When the POS renders a web page for output onto a printer or PDF, any javascript or active component might not be invoked.
  • If the page is being rendered to an HTML device directly, then javascript be invoked depending on who or what is processing the Javascript
  • HTML receipts are not suitable for very long receipts that span many pages, browsers and printers can start behaving strangely depending on the combinations involved.

Centrally Deploying Formats

Under settings, is an option to define receipt formats and specify their layout. This creates formats that override the normal "active receipt formats"

Centrally Deploying Formats across Memberships

If your system defines a membership, such as a franchise controlling server, then you are able to define receipt formats that are sent to all members. In the example below, the format 'Quotation' in the membership "CAUS" is being sent to all members. This essentially extends the normal receipt distribution and allows external organisations to supply receipt formats. Membership deployed formats do not automatically override standard formats such as "receipt" by default and must be selected as the format to use, but this "selection" of the format can be set by the membership owner, so essentially has the same effect.