Lesson 2-4

Services document posting

Let’s implement the same posting procedure for the Services document. Do not forget to select the Expense register record type for the Platform to subtract the Materials quantities from the balance.

Now, when the Posting event handler is implemented, let’s post this Services document:

This is what we get in the Main table of the BalanceOfMaterials accumulation register:

Note that all GoodsReceipt materials will be added to the Balance table, whereas Services materials will be subtracted from it. Here is what we will see in the Balance table of the BalanceOfMaterials accumulation register:

There are 25 (+ 10 + 20 - 5) extension cords and 47 (+ 50 - 3) PVC pipes left of the Main Warehouse.

Differentiation of material and service

A couple more things we should take into consideration:

• Filling out a GoodsReceipt documents’ tabular section, a user theoretically can add a service instead of material. It definitely does not make any sense, and the user should be prevented from doing this.
• Our Services documents can (and will) contain not only materials but also services. And we don’t want to store services “balance” in an accumulation register because there is no such thing.

It looks like, whereas earlier in this Lesson we found it reasonable to combine materials and services into a single catalog, now we can see the drawback - a necessity to treat them differently in some cases. OK, let’s do it.

First of all we need to learn how to tell a service from a material. The hierarchy we have created in the MaterialsAndServices catalog won’t help us here, because we cannot base the source code logic on the knowledge of data (users can change the data, and the code may stop working).

So we need some way to mark items in the MaterialsAndServices catalog as a material or a service. In other words, we need to add one more attribute to the catalog. But what type it has to have?

The best choice here is an Enumeration.

Enumerations

Enumeration is a list of values that is defined in the application (rather than stored in the infobase data). Only developers can change the content of an Enumeration, so you can consider this as a fixed list of values which fits to base any source code logic on it. You want to use enumerations when:

• The list of values are fixed, so users are not supposed to add, edit or delete anything from the list;
• Your source code needs to work differently depending on the selected value.

If your list contains fixed part, but users can add new items to the list, you should use a catalog with predefined elements.

Here are few examples of enumerations:

• Gender
  • Male;
  • Female.
• Car body type:
  • hatchback;
  • sedan;
  • SUV;
  • …
• Tourist accommodation types:
  • Camping park;
  • Hostel;
  • B$B;
  • Hotel;
  • Resort;
  • …

Enumeration creation is perfectly straightforward. We need to add a new Enumeration and then add two values: Material and Service:

After that, we need to mark every MaterialsAndServices catalog item as Material or Service. To do so we need to add a new attribute to the catalog:

and specify an appropriate type for every item in the catalog:

 Lesson 2-3 | Course description | Lesson 2-5