It is a well-known fact that when selling into a shop, it is very important to minimize the processing time in order to decrease customer wait time. From EnterpriseOne's perspective, this means that the releasing of the sales order and the printing of the receipt needs to be as quick as possible.
Regarding printing of a receipt: we recommend using the software programs developed or offered by the manufacturer of the particular cash registers or printers because they are optimized for their devices' speed. Such programs are Fprint of Datecs, Tremol Zfpcahs, Daisy Dprint, and ISL File Drive of ISL. EnterpriseOne supports all of the software listed above. During the printing, a small file is created and is sent to the printer/cash register. The file's creation is pretty fast and practically does not requires much time.
The issues regarding the releasing of the sales order are more complex. Releasing time is proportional to the number of sub-documents generated with the release of the sales order. Generally speaking, each sub-document takes from a half a second to a few seconds, depending on the document and the size of the database. For example, a store transaction is a complicated document which, when released, checks the availabilities, changes inventory and available to promise quantities which are relatively heavy procedures. Some documents are not tied to such complex logic and therefore run faster. However, creating and releasing documents takes time, although the process is a subject to certain optimizations, this time cannot be fully avoided. For example, when releasing a sales order with 20 sub-documents, it can not be expected the change of the state to be completed in less than 20 seconds.
Still, a significant time reduction can be achieved by a decrease in the number of sub-documents that are released simultaneously with the release of the sale. Of course, the sales order may have a long document flow for a reason. So the right decision is to divide the flow into separate stages - the first is going to be performed at the moment of the sale and the second later.
The separation could be achieved using user statuses for the system state Release. For example, these statuses could be "Sale" and "Completion". Upon releasing, the process must include only the most needed documents, such as payment orders, payment transactions and store orders on document state Planned. It is advisable the store order to be created with the first set of documents in order to update the quantities available to promise, the generation procedure on a planned status is relatively quick. When the document state is changed on the user status "Completion", the procedures generate the rest of the documents - invoice order, store order on a released state, payment order and more.
In this way, while the customer is still in the shop, the sales order is released on a user status "Sale" cash and the receipt is printed. This will take a minimum amount of time. Quantities available to promise still could be monitored using the “Physical and Available to Promise Report” as we will have a generated store order.
The second stage of the sale can be performed at the end of the day or in the free time when there are no customers in the shop. This stage includes the mass change of the sales orders’ user status to "Completion". This will allow the goods to be issued from the store, the cash register to be balanced and the invoice orders to be created. Employees will not have to enter another navigator, the change can be performed through the same Sales Order Navigator which they normally use.
If an invoice is required, the user state has to be directly changed on "Completion", but this is necessary only for a small number of the sales during the day and a few seconds longer won’t be in such matter.
In the future, once the BPM module is implemented in EnterpriseOne, the second sale stage can be automated. Within a few minutes or even seconds later, the user status of these sales order could be automatically changed to "Completion". However, this will not affect the workflow in the shop itself as the operation will be performed on the server. This will allow all subsequent operations to be near up-to-date or even real-time with a minimum customer wait time.
The approach described above (two-stage-sale) is already being implemented in real use cases and gives excellent results. So we recommend business which include retail/shop sales to start using it.