Integration of 1C from a self-written online store?

Question

1C

What are the risks of integration problems with 1C after creating an online store, what problems can there be, what should be taken into account before creating an online store so that there are no problems with integration?

Answer 1

Problem number 1 - the qualifications of the programmer.
Here at the junction - those who understand both the web and 1C - a few.
In fact, 2 programmers can do it - from the side of the site one, from the side of 1C the other.
They had only a way of interacting according to the data to coordinate.
But in fact, the work is not complicated by anything special, it is quite typical.
I did this integration many times...
Problem #2 - the cost of the work.
Whatever I write there, that the work is "normal".
This does not mean that it will cost a penny.
This or 2 programmers - one from the web, the other from 1C.
Or 1 programmer, but more qualified.
Problem #3
There are additionally some more admin tasks - after all, if you still easily transfer a list of goods with prices in almost any way (yes, even a POST request), then everything is not so simple with pictures.
In my case, custom synchronization to the cloud was used using the S3, OpenSwift protocols. It's not so much administration as just creating an account.
And there is an option with synchronization via Syncthing. And this you need to install and configure Syncthing on two servers (on the web server and on the 1C server).
Problem number 4. You need to clearly understand what you are going to do?
Do I need synchronization in one direction (to a site from 1C products and prices)?
Or vice versa too (from the site to 1C orders)
Is this a one-time synchronization or on an ongoing basis? How quickly should it happen? How to notify one system that another has sent data to it?
Does the catalog of goods in 1C correspond to what will be on the site (companies often simplify the list of goods in 1C for themselves - it’s all the same for the client, and it’s convenient for company managers to work with such a list). But if it will be unloaded "one-to-one" on the site, then an indistinct hierarchy of goods and / or indistinct names of goods is a big problem. Will they want to remake it in 1C so that the site is comfortable? In my case, it was considered more efficient to leave the hierarchy as it was in 1C for internal work and make a second alternative hierarchy for the website. Well, at least the names of the goods are normal.
And how will the website handle the bulk loading of goods (well, for example, reload the entire price list with goods every half hour so that the balances and prices are up to date), won’t this affect ordinary site visitors? We decided this on purpose - products and prices are rarely uploaded, and the rest in another file (compact) - quickly. That allowed to update the balances at least once every 5 minutes. A complete price list with names and prices for hundreds of thousands of products is often difficult to download. Yes, and it is not necessary.
And what will happen if goods A, B, C arrive from 1C to the site, but after that goods B, C will always arrive. From 1C, information about product A will never come again (since product A is no longer purchased). Product A will hang on the site forever? In what condition, with or without residues, at what price?
Will there be bonuses for buyers on the site? And how to make it so that using your bonuses on the site they could not be reused on the site. And vice versa.
How to identify a buyer on the site (this is important for bonuses) so that he is uniquely associated with a buyer in 1C. There is a separate problem here - the product, as a rule, is created only in 1 place, in 1C. And it always goes in only one direction - to the site. But new buyers can be created here and there. How will these two systems understand that we are talking about the same buyer if he is registered twice?
Will the product on the website be manually corrected after downloading and will new downloads overwrite these changes? Or will all adjustments be made only in 1C?
Are you ready to add data storage structures to 1C that are needed only for the site?
But what if you need to organize a very fast download of updates, but the catalog is huge? So you need a partial download. And so that 1C can track what is unloaded from the already changed and what is not, additional data structures are needed in the 1C database.
There is a separate organizational problem when all structures inside 1C want to be left unchanged. Then all fields needed must be stored in very inconvenient auxiliary data structures. This is solvable, albeit inconvenient. If you are making not for a specific enterprise, but a universal system for the purpose of multiple sales and implementation at different enterprises, you will have to go this way.
Etc. etc.