Quick viewing of a query result
During the modification of the posting procedure of the Services document you went through creating quite a complex query.
You might need to ensure that some data read from the database in a query is correct, and view this data as a table.
You can do it easily in Designer. We will discuss this feature using the query from your posting handler.
Suppose that you want to dump the execution result of Query2 to a value table (VT).
- Modify the script as shown in listing 14.34.
Listing 14.34. Posting() procedure (fragment)
... QueryResult = Query2.Execute(); VT = QueryResult.Unload(); SelectionDetailRecords = QueryResult.Select(); ...
- Set a breakpoint at the statement SelectionDetailRecords = Result.Select().
- Run 1C:Enterprise in the debug mode and repost one of the Services documents (for example, Services #2).
The script execution is interrupted at that point and the module text is opened in Designer.
- Double-click the VT word to select it, and then, on the Configuration Debug toolbar, click the Evaluate expression (Shift + F9) button.
This opens the expression preview window with the VT value table.
A value table is a collection, so you can use the standard method of viewing collection data.
- In the Result list, click the VT row and then click the Show Values in Separate Window (F2) button above the list (fig. 14.29).
Fig. 14.29. Viewing a value table that stores the query result
The window that is opened contains the entire value table that stores the query execution result.
You can use the Output list button to export the value table to a spreadsheet document if you want to analyze this data or save it for later use.
After previewing the query result, remember to remove the breakpoint from the document posting procedure and either comment or remove the line that exports the query result into a value table. You do not need it when you perform regular document operations.
Real-time and regular document posting
Let us discuss some specifics of document posting procedures that check the availability of materials in warehouses.
This check is not required all the time. It is required for real-time document posting and not required for regular document posting. So what are real-time and regular posting modes intended for? And how does real-time posting work?
The development of 1C:Enterprise configurations involves the concept of real-time and regular document posting. This concept helps solving tasks related to real-time accounting, such as inventory accounting, and ensures proper document processing in real-life conditions. But you can disable this feature (forbid real-time document posting) and implement your own algorithms that determine the document order on the timeline and perform other posting-related operations.
This concept implies that users can work in two fundamentally different modes.
Real-time document posting is performed in real time, in other words, it reflects the current changes and facts. Real-time posting is particularly relevant when multiple users work with a single application. Therefore, for this posting mode you need to implement the maximum number of checks to prevent errors when accepting user input.
For example, in real-time posting you need to monitor the on-hand balances for listed products in order to prevent a single item from being sold simultaneously by multiple sales reps.
During the real-time posting the platform first compares the document date with the current session date. The current session date is the computer system date converted to the session time zone. If the date of the document being posted matches the current date, the platform posts the document in real-time mode. The event handler is capable of getting the posting mode, so it can select the appropriate posting algorithm.
If the date of the document being posted is before the current date, the document is posted in regular mode.
Regular posting means that the facts that took place in the past or are certain to happen in the future are reflected in the database. Therefore, regular document posting is intended to simply reflect data on completed operations in the infobase.
For regular posting, many checks do not make sense, especially the balance checks. Naturally, if mistakes were made during regular document posting (such as issuing a number of products not available in the warehouse on the posting date), analysis of the resulting database state is a separate task, unrelated to regular posting and performed independently of that process. Instead, this process takes place when the database has sufficient data for analysis, for example, when earlier goods receipt documents are entered.
Hence real-time posting is intended to determine whether an operation can be executed in real time in a multiuser environment (and execute the operation if possible). By contrast, regular posting is intended for unconditional recording of operations that are already completed or will certainly be completed to the database.
Sometimes you might want to post a document with some date in the future in order to reflect some events that are certain to happen in the future. In this scenario the platform does not allow posting the document with a future date if the document is allowed to use real-time posting. You will be warned that real-time posting is not available for this document without any other options to choose from. So you will either need to change the document date to the current date (and then you can post the document in real-time mode), or to a date in the past (and then you can post the document in regular mode). So if the accounting logic suggests that some document should be posted with a date in the future, real-time posting mode should be disabled for this document in the metadata (on the Posting tab of the configuration object editor).
The concepts of "real-time timestamp" and "point in time" are related to real-time document posting. We will not use this information right now but this is a good chance to discuss it because we are talking about real-time posting.
"Point in time" concept
The Date document attribute determines its position on the time axis. A date includes time with one second precision. This allows you to control the document writing order. However, when a large number of documents are created, some documents might have identical dates (because they are created within a single second). How does one determine the sequence of document creation in this situation?
The point in time concept has been introduced to deal with this problem. A point in time is composed of date, time, and a reference to a database object. This lets you explicitly identify the position of any reference type database object on the time axis, but it generally only applies to documents. The point in time also allows you to determine the order of nonobject data, such as register records that are subordinate to a recorder.
The point in time concept is implemented in 1C:Enterprise script as the universal PointInTime object. This object has the Date and Ref properties, which provide you with the option to get the point in time "components", and a single Compare() method that compares two points in time. Besides, a PointInTime object has a constructor and can be created explicitly for any database object of reference type.
For multiple documents that have identical dates and times, the platform determines their order on the time axis based on the references to these documents. The order does not always match the order of document creation, and it is not available to users, so they cannot change the order of documents within a one-second period or determine that one document was created before another.
The platform generates a real-time timestamp at each real-time document posting. The timestamp value is generated based on the current time and the last real-time timestamp generated.
If the last real-time timestamp that was generated is less than the current session time, the current session time is used as the new real-time timestamp.
If the last real-time timestamp is equal to or greater than the current session time, the real-time timestamp is set to a value one second greater than the old real-time timestamp.
So, the platform processes posting of Document configuration objects that have real-time posting enabled (fig. 14.30) as follows:
- When you create a document, the platform assigns the current date and "zero" time to the document.
- When you post a document with the same date (day) as the current session date, the platform assigns a real-time timestamp to the document date.
- When you cancel the document posting and repost it (without changing its date), the platform sets a new real-time timestamp.
- When you attempt to repost a document, the platform sets a new real-time timestamp and posts the document.
- If you attempt to post (or repost) a document with the date (day) earlier than the current session date, the platform posts the document in regular mode.
- If you attempt to post (or repost) a document with the date (day) later than the current session date, the platform prohibits the posting.
Fig. 14.30. Enabling real-time document posting