This is the eighth edition of my SHIMS blog. If you would like to look at previous editions, you can find them at: Ed’s SHIMS Blog.
There are a lot of changes happening in the SHIMS world these days and I thought you might find some of them interesting.
So here goes.
Doing business with Amazon (and others)
Some of my customers get a lot of orders from Amazon. They certainly appreciate that business, but processing so many orders creates challenges.
I have been working with them on automating some of these processes.
The first step is creating all those orders. Amazon sends a spreadsheet containing:
– an identifier for each order
– a SKU
– a description of the product sold
– the quantity sold
– the price
The Amazon Order Creation program I developed keeps track of the identifiers used, so there is no danger of shipping the same order twice.
However, the SKU that Amazon sends may not be a valid SHIMS Alternate Code. In addition, the SKU sent may indicate a pack of 10, when what is sold is just a single item.
To handle those issues, there is (within the Amazon Order Creation program I developed) a new Amazon SKU Maintenance program which allows entry of the Amazon SKU, the corresponding SHIMS Alternate Code, and a multiplier to address the ‘pack of 10’ situation.
If the program still cannot identify the product sold, it enters comments on the SHIMS sales order showing the Amazon SKU, description, quantity and price.
Tax is another issue related to order creation. One of my customers uses my interface to the TaxJar service to compute the tax. Another has Amazon pay the tax so that all the orders my program creates are non-taxable.
Once the order is created, it is printed as a pick ticket. The order is then ready for invoicing, unless there is some change.
Suppressing the pick ticket print and picking from a printed pick list is another option to use for order picking.
Amazon pays its vendors in a single payment which covers the orders from a previous period. Determining the specific invoices paid is not easy.
As a result, the program I developed exports open Amazon invoices to a spreadsheet. They are then matched to data sent from Amazon.
Once the exact invoices to be paid have been determined, the invoices are uploaded to SHIMS and paid, with no manual intervention required.
This routine for cash application is one I have used many times. Even if you do not have Amazon as a business partner, you may be spending more time than necessary posting cash. This program may help you.
eBay, Walmart and other Partners
Other businesses like eBay and Walmart operate in a similar way. We have not addressed them yet, but I think it is likely that what we have done for Amazon would help with other business partners, too.
This continues the subject of SHIMS dictionaries.
In the previous post Ed’s SHIMS Blog Issue 7 I covered the basics. Now we will look at how to do:
Lookups to other files
I will also discuss some tricks for controlling the width of what prints.
Here is a dictionary for the CUSTOMER file which shows the price class description
Recall that in Customer Maintenance you assign each customer a price class. This is just a number like 10. In Price Class Maintenance you can enter 10 as a price class and a description showing what 10 means.
With the CLASS.DESC dictionary you can then do this:
As you can see, you can display the data from another file in a report that works off the CUSTOMER file.
Here are the most important parts of this dictionary:
On line 1, there is an S; it could also be an A. However, the convention we follow is that A dictionaries are the simplest ones. They just show a single attribute in the file, and CLASS is such a dictionary, so it is an A. CLASS.DESC is more complex, and it is an S.
One line 2, there is a 37 which is the attribute number of the CLASS field. That is the field we want to use to look up a CLASS.DESC record.
That works together with line 8. The idea here is: take the CLASS field (attribute 37) of the customer, find the CLASS.DESC record, and return the first attribute of that file. The first attribute is where the description is stored.
Breaking this down a little more:
TCLASS.DESC says: “find the CLASS.DESC record” and ;X;1;1 says: “return the first attribute”.
Why use ;X;1;1 rather than just 1?
The answer is that you might want to grab something other than a single attribute, and this format provides for that. For example, ;X2;1;1 says to grab just the second value of the first attribute.
There are then just two important things:
- Entering the field# where the price class is stored in the CUSTOMER file in line 2 of the dictionary.
- Using that to look up the PRICE.CLASS record and return attribute 1 of that.
We are assuming that you know where the price class is stored in the CUSTOMER file, what the name of the CLASS.DESC file is, and where the description is stored in that file. That is a lot to know, but if you do know those things, then it is easy to link the two files using the CLASS.DESC dictionary.
You may have been wondering about the other fields of this dictionary:
I will discuss line 7 shortly .
Line 9 says that the output is to be left-justified on the page. Since this is alphanumeric data, that makes sense.
Line 10 says to use 25 columns for the output.
The description field in the CLASS.DESC file holds 30 characters. As a result, you might have started with 30 in field 10. However, that might be too much. If you wanted the output to fit in 80 columns you need to shorten some fields.
But doing this can lead to another problem: wrap-around. Suppose you set the width of CLASS.DESC in line 10 to be 12. Then (leaving line 7 blank), you would end up with a report like this:
You might not want to show 2 lines per customer.
That is where line 7 is useful.
This says to display just the first 25 characters. That gets rid of your wrap-around problem.
If you put this in line 7
the output would skip the first four characters and then print the next 25 characters.
This blog is for educational purposes only. Zumasys makes no representation, express or implied warranty, or guarantee about completeness, accuracy, or usefulness. By using the information, you agree it is your sole responsibility to independently determine the suitability of the information for your particular situation and you agree that neither Zumasys nor its agents will be liable for any damages arising from or related in any way to the information.
The content in this blog is the intellectual property of Zumasys and you may not reuse, republish, or reprint the content without the prior written consent of Zumasys. All third party trademarks remain the property of their respective owners. Unless specifically stated, the use of such trademarks does not indicate any relationship, sponsorship, or endorsement.