1984hosting / 1984-dk-woo Goto Github PK

We will need the plugin in English and Icelandic, at least.

1984 can make the actual translations, but strings in the plugin need to be translate-able.

Developer asks:

Next question is
Should we reserve the product when user adds it into the cart? If yes, then on what time should it be reserved? If at some reason order wasn't completed, after what time a product will be unreserved?

When a product is added to dkPlus, the price is given without VAT. The VAT Is then calculated on top of the entered price.

This means that a product with a base price of 12.400 and 24% VAT, will have the total VAT-included price of 15.376, which is 12.400 * 1.24.

However, in Woocoo, the price received from dkPlus is assumed to include VAT, so the number gets divided: 12.400 / 1.24.

The interface on DK's side is incorrect. The user is presented with the option of changing quantity, but it does not update on DK's side.

Apparently more is needed to update quantity. Some kind of transaction. @helgihg will investigate.

DK can't make an invoice if a DK product ID (SKU in WC) is not assigned to a product or if a product has a SKU but it does not belong to a product in DK.

Currently, the DK API returns an error if an invoice with a product missing its SKU is POSTed. We need to prevent from the POST request from happening and log it into the Order Notes if there is such a product in an order.

This is not an edge case, as new users are likely to have several WooCommerce products without a SKU or a SKU matching a DK product ID.

Currently, products don't get updated on WooCommerce's side when imported again from dkPlus, but instead there is an error reporting that there is nothing to import.

Instead, the new values on dkPlus's side should be updated on WooCommerce's side.

This is apparently a bit of a complicated question.

I have consulted Sigmundur on the topic. He intends to send me examples of the complications before the end of 2023-01-11.

GitHub Updater.

Products may come in different varieties, for example a T-shirt that comes in different colors and sizes.

It is currently not obvious how they are managed in DK. We have asked DK and hope to have a response soon. We will also converse with an advisor on how existing software manages this.

Developer asks:

Regarding invoices.
Should we generate invoice before payment or after payment? Who will proceed with the payment? We have not found yet, if DK has the payments integration and if it sends the payment statuses.

Just got the following from the WordPress.org plugin review team:

Your plugin display name is: 1984 DK Connection for WooCommerce

Which made the following plugin permalink (aka slug): 1984-dk-woo

Due to the legality of trademarks, and confusion that could happen due to ownership and representation, we cannot permit your chosen display name nor slug and require you to change them.

What to do next

This email contains a great deal of information that will help you with renaming your plugin. Please read the entire email carefully (especially the 'Why This Matters' section) as it will address common mistakes that will delay your review.

We have changed your plugin permalink: 1984-connection-dk-woocommerce

And recommend the following display name: 1984 Connection for DK and WooCommerce

We need you to do the following:

Confirm the permalink is acceptable or suggest one you prefer (note: you must specifically request a different permalink if desired)
Update your code with a new Display Name that does not infringe on trademarks in both the readme and the main plugin file
Go to "Add your plugin" and upload an updated version of this plugin.

Be advised, your display name may not begin with any trademarked terms, nor use them in a manner that might imply a relationship. This often includes portmanteau when meant to reference trademarks for another entity. Some trademarks have stricter enforcement laws than others.

Alternatively if you feel this decision was made in error, you can do one of the following:

Prove that you legally have the right to the original name/slug
Provide the user account for an official owner to whom we should transfer the plugin

This looks a bit silly as we are not connecting DK or WooCommerce with 1984, but the other two, so the options are to:

• Bite the bullet and let the plugin review team dictate the plugin name and slug
• Make a reservation about this silliness

See product with SKU 516273, named "Peppermint lollypop" in dkPlus. The name in dkPlus is confusingly called Description, but is actually the name.

We should use "Description 2" ("Lýsing 2" in Icelandic) for the description field in Woocoo.

dkPlus side:

Woocoo side:

During checkout in WooCommerce, but putting in an invalid phone number like "aerg", then WooCommerce still reduces the stock.

This may be a bug in WooCommerce, but we need to make sure that it's not a bug in Woocoo.

Even weirder is that the stock in DK seems to be reduced by twice as much.

To reproduce:

1. Place 5 items of a product in the cart (GoodVin3, for example).
2. During checkout, put in an invalid phone number, like "aerg" and press "PLACE ORDER".
3. See stock in WooCommerce, which has dropped by 5, even though the purchase did not go through.
4. See stock in DK, which has dropped by 10, even though the purchase did not go through.

It appears that if the access credentials are missing, then they cannot be configured. See accompanied screenshots.

Stacktrace:

2022-06-14T12:47:38+00:00 CRITICAL Uncaught TypeError: Typed property woo_bookkeeping\App\Core\Main::$settings must be array, bool used in /var/www/html/wp-content/plugins/woocoo/App/Core/Main.class.php:13
Stack trace:
#0 /var/www/html/wp-content/plugins/woocoo/woo_bookkeeping.php(39): woo_bookkeeping\App\Core\Main->__construct()
#1 /var/www/html/wp-includes/class-wp-hook.php(307): woo_bookkeeping_load()
#2 /var/www/html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#3 /var/www/html/wp-includes/plugin.php(476): WP_Hook->do_action()
#4 /var/www/html/wp-settings.php(598): do_action()
#5 /var/www/html/wp-config.php(96): require_once('/var/www/html/w...')
#6 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...')
#7 /var/www/html/wp-admin/admin.php(34): require_once('/var/www/html/w...')
#8 /var/www/html/wp-admin/plugins.php(10): require_once('/var/www/html/w...')
#9 {main}
  thrown in /var/www/html/wp-content/plugins/woocoo/App/Core/Main.class.php on line 13

Developer asks:

There are different ways when we can check the product quantity and it's availability.

a) through some period of time. For example evey 1 hour. But in this case it can by out of sync in some short time period. For example it product is last one and we got information that it is in stock, but within this hour it was sold. Then user only in the cart will see that product is already sold and he will not be able to buy it. It is not critical quantity more than 5 in the stock, but if there is only last items left in the stock, this situation may be happened.

b) another way if we will check the product quantity every time when user enters product page. But in this case the time of page loading will be bigger, because we will wait for result from DK about product quantity.

and in any of the ways above we will surely check the product quantity again when user adds product into the cart.

work with product variations

It turns out that we can't assume that the currency used in DK and the WooCommerce shop is the same as one of our initial users is using EUR as their accounting currency in DK, while their WooCommerce shop uses ISK. This means that we need to add currency conversion support:

• Fetch currency rates hourly from DK.
• If the WooCommerce shop uses a different currency from DK, product prices need to be converted on sync if price sync is enabled.
• Add a checkbox to the wp-admin interface for disabling price sync by default
• Add an option for conversion markup to reduce risk from rate fluctuations

Currency rates are fetched vita a HTTP GET request to https://api.dkplus.is/api/v1/general/currency.

Take product "Twelve Hundred Forty Four", and let's say that it has unit quantity in DK of 1244 items available.

If you order 4 such items in WooCommerce, the quantity in DK is reduced by 4 in WooCommerce, but only by 1 in DK.

As can be seen in the following screenshots:

WooCommerce (1244-4):

DK (1244-1):

The different prices 1, 2 and 3 simply reflect different prices that the client-side might use in different contexts. For example, if the client-side wanted to have a different discount price when purchasing multiple items at a time, or maybe a special deal with some clients or what not.

We don't need to concern ourselves with that for now, since the plugin doesn't offer any such differences in pricing, at least yet.

If it's possible to program it so that we might easily add it later, that would be nice, though.

Developer asks:

There are a two ways how the store can be synchronized with DK system:
a) if the woocommerce store has its own products on the site and it is synchronized with DK for example by product ID (sku). And all information about product is placed on the site itself, but from DK we get quantity of product and if it is in stock or out of stock
b) the second way if we have relatively empty woocommerce site, and all product with its information and details we get from DK sytem. So it is fully linked with DK, not just quanity, but all the details of the product.
Which way would you prefer? Or should we realise both ways?

The imported price is currently without Value-Added Tax (VAT). The imported price should be the one that contains the tax.

See in DK:

The number "12.400" in the following image should be "15.376":

Developer asks:

The Price synchoronization, how and when should it be happened?
For example if price is changed in the DK system, should it be automatically changed on the site itself? Or if the price is changed on the site, but in the DK stock it is different. Which price should be in priority?

The current project name is "woo_bookkeeping", but should be "woocoo".

From README.md:

Field synchronization by field:

• SKU (product ID): The common identity between both systems, used to identify what products to add and update.
• Name/Description: Transferred from DK to WooCommerce when product is added, but not updated after that, because users may want different descriptors in WooCommerce than in DK.
• Inventory/Price: Always updated from DK to WooCommerce.

There was something broken on DK's server side. It seems to be working now. Changes to data should be reflected in the interface now and presumably the API.

In the process, it remains to send the properties to the DK

Prices in Iceland (and elsewhere in Europe) are shown with VAT included (Податок_на_додану_вартість).

Currently, Woocoo only displays the base price from DK.

In the following image, the base price is to the left, and the VAT-included price is to the right. (VAT in Icelandic is called "Virðisaukaskattur" and is abbreviated as "VSK".)

In order to set up VAT tax rates in WooCommerce, the following steps are required:

1. Enter WordPress administration.
2. Select WooCommerce on the left.
3. Select "Settings".
4. Under the "General" tab, enable the checkbox called "Enable taxes" - and save.
5. A new tab, called "Tax" should now be visible under WooCommerce -> Settings.

In that tab, WooCommerce allows the user to create different tax rates, that are later applied to products. I have created two tax rates, one is 24% and another is 11%. The WooCommerce user must select which tax to apply for each product, because some products are 24% and others are 11%.

Here is a screenshot of the 24% tax rate, called "Standard rates".

Here is a screenshot of the 11% tax rate, called "Reduced rate rates".

When users enter the product, they select which tax rate to use here:

Also, there is this option in WooCommerce -> Settings -> Tax, which allows the user to decide whether a price that is entered into WooCommerce, already contains the VAT, or if the VAT should be calculated on top of it. The syncing with DK should support this option.

The DK test account contains almost 11.000 products, which is infeasible to work with to develop this feature. We will need our own DK test account to adequately develop and test this functionality.

@helgihg will investigate.

Currently, the temporary directory tmp/dkPlus is required for the importing script to run. It must be created manually on a new installation. It should be automatically created.

API documentation: https://apidoc.dkplus.is/#77d42854-ab7c-4427-9352-7c57646dd473