Welcome to JRI's Help page for Panama's Government Printer

Due to Panamanian government regulations, all invoices going to a customer in Panama must be accompanied by a standardized form. In addition, this form must be printed on a "Government Printer". In our case, we got this setup from a company called WebPOS. All data submitted to the Government Printer must be in a pre-defined XML format.

This package includes a PC running some custom software and a dedicated printer (the Government Printer) that has a special chip in it. This chip apparently does several things. It:

  1. Records all xml files that are sent to it (via the software on the WebPOS PC)
  2. Deletes the xml file off the WebPOS PC
  3. If a file has previously been sent, it will not print the file again (changed or not)

Periodically, the Panamanian government can come in and download the data off the chip. Exactly what they do with this information is unknown. I assume it is a poor attempt at ensuring that they get the correct amount of tax.

This has caused an amazing amount of headache, but if we want to do business in Panama, we must comply with this law.

Known issues are:

  1. There is no way to really test anything
  2. If a document has a problem printing (jams, power loss, etc.) there is no way to print a clean copy
  3. If there were errors on the invoice, there is no way to print a corrected document
  4. The software can only handle 4 digits after the decimal - Avante users 5
  5. Header comments are severely limited and not well documented

The invoice printing programs (sales invoices, credit/debit memos & rental) all had to be modified to handle this. In addition to the normal printing of the documents, all information required by the Government Printer is loaded into a dynamic array. This array is then passed to SYSS9103.1, the universal program to submit data to the Government Printer.

SYSS9103.1 first determines if it is running in the LIVE environment of not. We NEVER want to send a non-LIVE document to the Government Printer! That would:

  1. Eat up a valid file name that could never be sent for real and
  2. Store a "test" document that would look "real" when the government came to read the chip


Next, SYSS9103.1 rips the data out of the dynamic array and massages it as needed. Based on the control data in DSCTBL DEFAULT.NETWORK.LOCATION2 and the account, SYSS9103.1 will call SYSS9100.1 (common Samba command) and ultimately:

  1. Put a backup copy on a network server (\\Daysup.com\apps\AvanteExports\Panama)1
  2. It then puts a 2nd copy on the WebPOS PC (\\22.1.17.142\c$\WebPOSFPrint\OutPutQ)1

1 If run from a non-LIVE account, it will put the xml file in a subfolder 1 more layer deep called either TEST or PILOT.

A service running on the WebPOS PC will grab the xml file in the main folder (but not the TEST or PILOT folder) and submit it to the Government Printer. The xml file is them deleted from the main folder.