nstalling SQL Express 2012 for

SambaPOS V3
1.Download SQL Express 2012
http://www.microsoft.com/en-au/download/details.aspx?id=29062

Click the Red Download button.

Select the version you need and click Next.

SQLEXPRWT_x86_ENU.exe - 32 Bit version with SQL Management
Studio\\r SQLEXPRWT_x64_ENU.exe - 64 Bit version with SQL Management Studio

Click Save File.

2.Installing SQL Express 2012

Run the file you downloaded above

Select New SQL Server Stand-alone Installation

Click I Accept and click Next

SQL Express will request to install updates, click Next

Click Next at Feature Selection

Create a new Named Instance called SAMBAPOS3, and click Next

Make sure both services are set to Automatic Startup Type. Click Next.

Select Mixed Mode, and enter a password for the database (remember this password for
later), I suggestsambapos. Click Next.

Click Next.

SQL Express will now install this may take several minutes.

Once installation is complete, click Close.

Close the SQL Server Installation Window.

3. Enabling Network Services

Run SQL Server Configuration Manager located under Microsoft SQL Server 2012 in
your start menu.

Expand SQL Server Network Configuration, and select Protocols for

SAMBAPOS3 Enable both Named Pipes & TCP/IP Protocols.

A warning message will appear when you enable the protocols, click OK.

Go to SQL Server Services, select SQL Server (SAMBAPOS3) and click the Restart icon.

4. Using SQL Express 2012.

Use the following line in SambaPOS Local Settings to use SQL Express 2012
Data source=localhost\SAMBAPOS3; User Id=sa; Password=sambapos
For all other computers on your network change localhost to your computers name that is
running SQL Express 2012. For example
Data source=John-PC\SAMBAPOS3; User Id=sa; Password=sambapos

Network connection issues are usually caused by Firewall programs running. Due to SQL
Express using Dynamic Ports, it makes it hard to configure access through firewalls. The
easiest solution is to turn off all firewalls.
If you feel the need to have the firewall running, then look at this
article http://technet.microsoft.com/en-us/library/cc646023.aspx
Turning off your Windows Firewall does to affect the security of your computers, as long as
you have a decent Internet Router with Firewall to stop external attacks, and you use
secure passwords for your Wifi Access Points to stop internal attacks.

Running SambaPOS v2 & v3

Databases
If installing SQL Express 2012 for SambaPOS v2, then I suggest using SAMBAPOS for the
Named Instance. This keeps both V2 & V3 databases running completely independent of
each other.

Installation of SQL Express 2008

Installation of SQL Express 2008 is exactly the same as 2012, with the exception of
Product Updates.
The installation files are available here http://www.microsoft.com/enau/download/details.aspx?id=22973
Upgrading from SQL Express 2008

When you run the SQL Express 2012 setup file that you downloaded, select Upgrade and
follow the Wizard.

Creating Printer Templates

Hello. Our topic is creating printer templates. In this tutorial we'll create a general ticket
template and give some examples of new features.
When we create a new ticket template a blank screen with some descriptions of usable
tags welcomes us.

V2 users will remember the sections available for different types of Ticket Lines (Orders).
For example we used Gift Line section for defining printing template for gifted items. On V2
order states such as Gift, Void was hard coded. With V3 we can create new Order States
for different uses such as returned or wasted items. So how we'll create templates for new
types of Order States? To be able to solve this problem we introduced a new feature called
Dynamic Sections. We'll type the section name in square brackets like [Orders:Gift] so
SambaPOS can understand the lines under this section name relates with orders that have
Gift state.
Now we can start creating the template.

This is the basic template. I've inserted two comments as a place holder for Resources and
Orders.
As you know a Ticket contains some collections of things such as Orders, Resources,
Discounts, Services, Roundings, etc. We want to list orders at the point I've inserted
comment under Ticket No: part. To tell SambaPOS where we want to list orders we'll
use {ORDERS} tag and {ENTITIES} for listing resource items. All possible tags are:

{ENTITIES}
{ORDERS}
{ORDER TAGS}
{TAXES}
{DISCOUNTS}
{SERVICES}
{PAYMENTS}
{CHANGES}

Collection Tags are displayed in Blue color and defines the place where we want to list
things.
But this format will print nothing for orders and resources because SambaPOS still don't
know how to print orders or resources. So we'll create sections for defining these
templates.

We created three sections. One for order line format and the other two are for Resources.
The format we created at [ORDERS] section will be used for all order lines but
[ENTITIES:Table] format will be used for printing table name and [ENTITIES:Customer] will
used when the resource type is Customer and it will print Customer Name and Customer
Phone. Customer Phone pulled with {ENTITIES DATA:Phone} tag because phone number
is a custom data. For example if you add a custom data named Mobile for Customer
Resource type you'll print it by using {ENTITIES DATA:Mobile} tag.
But of course we don't want to print all order lines on tickets. For example we want to
remove voided lines and display Gifted lines with a different format. So we'll create two
more sections.

We added an empty section for voided lines. If we do not create a section for
[ORDERS:Void], default [ORDERS] template will used instead. To be able to skip them we
created an empty section. [ORDERS:Gift] section is self descriptive. We'll print Gift instead
of price.

SambaCard Tutorial

Pre-paid cards works like Sodexo or Multinet cards. The difference is you give these cards
to your customers and you sell credits. Once funds added to a card the customer can
spend it on your restaurant. Some businesses prefers that because instead of paying
comission to card companies they want to make discounts to their customers.
SambaCard is just a fictional name. You can name it as you like.
Configuration
Hint: Before starting you can read a brief introduction of V3 Accounting Features.

SambaCard Account Type:

We'll create a new Account Type called SambaCard Accounts by navigating to
Management > Accounts > Account Types

A new SambaCard account is created for every card we give to our customers.

We need an account to track SambaCard Sales. We'll create a new Sales Account to differ
them from normal Sales.

We'll create a new Account Transaction Type to be able to Add Funds to Customer Cards.
We can create it by navigating to Accounts > Transaction Types.

We'll configure here how SambaCard Sales Account and related SambaCard Account
works when we add funds to a card. This configuration means when we Add Fund to a
customer card, it credits SambaCard Sales account and debits the SambaCard Account.
We'll need a Add Funds button on Card accounts to add funds to cards easily. We'll do
that by configuring a Transaction Document Type

This configuration will create a green button labelled as Add Funds at Account
Transaction Screens. We'll use it to add funds to SambaCards so to be able to display that
button for SambaCard accounts we selected Account Type as SambaCard Accounts.
Since it will create a SambaCard Sale Transaction we add it to the transaction list by
clicking to Add Account Transaction Type link.
Now we'll configure how that button will display. So we switch to Mappings screen.

We'll configure here on which user accounts, departments or terminals that button will
appear. * means ALL so we'll leave everything as * to make it work for everyone. That's all
we need to do for Adding Funds to Customer Cards.

Entity Configuration
On this step we'll introduce a new Entity Type so SambaPOS will know we have something
called SambaCard in our Restaurant and we need to select it on tickets like we select
Tables, Customers or other similar entities.
We do it by creating a new Entity Type. Navigate to Entities > Entity Types for creating a
new Entity Type

Name: A descriptive name of the entity.

Entity Name: The singular name of the Entity. It is SambaCard
Warehouse Type: We'll leave it empty since this entity is not related with
Warehouses.
Account Type: The Account Type of these Entities. We'll choose SambaCard
Accounts here.
Account Name Template: When we create a new entity we'll also create an
account linked to this Entity. For example for your Customers you can open an
account or not. If they have an account they can make payments later. What we
configure here is how we need to configure linked account names. Since we create
them automatically SambaPOS needs to know it. SK-[Customer Name]-[Phone] means
for the Customer Emre EREN with Phone number 111222333, the account name will be
SK-Emre Eren-111222333
Custom Fields: We'll configure additional data fields we need. Do it as it appears
on the screen shot. You can create new fields from right-click menu

That configuration means when we create a new SambaCard it will ask us the Customer
Name, Phone and the Address. It will also automatically create a new SambaCard
account and link it with new SambaCard.
Now we need a POS Screen to search, add, edit cards. We can do it by creating a new
Entity Screen

The screen name is also SambaCard and it will display as a POS button on top of the
screen. Ticket Type will be Ticket and the ViewMode should be Search . We'll switch to
Entity List screen.

On this page we'll configure which Entity Types we'll use on this screen. Obviously it should
be SambaCard Entity Type. We also need to configure how that screen displays to users.

If we have multiple departments we may want to disble SambaCard Selection Screen for
specific departments. For example we may want to disable it for Delivery department. I'll
use default settings by adding a new mapping and leaving all values as *.

To be able to use this entity on Tickets we need to assign this Entity Type to the Ticket Type
we'll use. You can configure the default Ticket Type from Management > Tickets > Ticket
Types menu.

Payment Type Configuration

Since we'll use SambaCard as a payment type we need to create a new custom Payment
Type for it. But before creating a new payment type we need to define how this payment
works. For example Cash Payment moves amount Receivables Account to Cash
Account. Likewise a SambaCard Payment transaction moves amount from Receivables
to SambaCard Accounts. We can configure it by defining a new Account Transaction
Type.

It looks like the SambaCard Sale Transaction but it does the reverse transaction.
Now we cen create the Custom Payment Type.

I named it as SambaCard and assingned SambaCard Account Transaction to it.

Mapping screen works likes the others but this time we also choose where it displays. We
can show that payment button on payment screen, under ticket or both.
That is all we need to do for the configuration. Let's see how it works.

Demonstration
We have an additional SambaCard button on POS screen. This works like the Customer
Search screen. We'll use unique card numbers as the card names. We can search for a
card number by typing it or by using a keyboard emulated magnetic card reader.

There is no 55716911 Card so no results shown. We can create this card by clicking New
SambaCard button.

And we enter the card details. Notice how address field permits multiple lines because it
configured as Wide String Field. Clicking Create Account button will create SambaCard,
Create linked account and assign it to SambaCard.
After creating a SambaCard we return to search screen to complete further actions.

Select SambaCard: Creates a new ticket or displays if there is an open ticket

linked to that card.
Edit SambaCard: You can change details or create linked account if not created
before.
New SambaCard: Creates a new SambaCard.
No SambaCard: When enabled it unlinks card from ticket.
Account Details: Displays Card Transactions.

Click Account Details to display Account Functions

We should see the Add Funds button that we configured to add credits to SambaCard.
Click it to add funds.

We added $200 Credits to the Card Account. Notice how account name genated from Card
Data we entered.

When saved it displays our transaction.

Now we can create a ticket and assign SambaCard to it.

Click Select SambaCard button to display SambaCard Search screen.

Type card number and click Select SambaCard (or press enter key)

Card assigned to the ticket. Add some orders and click Settle
SambaPOS switched to Payment Screen. You should see the SambaCard balance next to
account name. Also we have the SambaCard payment button.

Click All and settle the ticket with SambaCard payment. It should close ticket with
SambaCard payment.
Check the End of Day report to see if it recorded fine or not.
You can also check Card Account to display or print past transactions.

Adding Discounts to Orders with Order Tags

Hello. I've previously created a documentation about adding order based discounts. In
some cases that does not works fine so I decided to create another tutorial. This time we'll
use order tags to add discounts to orders.
We'll start by creating Discount order tag. Navigate to Management > Tickets > Order Tags
and create a new Order tag named as Discount. I've checked Add Tag Price to Order
Price setting to be able to see discounted price on ticket.

I'll add a single tag named as %50 Discount. Since I'll enable this tag by actions I don't map
this order tag group to a button.

On the next step we'll create an Automation Command. Switch to Automation tab, click
Automation Commands and add a new Automation Command. Name it as it shown in the
screen shot. I've selected blue color for this button.

Since we'll use this automation command we'll map it to Order Lines we need a mapping.
Switch to Mappings page, add new mapping line and change Visibility to Order Line. Click
Save to store this command.

We'll need an action to calculate discount and tag the order. Navigate to Automation >
Actions List and create new Action. Action Type will be Tag Order and Order Tag Name will
be %50 Discount. Be sure to type Order Tag Value as you've named sub tag. It is case
sensistive. We'll use an expression to calculate discount price. Since we need to decrease
product price we'll create negative priced tag. [=0(Order.Model.GetVisiblePrice()*0.5)] expression will calculate %50 of the Visible Price
and convert it to a negative value by subtracting it from zero. Visible Price means the price
of the product plus other order tag amounts.

Finally we'll need a rule to map discount action to the automation command button. Set
Event Name as Automation Command Executed and add related discount action as
shown on the screen shot.

We'll need a default mapping to enable this rule. Switch to Mappings Page and add a
mapping line. Click Save to save your changes.

When we click on an order we should see the blue %50 discount button. When clicked it
will calculate discount amount and tag order. To cancel discount you can click that button
again. If there is already a discount tag it will remove that.

There are lots of possibilities with SambaPOS. Let us know if it works fine for you or not.
You can find a link to sample database below for testing this configuration. Bye.

Adding Refund Button for Cash

Sometimes we need to return payments back to customer. On this documentation we'll
add Refund button to Cash account sceen.
We'll start by creating an account for Cash Refunds so we can track its amount. I named it
as Cash Refund and selected Account Type as Refund Accounts that I've recently
created.

Second step will be telling SambaPOS how Cash Refund account works. When we refund
cash it will decrease Cash account amount and increase Cash Refund account amount.
We can configure it by creating a new account transaction type and configure it as shown
at the screen shot.

Finally we'll need a button on cash screen for that transaction. We can do it by adding an
Account Transaction Document Type.
After setting up visual parameters we'll set Account Type as Payment Accounts and we'll
add Refund Cash Transaction to the Transaction Types list. That means when we click
Refund Button it will create Refund Cash Transaction

We'll switch to Mappings page to map this document type to admin user role. Click Save to
save your changes.

This is how my accounts screen looks like. I'll click Cash and Click Display Details

We have a Refund Button. Click it to create a transaction.

 and refund $5.

Cash balance decreased to 9.72 as a result.

Configuring Cash Transactions for V2 users

V2 users will notice that we don't have cash, credit card and voucher amount entries while
starting a work period. That was a great feature to input beginning cash values while
starting the work period but with V3 there are some differences.
The main reason of this difference is V3 have it's own accounting system, custom payment
types support, multiple cash support and foreign currencies support. Unlike V2 cash
transactions are not hard coded anymore and we have to configure transactions for our
needs. On this document I'll show you how we'll do it.
Unlike V2 cash account does not automatically close while closing a work period. Before
ending work period we need to create an expense transaction for the amount we receive
from cash. To be able to this we have to configure transaction types for cash.
First I'll configure some sample accounts for using with cash transactions.

You can add more accounts for your business needs. General idea is if you wan't to see a
total for your business transactions you'll create an account for it. For example if you need
to know how much you've paid for grocery you'll create an account for it.

While batch creating accounts we'll define account types by starting their names with #
Let's create Account Transaction Types. On SambaPOS accounting system all account
transactions should have a source and a target account. First we'll configure Income
Transactions type.

 and Expense Transactions

Now SambaPOS knows how cash, income and expense accounts are mapped together. As
you've noticed we've left Default Target Account empty on expense transaction because
We'll choose it while creating the transaction.
Now we'll create buttons for transactions. We'll configure it by creating Document Types.

We'll add default mapping here.

We'll do the same for Expense Button.

When we finish this configuration we'll Click Accounts > Cash > Account Details.
We should see two buttons for Income and Expense transactions.

This is how a transaction should appear.

You can change Account Screens configuration for displaying Income and Expense
Transactions or create a new Account Screen for displaying Income and Expense account
details.
At the end of work period you can close cash by creating an Expense transaction and
choose Cash Closing account there.
We'll be happy if you try this and share your thoughts to help us on improving these
features. Bye

Custom Package Delivery System

This documentation is about creating a custom package delivery screen configuration.
Before start reading this long document I highly reccomend you watching usage video of
this sample to better understanding what is it about. http://youtu.be/ljXkrkhuz3g . Video is in
Turkish Language but you can enable English Subtitles.
SambaPOS have lots of features for running your package delivery business. With V3 you
can even do more by using automation features and custom screen widget. This sample
will demonstate:
1.
2.
3.
4.

Receving orders by using Caller Id module.

New orders will receive Waiting Status and listed on a table.
We'll display orders by customer regions.
We can multi select waiting orders and assign them to a delivery personnel with a
single click.
5.
Listing tickets by Deliverers and settling them.
We'll start by creating a new Entity Type for deliverers. We'll have two custom fields for
personnel phone and address. You can add more for your needs by right clicking on the
grid. Creating a Deliverer Entity Type means we can create Deliverers and assign them to
tickets like we assign customers or tables.

While creating delivery personnel records we can update custom fields.

We'll need different ticket type for delivery department. We'll use same menu for delivery
and table service departments but you can create different menu with different prices for
delivery department if you need. The main reason we need different ticket type is we can
differ delivery sales on reports and make finer configuration. While creating this ticket type
we'll assign Customers and Deliverers entity types to this ticket type. This also means
we won't use tables with these tickets. Not in the scope of this document but as a side note
you can create custom Transaction Type for this ticket type and differ delivery sales
accounts. We'll talk about this more on further documents.

On this step we'll create Delivery Department. We'll choose Delivery Ticket as Ticket type
so tickets created from Delivery department will use this ticket type.

We'll create a Entity Screen for Delivery department. We'll use two screens for this
department. One of them is selecting Customers and the other one is for managing orders.
We'll create customer selection screen first. View mode of this screen is Search so
instead of clicking buttons we'll find customers by typing their name or phone number.

On the Entity List page we'll choose Entity Type of this screen. Since we select Customers
here that means we'll find Customers through this screen.

Finally we'll map this screen to Delivery department. That means this screen is visible only
for Delivery department. On default configuration Table selection screen is visible to all (*)
departments. Since we don't need table selection on Delivery department you can open All
Tables screen and map it to Restaurant department.

Second Entity Screen is the custom delivery screen we'll configure. We'll add widgets and
buttons on this screen like we configure a custom table screen so View Mode should be
Custom

On the Entity List Page we'll select Entity Type as Deliverers. That means we'll work with
deliverers on this screen. Add previously created delivery personnel to the list and set
Display State to Status so you can use Resource Grid widget on this screen.

Map it to Delivery department and select Ticket Type as shown here.

When we click Delivery department button on the bottom we should see two buttons for
two screen we recently created. If you see more screens here it means these screens
mapped to all (*) departmens. You can remove them from display by mapping these
unneded screens to Restaurant department.

We'll need some rules and actions in order to update states of delivery tickets properly.
We'll start by creating an action for updating Delivery Status of the ticket.

This rule executes Update Delivery Ticket Status action with Waiting value as soon as a
Ticket first Created. That means when we create a ticket it's delivery state becomes
Waiting

We'll map this rule to delivery department and delivery ticket. So this rule becomes only
active for delivery tickets. I won't show this step for every rules we'll create. Please map all
further rules to Delivery Department and Delivery Ticket as shown here.

We need another rule to change Ticket Delivery Status to Delivering when we assing a
Deliverer to Ticket. This rule activates when Ticket Entity Changes and if Entity Type Name
equals Deliverers it changes ticket state to Delivering. You can add more actions here.
For example you can print Delivery Ticket with deliverer name and customer address.

We'll create another rule to change Ticket Delivery state to Delivered when we settle the
ticket.

I'm not showing these steps but don't forget mapping these rules to delivery department
and delivery ticket.
We finished configuring rules for ticket state tracking. Now we'll start desiging Custom
Delivery Screen. Switch to delivery screen and enable design mode by right clicking on
the screen.

We'll add Resource Search widget.

Move this widget to the right bottom corner of the screen and resize it to the top. It is the
easiest way to position widgets. This widget looks like our customer search screens. Since
the Entity Type of this screen is Deliverers widget automatically configured itself to search
deliverer entities.

Right click on the widget and click Settings We'll configure this widget as displayed here.

On this step add two Ticket Lister widgets to the screen and position them as displayed
here. Ticket Lister is a special widget to list tickets filtered by it's state. Ticket Lister 1 will
display Waiting tickets and Ticket Lister 2 wil display Delivering tickets.

This is the settings screen of Ticket Lister 1. State is Waiting so it will display tickets with
Waiting state. Format setting is for configuring how ticket displays on the lister. We use
Printer Template formatting here. Most printer formatting features supported here. So you
can configure how tickets displayed like you configure ticket prints. {ENTITY
DATA:Customer:Region} will display Customers Region. We'll configure this field on next
step.

Ticket Lister 2 displays tickets with Delivering state. Display format is a little different here.
We display Deliverer name here.

Now we'll create Region field for Customers. Go to Management > Entity Types >
Customers and edit Customers entity type. You can add Region field by right clicking on
the grid. I've also entered possible region values here by splitting them with commas.

Switch to Delivery Customers screen and create a new customer. As you can see I can
choose a region from combobox while creating a customer. We forgot adding an address
field here but it will be useful if you add it too :) Click Select Customer to create an order.

When we create an order we can see how Customer displayed on the title and the delivery
status of the ticket.

When we close this ticket it should appear on ticket lister 1.

On this step we'll create some actions and rules for configuring our custom screen. We are
expecting to choose tickets from Ticket Lister 1 and assign them to a delivery personnel
with a single command button click. Let's start creating needed actions.
First we need to store selected Ticket Id's in program memory. This technique is useful to
pass values from one widget to another. Ticket lister 1 write selected ticket ids to a program
setting and when another widget needs to know which tickets are selected it will read it
from this program setting.
Create a new action, select update program setting action type and configure it as shown
here. The setting name we are using here is TicketIds when we need to read selected
ticket ids we'll use {:TicketIds} tag.

We'll need an autmation command to trigger needed rules when we click on a ticket from
ticket lister 1.

Create a new rule and when this automation command triggers we'll execute Store
Selected Ticket Ids action.

This awesome action does looping actions. It reads a value and executes Value Looped
rule multiple times with supplied values. On this sample it reads selected Tickets Ids from
{:TicketIds} tag. When we write a value in curly brackets it reads it's value from program
settings. If you remember we stored selected ticket id's to TicketIds setting with Store
Selected Ticket Ids action. It will read this setting, for example if stored ids are
101,105,109 it will split these values to three and loop these values. In this case three
times.

We need another action to change ticket deliverer. This action does it. Please notice this
rule also reads selected deliverer name from program settings with {:Deliverer} setting
name. We'll store selected deliverer name when we click Deliverer button.

This action Loads a ticket and keeps it in memory. It is useful to use ticket related actions.
For example change ticket entity action we'll use to change ticket deliverer needs an active
ticket. Since there is no ticket loaded we have to load it with this action. We'll send Ticket
Id parameter from next rule we'll create so we'll configure it as variable by typing it in
square brackets.

This rule is the place where all pieces used together. Like I've mentioned before value
looper action executes Value Looped rule multiple times. For example if we choose 4
tickets on ticket lister 1, this rule will execute four times and on each step it will send next
Ticket Id with Value parameter.
It will first load a ticket with Load Ticket action. We pass ticket id with value parameter. On
next step it will change ticket's deliverer. If you remember this action reads selected
deliverer from {:Deliverer} program setting. On the last step it closes (saves) ticket.

To be able to trigger value looper action we need to configure an automation command and
map it to the deliverer button widget. Create a new automation command and configure it
as shown here.

We'll create a rule to handle this automation command. When a deliverer selected we'll
store deliverer name in memory and start looping stored ticket ids.

When we click on a ticket on Ticket Lister 2 we want to display this ticket. We'll handle it
with Display Selected Ticket automation command. Create is as shown here. Since we call
these automation commands from widgets there is no need to map these commands to
buttons.

This action displays a ticket.

This rule handles Display Selected Ticket automation command and execute Display Ticket
action. We'll map Display Ticket parameter to [:Value] too.

All required actions and rules are created. Now will map these rules to widgets. Enable
Design Mode on delivery screen and open Ticket Lister 1 Settings.
We'll enable Multi Selection setting and Map it to Ticket Selected on Ticket Lister
command.
When we click on a tickets there widget calls Ticket Selected on Ticket Lister command and
passes Selected Ticket Ids as comma separated values. If you need to use different values
you can use Command Value setting here.

Now we'll start adding Automation Command Button widgets for each deliverer personnel
and configure them as shown here. This button calls Deliverer Selected command and
passes John D. as Value parameter.

We'll set Ticket Lister 2 Command Name to Display Selected Ticket. While executing this
command it also passes Selected Ticket Id as value parameter.

That's all. We've created a useful delivery screen and configured it for our business needs.

It should work as shown at the sample video. Let us know your results.
Thanks.
By clicking the link below you can download sample sdf file for this configuration.
Continue Reading: Custom Package Delivery System Part 2

Custom Package Delivery System Part 2

If you didn't do so reading Part 1 of this document is strongly recommended. If you want to
continue from where Part 1 ends please download sdf file from Part 1 and upgrade to
3.0.11 (or later).
We'll contiune configuring our Custom Package Delivery System. On this tutorial we'll
configure Servicing Fee by Customer Region.
We'll start by creating an Account for Servicing Fees. From this account we'll track how
much servicing fee we've settled during our business. Navigate to Management > Accounts
and create a new Account.

I've selected Sales Accounts as account type. If you need you can create separate
account type. To make this documentation simpler I'll create single account for servicing
fees but if you need you can create individual accounts for each servicing fee type.

Next, I have to configure how servicing account works. To do this I'll create a new Account
Transaction Type. That transaction debits Servicing Fee account and credits
Receviables account.

On this step we'll create a Calculation Type. Calculation Types are values we add to
tickets such as ticket based taxes, servicing fees or other similar additions. Discounts are
calculations too but they decreases ticket amounts. Since we track Servicing Fees from a
single account Singe Calculation type will be enough for us.
We'll set Servicing Fee Transaction as Account Transaction type and Fixed Amount as
calculation method. Since we'll update amounts dynamically from rule we can leave
Amount value zero. I'll also enable Include Tax setting because we want to add this
amount to ticket amount after tax calculation.
You can try different calculation methods if your servicing fee calculation is different.

We'll create an Action to update Ticket Servicing fee after a customer selected. Action Type
will be Update Ticket Calculation and Calculation Type should be Servicing Fee. As
you've noticed this is the calculation type we've recently created.
If I enter 5 as Amount this action will always add $5 as servicing fee but we want to
determine Fee amount by Customer Region. For this reason I'll create a variable by typing
[:Fee] as Amount Value.

We'll need 4 different rules because we have 4 different regions and 4 different Servicing
Fee amounts. This rule will work when we select a customer to the ticket so we'll handle
Ticket Entity Changed event.
From the Conditions section we'll choose Customers as Entity Type Name because we
want it to work only if the selected entity is a customer.
Second condtion will be Region check. A customer custom data contains a lot of
information like Phone Number, Address and what you've added for your needs. So we
need to check if that data Contains Region 1 value. We can do it by changing equality
operator to question mark (?).
We'll select Update Servicing Fee action we've recently created. Since we configured fee
amount as a variable we can see it by expanding blue action box. Enter 3.90 there because
customers from Region 1 will pay that amount.

We want this rule to work only on Delivery department. To do this switch to Mappings
section and map this rule to Delivery Department and Delivery Ticket Ticket Type.
Save it when you finish that.

We have 4 regions so we'll need three more rules. You can right click Update Servicing
Fee by Region 1 rule from Rules List and Clone it for easier configuration. Name it,
update region check and region fee. This is how rule for Region 4 configured.

When we save it we should see something like that on rules list.

This is what happens when we create a ticket for a Customer from Region 1

Even if I change the customer, servicing fee changes by region.

This is what we'll see on Accounts Screen.

Now we'll see how we can update Ticket Templates to display Servicing Fee on Bills.
I'll list Services just after Discounts.

I'll list services just af

I can configure how Services looks on printer Ticket by creating a Section for [SERVICES]
at the end of the template. We'll print Calculation Template Name and Calculation Amount.
This is how it looks.

Notes: