07-27-2018, 10:44 AM
How to specify the format of you fields when sending in through webservice
In the default behaviour, a webservice call to either revise or update will demand you to make sure all fields are sent to coreBOS in the form of your current user. This applies in particular to number and currency fields, but also to date fields.
Let’s say you use user ‘John’ to login to coreBOS through a webservice in a remote application (maybe some customer portal). John has his preferences stored in the user settings page for his user. He likes his thousands separator to be a dot, his decimals separator to be a comma and he wants only two decimals. So his currency fields and numbers would be formatted like:
1.234,56
In the database however, the number would be stored like this:
1234.560000 if it’s a currency field, or
1234.56 if it was for instance a percentage.
When you send a record, or part of a record to either the revise or update webservice methods, you would be expected to send in the data in the format of the user that sends the data in. So for John, he would have to send in ‘1.234,56’ on a currency field to end up with ‘1234.560000’ in the database. When logged in to coreBOS, coreBOS would take care of the correct formatting when John views or edits a record.
But what if John sends in the value in database-format? What if he would send in ‘1234.560000’ for his currency field? Well, coreBOS wouldn’t understand that and try to convert it to the database format anyway. Since John uses the dot as his thousands separator, coreBOS would remove that from the value first, since databases don’t know this concept. Then coreBOS would apply decimals, if there weren’t any to start with. CoreBOS would expect those to be indicated with a comma, since it knows it’s John that sends in the data.
Now John would end up with the number ‘1234560000.000000’ in the database. In the application, he would see ‘1.234.560.000,00’, which is not what he wanted.
So John has to make sure he sends in all currency and number fields in the format he specified in his user preferences.
But, since 26-07-2018, he could also do something else. He could add a special flag (or multiple) to his data, that tells coreBOS what to expect. Say John is updating a Potential with this data:
Normally, this would go horribly wrong. But if he were to update the input array with some special fields, it wouldn’t:
If he were to add the two fields with the name-prefix ‘__cbws_skipcurdbconv’ followed by the fieldname that he wants to send in formatted as database-format, he would get the result he expected (1.234,56 and 5,00).
But, there’s more. He could also add a single, special flag called ‘__cbws_skipcurdbconvall’ (notice the ‘all’ at the end) to make sure coreBOS treats all his fields as database-formatted.
There is one drawback to using the ‘all’ special flag though, which is quite obvious: you really need to make sure to input all data in the database-format. This includes date fields. Basically, setting the ‘all’ flag forces you to format the record as if you were doing an INSERT or UPDATE query on the database.
What about inventory lines?
If you had tried the above examples on an inventory module, you would notice that would not work. This is because the inventorylines are not fields, and are not treated as such by coreBOS. To be able to send your inventorylines with currencies formatted in the database format, you need to add:
‘__cbws_skipcurdbconv_pdo’
to your record and set it to anything, like ‘1’ or ‘true’ .
This mechanism works completely separate from the ones mentioned before. If you want to send in your entire inventory record (for instance a salesorder including the inventorylines) in database-format, you would have to set both ‘__cbws_skipcurdbconv_pdo’ and ‘__cbws_skipcurdbconvall’ to your record.
A note: Do not mistake inventorylines with the InventoryDetails modules. InventoryDetails is a modern module that does treat all of its numbers as fields. Setting the ‘__cbws_skipcurdbconv_pdo’ flag there or on a salesorder (for instance) that does not use the ‘old’ inventorylines mechanism would not do anything.
In the default behaviour, a webservice call to either revise or update will demand you to make sure all fields are sent to coreBOS in the form of your current user. This applies in particular to number and currency fields, but also to date fields.
Let’s say you use user ‘John’ to login to coreBOS through a webservice in a remote application (maybe some customer portal). John has his preferences stored in the user settings page for his user. He likes his thousands separator to be a dot, his decimals separator to be a comma and he wants only two decimals. So his currency fields and numbers would be formatted like:
1.234,56
In the database however, the number would be stored like this:
1234.560000 if it’s a currency field, or
1234.56 if it was for instance a percentage.
When you send a record, or part of a record to either the revise or update webservice methods, you would be expected to send in the data in the format of the user that sends the data in. So for John, he would have to send in ‘1.234,56’ on a currency field to end up with ‘1234.560000’ in the database. When logged in to coreBOS, coreBOS would take care of the correct formatting when John views or edits a record.
But what if John sends in the value in database-format? What if he would send in ‘1234.560000’ for his currency field? Well, coreBOS wouldn’t understand that and try to convert it to the database format anyway. Since John uses the dot as his thousands separator, coreBOS would remove that from the value first, since databases don’t know this concept. Then coreBOS would apply decimals, if there weren’t any to start with. CoreBOS would expect those to be indicated with a comma, since it knows it’s John that sends in the data.
Now John would end up with the number ‘1234560000.000000’ in the database. In the application, he would see ‘1.234.560.000,00’, which is not what he wanted.
So John has to make sure he sends in all currency and number fields in the format he specified in his user preferences.
But, since 26-07-2018, he could also do something else. He could add a special flag (or multiple) to his data, that tells coreBOS what to expect. Say John is updating a Potential with this data:
PHP Code:
$input_array = array (
'amount' => '1234.56',
'probability' => '5.00',
'id' => '5x195784',
);
$moduleName = 'Potentials';
$update = $cbconn->doRevise($moduleName, $input_array);
PHP Code:
$input_array = array (
'amount' => '1234.56',
'probability' => '5.00',
'id' => '5x195784',
'__cbws_skipcurdbconvamount' => 1,
'__cbws_skipcurdbconvprobability' => 1,
);
But, there’s more. He could also add a single, special flag called ‘__cbws_skipcurdbconvall’ (notice the ‘all’ at the end) to make sure coreBOS treats all his fields as database-formatted.
There is one drawback to using the ‘all’ special flag though, which is quite obvious: you really need to make sure to input all data in the database-format. This includes date fields. Basically, setting the ‘all’ flag forces you to format the record as if you were doing an INSERT or UPDATE query on the database.
What about inventory lines?
If you had tried the above examples on an inventory module, you would notice that would not work. This is because the inventorylines are not fields, and are not treated as such by coreBOS. To be able to send your inventorylines with currencies formatted in the database format, you need to add:
‘__cbws_skipcurdbconv_pdo’
to your record and set it to anything, like ‘1’ or ‘true’ .
This mechanism works completely separate from the ones mentioned before. If you want to send in your entire inventory record (for instance a salesorder including the inventorylines) in database-format, you would have to set both ‘__cbws_skipcurdbconv_pdo’ and ‘__cbws_skipcurdbconvall’ to your record.
A note: Do not mistake inventorylines with the InventoryDetails modules. InventoryDetails is a modern module that does treat all of its numbers as fields. Setting the ‘__cbws_skipcurdbconv_pdo’ flag there or on a salesorder (for instance) that does not use the ‘old’ inventorylines mechanism would not do anything.
