| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 16 online users.
» 0 Member(s) | 16 Guest(s)
|
|
|
| Oportunidad |
|
Posted by: Inakifernandez - 09-28-2018, 09:29 AM - Forum: International
- Replies (1)
|
 |
Buenos días a todos
tengo un problema en el módulo de oportunidades, que es que no me almacena la persona de contacto, es decir me la busca, me la pone, pero cuando voy a otra pantalla y vuelvo ya no está.
Y en el caso de que la guarde y pinche sobre ella este es el mensaje que me sale:
A record number must be specified to view details.
¿Cómo puedo solucionarlo?
Saludos y gracias
|
|
|
| Scheduled Reports passes 1970-01-01 25:43 as date string |
|
Posted by: Guido1982 - 09-24-2018, 07:11 PM - Forum: coreBOS Development
- Replies (2)
|
|
I'm having problems with my scheduled reports. I logged the output to the CLI like advised in the 'cron debug' thread and git this error:
PHP Code:
DateTime::__construct(): Failed to parse time string (1970-01-01 25:43) at position 11 (2): Unexpected character
|
|
|
|
| The cron debug thread: my cron task keeps running |
|
Posted by: Guido1982 - 09-24-2018, 09:53 AM - Forum: Administrator Support
- Replies (2)
|
|
I've got a recurring salesorder task and a planned report task that keep running. No idea why but that's not really my intention of this thread. I'd like to use this thread to teach a man how to fish. What are the best ways to debug any cron task that exceeds the time limit? Maybe I'm missing some Apache or PHP modules? I've come across this problem before and think it would be very useful for any coreBOS admin to have a good debug toolbox for cron tasks since they are hard to debug and I never really found a peak under the hood.
|
|
|
|
| How to sum invoices on a salesorder and record the 'fully invoiced' date |
|
Posted by: Guido1982 - 09-23-2018, 12:18 PM - Forum: Administrator Support
- No Replies
|
|
Say you have the following use case:
You create salesorders to keep track of you sales, but your company has the habit of not invoicing the salesorder in one invoice. You want to record the date that a SalesOrder is fully invoiced, meaning: when did I create the invoice that totally invoiced this SalesOrder?
Well, here is what you would do.
First off, update your coreBOS! We discovered a small bug that we fixed here. Without this change, this will not work.
Next, create some fields on the salesorder module:
- One for the sum of all invoices
- One to record the date we're looking for in the first place
Of course create the fields with the right types.
Next, you need to create a text field on invoices that will hold the SalesOrder no. that the Invoice was created from or related to. We need that later to match the invoices to the salesorder. Call it anything you like.
Now we create the workflow on the Invoice module. I created the workflow to check on every save, but you can adjust that if your needs are different, but do understand that it may not work exactly as described here if you do.
First you create a task that gets the salesorder no. on the invoice field you created. Use an 'update field' task type and don't let it evaluate conditions on execution: we want this to happen always. Add a field to fill (the one you just created on invoices) and set it to 'use field'. use
Code:
$(salesorder_id : (SalesOrder) salesorder_no)
(or just select the Salesorder no. field from the dropdown, will do the same thing).
We now have a task that gets the salesorder no. and fills that into our custom field on the invoice, every time the invoice is saved. Now let's create the second task that will use that field to update the sum of all invoices on the salesorder based on that Salesorder no.
Create a second task in the workflow that you call 'sum all invoices on salesorder field' (or something like that in your language). Select the 'update field' tasktype again and don't evaluate conditions. Again, we need this to happen always. Select the 'sum invoices' field you created in the beginning as the field to update. Now use this code to sum all the invoice amounts into the field (Beware, adjust the custom field name here):
Code:
aggregation('sum','Invoice','sum_nettotal','[cf_1248,e,$(salesorder_id : (SalesOrder) salesorder_no),or]')
You need to replace 'cf_1248' for your own custom field no. That will be the field no. that you save the SalesOrder no. on in your Invoices. So again, this is the custom field on Invoices that you filled one task earlier.
What this does is: it uses the 'sum' method of the 'aggregation' function to get all the 'sum_nettotal' values of the 'Invoice' records. In the second to last parameter we say: 'cf_1248' (should be your custom field name) needs to be equal (the 'e') to the 'salesorder_no' field of the related SalesOrder. The 'or' is mandatory to glue more conditions, even if we don't have any. So this is how we match the invoices to the salesorder or: get only the invoices that belong to the salesorder we are updating.
We now have a mechanism in place that updates a field on salesorders with the totally invoiced amount. Beware, I use the sum_nettotal field here. If you need some other total, replace all instances so far (maybe you want the value with taxes, or with grand discount deducted).
Now we want to record the date that the salesorder is totally invoiced. So we want to prevent updating the date field when the 'sum' field on salesorders is lower that the salesorder total, and we want to prevent updating the date field after is has been recorded once. Say we edit an old invoice to change some date field or mark it as Paid, we don't want to affect the date field on SalesOrders when we do that (at least in this example, your needs may vary).
So we create a third task on the workflow we've been working on. This will again be an 'update field' task type. This time, we need to check the 'evaluate conditions' box and create some conditions. The first condition will prevent us from altering the date field once it has been filled once. Create the condition and select the date field we created on salesorders, choose the 'is' condition and leave the field right to it empty. Essentially we are saying "only do this if the date field is empty". Now create a second condition and leave the 'glue' to 'and' (the default). Select the 'sum' field we filled in the second task and select the condition 'greater than or equal to' (or just 'equal to' if you only want to do this when it equals but want to prevent filling the date when you over-invoice). Now in the right-most field you can select the field you want to match against. In my case this resulted in
Code:
$(salesorder_id : (SalesOrder) sum_nettotal)
but again, your needs may be different. Anyway, this matches against the sum_nettotal field of the salesorder. Since that's also the field we used on Invoices I would advise you to use the same fields on the entire worflow, otherwise you would be comparing pears to apples.
Now add a field to update and select 'SalesOrder' from the first dropdown. Because this is a reference field, a new dropdown will appear with all the fields from salesorders. There you can select the date field you created in the beginning. Now just select 'formula' when you click the rightmost field and enter
in the box. This will get the current date for you.
So there you have it. Whenever invoices are created or edited, they will update the salesorder with the totally invoiced amount and record the date of the first 'totally invoice' occurance for you. Any questions or remarks: please respond below.
|
|
|
|
| A regular expression to assert Workflow expressions |
|
Posted by: Guido1982 - 09-21-2018, 07:14 PM - Forum: coreBOS Development
- No Replies
|
|
Just for fun I wrote a regular expression that would assert and capture a vtlib expression in 'normal' and 'poorly' written formats. I also tested some deliberately wrong formatted ones. Tested them on https://www.regexpal.com/. The expression is:
PHP Code:
\$\((\w+) ?: ?\((\w+)\) ?(\w+)\)
The 'right' variations I came up with are:
$(reffield : (ModuleName) field)
$(reffield: (ModuleName) field)
$(reffield :(ModuleName) field)
$(reffield:(ModuleName) field)
$(reffield : (ModuleName)field)
$(reffield: (ModuleName)field)
$(reffield :(ModuleName)field)
$(reffield:(ModuleName)field)
The 'wrong' ones I tested are:
$reffield: (ModuleName) field
$(reffield) : ModuleName (field)
$(retfield : ModuleName field)
Maybe we could use this one day, or just for fun keep coming up with correctly formatted or incorrectly formatted ones.
|
|
|
|
| fetch_array vs FetchRow |
|
Posted by: Guido1982 - 09-17-2018, 08:11 PM - Forum: coreBOS Development
- No Replies
|
|
I noticed something in the August blog, a speed comparison between fetch_array and FetchRow. Joe, could you elaborate a little on this? What is the difference between the two, in speed, usage and results?
|
|
|
|
| GenDoc questions |
|
Posted by: addady2 - 09-16-2018, 01:00 PM - Forum: Administrator Support
- Replies (6)
|
|
Hello,
I have several questions regarding GenDoc extension.
1)
I Find in this forum old post regarding GenDoc online demo. https://demo.coreboscrm.com , but it don't seems to have GenDoc
Is there other any online demo?
2)
Will GenDoc work on the task / todo module?
3)
Dose sending generated pdf as email attach to the customer from the CRM need payed subscription.
Thank you
|
|
|
|
|
