Data Exportation

dhosny — Fri, 10 Jul 2009 08:48:38 +1000

I am trying to write an app.config file generator for a data exportation service being used by Amicus (Supermarket point of sale system) and need to know how to create a very specific app config file.
What I need is a class that takes in a Dictionary>> and organises an app config file in a very specific way. Iâ€™ve played around with a few things, but canâ€™t quite get the layout I want. Currently Iâ€™m writing them by hand.

What the various parts represent and how Iâ€™m trying to get the layout below:

I know what my supported section types are, as well as what their settings names are going to be (it may be easier to create a class for each supported type?). I assume that as there is nothing separating my settings other than white space, I could just pass back a single string with all settings and values rather than key value pairs.

On top of creating a class for the instance object, I have created a class that extends ConfigurationSection, another that extends ConfigurationElement, and another that extends ConfigurationElementCollection with limited results.

Does anyone know how to accomplish this task? Or know of a good site where I can figure it out.

Thanks in advance.

David - Neotechnology Business Systems

XAFGrid

dhosny — Fri, 31 Jul 2009 09:08:36 +1000

My current problem:

I have a web app constructed using Dev Express v8.3 that is used to create customer licences for a POS (Point Of Sale) System Amicus, and I would like to include a grid display in one Domain Object that is populated by two other Domain Objects.

The model can be described as follows;
The first object is a customer registration object. It holds key information about a registration such as expiry date, customer, registration name and number etc.

The second object is a list of licence types used by Amicus (Such as Restaurant, Cafe, Retail, Fuel etc).

The third object is a licence record which is essentially a linking table between the two. A registration may contain 0 to many licence records, but the licence records assigned to a registration must point to unique licence types. This table also contains information on the quantity of licences of a type that belong to the registration (I.e. registration for customer â€˜Aâ€™ may have 5 Restaurant and 4 Cafe licences, but customer â€˜Bâ€™ cannot have two licence records where the first links to a Supermarket and the second also links to a Supermarket licence).

Currently we have to navigate to the licences tab, and create individual records for each licence type we want to link to a registration, but seeing as there are only currently about 10 licences, and this is likely to never exceed 30, we would like to display all available licences on the registrations tab in the form of a grid.

With this approach we would be able to quickly and easily look down the list and simply allocate a qty for each type required. If a qty is chosen (I.e. greater than 0), then a record should be inserted in the licence table for the licence type and customer registration with the given qty. Similarly, when editing a registration, if a qty is altered, then the new value should be saved back to the applicable record, with the exception of 0 where the record would be deleted.
I am currently searching DevExpress articles to see how this can be achieved, and have also sent them a question, but if anyone knows how to achieve this, it would be greatly appreciated.

Dave

Licences

dhosny — Fri, 21 Aug 2009 09:14:28 +1000

The purpose of this blog is to detail the included components of the various licence types that are available with Amicus point of sale software.

There are a couple of general categories that the licences can fall under, express, standard, and add-on licences. Express licences are for very small enterprises and demonstration releases. An enterprise may only have a maximum of two express licences at any time, and the inclusion of an express licence excludes the ability to also include standard licences. Standard licences are for the majority of our customers and larger demonstration models. A client release can include any number or combination of standard licences up to the maximum licence type limit. Currently this is set as 4096 licences (this maximum refers to each licence type, therefore a client could feasibly have 4096 licences for each of the 4000 approx available licence slots). As the name suggests, add-ons are not stand alone editions of Amicus, but rather include non-core functionality that lives outside the standard and express editions.

Licences â€“ A Brief Description

Amicus Cafe POS - Includes core Amicus functionality, Meal Order, COGS, and Report Viewer (COGS & Report Viewer not available in Express edition). Designed to be used in conjunction with add-ons like PDA & Synchronisation this edition is best used for clients whose primary interest is in sales and stock control within the smaller scale hospitality industry.

Amicus Fuel POS - Includes core Amicus functionality and Fuel (Note: not available in Express edition). Designed to be used in conjunction with add-ons like PDA & Synchronisation this edition is best used for clients whose primary interest is in sales and stock control within the fuel distribution industry.

Amicus General Retail POS - Includes core Amicus functionality, COGS, and Report Viewer (COGS & Report Viewer not available in Express edition). Designed to be used in conjunction with add-ons like PDA & Synchronisation this edition is best used for clients whose primary interest is in sales and stock control.

Amicus Restaurant POS - Includes core Amicus functionality, Meal Order, Table Service, Booking, COGS, and Report Viewer (Booking, COGS, & Report Viewer not available in Express edition). Designed to be used in conjunction with add-ons like PDA & Synchronisation this edition is best used for clients whose primary interest is the larger scale hospitality industry.

Amicus Supermarket POS - Includes core Amicus functionality, COGS, and Report Viewer (COGS & Report Viewer not available in Express edition). Designed to be used in conjunction with add-ons like PDA & Synchronisation this edition is best used for clients whose primary interest is in large scale sales and stock control.

Add-Ons â€“ A Brief Description

Amicus PDA

Enables usage of a hand held PDA for sales and stock control.

Amicus Report Viewer - A stand alone application which allows the client to run and view reports.

Amicus Smart Docket - Enables usage of a hand held PDA for sales and stock control in a table service environment.

Amicus Sync - Allows the client to configure settings for the Sync Service.

Amicus Sync Service - Allows the synchronisation of data across multiple sites.

Amicus EBET - Allows the client to utilise EBET functionality.

Amicus IGT - Allows the client to utilise IGT functionality.

Amicus PMS - Allows Amicus to charge sales directly to hotel rooms.

Amicus POS new licences

dhosny — Fri, 18 Sep 2009 16:18:27 +1000

Weâ€™ve added some new licence types, which allow more flexibility for our customers. In particular this is useful for hospitality, retail or fuel businesses that do not want all Amicus funcionality at the touchscreen POS interface:

Back office Licences â€“ Allow most amicus functionality (of their standard edition counterpart) with the exception of sale finalisation and meal order creation.

{LICENCE_ID__SUPERMARKET_BACK_OFFICE, "AMI_SUP_BE_DLI", "Amicus for Supermarket Back Office"},
{LICENCE_ID__RESTAURANT_BACK_OFFICE, "AMI_RES_BE_DLI", "Amicus for Restaurant Back Office"},
{LICENCE_ID__FUEL_BACK_OFFICE, "AMI_FUL_BE_DLI", "Amicus for Fuel Outlet Back Office"},
{LICENCE_ID__CAFE_BACK_OFFICE, "AMI_CAF_BE_DLI", "Amicus for Cafe Back Office"},
{LICENCE_ID__GENERAL_RETAIL_BACK_OFFICE, "AMI_GRT_BE_DLI", "Amicus for General Retail Back Office"},

Point of Sale (POS) licences â€“ Basically these are the opposite of the back office licences. They allow sales etc.

{LICENCE_ID__SUPERMARKET_POS_ONLY, "AMI_SUP_PE_DLI", "Amicus for Supermarket Point Of Sale"},
{LICENCE_ID__RESTAURANT_POS_ONLY, "AMI_RES_PE_DLI", "Amicus for Restaurant Point Of Sale"},
{LICENCE_ID__FUEL_POS_ONLY, "AMI_FUL_PE_DLI", "Amicus for Fuel Outlet Point Of Sale"},
{LICENCE_ID__CAFE_POS_ONLY, "AMI_CAF_PE_DLI", "Amicus for Cafe Point Of Sale"},
{LICENCE_ID__GENERAL_RETAIL_POS_ONLY, "AMI_GRT_PE_DLI", "Amicus for General Retail Point Of Sale"},

New Licences - Point of sale only and back office only

dhosny — Mon, 21 Sep 2009 11:26:37 +1000

Hello all

Just a quick note to update you all on the various changes to licensing that have occurred since writing the last blog. We have recently added some more edition sub-groups to licence types, and you will need to be aware of them when talking to Amicus POS clients. Although not separate licence type edition groups (at this stage), they do heavily restrict the functionality and usability of Amicus when compared with the other edition groups.

The first type is designed for Amicus POS customers who need to be able to run Amicus for reporting / accounting purposes, but do not need point of sale (POS) functionality. Therefore we have included a Back Office Licence Type for each of the standard licences (Restaurant BO, Supermarket BO, Cafe BO, Fuel BO, General-Retail BO).

Similarly, we have created another licence type which is designed for Amicus customers who need licences for point of sale (POS) tills, but do not need the back office functionality. Again, we have created a POS Only licence for each of the standard types (Restaurant POS Only, Supermarket POS Only, Cafe POS Only, Fuel POS Only, General-Retail POS Only).

The major benefit of this is that we can offer Amicus POS customers a reduced rate for these licences, as they do not include all functionality. The obvious differences are that BO licences will not allow sale or meal order finalisation, whereas the POS licences behave more like redundancy, and have removed access to reports etc. There has also been a minor overhaul of key-mapping, with actions now linked to specific action types. This was completed to ensure that POS functionality could not be accessed via key mapping when logged in using a BO or POS licence.

It is important to note however, that all licence type edition groups (with the exception of add-ons) and now these BO and POS licences create restrictions to functionality. From the top, Standard licences have no restrictions, Express licences restrict the number of licences available to a customer, BO and POS licences restrict functionality from their standard type.

POS System Customer Card

dhosny — Fri, 23 Oct 2009 12:24:26 +1100

Hey lads/ladies

Just a quick heads-up on changes to the POS system (Amicus). I have cut out the old Customer Card logic (one card per customer) and replaced it with multiple customer card functionality. The main differences is of course that a customer may now have more than one card, but in addition to this, each customer card can have its own pin (encrypted of course) and a hint field as required. On top of this, a customer may have their own pin as well (with or without cards). When a card is used to identify a customer for a sale, we now record the card against the sale, meaning that we can display which card was used to make a sale (now shown on invoices and account statements). We could also expand this further across our suite of reports if required (let me know).

Changes for the user:
Swiping a customer card (or inputting card number in barcode field) on the sale screen will display a prompt for pin (if a pin exists) dialog to the cashier, complete with a hint field (if a hint exists for this card pin). On receipt of a valid pin, the card will identify the customer for the sale. A customer may still be chosen directly at any time, and the sale logic will look for a customer pin. In the event that a customer and their card both have pins, then the pin to use will be determined by the mechanism used. I.e. if a card identifies the customer, then the card pin will be required, otherwise the customer pin.

This change is available to all the standard, express, POS only, and back office licences for all editions (Supermarket, General Retail, Restaurant, Fuel and Cafe) but there is also now additional security in and around the Add / Edit Customer Card Dialog. This new security is designed to limit a staff memberâ€™s access to sensitive customer screens such as the new Customer Card screen, and the Customer Credit Limit screen. A staff member with general access rights to the Add / Edit Customer Dialog will still have their usual access to the details, transactions, history, etc tabs.

This new functionality has been mostly sought after by our Supermarket, General Retail and Cafe clients, so please spread the word that it will be available in the next release.

Cheers

Managing Meal Orders within Amicus POS Software

dhosny — Mon, 09 Nov 2009 14:07:44 +1100

Howdy all

As a result of popular demand we have developed a new dialog for viewing and managing meal orders within Amicus point of sale and business management system for hospitality.

The new Meal Order manager Dialog can be accessed via the usual Meal Order Module menu as well as the Table Service screen, both for cafes and restaurants. It is designed as an easy to use full screen dialog that will display meal orders for a given date range. You can also limit the displayed results by status (open and or receipted).

There are three main buttons which have varied behaviour depending on the meal order selected. The first button is the receipt button, and if a meal order is in the open status, the dialog will send that meal order to the sale screen for receipting. If however the meal order is in the receipted status, then it will load an output dialog displaying the existing receipt (This has also been changed to allow printing directly from this dialog). The second will always print the bill for the meal order, regardless of status while the third is designed to open the meal order (only available for open orders).

Double clicking on a row will also perform specific tasks. If the meal order is â€˜openâ€™, then a double click will open the meal order. If however it has been receipted then this action will open the reprint invoice dialog.

Other tid bits of information include; The user can sort by number, description, date/time or status; If the table service module is present then there will be an additional two (table service specific) columns displayed (Diners, Last Course).

This should be a great addition to functionality for all our Point Of Sale / Hospitality Amicus POS software clients so be sure to let them know about it.

Regards

Dave

Latest update on Amicus POS â€“ Dynamic Payment Types

dhosny — Mon, 07 Dec 2009 09:49:01 +1100

I am currently in the process of removing all the hard-coded payment types from Amicus point of sale and business management system (which is a mammoth task), and replacing them with Dynamic Payment types. This enhancement will allow users of Amicus POS software to dynamically create their own payments types based on a few simple rules (as follows):

Requires Customer
Uses Authorisation Code
Authorisation Code Label
Requires Tendered Amount
Change Threshold
Is Credit Based
Opens Cash Drawer On Completion
Specialised Actions
Uses Payment Terms

We will still be adding the standard types initially (when no other payment types exist). I.e. Cash, Cheque, Card, COD, Account, Finance, Direct Deposit, Gift Voucher, EFTPOS, as well as the standard module payment types (if the modules are present), Charge hotel, EBET, IGT.

This will be an excellent functionality enhancement for our clients with Different needs such as Restaurants, Hotels or Petrol Stations, who will wish to exclude certain payment types from the displayed list, or include custom generated payment types.

This new feature will of course be available for all our major Amicus POS licence types (Restaurant, Cafe, Hospitality, Supermarket, General Retail).

These features should be available in the 05.08 Release. If you have any questions, or would like to influence the design path of this feature, drop me a line.

POS software data exportation to QuickBooks & MYOB

dhosny — Fri, 15 Jan 2010 11:41:58 +1100

Hello Team

Iâ€™ve been playing around with importing data from the Amicus POS system into QuickBooks & MYOB accounting software solutions and have unearthed a little more information that you may not have been aware of in regards to the third party software.

Firstly, let me confirm that the importation process can be automated from the third party software via its front end. Basically it will set up a service that monitors the contents of a folder for a specific file type and uses pre-defined column mappings to import them. So combined with our Amicus POS software data exportation service, this should really be a set and forget process.

Currently we can import invoices & sales receipts into MYOB. In addition to these types, we can also import payments, bills and credit memos into QuickBooks.

Although currently the Amicus data exportation service is geared for quick books, the column mapping protocol for the third party software is quite straight forward, and better still, once we have done it once, we can pass around the Settings.xml file complete with mappings to all customers.

I have found one minor problem with the MYOB importation however. It appears that MYOB is only geared towards a maximum of 8 characters for sale numbers. Currently Amicus revolves around int64 sale numbers (20 chars). We are currently investigating the most efficient way to transform our decimal numbers into a shorter form (perhaps base 36?). What does this mean for our clients? For the majority of our clients (particularly those in single site fuel, retail or hospitality sectors), this will not be an issue. For our larger multi-site supermarket chains however, potentially producing thousands of sale records per day, we will need to give them the modified exportation service.

If you have any further questions, just drop me a line.

Dave

New Discount Reports For Amicus POS

dhosny — Tue, 16 Feb 2010 10:09:41 +1100

Hey all

Iâ€™ve added a couple of new reports to the sales reports section within the Amicus Point Of Sale software.

The first report is called the SaleItemPriceVarianceReport and is designed to list sale items with the intention of displaying how much discount they have had applied to them. It also displays what type of discount they are, or whether they have had a price override.
It filters by all the usual product filters, SiteGroup, Site, Customer, and the user can specifically include sale items that have a zero value variance from the RRP to their actual sell price.

The second report is based loosely on the SaleItemPriceVariance report and shows many of the same values, but is designed to group like discounts for a product. I.e. it will (possibly) show the same product many times with an individual record for each occurrence of a unique discount value with summary information for the total number of units sold at the specified discount value over x number of sales. It displays each unique product as a separate sub report, with each record within a sub report representing a differing discount value. Each subreport also provides summary information for the product, and the report as a whole will show summary information for all items displayed.

An example of this report might show a can of softdrink which retails for $1 occupying one subreport, having 4 separate entries. The first entry will be the largest discount (based on percentage) given for the product (i.e. 40%), followed by lesser variances.

Where a price has been specifically overridden (I.e. a specific discount percentage has not been saved against the record), then a calculated value will be used, based on the calculated total RRP as a percentage of the actual sell price. If no variance is present (and the checkbox to include such records has been checked), then a blank space will be placed in the discount percentage box.

These reports will be particularly helpful for our general retail, fuel, hospitality, and supermarket clients who want to track specific products (or groups) to see how many items have been sold at the various discounted rates.

As always, if you have any queries, come and see me.

Dave.