Another error in Ceil in Tutorial

[Lou_Reed]

What is going on in the Ceil Inn tutorial here:



http://www.functionx.com/access/appl...ns/ceilinn.htm

it asks for a receipt number which I do not have. The receipt number is the primary key and hence this will not work.
I used the occupancy number instead - it was generated by the program discussed before this section. Thus no receipt number
use occupancy number as primary key - correct?

We already know that

1. In the Navigation Pane, right-click Payments Occupancies and click Design View
2. Right-click ReceiptNumber and click Primary Key
3. Complete the table as follows:
   

   Field Name	Data Type	Caption	Field Size	Format
   OccupancyNumber		Occupancy Number
   EmployeeNumber	Text	Processed By	20
   DateOccupied	Date/Time	Date Occupied		Long Date
   AccountNumber	Text	Processed For	20
   RoomNumber	Text	Room #	10
   RateApplied	Number	Rate Applied	Double	Fixed
   PhoneCharge	Number	Phone Charge	Double	Fixed
   Notes	Memo

4. Close and save the table
5. To create a form, on the Ribbon, click Create and, in the Forms section, click Form Design
6. Save the form as Occupancies
7. Using the Properties window, set its Record Source as Occupancies
8. Design the form approximately as follows:

[orange]

I have not done the tutorial, however, I see this regarding Receipt Number in the Payments part

We will need or use the following pieces of information for each payment:

• Receipt Number: A receipt should be given to a customer
• Employee Number: This is the employee who processed the payment. This is usually the employee at the desk when the customer checked out
• Payment Date: This is the date the payment was made. It may not be the checked out date (a customer could pay on the check-iin date or a few days after check-out)
• Account Number: As mentioned previously, when a customer registers with the hotel, (s)he gets an account number. While the customer is using the room, this account number is used to keep track of both the customer's occupancy and phone use. This the reason we decide to create a new account every time, including a returning customer. When the customer decides to pay the bill, the account number holds a summary of his or her consumption
• Amount Charged: This is the total resulting from the customer renting a conference room or occupying the bedroom
• Tax Rate: The government needs to collect its due
• Notes: Comments can be made in this field

Practical Learning: Making Payments

1. On the Ribbon, click Create and, in the Queries section, click Query Design
2. In the Show Table dialog box, click Close
3. Right-click the top section of the window and click SQL View
4. Type the following code: CREATE TABLE Payments
   (
   ReceiptNumber Counter(1001, 1) not null
   );

Note, the tutorial is quite long, so if there is a specific line or item that seems incorrect, please be more specific in the location to assist readers.

Good luck.

[Lou_Reed]

Of course you do not have to do the tutorial! I am just being driven crazy, by all the typos.

The code that I see is like this:

CREATE TABLE Occupancies
(
OccupancyNumber Counter(10001, 1) not null

);

The rest of text I have shown above. We are saving the form as occupancies. The term Payments in the text is Occupancies. After
the table we have created is Occupancies.

Also since it puts out OccupancyNumber that is the first record and it has no need for Receiptnumber.

So I am guessing that Occupancy is also the primary key in this section.

There is similar code for the Payments table (misnamed here a Occupancies) later in the tutorial. Someone told me here that when it says (in the text) Payments put Occupancies
and vice versa.

I think that is right so is OccupancyNumber a primary key.

In the later code ReceiptNumber is the primary key.

Does this seem correct.


Respectfully,

Lou_Reed

[orange]

I'm not sure what you are asking, and don't know the extent of typos. I looked for "Receipt Number" based on your first post and the link you gave, and found it in Payments section. If you found it somewhere else, we may be looking at different things???