Skip to main content
Version: 5.x

How-to: Working with documents

Posting documents


There is some logic for working with orders.

CLASS Book 'Book';
name 'Name' = DATA ISTRING[100] (Book) IN id;

CLASS Order 'Order';
date 'Date' = DATA DATE (Order);
number 'Number' = DATA STRING[10] (Order);

CLASS OrderDetail 'Order line';
order 'Order' = DATA Order (OrderDetail) NONULL DELETE;

book 'Book' = DATA Book (OrderDetail) NONULL;
nameBook 'Book' (OrderDetail d) = name(book(d));

quantity 'Quantity' = DATA INTEGER (OrderDetail);
price 'Price' = DATA NUMERIC[14,2] (OrderDetail);

An order edit form has been created for orders.

FORM order 'Order'
PROPERTIES(o) date, number

OBJECTS d = OrderDetail
PROPERTIES(d) nameBook, quantity, price, NEW, DELETE
FILTERS order(d) == o


FORM orders 'Orders'
OBJECTS o = Order

NEW orders;

Besides, a posted property has been added for orders. In the future, only orders with this property will take part in subsequent calculations (for example, calculation of the reserved quantity).

posted 'Completed' = DATA BOOLEAN (Order);
reserved 'Reserved' (Book b) = GROUP SUM quantity(OrderDetail d) IF posted(order(d)) BY book(d);

PROPERTIES(o) posted

We need to do so that instead of the ОК button on the order form, there is a Post button that simultaneously sets the posted property for the order, saves changes, and closes the form.


post 'Complete' (Order o)  { posted(o) <- TRUE; }

EVENTS ON OK post(o)
DESIGN order {
PROPERTY(formOk()) {
caption = 'Complete';

Each time the renamed OK button is pressed, the post action will be executed in a single transaction. With this scheme, if the user wants to "post" a document, they just need to go to the edit form, uncheck the Posted box in the document header, then click Save and Close.

Line selection


We have an order with an edit form similar to the Posting documents example.

We need to add a possibility to enter order lines by specifying the quantify in the table containing the list of products. Any changes in order lines and this table should be automatically synchronized with each other.


quantity 'Qty' (Order o, Book b) = GROUP SUM quantity(OrderDetail d) BY order(d), book(d);
lastOrderDetail 'Last line' (Order o, Book b) = GROUP LAST OrderDetail d ORDER d BY order(d), book(d);

changeQuantity 'Change quantity' (Order o, Book b) {
INPUT q = INTEGER DO { // requesting a number
IF lastOrderDetail(o, b) THEN { // checking if there is at least one row
IF q THEN // inputting a number
// writing the quantity in the last row with such a book
quantity(OrderDetail d) <- q IF d == lastOrderDetail(o, b) WHERE order(d) == o AND book(d) == b;
ELSE // the number is dropped - deleting the row
DELETE OrderDetail d WHERE order(d) == o AND book(d) == b;
NEW d = OrderDetail { // creating a new row
order(d) <- o;
book(d) <- b;
quantity(d) <- q;

OBJECTS b = Book
PROPERTIES name(b) READONLY, quantity(o, b) ON CHANGE changeQuantity(o, b)

DESIGN order {
NEW pane { // creating a container after the order header
fill = 1;
type = TABBED;
caption = 'Selection';

The form will look like this:

If the quantity changes on the Selection tab, the system will automatically change order lines. If the order lines are changed, the quantity on the Selection tab will change as well.

If an order has two or more lines with one book, the system will reset the quantity in the first lines and set the total in the last line. If you want the change to affect the last line only, you need to use the following action during saving:

quantity(OrderDetail d) <- q WHERE d == lastOrderDetail(o, b);

However, users may not understand this behavior, since after they enter a particular quantity on the Selection tab, the total quantity for all lines will be shown in the same column and it will be different from the entered value.

Aggregated documents


We have the order logic.

We need to add some invoicing logic so that an order could automatically create a corresponding invoice.


In order to implement this logic, you need to create an abstract Invoice class with the necessary set of abstract properties.

CLASS ABSTRACT Invoice 'Invoice';
date 'Date' = ABSTRACT DATE (Invoice);
number 'Number' = ABSTRACT STRING[10] (Invoice);

CLASS ABSTRACT InvoiceDetail 'Invoice line';
invoice 'Invoice' = ABSTRACT Invoice (InvoiceDetail);
book 'Book' = ABSTRACT Book (InvoiceDetail);

quantity 'Quantity' = ABSTRACT INTEGER (InvoiceDetail);
price 'Price' = ABSTRACT NUMERIC[14,2] (InvoiceDetail);

A form containing the list of objects of this abstract class is also created. It will contain the objects of all classes inherited from the Invoice class.

FORM invoices 'Invoices'
OBJECTS i = Invoice

NEW invoices;

The edit property will call the current object's edit form defined for its class. If it's not defined for the current object's class, no action will be taken. The DELETE property will delete the current object if it doesn't violate any constrains.

An object of an abstract class cannot exist in the system. In order for the user to manually create an invoice, a separate class UserInvoice is created . Also, it requires the creation of properties symmetrical to the abstract ones that are later added as their implementation.

CLASS UserInvoice 'Custom invoice' : Invoice;
date 'Date' = DATA DATE (UserInvoice);
number 'Number' = DATA STRING[10] (UserInvoice);

CLASS UserInvoiceDetail 'Custom invoice line' : InvoiceDetail;
userInvoice 'Custom invoice' = DATA UserInvoice (UserInvoiceDetail);
book 'Book' = DATA Book (UserInvoiceDetail);
nameBook 'Book' (UserInvoiceDetail d) = name(book(d));

quantity 'Quantity' = DATA INTEGER (UserInvoiceDetail);
price 'Price' = DATA NUMERIC[14,2] (UserInvoiceDetail);

// implementing invoice properties
date(UserInvoice i) += date(i);
number(UserInvoice i) += number(i);

// implementing the properties of the invoice lines
invoice (UserInvoiceDetail d) += userInvoice(d);
book (UserInvoiceDetail d) += book(d);

quantity (UserInvoiceDetail d) += quantity(d);
price (UserInvoiceDetail d) += price(d);

Let's create a form for editing a user-generated invoice. Let's add a button for adding a user-generated invoice to the form with a list of abstract invoices.

FORM userInvoice 'Invoice (custom)'
OBJECTS i = UserInvoice PANEL
PROPERTIES(i) date, number

OBJECTS d = UserInvoiceDetail
PROPERTIES(d) nameBook, quantity, price, NEW, DELETE
FILTERS userInvoice(d) == i

EDIT UserInvoice OBJECT i

EXTEND FORM invoices

For orders, let's create a createInvoice option that will be used for generating an invoice. We will now need to create a OrderInvoice class that will be inherited from Invoice. An object of this class will be automatically created and deleted by the system for every order with the createInvoice option. Therefore, this invoice is an aggregated object for the corresponding order. Aggregation for the invoice line relative to the order line is created identically.

createInvoice 'Create invoice' = DATA BOOLEAN (Order);
EXTEND FORM order PROPERTIES(o) createInvoice;

// aggregated invoice
CLASS OrderInvoice 'Invoice based on order' : Invoice;
orderInvoice = AGGR OrderInvoice WHERE createInvoice(Order order) MATERIALIZED INDEXED;
date(OrderInvoice i) += date(order(i));
number(OrderInvoice i) += number(order(i));

// aggregated invoice lines
createInvoiceDetail 'Create invoice line' (OrderDetail d) = createInvoice(order(d));

CLASS OrderInvoiceDetail 'Invoice line based on order' : InvoiceDetail;
orderInvoiceDetail = AGGR OrderInvoiceDetail WHERE createInvoiceDetail(OrderDetail orderDetail) MATERIALIZED INDEXED;

invoice (OrderInvoiceDetail d) += orderInvoice(order(orderDetail(d)));
book (OrderInvoiceDetail d) += book(orderDetail(d));

quantity (OrderInvoiceDetail d) += quantity(orderDetail(d));
price (OrderInvoiceDetail d) += price(orderDetail(d));

We specify that an attempt to edit such an aggregated invoice will have to open the edit form for the associated order.

edit(OrderInvoice i) + {  edit(order(i)); }

When you try to delete an invoice created for an order, you will see an error message.

The fundamental difference between this aggregation approach and one based on generating an invoice against an order is that the system automatically ensures synchronization between orders and invoices. When creating order-based invoices, the user has to manually modify them if corresponding orders are changed. Otherwise, it will require a separate event handling mechanism that will be responsible for it.