The flow is as follows:
Create Purchase Order
Confirm Purchase Order
Receive the products with lot (and some information in customized fields in Detailed Operations dialog) [From Supplier to WH/Input]
Validate
The system automatically creates a new Internal Transfer [From WH/Input to WH/Stock]
The Internal Transfer along with its Detailed Operations have been created by the system according to the previous action, and this is where the question comes. Which method do I need to inherit (customize) in order to auto fill the customized fields inside the Detailed Operations (stock.move.line) according to the previous transfer?
Related
For our Spartacus project, we need to introduce additional Data properties in the checkout:
We have the case, that the user needs to select a delivery mode per product.
In an ideal world, upon selection, the selected delivery mode would be saved in the NGRX Store and also in the Backend to stay within the principle of the data binding defined here: https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
Expected Data / User flow:
User goes to Checkout and to Delivery Mode Step
Custom OCC Call is made to load the supported delivery modes for each product (depends on product type and further customer specific logic)
The cart items are displayed, enhanced with a dropdown containing the available delivery modes
The user selects a delivery mode
The selected delivery mode is stored on the cart entry within the NGRX Store and saved in the backend
The new Cart totals is calculated based on the costs of the selected delivery mode
The new Cart totals is stored on the cart within the NGRX Store and saved in the backend
The user clicks on continue to get to the Review Order Step
The cart items are listed with the previously selected delivery mode
After some analysis of the existing code, we found a property deliveryMode on the orderEntry. This does not seem to be used anywhere in spartacus, but could be used to make Step 9 work by following this stackoverflow answer and this one.
Questions regarding this flow:
How can we extend the NGRX Store? We assume, it would be possible to just extend the facade (Active Cart Service), bypass the store and save the information in the backend (Described here) and afterwards refresh the store from the backend. Is that Assumption correct? If yes, that feels awkward though, as we need to reload the whole store just to contain the new property deliveryMode on the orderEntry
How can we hook into the price calculation of the cart totals to update the total based on the selected delivery mode? And again, how can we bring the new total sum into the store?
There seem to be several Answers within the Slack Channel without very few usable answers around extending the ngrx store, even though for us, it seems to be a quit normal task.. :-/
Any thoughts, inputs or support would be very appreciated. :-)
This seems like a difficult thing to accomplish seeing as delivery modes per product aren't supported as-is in spartacus. But some ideas:
You can extend core CartEntry classes (adapter, connecter, facade, etc.) to include the delivery mode for entries added to the cart. You will probably need to change all to include the delivery mode setting(s). All of these are exposed so you can modify them as needed including the store.
Utilizing multiple carts to have a product per cart and set delivery mode that way. But this would be cumbersome in my opinion.
As far as price calculation goes, I'm assuming OCC calls return total prices. Does the call for the cart entries include delivery mode costs per entry?
We have implemented the following work around and it works so far:
Enhance the Cart Model in the backend
Add new Endpoints to load the available delivery Modes per Product (by bypassing the NGRX Store)
Add new Endpoints to save the selected Delivery Mode (by bypassing the NGRX Store)
After Save Endpoint, a cart Reload is triggered, which loads the new cart totals having a custom property on the order entry (via type augmentation) into the store from the backend
It's already a lot of years past since Spartacus project started, but looks like it's still really raw projects. Spartacus is not ready to deal with real word customer's requirement and complexity of customize it quickly grow at real project(so you start to think do we really need it, as it's so unflexible at some dimentions). Some parts is really hard or not possible to customize, so you begin to search a workarounds(This question is one common case).
I think NGRX Store is one of the biggest pain in the ass to customize something at Spartacus. 2 years past and nothing changed by Spartacus team...
Does Saleor have some minimum implementation of interaction for receiving data from client
I need to receive some data from client for special product that will be created and send to him.
As for me the best way will be order Line Note editable by user
I've tried to add new fields to CartLine after to CheckoutLine, but it's not good way because i need to modify #saleor/sdk in frontend and modify backend API.
I've tried to esaminate different custom fields like:
customerNote (OrderAddNote)
OrderLine
OrderLineInput
OrderLineCreateInput
CheckoutLine
CheckoutLineInput
CheckoutCreateInput
MetaStore
MetaItem
MetaClientStore
Metadata
and found that in all of them some notes can create only stuff users.
My question is:
What is the best way to have interaction with customer? If there is noting: Is it reasonable to change permission for Add Metadata o Add Note.
PS. How can I see metadata in dashboard orders
Metadata can be created / updated for a checkout without any special permissions and can be seen and edited from the Dashboard. Customer notes can be used as well, but have less features.
Is there a way to know what specific changes were made to a product in Prestashop 1.7?
In Advanced parameters> Logs I can see the employee who has made the modification, the severity, the message of the modification, the id of the object that has been modified and the date on which the modification was made, but it does not show me what the modification was. specific change that was made, if the name, price, description etc.
Is there a way to know that?
There is a way but it's a complex issue, you can hook into dynamic hooks like:
actionObjecProductUpdateBefore
and
actionObjectProductUpdateAfter
and compare two set of object data to see what has been changed.
Of course if you want to log more detailed informations like changes in Specific Prices etc. you also need to get informations about them before and after product change, it might be a time and resource consuming operation so be careful with it.
We have a requirement to connect to an external catalog from ME51N tcode (Purchase Requisition). This integration must be done entirely from ECC side and shouldn't be linked with SRM.
I have tried configuring the OCI on two different places. Let me explain the results and doubts for each. I don't need the two solutions, just one that gives me what I require.
Path: SPRO-> IMG-> Materials Management-> Purchasing-> Environment Data-> Web Services: ID and Description
Here I was able to configure the connection to the Catalog, and after defining it as default I get the button on ME51N's toolbar to get to the catalog. I'm able to select the data and return it to the purchase requisition. However some data that the client is sending is not the same as we have configured in our materials management, e.g. if they send a material group that we don't have the received material group is deleted and I can't see what the catalog returned for that field.
I've searched for a way to map these fields, and possibly insert some Z code to map those values and fill them like we need to, but I havent found anything that is usefull, most documentation is made for SRM, not for ECC.
So, how can I map/configure these values returned from the catalog? I'm currently looking at BADI ME_PROCESS_REQ_CUST to makes changes based on what the Catalog returned, but this is too late, as not configured values have already been deleted by then.
Since I couldn't configure this, I tried another way, using this other path, that does give me the option of mapping the fields from the catalog to SAP's standard fields, and even the possibility to set exits to add personal logic.
Path: SPRO-> IMG-> Plant Maintenance and Customer Service-> Maintenance and Service Processing-> Maintenance and Service Orders-> Interface for Procurement Using Catalogs (OCI)-> Define Catalogs.
However I haven't been able to display a link to these catalogs in ME51N.
Can these Catalogs be linked to ME51N?
Thanks
Well, I have no catalog by my hands now, but the procedure for connecting catalog to ERP via OCI seems to be the following:
You should make proper customization in the path
SPRO-> IMG-> Plant Maintenance and Customer Service-> Maintenance and Service Processing-> Maintenance and Service Orders-> Interface for Procurement Using External Catalogs
To adjust automatic Purchase Requisition creation you should set item category to N (non-stock item).
And also you should activate method COMPONENT_VIA_CATALOG_GET in BAdI PLM_CATALOG_IF.
See additional details here.
When a piece of data that I want to assert on in a later test is derived from an earlier step, is there an accepted method of storing and recalling that data later on in the scenario?
For example:
Scenario: Recently viewed product
Given I am on a product category page
And I click on the first product
When I am on a product category page
Then the recently viewed products should list the product I just viewed
On the step And I click on the first product can I somehow persist the product name so that I can assert that I am actually seeing that product in the last step? The reason I can't specify an actual product name in the feature file is that this could and will become out of sync with live product data.
Thanks!
It's entirely up to you how you implement this. The simplest way is in your "I click on the first product" step definition store the clicked product information in a static variable (or as a global variable) and then use it in "the recently viewed products should list the product I just viewed" step to verify it's present.
Store the values you need to persist between steps as FeatureContext class properties.
Don't forget to clear them when the Scenario ends, or before each new Scenario.