The SHOP interface to nopCommerce goes far beyond the transfer of articles and orders. Essentially, articles with pictures and the assignments in the characteristic tree, prices and warehouse stocks are transferred to the SHOP and in return, orders and customer addresses are read out by the SHOP and created in EULANDA. However, there are many practical functions in detail, which are now listed in detail.
SHOP systems allow the hierarchical search for articles. This type of classification is also called catalog, category or category there. This division can also be found on eBay, Amazon and others. In EULANDA these are generally called characteristic trees, since they are available in all modules, like addresses or offers etc. and are not limited only to articles.
So that you can continue to use the characteristic tree within EULANDA for your own purposes, you can only use an excerpt from it for the SHOP interface. You can specify the branch from which the characteristic tree is to be transferred to the SHOP. Each characteristic folder in EULANDA can contain its own characteristic folders. The last folder then contains the actual catalog element. Articles can be assigned to a characteristic more than once.
The characteristic tree is transferred to the SHOP system with the articles and their assignments. Each characteristics folder can contain its own image and a description in the SHOP. The entries for this are made in the properties dialog of the characteristic within EULANDA. You no longer have to create a catalog manually in the SHOP, the interface takes over the synchronization.
Assignment of Characteristic Tree to Catalog
The complete characteristic tree, in this example from the "\SHOP" branch, is transferred to the SHOP system.
Images in the Characteristic Tree
You can store images in the characteristic tree by specifying the simple file name in the properties of the characteristic. To do this, the keyword "IMAGE:" must appear in the first line followed by the file name.example: IMAGE:test.jpg
The image itself must be located in the "CHARACTERISTICS" subfolder in the DMS article folder. For example, if the document system DMS is on the network share "\\MyServer\DMS", the article folder is automatically \\\MyServer\AMS\article. The folder for the images of the feature tree would then be \\MyServer\DMS\Artikel\MERKMAL".
Please note the spelling of the image name, it must exactly match the spelling in the characteristics folder, since the images may be saved on a Linux system. Such systems are case-sensitive.
The images are transferred to the SHOP and are then visible as catalog selection depending on the layout.
Publish a feature
Normally all characteristics are published in the SHOP. However, the line"PUBLISHED:0" in the property of the characteristic can be used to suppress publication. The characteristics folder is then transferred to the SHOP, but not displayed on the Web page.
The line"PUBLISHED:1" publishes a characteristic, but this is the standard, so this information can be omitted.
If the"IMAGE:" line is also used, it must appear in the first line of the properties.
This allows you to test individual areas beforehand and then publish them as needed.
Please note that the articles on this feature are published independently according to their own rules. An article can therefore also be found using the full text search if a characteristic is suppressed.
Exchange of articles
The articles and their texts are also transmitted in several languages. In EULANDA, the corresponding correspondence language is required as an option for several languages.
EULANDA has several text fields. However, only the"Long text" and"Info text" fields are suitable for display in the SHOP, since only these are multiline and this is the only way to divide the texts into subsections. In the SHOP itself, handy short texts are required for overviews. On detailed pages headlines are required and additionally short descriptions, as well as a detailed description and texts which are suitable as link labels.
Both EULANDA and the SHOP system are available in several languages. One or more of the optional correspondence languages are required on the EULANDA side so that article texts and also the catalog (= characteristic tree) can be displayed in different languages. The language separators are used to enter text in square brackets. [DE] for German,[EN] for English, etc. The codes are divided into two-digit language codes according to ISO 3166. A long text in EULANDA for the three languages German, English and Italian would look like this:
Profi-Aqua perlglanz perlmutt - 12 ml
Profi-Acqua Brillante madreperla - 12 ml
Profi-Aqua pearlised pearl - 12 ml
In SHOP systems, however, normal long texts are hardly sufficient today. In addition to the text description, a clear and concise short text, technical descriptions and other information may be required. So that these things can be accommodated in EULANDA, there is the possibility to create text subgroups. A complete long text in the three languages mentioned above could look like this:
Perlglanz Perlmutt - 12 ml
Brillante madreperla - 12 ml
Pearlised Pearl - 12 ml
Profi-Aqua perlglanz perlmutt - 12 ml
Profi-Acqua Brillante madreperla - 12 ml
Profi-Aqua pearlised pearl - 12 ml
For clarification the next picture shows the same article directly from the EULANDA mask. The short texts from EULANDA are not particularly easy to process in the SHOP area, since they are only single-line and therefore too short. This can be remedied by subdividing the long text into individual sections, whether for languages or for text areas, for example: [EN:SHORT].
Eulanda Article Mask
In the SHOP system, the languages are then displayed in such a way that the entire system can be switched between the supported languages via a selection box.
Shop display of the article mask
Switching in the language is normally automatic. For example, if the customer comes from Italy, the language Italian is proposed. The user can still switch the language at the top left. If he is also a regular customer with an account, the system also remembers the language and automatically suggests the last language selected.
In the detail area of the article there is another text in the lower area, this is taken from the INFO text from EULANDA and is used for the technical description of a product.
The catalog on the left corresponds to the characteristic tree from EULANDA. In the properties of the characteristics of EULANDA, the text can be specified in any language.
Languages in the Characteristic Tree
The interface automatically generates useful links for search engine optimization (SEO) based on the characteristic names. The text of the characteristic is converted accordingly and made unique. Characteristics also represent unique short links that can be used directly in newsletters, for example.
Within EULANDA any manufacturer and also a manufacturer number can be stored for each article, these will also be transferred
The manufacturer will be created in EULANDA as normal address and then activated in the actions menu as manufacturer. In the article, the manufacturer can then be assigned on the extended index card. The manufacturer number can then also be indicated there.
In the SHOP there is a special option to search for manufacturers. For this purpose, a section with manufacturers is displayed in the left-hand area below the catalog display.
Overview of manufacturers
If you select the option "Show all" in the web browser, you will get a list with the logos of the manufacturers and can then display the corresponding articles by clicking on a manufacturer.
The stock is transferred from the main warehouse. Three availability stocks can be displayed in EULANDA. "Available" (this is the stock that is in stock), "Available1" (this is the stock that can still be sold - it is reduced by the open orders), and "Available 2" (the stock that is in turn increased by a possible purchase). The sales stock"Available 1" is relevant for the SHOP, but in addition
to this stock, the interface can also be configured so that a sufficiently high stock is always transferred. This is the case, for example, with companies that produce in real time.
Last but not least, the interface can be"fed" from a feed. The stock from the vendor article of EULANDA is used here. If several suppliers have been created in EULANDA and assigned to the articles, the supplier's stock can be entered in EULANDA in the "Delivery articles" area. For some suppliers, it is also possible to automatically accept this as a feed. For this EULANDA offers different individual extensions.
The transfer of a changed warehouse stock can be transferred to the SHOP in a separate interval. The stock information is compact and can be easily updated at five minute intervals.
Source of supply
In EULANDA any number of suppliers can be assigned to each article. One of these can be the main supplier, which is entered on the extended article index card. If this is set, it is possible to send the stock from the supplier to the SHOP. This is particularly interesting if these articles are delivered as third-party articles, that is, the vendor delivers them directly to the customer.
The purchase price can optionally be transferred to the SHOP. In this way, statistics are output directly from the shop that represent the gross profit of a shop order.
Correction Amazon Plug-In
The company Nop4You supplies a plug-in to connect to the online retailer Amazon. However, with the current status of the plug-in (28.06.2017), various errors occur on a German-speaking system when orders are transferred. On the one hand, the individual and total prices for the order items are reversed and on the other hand, the gross prices are also transferred to the net fields. The EULANDA shop interface recognizes these errors and corrects them as follows.
- If the unit price of the item is higher than the total rice, the fields are reversed before the transfer.
- If the fields Incl. VAT and Excl. VAT are identical, 19% is constantly deducted to determine the net price. This is done with the item prices as well as with the shipping costs.
- The line price of an item is too high by a factor of 100 in some purchase orders.
The configuration parameters "CorrectionPrice100", "CorrectionVatMissing" and "CorrectionUnitTotalPrice" must be set so that these errors can be detected and corrected.
Net and gross prices
EULANDA and nopCommerce allow prices to be saved as net or gross prices, i.e. including VAT. Both have similar concepts, but there are important differences in detail, which are discussed in more detail here.
Conversion of the price system
First of all it has to be said that depending on whether you want a net or gross shop, only the field "Prices incl. VAT" under "Configuration > Settings > Tax" has to be changed in the shop. If there are already articles in the shop, they have to be uploaded again via the interface. The interface is based on this setting and uses the correct prices or exports orders according to this setting.
In EULANDA, either net or gross prices are stored in the article table (= article file). This means that the article master can have mixed prices. To differentiate whether the field "VK" is a gross price or not, an additional field "BruttoFlg" is used. If this is true (= TRUE), the price for this item is saved including VAT. Another article can be stored without VAT.
When you enter prices in the EULANDA article master, the field of the last change specifies which of the prices is to be saved. The other price is calculated.
In the customer master you can specify whether a customer wants to have an invoice net plus VAT, or whether he only wants gross prices to be shown in the invoice and the VAT is to be deducted at the end. Since VAT is only calculated once at the end of a net invoice, the final price of such an invoice is inevitably different from a gross invoice and always when a calculation yields fractions of a cent.
If price lists are used in EULANDA, they can also be net or gross accurate per price list, irrespective of the item-specific price. Here, however, this always applies to the entire price list. In the shop there is a similar mechanism for this, the "animalprices". However, like the normal price, this is linked to a single setting. If the shop is set to "net" and the price list to be imported is "gross", it must be converted to net on import.
Make sure that you always transfer compatible prices to avoid rounding differences. If the shop is set to net, the price lists to be exported should also be net.
In SHOP nopCommerce, on the other hand, there is only one price scheme in the article master. All prices in the article master are either net or gross.
Which method the SHOP uses is defined in the configuration under Settings and there under Tax.
If the field "Prices incl. VAT" is checked, it is assumed that the prices in the article master are gross.
Switching the field in the SHOP does not recalculate it. The articles must therefore be uploaded again via the interface after a changeover.
The field "Prices incl. VAT" in the SHOP can also be changed directly via the database. It is listed in the table "Settings" and has the name "taxsettings.pricesincludetax".
The SHOP interface evaluates the database field "taxsettings.pricesincludetax" and transfers either the net or the gross price to the "Product" table of the shop for prices.
If the net price was entered in the article mask in EULANDA and the shop wants gross prices, then the gross price is calculated by the interface and stored in the SHOP. If the shop expects gross prices as product price and if this is not available in EULANDA, a rounding error may occur. Conversely, it should be a B2B SHOP that manages everything on a net basis and if the price is entered gross in EULANDA, the net price must be calculated, which can also lead to a rounding problem.
It is therefore important to check that the prices are entered in EULANDA according to the setting of the SHOP. For example, you can create a feature in EULANDA that displays products with unwanted accuracy.
Creating Control Characteristics
In EULANDA, you create a new SQL characteristic in the article master, for example in the root of the characteristic tree. In this example, we assume that the shop is an end customer shop, that is, it should have gross prices. The SQL command for the characteristic is "GrossFlg<>1".
In addition to the sales price of the EULANDA article mask, it is also possible to output price lists (graduated prices) via the interface. In this way, prices for different groups of customers such as schools, resellers and end customers can be displayed in the shop.
The"TierPriceFilter" parameter can be used to determine which price lists are to be exported.
If you work with graduated prices, it is important to know that changes to graduated prices assigned to an article do not affect the change indicator of an article. For the scales to be exported, the corresponding articles must also have been changed.
Changes to scale prices do not change the article itself.
If several price lists are to be exported, the names of the price lists must be entered separated by commas in the"TierPriceFilter" parameter. If all price lists for the respective article are to be issued, an asterisk "*" is indicated here.
Customer groups and discount groups as price lists
Alternatively, price lists can also be calculated. This means in EULANDA a considerably lower expenditure for the care of the different prices.
In this case, a discount group is assigned to an article and a customer group to a customer. In the settings of EULANDA you can now store discounts for each combination. Using a special parameter setting, "virtual" price lists can now be calculated from this discount link for export. In the XML export file for the shop, these then look like normal price lists.
In the"TierPriceFilter" parameter, the short names of the customer groups are now displayed instead of price list names. If you want to output more than one, separate them with commas, if you want to output all of them, set an asterisk "*". In addition, the"TierPriceFromCustomerGroup" parameter must be set to"1".
This way, the export module EUL.exe can decide where to get the prices for the export file.
Changes to the discount matrix do not change the article itself.
This means that an article is not automatically exported if only one value in the discount matrix has changed. To always export all articles, the"Forget" parameter can be set to"1" for a complete export.
If only the prices of the articles and not all other information are to be exported, a pure price export can be used instead of a product export. To do this, set the"ExportPrice" parameter to"1" instead of the"ExportProduct" parameter.
Terms of payment
The interface expects three different terms of payment,
which must be created in EULANDA: "SHOP.PAID", "SHOP.PREPAID", and "SHOP.PICKUP". You can define the terms of payment in the settings under Accessories.
Standard means of payment
For standard means of payment, the name "SHOP.PAID" is recommended with "1" as "net destination", the text "payment has been made via the online shop" as "target text" and the "shipping payment method" with the value "other"
This payment term is used if the customer has paid for his goods in the SHOP using a means of payment such as PayPal, credit card, Amazon Payment etc. So a payment that is directly available to you.
The order is brought in and booked and can be processed directly.
Payment in advance
For prepayment, the name "SHOP.PREPAID" with "7" as "Net target", the text "Payment 'Prepayment' via the online shop" as well as the "Shipping method" with the value "Prepayment" are recommended as "Target text".
This payment term is used if the customer wishes to pay for his goods in advance in the SHOP. The order is fetched into EULANDA via the interface with this payment term and the order is posted. This will reserve the goods. Further processing cannot take place until the incoming payment has been assigned to the order.
For prepayment, the name "SHOP.PICKUP" with "7" as "Net target", the text "Cash payment on collection' via the online shop" and the "Shipping payment method" with the value "Cash payment on collection" are recommended.
This payment term is used when the customer wishes to collect the goods from a shop or collection point and pay in cash,
thus reserving the goods. However, further processing cannot take place until the incoming payment has been assigned to the order. Once the payment has been received, further processing takes place manually.
If multilingual article texts are required, there is an optional interface to the "Sisulizer" translation system. Article texts are separated from each other by language sections. For the German section, a"[DE]" is placed in front of the text block in the long text. Besides this main text two other texts are supported, which are separated by colons:
A very short text, which is mainly used for captions is"[DE:NAME]" and a short description for headings as"[DE:SHORT]"
The info text in EULANDA can also contain a"[DE]" section and a further"[DE:TECH]".xml" would look like this for Sisulizer in the output file "German.xml":
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Language SupportedVersion="3.80" Name="German">
<Value>Hansadesigno Unterputz 41109573</Value>
<Value>Hansa 41109573 Hansadesigno Brause- Einhebelmischer Unterputz, chrom</Value>
<Value>Fertigmontagegestell, schraubenlos passend zu Hansavarox.</Value>
These texts can be translated in the Sisulizer program, either manually or via machine translators. Then Sisulizer creates a separate output file for each language which is then re-imported by EUL and made available in the articles.
You can export as often as you like. If such a file is re-imported by Sisulizer, Sisulizer can register changes and thus draw the translator's attention to any text passages that may need to be retranslated.
During the complete integration orders with the following conditions are collected from the nopCommerce-SHOP.
- You have never been picked up
- You are paid
- Or if you are not paid, there is collection in the shop or prepayment as means of payment.
Technically, the relevant values are in the"Order" table in the shop system. Orders that have been picked up are marked in the "CustomerIp" field with a preceding small "z". Any IP number of the customer remains unchanged.
The field "PaymentStatusId" has the value 30 when the order is paid. If prepayment was selected, the field "PaymentMethodSystemName" contains the value "Payments.PurchaseOrder". On the other hand, the field "PaymentMethodSystemName" contains the value "Payments.PayInStore" when picking up from a branch.