Amazon MWS Inventory Add Quantity (increment/decrement instead of setting Quantity) - amazon-mws

Is there a way (feed) to increase/decrease the inventory quantity instead of setting quantity to an absolute value ?
So instead of
<Quantity>100</Quantity> => set to inventory qty to 100
use e.g. something like this (incr/decr)
<AddQuantity>10</AddQuantity> => add 10 to inventory qty
or
<Quantity>+10</Quantity> => add 10 to inventory qty
Is there any feed or other possibility to do this in MWS ?
Thanks a lot for your answers.

There is no such API - you will have to calculate the new quantity yourself.
You could, however, get an inventory report through MWS first to determine the current quantity in stock (call RequestReport to get a _GET_FLAT_FILE_OPEN_LISTINGS_DATA_)
Sidenote: I find it a bit awkward that Amazon seems to know more about your quantities in stock than your own software...

Related

Apex/Salesforce/flow: Be able to increase price and clone/update product automatically

I asked a similar question before but I am still struggling and was not able to do what I was required to do and am coming back to this community for help.
I am trying to increase the price of the products on a quote in salesforce CPQ/Billing based on a field and to do this automatically.
The Setup
In Salesforce CPQ, If you go to account -> Contract -> Sales Service: There is a field called Price Increase %(PROD_Price_Increase__c)
A contract can have multiple quotes
What I want to do
When a quote has reached the final step a contract is created. In the contract I have the option to click a button called Amend. Which allows me to take the products in the existing quotes and amend it.
I want to create a batch job that does the following:
The Contract has these fields: Start Date (PROD_Start_Date__c), Price increase Date (PROD_Increase_Date__c), End Date (PROD_End_Date__c).
-- If the Price Increase Date is 12 months after the start date, these are the contracts that will need to be updated
-- For example, If the start date is 15 Feb 2023, Price increase is 1 Jan 2024, end date is 15 Feb 2025. Since the increase date is not 12 months, these contract should be ignored.
Main Task
When products who have a price increase 12 months after the start date, the contract should be able to 'amend' and update the quantity of the products and clone the products.
In the contract, the action buttons on top have "Amend". once clicked, it shows all the subscriptions products, you click next then it comes into the edit quote page.
Once here it shows all the products that were part of the contract and its quote. The net price filed for the original products will be '0'. These products will need to be cloned and the quantity for these to be applied to the cloned products. Once the quantity has been copied over, the original products quantity should change to 0.
After these products have a quantity of 0, the clone products should have the price increase. The value I mentioned from earlier Price Increase % (ROD_Price_Increase__c) value should be added to the Discount filed in the quote but as a minus value since we are doing an increase of price.
Once this has been done, we can submit/order the quote. This creates a new quote. Once the new quote has been created, I want to be able to update a filed in the quote - a checkbox that says order. I want to be able to check the value on it.
This all should be done automatically like though Apex and Flows.
Sorry for this long text and request. I apologise and know some of the information not be out of box or confusing. Its one of these challenges I have been facing with trying to automate this.

How can I update or change cost price (standard price) in odoo v13 postgresql database?

I am trying to change the cost price of products in Odoov13 in postgresql database, can anyone please support me with an example or guide? The question is simple, there is a selling price and a cost price (standard price) on the products, I just try to change the cost price, not the selling price, but I don't know how to get to the table or column, the Only reference I have is that the value can be stored in property field, but I don't know how to access it.
SELECT * FROM ir_property WHERE name = 'standard_price';
Fini
The field standard_price is computed field without store=True So it can store the data into postgres database.
If you want to update the field value, You can make the server-action following step:
Goto Settings->Server Actions
Model : Product Template
Action To Do: Update the Record
Data to Write:
Field : Cost (product.template)
Evaluation Type: Value
Value: Add your value example, 112
make the Create Contextual Action
Goto Product template and refresh the page on the action you can find the created server action and execute.

qliksense: measures are not showing the right numbers

Qliksense measures issue:
I have a report basically containing a table with data coming from purchase invoices with the following fields:
creation_date
expect_Rcpt_date
buy_From_vendor
quantity
Unit_cost
amount
project_Nbr
I have added a pivot_table and a graph next to it to display a measure of summaries on amount (calculated using quantity X unit_cost). I want to visualize by year and vendor, but however all vendors show up the same number, being the total number.
Any help please??
You need to include a term to aggregate the information
if this is your existing code
quantity * unit_cost
change it to
sum(quantity * unit_cost)

How to Store purchases of "N of the same Product" in an Orders table

So We have our basic tables for the categories, products, and variants of products
categories
id | name | active | parent_id
products
id | name | price | active
c_p_link
category_id | product_id
variants
id | product_id | price | price_override | active | stock
Which works great.
But I have two queries.
The first being how to structure the orders.
We have an orders table
id | customer_id | ordered | status
And we also have a order_products table
id | order_id ..?
this is the one I am curious about.
Say a customer orders 30 of a product. do we
Add 30 rows, and add the price for each individual item on each row.
Add one row, add the combined total onto the row
Add one row, add the individual price onto the row
The next part is, later we are expecting to add voucher support to the cart. e.g. 10% off, buy two, get one free etc. the overall design of this I am not too fussed about right now (this is a couple of months off at least). but I am wondering if that is going to affect which version of the order_products table I should choose?
Disclaimer: I have never written a database model dealing the "Shopping Carts" or "Orders"'
I think the price at time of purchase should be encoded into the purchase data: just like a paper receipt from a store. Let's call this total_price which represents each itemized "line" on the receipt and should not be confused with total_purchase_price.
That is, the amount charged is fixed. It doesn't matter if the product price changes later and changes to prices should not reflect in how much was [to be] paid.
Thus I would have these fields: product, unit_price, quantity, total_price. A computed column of say, base_total_price (unit_price * quantity) can be easily added if required.
Now, the total_price might be a computed value based on say base_total_price * precent_discount field: but, whatever it ends up being, I hold that total_price should exist and should be fixed at time of purchase. (This implies that, if it is a computed column, all inputs are also fixed at time of purchase.)
Addendum: As stated above, I've never designed a model like this before, but one thing I have observed at stores is discounts being applied as a negative cost itemized item. That is, items are bought "at full price" and then the register adds an entry to offset the cost per whatever promotional is occuring. I do not know the merits/reasoning of such an approach.
simply add quantity of product to your order_products table :)
I prefer the 3rd solution, i think it's the best for the performance of your database..

Implementing a sales tax strategy for Invoices

Here in South Africa we have Value Added Tax (VAT) which is pretty much identical to Sales Tax and is currently fixed at 14%, but could change at any time.
I need to include VAT on invoices (which are immutable) consisting of several Invoice Lines. Each line references a Product with a Boolean property, IsTaxable, and almost all products are taxable.
I don't want to store pre-tax prices in the database, because that just makes it hard to read the real price that the customer is going to pay and everywhere I display those prices, I then have to remember to add tax. And when the VAT rate does change, for this particular business, it is undesirable for all prices to change automagically.
So I reckon a reverse tax calculation is the way to go and probably not uncommon. The invoice total is the sum of all invoice line totals, which includes any line discounts and should be tax-inclusive. Therefore the invoice total itself is tax-inclusive:
TaxTotal = InvoiceTotal / (1 + TaxRate),
where InvoiceTotal is tax-inclusive and TaxRate == 0.14
Since invoices cannot be changed once issued (they are immutable), should I:
Store a single Tax amount in my Invoices table that does not change? Or...
Store a tax amount for each invoice line and calculate the invoice tax total every time I display the invoice?
Option 2 seems safer from a DBA point-of-view since if an invoice is ever manually changed, then Tax will be calculated correctly, but if the invoice has already been issued, this still presents a problem of inconsistency. If I stick with option 1, then I cannot display tax for a single line item, but it makes managing the tax total and doing aggregate calculations easier, though it also presents inconsistency if ever changed.
I can't do both since that would be duplicating data.
Which is the right way to go? Or is a reverse tax calculation a really bad idea?
Store the pre tax value in the data base, you can also store the with tax value and use that for most use cases.
Th big problem I forsee is the rounding rules for VAT on invoices.These (at least in the UK) are really strict and there is no way for your reverse calculation to get this right.
Also you need to store the tax item by item as the VAT dragons will expect you to refund exactly the tax paid if an item is returned. You really need to get hold of the local sales tax rules before you start.
My experience is that you can get dragged over the coals if your calculations are out by as little as a penny, and, if you are audited you need to be able to show how you arrived at the VAT figure so not storing anything used in your calculations will catch you out.
I totally agree with James Anderson! In Germany the rules according VAT calculations are as strict as in the UK.
We have to accumulate the net value by VAT percentage (we have three types: 0, 7 and 19 percent) rounded by two digits. On this rounded value we have to calculcate VAT.
VAT has to be rounded by two digits and has to be showed at the invoice.
But nonetheless you can store prices including tax. It depends whether the net prices or the end prices stay unchanged when tax rises. In Germany usually B2B net prices stay unchanged but B2C end prices stay unchanged - it depends.
You can calculate it this way:
with cPriceIncludingVAT as (
select InvoiceNo, VATPercentage,
PriceIncludingVAT = cast(sum(amount * price) as decimal(12,2))
from InvoiceLines inner join VAT on VAT.VATID=InvoiceLines.VATID
group by InvoiceNo, VATPercentage
),
cVATcalculated as (
select InvoiceNo, VATPercentage, PriceIncludingVAT,
VAT = cast(PriceIncludingVAT * VATPercentage /
(1+VATPercentage) as decimal(12,2))
from cVATcalculated
)
select InvoiceNo, VATPercentage, PriceIncludingVAT, VAT,
NetPrice = PriceIncludingVAT - VAT
from cVATcalculated;
If you save this as a view you should be able to reprint a dynamically calculated VAT value exactly. When there is an accounting system you can (and should) export exactly the same data you printed.
Usually you should save values like these as field values within the database - but I understand if you'd like to have a more dynamic approach ...
The other answers are good, but as idevlop mentions, it's almost a certainty that at some time in the future, you'll start having different rates for different categories of products. Adding that capability up front will save you a ton of heartache later on. Been there, done that.

Resources