Presets

Before starting work on a mobile device, you must install the root certificate of the 1C: Link service.

In the settings of the mobile application, you must specify the path to information base, published through "1C: Link". A feature of working with mobile applications through "1C: Link" is that the connection to web services is carried out by their names, and not by aliases (aliases). In some mobile applications (for example, 1C:DO), the connection string is generated automatically and does not require the web service name.

Features of setting up mobile applications

1C: Orders

• In the infobase, go to the "Administration" section, select the "CRM and Sales" menu item, check the "Allow data synchronization with the 1C: Customer Orders" mobile application checkbox, click the "Sync settings" link and add a setting for the user.
• Login: 1C user login
• "1C:LINK" setting is enabled
• Tunnel name:<ваш-туннель>
• The "SSL" setting must be enabled to work with IS via HTTPS and disabled to work via HTTP
• Catalog: <путь веб-приложения>

Mobile Document Management

• Enable the mobile client in the infobase settings.
  To do this, go to the infobase as a user with administrator rights, select the menu item "Settings and administration" - "Program settings" - "Data exchange" and check the box "Use mobile clients"
• Connection address: https://<ваш-туннель>.website/<путь веб-приложения>
• Login: 1C user login
• Password: his password

Please note that in order to work with the mobile application, you must have version 1C: Document Management 8 not lower than 1.3.1.3 CORP

1C: UNF

• In the synchronization settings of the "1C: UNF" mobile application, go to the "Other service" section
• In the "application address" field, enter (without ru_RU)
• Specify the login and password of the infobase user and click the "Login" button.

1C: ERP Monitor

• Login: 1C user login
• Password: his password
• "1C:LINK" setting is enabled
• Tunnel name:<ваш-туннель>
• Catalog: <путь веб-приложения>

​

1cfresh accounting client

To synchronize with the Enterprise Accounting Department published in 1C: Link, you can use the 1cfresh Accounting Client mobile application.

• In the settings of the mobile application "Accounting Client 1cfresh" go to the "Other service" section
• In the "base address for connection" field, enter https://tunnel name.link.1c.ru/web application path(without ru_RU)
• Specify the login and password of the infobase user and click the connect button.

​
​

The practice of developing a mobile application 1C 8.3 (part 1)

This article will focus on what I had a chance to try and what rake to step on before I managed to make a more or less normal application for tablets. The application was originally sharpened only for Android, based on the configuration 1C: Orders, and mobile app for development.

Initially, the "wrong" approach was chosen with compiling the application and uploading it to the tablet manually. Let me remind you that for building mobile applications, the Mobile Application Creation Assistant (MobileAppWizzard) is used. Then a beautiful solution was found on one of the forums using a mobile application for development. This application is included in the mobile platform installation kit. At the time of development, platform version 8.3.3.24 was used. In the folder " Android"You can find the file 1cem.apk. This is the mobile application for development. Its biggest plus, which saved us a lot of time, is that you can publish a mobile application on a web server, and on a tablet, specify a path like http://[ Web server address]/[ Mobile app name].

On a tablet PC, in the settings of the added application, you can check the box "Update from the configurator", and each time the application starts, it will try to connect to the web server and check for updates.

After the mobile application was deployed, the process of its finalization began.

What was required:

1. Set up the exchange between the central base and the mobile device.

2. Organize asymmetric synchronization: upload data on the product range, counterparties, stock balances and settlements from the central database, and download only customer orders from the mobile application.

3. Implement a simple interface for managers, where they can quickly view balances, prices and settlements.

At the testing stage, the "Managed Application" intermediate base was used, due to the fact that the 1C: Orders demo application was initially designed for exchange with the Managed Application.

The first pancake came out lumpy. Literally. v82.ComConnector was used to exchange with the central base. I will not go into the details of its settings, there are a bunch of separate materials about this. I'll just go through the difficulties that I encountered.

1. Com-use objects on a 64-bit server OS. A wrapper was used to solve the problem COM+ Applications, which is configured in Component Services.

2. Remote call Com from another server. The called server must have the role application server, and it should be configured COM+ Network Access. In addition, the server Apache must have appropriate rights (i.e. run as a service on behalf of an authorized user)

Having suffered with Com connections, we decided to transfer the working base to web services.

A lot has also been written about publishing web services, but it is written about how it works. How it does NOT work, I will share below.

The working base is deployed on the 8.2 platform, the mobile application, respectively, on 8.3.

When publishing first application 8.3, and then 8.2. periodically snatched out the "Stream format error" glitch in the 8.3 web client, or the error message "client and server platform versions differ." Reposting doesn't help, and neither does restarting. Apache. But disabling the publication and reconnecting it helps.

Further, I caught a funny error when authorizing a user (when creating ws definitions). When testing on a computer, authorization with a long full name is easy. When trying to authorize the same user from a tablet running android, authorization ended before it started. Experimentally, it was possible to calculate that the length of the login in Cyrillic is limited to 22 characters. At the same time, the combination of Cyrillic characters and numbers made it possible to log in with a login of 27 characters long. There is a suspicion that this is due to the conversion of Cyrillic characters. So, for example, in the browser Firefox Wikipedia line "ivo" is converted to "».

Technologically, the mobile platform 8.3.3 currently has a number of limitations. The most expected, in my opinion, innovation is support for requests. But, since the mobile platform does not yet support arbitrary requests in dynamic lists, I had to “go the other way”.

The following approach was used to solve the problem of displaying an item reference book with prices and balances:

1. Two tables have been created in the form of an item reference book. The first is a dynamic list, the actual directory itself. Filter dynamic list configured to display only groups. The second table is the actual balances and prices. When a dynamic list line is activated, the table of values ​​is filled on the server, which is then displayed in the second table. When obtaining prices and balances, an object model was used. All these dances with a tambourine were performed only because there is no method “when outputting a string” or “when receiving data”, which is familiar to a thick client, and it is impossible to dynamically draw numbers in a column.

A similar approach was used in the form of selection

2. The Formatted String was perfect for displaying a string with current prices.

Below is a code example.

&AtServerWithoutContext Function ResidualsWhenRowsAtServer(number)RecordSet is Activated =RegistersInformation.ProductPrices.CreateRecordSet(); RecordSet.Selection.Product.Value = nom; Recordset.Selection.Item.Use = true; RecordSet.Read(); ArrayFormattedStrings = New Array; For Each Set Row From RecordSet Loop ArrayFormattedStrings.Add(New FormattedString(SetRow.PriceType.Description,WebColors.Blue)); ArrayFormattedStrings.Add(New FormattedString(" " + String(SetString.Price) + " ")); EndCycle; Return New FormattedString(ArrayFormattedStrings); // Insert the contents of the handler. EndFunctions

3. To load directories, balances and prices into the mobile application, a web service was used, which receives a parameter structure at the input, and returns a value store at the output. Another unpleasant discovery was the crash of the exchange due to too long processing on the server side. I got the impression that there is some kind of timeout after which the application "thinks" that the connection is interrupted (although in fact the data is still being processed in the working database via the ws connection), and stops the exchange with an error.

To avoid this, it was decided to split the full exchange into portions with the return of focus back to the mobile application. Those. first synchronize the item, then the counterparties, then the balances, etc.

4. To receive reports, the same approach is left as in the configuration 1C: Orders. A web service is called with parameters, a spreadsheet document is formed on the server side of the working base, and then the already prepared spreadsheet document is returned to the mobile application.

In this article, we will consider the initial settings that must be made before starting work with the mobile application.
The mobile application "1C-Rating: Mobile waiter" is used in conjunction with the "1C-Rating: Restaurant" configuration, with which it is connected through periodic data exchange. Therefore, before installing the 1C-Rating: Mobile Waiter configuration, you must make the appropriate settings in the 1C-Rating: Restaurant program.

Setting up the information base "1C-Rating: Restaurant"

All regulatory and reference information used in working with the mobile application is filled in the information base of the "1C-Rating: Restaurant" configuration. Before activating and performing an exchange between the mobile application and the "1C-Rating: Restaurant" configuration, fill in the following data in the "1C-Rating: Restaurant" configuration:

• Directory Organization;
• Directory Stock;
• Directory Cash register;
• Directory Hall;
• Directory Modifiers;
• Information registers Meal modifiers;
• Information registers Predefined Order Items;
• Information registers Stamp printing routing;
• Directory Menu types;
• Directory RMK setup;
• Directory Users.

User setup

Users who will work with the mobile application must be created in advance in the 1C-Rating: Restaurant information base. The user of the mobile application, in addition to the basic settings and roles related to the "1C-Rating: Restaurant" configuration, must have a role that allows the user to work with the mobile application.

Automatic stamp printing

After placing an order in a mobile device, it is possible to print stamps at the places of preparation (kitchen, bar). Stamps are printed according to the following algorithm: in the mobile application, the user creates or changes orders, which are transferred to the central information base of the 1C-Rating: Restaurant configuration. In the central database, they are accumulated in the information register Stamp Print Queue. At the frequency specified in the accounting parameters settings, a procedure is launched that prints stamps from this register of information to the places of preparation.
To enable this feature, you need to configure "1C-Rating: Restaurant" in the settings of accounting parameters in the group mobile waiter set the following settings:

• Print mobile waiter stamps– enabling this option allows you to send stamps with information about the preparation for printing.

• User to print mobile waiter stamps– you need to select a user from the directory Users, on behalf of which the printing procedures will be performed. To print stamps, you must run a session as the specified user. In order to ensure that the stamp printing procedures do not slow down the work of users, it is recommended to create a separate user (for example, “Launch RMK” or “Print Stamps”) and launch a separate 1C:Enterprise session with this user to perform background printing.

• Mobile Waiter Stamp Printing Interval– this setting specifies the time interval in seconds for printing. Filling in this parameter is mandatory for printing stamps. The value of this parameter is selected based on the requirements of a particular organization, the recommended value is 10 seconds.

Publishing to a web server

For the joint operation of the mobile application and the stationary information base "1C-Rating: Restaurant" it is necessary to organize the appropriate infrastructure:
1. In the area of ​​work of waiters should be configured wireless network WiFi.
2. On the computer where the information base "1C-Rating: Restaurant" will be published, a web server must be installed and configured (working with the Apache or IIS web server is supported).
3. The 1C:Enterprise platform and web server extension modules must be installed on the same computer. Modules are installed during platform installation.


4. The information base "1C-Rating: Restaurant" should be published.
5. The computer with the published infobase and mobile devices must be in the same local network.
To publish the 1C-Rating: Restaurant infobase, launch 1C:Enterprise in the Configurator mode (menu Administration - Publishing to a web server). In the window that opens, do the following:

• Manually enter the name of the publication in the field Name, while it can only consist of characters of the Latin alphabet. given name will be entered later in the mobile application settings.
• In field Web server Specify the type of web server to which you are publishing.
• In field Catalog specify the path to the directory where the files describing the virtual directory will be located.
• Go to bookmark HTTP services and enable setting Publish default HTTP services. In the tabular section, check the HTTP service Data in the list of available services.
• Push button Publish. You must restart the server after publishing.

Configuring "1C Rating: Mobile Waiter"

The mobile application "1C-Rating: Mobile waiter" is available for free download to mobile devices from the official Google Play online store. To use the application commercially, you must purchase the required number of Device Licenses and activate the mobile application on each mobile device. To study the functionality of the mobile application, a demo mode is provided that does not require the purchase of a Device license.
The installation of the mobile application "1C-Rating: Mobile waiter" is carried out automatically, and does not differ from the installation of any other mobile application. Updates to the 1C-Rating: Mobile Waiter application are available in the official Google Play online store without any restrictions and registration with 1C-Rating.
When you first launch the mobile application, a form for selecting the operating mode appears. There are two options to choose from: Demo mode And Activate app.
The demo mode can be enabled when you first launch the mobile application or later, after activation, in the settings form, using the switch of the same name.
When this mode is enabled, the database of the mobile application is automatically filled with demo data, which allows you to get acquainted with the functionality product.

Application activation

To work with the mobile application and two-way data exchange with the registration database of the "1C-Rating: Restaurant" configuration, you must activate the application.
There are two options for activating a mobile application:

• Internet activation.

• Offline activation.

Internet activation

To perform Internet activation, you must:

1. Provide mobile device access to the Internet.
2. Enter the registration number in the window Application activation and press the button Activate.

Offline activation

Offline activation is performed if it is not possible to connect the mobile device to the Internet.
To perform offline activation, you must:

1. Get the registration number of the mobile application. To do this, you need to contact the partners of the 1C-Rating company in your region or directly to the 1C-Rating company.
2. In the window Application activation click on the link Offline application activation.
3. In the window Offline application activation enter the registration number of the mobile application.
4. Push button Get application code. A window will open containing the application code. This code must be transferred to the 1C-Rating company. In response will be issued Activation code.
5. The activation code is entered in the window Offline application activation to the appropriate field. At the push of a button Activate the mobile application is activated.
6. After successful activation, the mobile application is ready to use.

Important!

After reinstalling the mobile application, re-activation will be required.

Setting up a connection to the information base "1C-Rating: Restaurant"

After activating the mobile application (by any of the above methods), the user authorization form automatically opens. During the initial authorization, the form contains the following fields:

• User- the user under which work will be carried out in "1C-Rating: Mobile waiter". Mobile device users must be pre-created in the 1C-Rating: Restaurant configuration infobase.
• Password- password for user authorization, specified in the user settings, in the "1C-Rating: Restaurant" configuration.
• Server address– this field specifies the ip-address of the computer on which the web server is running.
• Port– the default value is 80. If the web server was configured on some other port, then its number must be specified here.
• Publication name– the name specified when publishing the HTTP service in the infobase of the "1C-Rating: Restaurant" configuration.

Authorization occurs at the click of a button Connect. The fields Server address and Publication name contain technical data for connection and are filled in at the first connection. The next time you start these fields will be hidden and available only in the settings form.

Important!

The username and publication name must be entered in a case sensitive manner. If the case does not match, then authorization will be denied.

When re-authorizing or changing a user, it is enough to specify the user, enter the password and click the button connect.


After authorization is completed, the order list form opens - you can start working. To create an order, click on the button New order.

Connection messages

When connecting a mobile application to the 1C-Rating: Restaurant configuration, the following messages may appear:

1. "A network error has occurred"

This message may occur if:

• Lost Wi-Fi signal.
• The web server is configured incorrectly.
• The web server stopped working - you need to restart the web server.
• Wrong web server address and/or port.

2. "Insufficient rights to use the resource with this HTTP method"

This message means that the user does not have a role enabled Access to mobile waiter objects.
3. "The requested URL /REST/hs/Data/Registration was not found on this server."
An authorization message occurs if:
Invalid publication name specified.
The name of the publication in the Mobile Waiter differs from the name specified in the Restaurant configurator when setting up the publication (it is necessary to check whether the name of the publication matches, the register of letters is important).
4. "1C:Enterprise 8 application error. HTTP: Not found"
This message occurs if no HTTP service was selected when setting up the publication. It is necessary to check the presence of flags in the setting Publish HTTP Services by default and in the tabular part of the row Data.

• (3475)

Introduction

IN new version 1C platform (8.3.5), a lot of new functionality has appeared. By the way, for those who do not know, there is a resource on which 1C developers describe emerging innovations in the platform. One of these is the mechanism. He attracted my attention, I wanted to implement something for fun. I immediately came up with the idea to make something similar to the site, but with this idea they would not understand me even at the infostart, so I threw it out of my head. It seemed that he threw it away, but the idea was transformed into something not so large-scale, something that could find real use in life - a mobile web application.
I believe that a lightly loaded and simple mobile web application for a limited number of users, for example, employees, can be implemented in 1C using HTTP services.

Mobile web application "Contacts"

I'll start with the result. The Contacts mobile web app looks simple, and it is. At the beginning, you only see a field for searching for a contact.

Let's look for someone (in order for the search to start, you need to enter at least 3 characters). Someone has been found.

Let's call Alex.

Let's write a letter to Timothy.

That's the whole mobile web application.

By the way, it is very easy to adapt to any configuration.

A little about the implementation

Tools used:
- 1C platform HTTP services mechanism (starting from version 8.3.5)
- jQuery JavaScript library (http://jquery.com)
- JavaScript library jQuery mobile (http://jquerymobile.com)
- 1C:JSON()

The "Contacts" HTTP service accepts all requests and passes them to the "ContactsMVP" for processing. All the logic of the mobile web application is concentrated in the "Contacts MVP" processing.

This is what request processing looks like.

Function HandleRequest(Request) Export If MatchesResource(Request, "/index.html") Then Return GetResourceIndexHTML(); ElseIf MatchesResource(Request, "/application.js") Then Return GetResourceApplicationJS(); ElseIf MatchesResource(Request, "/contacts.json") Then Return GetResourceContactsJSON(Request); EndIf; EndFunctions

And so, for example, the return of the index.html page looks like.

GetResourceIndexHTML() Function Response = New HTTPServiceResponse(200); Text = GetLayout("IndexHTML").GetText(); Answer.SetBodyFromString(Text); Answer.Headers.Insert("Content-Type", "text/html"); Return Response; EndFunctions

Nothing complicated. You can study the mechanism in more detail by downloading ContactsMVP.dt

Publication Features

There were some difficulties when publishing the HTTP service, so that it would be easier for you to state some notes:
- There are quite detailed descriptions about the publication - read carefully.
- Do not forget to run the configurator as administrator before publishing.
- It was possible to start the HTTP service only with the file version, some error occurred with the client-server version.
- In order for the mobile web application to work without an authorization request, if there are registered users in the database, then after publication, in the default.vrd file, the Usr and Pwd parameters must be added to the connection string (point.ib).

Conclusion

I hope the material of the article will be useful to you.

Thank you for your attention.

Using the example of the mobile application "1C: Managing our company" (abbreviated as UNF), I want to show the evolution of a mobile business application from its inception and the release of the very first version to the present day. Now this app has over 220,000 downloads; the application is free, but it has paid options (implemented through in-app purchases).

The first version of the mobile UNF was made on one of the first versions of the 1C:Enterprise mobile platform in 2012. At that time, there was already a client-server configuration "1C: Small Company Management" (then the name was like that), a program for automating the activities of a small company - sales, purchases, customer and supplier database, warehouse management, production, etc.

Like most mobile applications written on the 1C:Enterprise cross-platform mobile platform, mobile UNF is available on iOS, Android and Windows.

The task was set as follows: to make a mobile application that supports part of the work scenarios of the "big" UNF. The application must be able to work both autonomously and synchronize data with the "large" UNF (hereinafter, the word "large" in relation to the client-server version of the UNF, I will write without quotes so as not to overload the text). In the case of working with a large UNF, scenarios of "mobile" employees - a sales representative, a service engineer, a salesperson - should be supported.

The first version was created in 1 man-month. When creating a mobile application, some of the metadata objects (directories, documents) were implemented on the basis of large UNF objects. But some of the functionality had to be programmed from scratch, for example, the process of exchanging data with a large UNF. True, in relation to data exchange, we had to actually program a little - we used standard platform mechanisms (in particular, exchange plans), which reduce code writing to a minimum.

In addition to simplifying work with data synchronization, the 1C platform significantly facilitates the design of a full-featured mobile application by providing the developer with such interface components as lists (tabular and hierarchical) with the ability to search through them, input fields with search, tables for reports, a wide range of charts, the ability to printing on WiFi and Bluetooth printers, etc.

Mobile version features

There are two main strategies for choosing the functionality of a mobile application. The first one is “one application – one function”. For example, a mobile application for receiving goods in a warehouse, which can only scan the barcode of the goods with the built-in camera and send information about the received goods to the server. The second strategy is to create a mobile application with wide all-in-one functionality. Both approaches have the right to life; when writing a mobile UNF, we chose the second approach - our application covers many tasks in its subject area and can work completely autonomously, serving the needs small organization. Another plus of this approach is that the user can work with several interrelated functions from one application.

Mobile UNF widely uses the functionality of a mobile device, in particular:

• The built-in camera of the device can be used to take pictures of the product when filling out the product card, to read bar and QR codes
• The invoice for payment can be sent to the client by email or via SMS
• The counterparty can be selected from the address book of the mobile device
• If the counterparty has a phone number, you can call the counterparty or send an SMS with one touch; if an email is specified, send a letter; if an address is specified, show it on the map
• Can print documents to printers via WiFi and Bluetooth

There is an option to backup and restore the mobile UNF database to Yandex.Disk and send the database by mail.

The configuration of the mobile UNF looks quite spartan (see the screenshot below):

• 8 reference books (in the large UNF - 273 reference books)
• 7 documents (in a large UNF - 125)
• 3 journals of documents (in a large UNF - 24)
• 3 registers of information (in the large UNF - 357)
• 4 accumulation registers (in a large UNF - 64)

The main objects of the mobile UNF

But, despite such a small number of application objects, the product turned out to be quite functional.

An interesting feature of the mobile UNF is that it is often used by people who have not heard of 1C before (yes, there are some in our country), those who needed a mobile application to keep records of their small business (for example, home crafting). They just found it by searching Google Play or the AppStore, read the reviews, and started working.

Offline work

This scenario is designed for very small organizations, when all accounting is done exclusively on a mobile device. This may be, for example, a "home" business - making jewelry at home and selling them on the VKontakte page. Or maybe even a small store - I personally saw a case where a toy store specializing in the sale of Lego constructors, kept records exclusively on mobile version UNF. Given that the mobile UNF can print on WiFi and Bluetooth printers, it can be used to solve a fairly large number of tasks. Mobile UNF supports the processing of orders, the input of incoming and outgoing invoices, accounting for the receipt and expenditure of money.

Work in synchronization mode with the server (first versions)

In synchronization with the server in the mobile UNF in early versions accounting functionality became unavailable, and work in it was carried out mainly with orders (receiving and fulfilling orders) and related activities (maintaining directories of counterparties, goods and services, etc.).

Synchronized with a large UNF directories of goods and services, contractors, and orders.

Data exchange between mobile and large UNF in the first versions

Orders entered from mobile devices ended up in a large UNF, and when synchronized, they ended up on the mobile devices responsible for the orders. Documents such as cash receipts, sales of goods, etc., entered on mobile devices, went to a large UNF, but were not synchronized between mobile devices. All work in the mobile application in synchronization mode was carried out mainly around orders - their acceptance and execution, while full-fledged accounting on a mobile device was not carried out, for this it was necessary to use a large UNF on a computer.

This was the case in the first versions, but later we changed the situation and expanded the list of scenarios for using the mobile UNF to make working with it more convenient for users.

A little about data synchronization

Data exchange between mobile and large UNF goes through web services; mobile UNF invokes web services deployed on the side of the large UNF. The data structures in large and mobile UNFs are different; when designing the architecture, we considered 2 options for data exchange:

1. Create a data structure in a large UNF, duplicating the data structure of the mobile UNF, and exchange data with the mobile UNF "one-to-one". When changing data in a large UNF, it is necessary to transfer the new/changed data to this duplicate structure, and after exchanging data with a mobile UNF, convert the data that came from the mobile device and placed in the duplicate structure into the large UNF format.
2. Exchange data directly with the structures of a large UNF, converting data "on the fly" according to the exchange rules.

We decided to opt for the second option. The first option, although it promised some advantages associated with the simplicity of the actual data exchange, poorly handled the situation when the data structure changed (expanded) in the new version of the mobile UNF; in order for the one-to-one data exchange to continue to work, it would be necessary to update the server, large UNF. Which, for many reasons, was unacceptable.

The data exchange mechanisms implemented in the platform take on most of the work of forming packages for data synchronization, allowing you to reduce code writing to a minimum. In the exchange process, the standard mechanism of the 1C: Enterprise platform is used - the data exchange mechanism; for each mobile UNF, a data exchange node is created in the large UNF, a change registration service is used in the large and mobile UNF to track data that has changed since the last synchronization, and so on.

The mobile application initiates data exchange, forms an exchange package using the platform mechanisms (containing the mobile application identifier and data updated on the mobile UNF since the last synchronization) and sends it to the large UNF. Based on the information in the start package, the large UNF prepares for the mobile UNF the data changed in the large UNF since the last synchronization, and packs them into packets. Packages in XDTO format are 1C metadata objects serialized in XML; the size of each package is no more than 500 objects.

Mobile UNF takes this data packet by packet. After downloading the last package, the mobile UNF begins to process the received data - to post documents, write reference books, etc. In the event of a connection break, packets are resumed; we wrote the resume mechanism for the UNF ourselves (it is not in the platform), but since the mobile UNF is supplied in source codes, developers can look at the implementation of the mechanism and borrow it for their applications.

During the initial synchronization of a mobile UNF with a large UNF, you cannot work in a mobile UNF - a modal window appears showing the progress of the process. All subsequent synchronizations are background and do not block the operation of the mobile UNF.

The full list of objects exchanged between mobile and large UNF:

• Reference books:
  • Nomenclature
  • Counterparties
  • a list of users
• Documentation:
  • Buyer orders
  • Checkout
  • Checkout expense
  • Purchase Invoice
  • Sales Invoice
  • Production
• Registers (but not all prices, but only the main ones):
  • PricesSuppliers
  • Prices of Goods
• Organization details:
  • Name
  • Tax Information

In a large UNF, goods have pictures - images of the goods themselves. In order to minimize traffic, we do not upload pictures to the mobile UNF, they are loaded on demand - for example, when we open a product card in the mobile UNF.

Product card with product image

Application evolution - developing use cases

A typical situation is that the business is growing, and the functionality of the mobile UNF on one mobile device is no longer enough. Another employee (or employees) appears in the business, and they also need to work with orders.

In the first versions of the mobile UNF, the migration scenario was quite straightforward - the data entered in the mobile UNF was copied to the database of the large UNF, and the user had to keep records on the computer from now on. In this case, the mobile UNF will work in the mode of working with orders, and it will no longer be possible to keep records (as on the standalone version of the mobile UNF).

This, of course, was not very convenient for the end user - he was already used to keeping records from a mobile device, and here he was forcibly forced to move to the computer keyboard. Not everyone will be happy with this.

Therefore, we have expanded the list of scenarios for the operation of a mobile UNF. This was helped by the emergence of our cloud service http://1cfresh.com, based on cloud technology 1cFresh. It became possible to place a large UNF in the cloud. We have described three scenarios for using a mobile application as the user's business grows:

1. Quite a small business. The account is kept on one mobile device.
2. Business is growing - employees have appeared. You can put a mobile UNF on mobile devices of employees. At the same time, you need to be able to exchange data between mobile devices to synchronize data; To do this, we decided not to use the exchange through files, but to use for synchronization (and at the same time for backup) a version of a large UNF located in the cloud http://1cfresh.com. When this script is enabled, a large UNF instance is created in the http://1cfresh.com cloud, the base of which will be used to synchronize data between mobile devices. The use of one mobile device in such a scenario is free of charge, for each additional device we charge 75 rubles / month, you can use no more than three devices in this scenario. At the same time, users of mobile devices can be assigned predefined roles - sales representative, service engineer, seller (it is also possible detailed setting roles); the functionality of the mobile application will be limited accordingly. You can also work through the web client or thin client with a large UNF hosted in the cloud, but the functionality of the cloud UNF will be reduced to the functionality of a mobile UNF. But it is not necessary to work directly in the cloud UNF - all work can only be done from mobile devices.
3. The business has grown to the size of an average firm. In this case, it makes sense to rent a full-fledged version of a large UNF in the cloud in order to get (via a web client or thin client) additional functionality - CRM (there are plans to include CRM in a mobile UNF, but so far it is only available in big version), warehouse management, advanced pricing, the ability to work with banks, etc. In this case, the number of mobile devices operating with a large UNF is not limited (each device is charged additional fee according to the tariff , as for one workplace; 1 license for UNF in Fresh or for a “boxed” UNF gives the right to use 1 mobile application for free).

Application monetization experience

The UNF mobile application, as I already wrote, is free. Some time ago, we decided to monetize our application (using the in-app purchase functionality implemented in the 1C:Enterprise mobile platform version 8.3.8), selling additional functionality - production, and the ability to synchronize with additional mobile devices.

The purchase of the "Production" functionality is a one-time purchase, and the ability to synchronize with additional mobile devices is framed as a subscription that needs to be renewed every month. Interestingly, within 3 weeks after adding the functionality of purchases, the mobile UNF got into the top 15 Google Play in terms of sales of applications for business.

Conclusion

Mobile UNF is a relatively small (in terms of the amount of source code), but quite a popular product. We hope that the story about its evolution will be useful to the creators of mobile end-user products both on 1C technologies and on other development tools.

It would be useful to recall that on the 1C mobile platform, you can make applications that interact not only with the 1C server backend; protocols used for data exchange in mobile applications on the 1C platform are platform-independent (web and HTTP services, support for XML and JSON, etc.). So if you need to quickly and dynamically develop a cross-platform (Android, iOS, Windows) mobile client, and with the ability to work offline without a constant Internet connection for your business application, then the 1C mobile platform may well be the best choice for you.