This content has been marked as final. Show 3 replies
The standard ticketdownload batch is in my opinion just an example. One will need to build one's own ticket printing subsystem. We had to extend the user interface and datamodel to record additional details about the ticket request, and wrote a new PLSQL package to output an XML file that in our case is sent to a ticket service provider (external printing house, Checkpoint, operates worldwide), in a layout according to their specifications.
In the past we had an internal printing system, using Meto AS40 printers and now Zebra (industrial) printers, and we wrote new programs (in Pro*C at the time, but I tend to avoid Pro*C nowadays) to write the printer instructions to a temporary flatfile, that was then send to the network connected printer using the lpr unix printer daemon.
You may also like to check out the module Oracle Retail Labels and Tags (ORLAT), see e.g. http://www.oracle.com/us/products/applications/061853.html and http://www.oracle.com/technetwork/documentation/oracle-retail-100266.html - it is mostly oriented to the store's backoffice.
Hope this helps, please let us know any additional questions you may have.
Best regards, Erik Ykema
HI Erik Ykema,
Thanks for your reply...
Actually we can print the tickets from SIM(Store Inventory Management) and Using Labels and Tags (BO) but the flat file generated in RMS by running the batch called tcktdnld has a facility that it can print many attributes (predefined and User defined) into the flat file.That is the main reason am searching for any preferred printer for RMS.
Can u suggest me any help.
I believe that the program tcktdnld.pc is not suited for sending to a real, specific printer, it is just the first step in collecting the data, a custom file layout formatting and/or enrichment task will be required.
Please also see Oracle Support note What Kind of System(s) to Use And How Can the Output File of the TCKTDNLD (Ticket Download) Batch Be Sent to Printing System? [ID 550865.1], that confirms my assumption.
The Oracle Retail modules almost always need to be integrated in a custom local way, the package just cannot deal with all end user's scenarios that e.g. MS Office can do with the large customer AND development base.