[coldrick]

Issue – P002
Processing a CASH TRANSACTION where the goods need to be ordered and a DEPOSIT is taken in the first instance.

We would like to take a deposit from a customer for items that are not in stock. Process the transaction as a Order/Invoice and then release the items once received to the customer.

Over the last two weeks we have tried every possible method to make this simple transaction work without success. As shown below, the Capital help files clearly state that it is a straight forward process that is standard functionality for the Capital Enterprise Edition.

Can you please assist with identifying what we are overlooking? Could you also please explain how to setup in the install workshop and then explain the process of completing the transaction?


Cash Orders
________________________________________
Cash orders are similar to the more commonly used sales orders. There are, however, important differences. In a sales order an account customer is not billed until at least part of the original order is shipped.
In a cash order system, there are usually no special account provisions made for the customer. The customer may leave a deposit, which is immediately recorded as part of the day's cash takings, and goods are transferred (usually) to the back order system for delivery at some later point.
CAPITAL does not record an expense as having occurred when the cash order is initially entered. It is assumed at some later date that a zero value invoice or delivery docket will be raised (typically produced automatically from the Back Order Control Centre) and the cost of the shipped goods are recorded at this 'release' stage.


Order/Invoices
________________________________________
An order/invoice is a special type of invoice transaction that allows you to order goods and/or sell them in one step.
It achieves this by automatically ordering whatever quantities you enter onto an invoice. This works best when the transaction type is also a lay-by or a cash order. However, this type of transaction will also allow you to invoice for the goods now, and then let the Back Order Control Centre handle the ordering and dispatch of those goods at some later date.
The Back Order Control Centre allows you to produce invoices or dispatch notes at zero sale prices, which would be necessary if you had already billed for the goods.
CAPITAL does not usually allow you to back order directly from an invoice unless:
• The "back order " setting in INSTALLATION Workshop under Invoicing/Other Options is set to Automatic or Manual.
• The account you have specified accepts back orders.
This is not the case if you have selected an order/invoice transaction type. back orders will still be issued automatically if this transaction type is selected, EVEN IF the back ordering option is set to None in INSTALLATION Workshop.
However, if the "back order" setting in INSTALLATION Workshop is set to None, you will be unable to change the default quantity to back order. This will always equal the invoiced quantity.
This situation may be desirable if you want retail staff in a point-of-sale environment to produce a customer order for stock (and also perhaps accept a deposit in the process) in much the same way they would enter a lay-by or a cash sale. You should not mix sale items with ordered items. If the transaction type is an order/invoice type, then all items on that transaction will be sent to the back order file unless you manually override the back order quantity. (Which is not possible under certain parameter selections as mentioned above.)
In some situations you may not want point-of-sale staff entering back order quantities as this makes the whole process of ordering stock more involved and therefore prone to operator error.
A typical point-of-sale set-up might deal with the following transactions:
Description CAPITAL Internal Reference
Cash Sale Receipt
Lay-by Lay-by
Account Sale Invoice
Cash Order Lay-by (with invoice/order option set)
Cash orders are handled by CAPITAL in much the same way as lay-by's in the above set-up, with the only difference being that any items on lay-by are also sent to the Back Order Control Centre where they can be placed on order.

[coldrick]

Attn: Capital Support

I will post some more information on this to let you know what we have tried and what the results are. The above post was done by someone else here but I don't think they have provided enough information to let you know where we are having problems. I'll let you know when the post has been updated.

Rgds
Barry

[coldrick]

What we are trying to do is...

Accept a backorder (goods not in stock) from a non account customer.

Accept a deposit (pre-payment) from the customer which may or may not be the full total of the invoice (or sales order, but prefer to do it through invoicing).

Have that deposit go into the nominated bank account.

When the goods arrive - invoice the goods through backorder control and have the system recognise that a deposit has been taken (or at least that the customer has an unallocated credit amount).

Have the credit amount applied to the invoice (either with or without a prompt).

=====================================

What would be the suggested way of achieving this? You mentioned once before that it could be achieved with a simple script at the invoicing stage if the non-account customers were set up as COD (no terms). Is this still the best option, and if so should the backorders be entered through invoicing or as a sales order? Can you provide the script for this?

=====================================

The closest we have been able to get to the above functionality is if we enter the order as a Sales Order to a COD customer. On saving, the system prompts for a deposit and the payment amount is recorded in the bank account. On invoicing the goods (when they arrive) the biggest problem is that the system doesn't alert the operator to the fact that the customer is in credit until after the invoice has been saved and the operator has been asked to collect another payment. If the operator hits "next" at this point the system then recognises that the customer has unallocated credit and asks if it should be applied. All that really needs to happen is for the "unallocated credit" prompt to occur first so that the system doesn't ask for another deposit on the invoice.

================================

We have tried many methods trying to get this working, and we have had mixed results including deposits not being shown in the bank account until the goods are invoiced (could be weeks later), and deposits not being applied to the invoice at all.

We have a summary file with screen shots which shows all the methods we have tried, and the results we got from each method and we can send it to you if you like, but I'm hoping there is just a simple solution that we have overlooked, or that can be fixed with a simple script.

Thanks.

[COBS Tech Support]

If the system alerted the operator to any unallocated payments pending in the system (on condition that the account's terms was COD) and took that into consideration when prompting for the balance to pay, would that be sufficient for your requirements?

[coldrick]

Hi

The preferred result would be

COD customers

1. Allocate the prepayment prior to asking for the balance to pay. If the prepayment was 100% there should be no prompt for a balance to pay. If the prepayment was only 40%, then the balance to pay prompt would be 60%.

2. A reference on the invoice - "Refer prepayment number XXX and original document number"

Thanks.

[coldrick]

The Cust3.mac script supplied as a sample looks like it will do what we want. Would you agree?

If so, where should we implement it to ensure that it gets processed when an invoice is saved, prior to the request for the payment of any balance?

Is there also a way to have the payment referenced on the invoice?


Rgds
Barry