You can also arrange for data download or web scraping of your account on the web from American Express to compare to what has been recorded to confirm you are not missing receipts.
All the information needed to properly track credit card transactions is not available from the credit card companies. I wrote an application that is used to track credit card transactions but it does not import from any of the credit card companies because the data is too inconsistent and not coded as to transaction type.
The only issue I seem to be having is missing or lost receipts.
Each credit card bank has its own way of doing things. I have FM scripts that work well with Discover Card and Wells Fargo (includes Visa). It is dependent on them not changing how they support exports, but I have been using both of these for about 10 years without them changing formats. But they could change them tomorrow for all I know. Then again, I can just change my FM script anytime too to adopt any new changes.
That aside, it doesn't sound like credit card transaction comparison is a priority for you. That makes things even easier. Just create a FileMaker file with a good user interface for the mobile devices where they can take pictures of receipts and record the accounting information you need. I think it will work well for you.
If the receipts are saved to a container field, is there any complications in creating a report that prints the receipts saved to a container field?
Well, there might be. The size of the container field will be important; depending on the resolution of the image and the size of the original receipt, it might be problematic to read once printed. So you'll probably have to experiment a bit with that.
Another variable is how will you be printing? If you're going to interface directly with the printer from the mobile device, you'll need a driver for your chosen printer for the mobile device. Some printers have them; others don't. So that might mean creating a PDF instead and then emailing it for printing later. And the PDF might monkey up the resolution on the receipt.
One option to consider would be an upload of the container data to a server / desktop copy of FileMaker so you can bypass some of the mobile printing issues. There are some options for syncing solutions out there (I know EasySync and MirrorSync both support container data, for example; GoZync probably does too, but I don't know that for sure). Or, you can just upload the database from the mobile device once the data are collected and import the records manually. (Painful, but for small workflows, still possible.)
Of course being environmentally friendly and not printing the reports would be nice. Do they need printed or just to be seen on a computer? As Mike said, it is easier to print from a desktop computer. But I would encourage you to look at solutions that avoid creating more paper unless there is a specific need for it.
FileMaker prints the receipts just fine, but within the size of the container you put in the layout. And since receipts vary in size so much, it is hard to find a layout that all receipts look good in. If you just stick with computer access, I usually have a thumbnail of the receipt and if you click on it, up pops a full version that fills the screen. That works well for many of my clients.
Mike and Taylor
Thanks for all the good information.
I probable wasn't clear on this point, but this will be a Filemaker Go solution that will simply take a picture of the receipt. It will be connected to a server at the office and the printing will be done from a Filmaker client connected to the server at the office and then printed to a local printer. The printing feature would be included in the same application.
No syncing necessary. After printing, the receipt would be saved in an archive file.
So you're logging into the solution hosted at the office? Okay, that being the case, here are some things to think about:
1) Bandwidth, bandwidth, bandwidth. If you're on the cell network, be very cautious about the size of the photos you take. Otherwise, you're going to be one of those, "Why is this %#]^*<€ thing so slow?!?" frustrated users.
2) Related to (1), be prepared for situations where you don't have a network connection. Despite our assumption it'll always be available, there are still plenty of times you won't have a signal. Have a contingency plan.
3) Be sure to design the solution for remote / slow networks. Thin tables, lean graphics, etc. Also consider using a transactional model in case you lose connection during an operation (because that can and will happen).