TIMSS 6: INV620 Packing Slip Mod

I wanted to add email and phone number to the packing slip that comes out of the TIMSS INV620 TRS process. I though I'd have to pay TMAR to do this simple mod because I can't modify the INV620.exe that the process runs. But I was wrong... I don't have to touch the exe.

This process works off a stored procedure: INV620_sp, a view: INV620_vw, and a table: INV620_Processed. So I added my 2 columns to the view (included primary_phone & primary_email_address in the view for the ship to customer), added the columns to the table, and updated the stored procedure to include these 2 columns... and voila! The next time I ran the process, the columns were available in the Crystal Report!

For the Crystal Report, I ran the INV620 process and saved the output as a Crystal Report. Then I opened it, added the columns on the report where I wanted them and saved it as my new INV620_PackSlip.rpt report.

I do have to caution you that anything you mess up and can't fix, TMAR will charge you to fix it. So do it in TTST first and make sure you can undo it. Also when you upgrade, you will be responsible to make sure it still works since you did it, not TMAR.

Applies to: TIMSS6

TIMSS 6: Default Authorized Group for Batches

In TIMSS 6, batches can have an Authorized Group that can use the batch. This allows anyone to use or manipulate the batch who is a member of a given security group.

I have made the default group the one that has my accounting staff so that they always have access to all batches. I have done this by adding a constraint to the table that defaults in the group when a row is inserted into the FAR_BATCH table. I did it this way instead of through extender because there at batches that are created outside of the FAR001 Batch screen, for example TCMS eCommerce batches.

I have hidden this field on the FAR001 screen, so that it's defaulted to that groups and it can't be changed on FAR001.

Applies to: TIMSS6

TIMSS 6: Addresses

There seems to be a lot of confusion on how addresses are stored in TIMSS 6. First of all, addresses are broken into 2 parts: the address & the address detail. The address is stored in the CUS_ADDRESS (AD) table and has the street address (i.e. Address lines, City, State, Zip, Country).

The address detail, stored in the CUS_ADDRESS_DETAIL (CAD) table, has the label name, job title, company, personal line, mail stop, etc. It's stored this way so many customers can share the same street address.

Joining the 2 tables is done on the CUS_ADDRESS_ID. The CAD will have the MASTER_CUSTOMER_ID of the customer we are looking at. The CA will have the MASTER_CUSTOMER_ID of the customer who is the "owner" of the address. There can be many references to the CUS_ADDRESS_ID in the CAD table, but only one in the CA table. If an address is linked, the MASTER_CUSTOMER_ID will be different customers (i.e. the person in the CAD is not the Owner of the address in the CA table).

A primary address for the customer is denoted by the PRIORITY_SEQ field in the CAD. A value of 0 (zero) is the primary. The sequence also controls the display order on the Customer's Address tab.

There are also FORMATTED_ADDRESS and FORMATTED_DETAIL fields in the CA & CAD tables, respectively, that have all the address lines separated by CRLF (carriage return/line feed, ASCII values 13 and 10). These 2 fields can be added together to give the full address label. It's very handy when merging into a document because you only have to use one field and it's already formatted for the given country as you've defined in TIMSS.

When linking to an address (from the ORDER_DETAIL table) there are 3 thinks that make the address distinct: the MASTER_CUSTOMER_ID in the CAD table, the CUS_ADDRESS_ID, and the ADDRESS_TYPE_CODE in the CAD table. A customer can have multiple address, even multiple address linked to the same address, but they must be of different types.

A couple handy views are in TIMSS. CUS_ADDRESS_VW can be used when linking to addresses from orders or committee terms. CUS_PRIMARY_ADDRESS_VW is an easy way to get the customer's primary address. You can always refer to these views for a reminder how the CA and CAD should be joined.

Applies to: TIMSS6

TIMSS 6: Hotel Blocking for Meetings

I don't know how many clients actually use hotel blocking in TIMSS, but we use it extensively. The theory is that when you have a meeting, you book room blocks at hotels and your attendees will stay in those blocks. Usually the hotel will charge attrition if you don't book enough rooms in your block.

TIMSS allows you to take hotel reservation requests with a meeting order. This is not only more convenient for your customers (one stop shopping), but you can also keep track of how many room nights your attendees actually booked at the hotel. TIMSS does not charge the customer for the reservation, instead (using the HTL500 report) you pass the reservations to the hotel and they charge the customer.

To set this up:

1. Setup the hotel as a Facility, adding room types on the appropriate tab
2. On the meeting setup screen for the main meeting product, go to the Hotel Blocking tab and add your hotel
3. Create room blocks at the hotel.

You will need to setup every room type for every night. One nice feature is the Nights box which lets you choose a number of nights to create when setting up a Date. Thus it will copy that setup for so many nights (the field is only available when creating a date).

Once you have setup the hotel(s), when you place an order for the meeting, go to the Product Specifics tab, and click on the Hotel Blocking button to reserve a hotel room for the order.

On this screen, you can search for all room, reserved rooms, or available rooms. Check the boxes for the nights are each hotel and each room type to make a reservation. You can also set flags like Smoking, Wheelchair Access & Special Needs, plus record any persons sharing the room. Credit card information stored on this screen will be passed to the hotel so they can charge the customer.

Now that you have reservations, you need to give them to the hotel. Running the HTL500 process will take all the reservations that haven't been reported to the hotel (based on the Reservation Status) and create a report that you can send to the hotel.

Here are a couple of notes:

1. I changed the field from Non-Smoking to Smoking since most reservations are not smoking you only need to check the box when someone is a smoker and that saved processing time; I also had to modify the HTL500 report accordingly.
2. You need to be very clear on the departure date. If I'm staying on at the hotel from 9/18-9/20 does that mean I need a room on the 20th or only on the 19th. Just make sure you data entry staff and hotel are in agreement.
3. All hotels are different and want this information passed differently. Some will take a PDF and key it in, others want an excel file they can import. The good thing with a Crystal Report is that you can give them either, although you might need to modify the excel file a bit to get it in a good format for them.
4. If you are using TCMS there is a Web Enable on each room block, so if there are rooms you don't want to make available on the web, that's the place to do it. Also in TCMS, to make the reservation, after you've purchased the meeting product, there is a tiny hotel icon( ) on the screen that the user has to click on to get to the reservation screen. I'm trying to make this more visible so that no one misses it... I don't want to be charged attrition!

Applies to: TIMSS6