Wrong payer for TTN delivery
According to this process, the payer for delivery was incorrectly established https://one-box.shine-bright.com.ua/290089/
Everything is ok with other processes.
I wanted to see the NP logs for this day, but the page does not load.
What could be the reason?
Original question is available on version: ru
Everything is ok with other processes.
I wanted to see the NP logs for this day, but the page does not load.
What could be the reason?
Answers:
the data in the block is more important than the data in the action settings
10.01.2023, 11:50
Original comment available on version: ru
In MVP, these fields were never touched, the payer in tn was indicated based on the automatic action settings. Actually, if there is a choice in action, who is the payer, then somehow it is wrong to ignore it.
But, for all other processes, everything is in order, despite the fact that the payer is the Recipient in the block by default.
Process examples:
https://one-box.shine-bright.com.ua/290552/
Problem with only one process https://one-box.shine-bright.com.ua/290089/
But, for all other processes, everything is in order, despite the fact that the payer is the Recipient in the block by default.
Process examples:
https://one-box.shine-bright.com.ua/290552/
Problem with only one process https://one-box.shine-bright.com.ua/290089/
screenshot_1.png
screenshot_2.png
screenshot_3.png
screenshot_4.png
screenshot_5.png
screenshot_6.png
11.01.2023, 00:16
Original comment available on version: ru
Farkhshatov Rodion wrote:
In MVP, these fields were never touched, the payer in tn was indicated based on the automatic action settings
The logic of interaction between the block and the automatic action did not change on os.
Farkhshatov Rodion wrote:
Actually, if there is a choice in action, who is the payer, then somehow it is wrong to ignore it.
This is your subjective opinion, it can be safely flipped as "If there is a choice in the block, it is somehow wrong to ignore it." There is a logic that I described above, if it does not suit you, I can estimate the cost of reworking it to suit your needs.
11.01.2023, 12:28
Original comment available on version: ru
bu
OneBox production wrote:
The logic of interaction between the block and the automatic action did not change on os.
It's good that the logic hasn't changed, but what you're talking about doesn't work. I sent you examples of processes. In the IR block, by default, the payer is always the Recipient, but at the stages where the action is indicated by the payer to select the Sender, this is how it works.
Have you looked at examples?
11.01.2023, 12:58
Original comment available on version: ru
Yes, I looked. The data in the block is output but not saved. If the data is not saved, it is taken from the integration settings. They are saved when you save the process with the output block when you press edit . Those. in an order with an "error", the data on the payer is saved, but not in the rest.
11.01.2023, 14:20
Original comment available on version: ru
If you are talking about editing the Payer fields, then we never touch them. In this block, only the city and branch are selected.
Integration settings - what are they? Setting parameters for automatic creation of TT?
Integration settings - what are they? Setting parameters for automatic creation of TT?
11.01.2023, 21:47
Original comment available on version: ru
Farkhshatov Rodion wrote:
Payer, then we never touch them
well, apparently touched
Farkhshatov Rodion wrote:
Integration settings - what are they? Setting parameters for automatic creation of TT?
personal account settings in boxing.
12.01.2023, 11:09
Original comment available on version: ru
bu
OneBox production wrote:
well, apparently touched
100% untouched. Now only 2 people work with the system, including me, and both of them know that the ttn is created by an automatic action, and the payer is set based on several conditions. Therefore, no one interacts with these fields.
bu
OneBox production wrote:
personal account settings in boxing.
Tested - the payer is pulled from the Return Delivery settings section.
I checked all the tn since October, this problem appeared with the transition to OS. Every day a TTN is created with an incorrectly specified payer. Here is the list of orders:
01/09/2023 289916
01/07/2023 290275
01/06/2023 290142
01/06/2023 290126
01/06/2023 290262
01/06/2023 290029
01/05/2023 289924
01/03/2023 289657
12/30/2022 288113
12/26/2022 287891
12/25/2022 288274
I beg you to sort out the problem, tk. I will repeat with the hands of the Payer field, no one has ever edited, before there was no such problem for several years.
The problem is critical, because it is an unpleasant situation when the client has to pay for delivery when the promised free shipping is promised and spend time figuring it out.
Is it possible to add to logging the preservation of these fields for tracking? Or track where exactly the payer is transferred to the TTN during creation? From an automatic action or from this block?
12.01.2023, 12:48
Original comment available on version: ru
I wrote to you several times above that the delivery payer is taken from the block, if it is not filled in the block - from the action.
You can make a setting to force get out of action and ignore block settings, it will take 1h. You can also use the setting or "Use return shipping type, return shipping payer and shipping payer from settings ..." in action and configure matching shipping payers in the integration. If the settings above are filled in, they will take precedence over the block and action settings.
If you want me to search for which of your employees and how to fill in the data in the block, this can be done - it will take about 3 hours.
You can make a setting to force get out of action and ignore block settings, it will take 1h. You can also use the setting or "Use return shipping type, return shipping payer and shipping payer from settings ..." in action and configure matching shipping payers in the integration. If the settings above are filled in, they will take precedence over the block and action settings.
If you want me to search for which of your employees and how to fill in the data in the block, this can be done - it will take about 3 hours.
12.01.2023, 13:07
Original comment available on version: ru
Tested, works as you say, but with a little clarification:
the payer is set from this block if this field was edited, i.e. there was a pressing on it.
If you do not touch it, then the Payer is set from the Automatic action settings.
I repeat, no one touches these fields, 2 people are working with the system now, including me, and both know how everything works. This block has been put into the interface from the very beginning of working with boxing, for more than 4 years, and no one has ever edited the payer in this block. And this problem didn't happen.
But even despite this, I found a way out of the situation by removing the payer setting depending on the payment method. And now the fields Delivery Payer and Return Delivery Payer in this block are empty.
Found that for several orders, the Payer fields in the block are filled. And both fields. But no one edited them. The payer is set incorrectly again.
https://one-box.shine-bright.com.ua/291978/
https://one-box.shine-bright.com.ua/291513/
https://one-box.shine-bright.com.ua/291419/
Please see what's up. Why are these fields filled if they are empty in all other orders? Thank you.
the payer is set from this block if this field was edited, i.e. there was a pressing on it.
If you do not touch it, then the Payer is set from the Automatic action settings.
I repeat, no one touches these fields, 2 people are working with the system now, including me, and both know how everything works. This block has been put into the interface from the very beginning of working with boxing, for more than 4 years, and no one has ever edited the payer in this block. And this problem didn't happen.
But even despite this, I found a way out of the situation by removing the payer setting depending on the payment method. And now the fields Delivery Payer and Return Delivery Payer in this block are empty.
Found that for several orders, the Payer fields in the block are filled. And both fields. But no one edited them. The payer is set incorrectly again.
https://one-box.shine-bright.com.ua/291978/
https://one-box.shine-bright.com.ua/291513/
https://one-box.shine-bright.com.ua/291419/
Please see what's up. Why are these fields filled if they are empty in all other orders? Thank you.
23.01.2023, 00:50
Original comment available on version: ru
Unfortunately, I do not have a place where I can "see" which of you and how filled in this or that field. I see several solutions to your situation:
1. You monitor the behavior of the block and look for how you managed to fill it. Let me know, I'm looking at the place where and how you managed to do it. If he did something wrong, probably not only you would contact us, but also several dozens of clients who actively use it.
2. Set the settings as I wrote above and they will always be delayed by default as you need, or change the settings so that the payer is delayed from the additional field.
3. We make the setting as I wrote above, so that in the action it was possible to force the use of the sender only from the action.
4. We cover your system with logs and see who, when and from where will change this information in the next order, this is 3 hours. improvements.
1. You monitor the behavior of the block and look for how you managed to fill it. Let me know, I'm looking at the place where and how you managed to do it. If he did something wrong, probably not only you would contact us, but also several dozens of clients who actively use it.
2. Set the settings as I wrote above and they will always be delayed by default as you need, or change the settings so that the payer is delayed from the additional field.
3. We make the setting as I wrote above, so that in the action it was possible to force the use of the sender only from the action.
4. We cover your system with logs and see who, when and from where will change this information in the next order, this is 3 hours. improvements.
23.01.2023, 10:55
Original comment available on version: ru
bu
OneBox production wrote:
1. You monitor the behavior of the block and look for how you managed to fill it. Let me know, I'm looking at the place where and how you managed to do it.
Let's go down this path
24.01.2023, 13:19
Original comment available on version: ru
Good afternoon. The problem repeats daily on several orders. We try to keep track of everyone, but only today we managed to catch the moment of filling in the fields in real time.
For this order, after going to the Editing order stage on February 3, 2023 at 15:18:23, in the IR block, in the two fields Payer and Return shipping payer, the value of Recipient was registered. Manually changed to Sender.
https://one-box.shine-bright.com.ua/293031/
Please see what is the reason.
For this order, after going to the Editing order stage on February 3, 2023 at 15:18:23, in the IR block, in the two fields Payer and Return shipping payer, the value of Recipient was registered. Manually changed to Sender.
https://one-box.shine-bright.com.ua/293031/
Please see what is the reason.
03.02.2023, 17:01
Original comment available on version: ru
I managed to catch the problem in real time on one more order https://one-box.shine-bright.com.ua/293750/
The fields were filled in when starting the procedure Check receipt at the stage Waiting for goods.
On other orders, with the same actions, it was not possible to reproduce the problem. It happens randomly when changing stages and working out the procedure on the button.
The fields were filled in when starting the procedure Check receipt at the stage Waiting for goods.
On other orders, with the same actions, it was not possible to reproduce the problem. It happens randomly when changing stages and working out the procedure on the button.
06.02.2023, 18:56
Original comment available on version: ru
Please let me know when you can fix the issue. Repeats every day
17.02.2023, 15:12
Original comment available on version: ru
Good afternoon. Above I gave you 4 options to solve your problem. The second point for you solves the issue once and for all. I can only "see" something if you give me the exact algorithm of how to see in 100% of cases that the value in the block is saved.
17.02.2023, 15:15
Original comment available on version: ru
I wrote to you how it happens. You have a bug, and I still have to find a way how it is reproduced in 100% of cases?
This happens when updating the process, when moving to different stages. I personally saw it: there were empty fields, I went to the stage, the fields were filled. Is that not enough for you to track down this bug? You don't believe me or what?
We are already tired of monitoring every order every day so that the payer is set correctly.
Of course, I can spend more of my time and record the screen every time the processes change, but is this really normal? Are my words not enough?
This happens when updating the process, when moving to different stages. I personally saw it: there were empty fields, I went to the stage, the fields were filled. Is that not enough for you to track down this bug? You don't believe me or what?
We are already tired of monitoring every order every day so that the payer is set correctly.
Of course, I can spend more of my time and record the screen every time the processes change, but is this really normal? Are my words not enough?
17.02.2023, 15:25
Original comment available on version: ru
.dev
OneBox production wrote:
I wrote to you how it happens
Farkhshatov Rodion wrote:
On other orders, with the same actions, it was not possible to reproduce the problem.
I can’t repeat the situation myself, therefore I give you a solution on how to avoid the problem or ask you to show me how I can repeat the error in 100% of cases so that I can reproduce it and fix it if the problem really exists. I believe you have a problem. It can be in the code, setting up the BP, your actions, the combination of the output blocks, the combination of actions at the stage, etc., there are hundreds of options. But unfortunately, I can’t tell you anything new here: I need either an algorithm for repeating the error, or you can avoid it and not waste time on it. You choose.
Have a good day.
17.02.2023, 15:38
Original comment available on version: ru
I just don't understand why this is the position. Those. any error that does not happen consistently with certain actions, but randomly you do not take into account? You can also put logs on these fields and see what fills them and when.
At MVP for 5 years, we have not encountered this problem.
At MVP for 5 years, we have not encountered this problem.
17.02.2023, 15:43
Original comment available on version: ru
+ you offer to use the payer settings depending on the payment method, but this is a very limited functionality. We set the payer, depending on the amount of the order.
If you take the payer from the additional field, then this field is also in this action, which has a lower priority than the IR block
If you take the payer from the additional field, then this field is also in this action, which has a lower priority than the IR block
17.02.2023, 15:47
Original comment available on version: ru
The operation of the block did not change during the transition from mvp to os.
Farkhshatov Rodion wrote:
Those. any error that does not happen consistently with certain actions, but randomly you do not take into account?
took into account
Farkhshatov Rodion wrote:
You can also put logs on these fields and see what fills them and when.
Yes, of course - it is on the list of my suggestions for solving your question. 4 point.
Farkhshatov Rodion wrote:
Those. any error that does not happen consistently with certain actions, but randomly you do not take into account?
took into account
Farkhshatov Rodion wrote:
You can also put logs on these fields and see what fills them and when.
Yes, of course - it is on the list of my suggestions for solving your question. 4 point.
17.02.2023, 15:48
Original comment available on version: ru
.dev
OneBox production wrote:
Yes, of course - it is on the list of my suggestions for solving your question. 4 point.
so let's do it, only I don't understand why I have to pay for it, it's a bug.
17.02.2023, 18:14
Original comment available on version: ru
I heard hundreds of times that something is a "bug", but in the end it turned out that someone put an action at the stage that changes what is described in the "bug" and it turned out that the error was in the bp settings.
Let's do it again.
I gave you some solutions to your problem and posted the cost where it is. You have chosen an option with a revision estimate, I have billed you for it. If you do not pay the bill - choose any other way to solve your problem.
I have given you several 100% solutions to avoid the situation described above, which can be set up in 5 minutes. If you want to argue with me about whether this is a bug, not a bug, and who owes what to whom, then unfortunately I have too little time for this. If you have information on how to repeat the error in any case - I can see it if you are ready to pay for logging - just write.
Have a good day.
Let's do it again.
I gave you some solutions to your problem and posted the cost where it is. You have chosen an option with a revision estimate, I have billed you for it. If you do not pay the bill - choose any other way to solve your problem.
I have given you several 100% solutions to avoid the situation described above, which can be set up in 5 minutes. If you want to argue with me about whether this is a bug, not a bug, and who owes what to whom, then unfortunately I have too little time for this. If you have information on how to repeat the error in any case - I can see it if you are ready to pay for logging - just write.
Have a good day.
20.02.2023, 12:18
Original comment available on version: ru
.dev
OneBox production wrote:
I heard hundreds of times that something is a "bug", but in the end it turned out that someone put an action at the stage that changes what is described in the "bug" and it turned out that the error was in the bp settings.
Nobody set any actions, the problem appeared after the upgrade to the OS.
Of your solutions, only one came up with an indication of the payer in the add. field. And this is a very strange work of the action, when the choice of the payer from the list has a priority lower than the IR block in the process, and the setting of the Payer in the same action from the add. field takes precedence over the NP block. Well, at least with such a crutch you can get around the problem.
20.02.2023, 12:54
Original comment available on version: ru
I'm glad that one of my solutions worked for you.
20.02.2023, 17:11
Original comment available on version: ru
Please join the conversation. If you have something to say - please write a comment. You will need a mobile phone and an SMS code for identification to enter.
Log in and comment
Copyright © OneBox 2024
