I created two user fields, one for first use in commerce and one for first use anywhere. I wouldn't try to overload priority date or some other pre-existing date with first use information.
Of course, it would be nice if AppColl had standard fields for these dates.
As the number of tasks continues to grow, we need to be able to filter the list of task types in addition to just searching for the next task type that contains a word. While I would prefer filtering based on any of several task fields, even filtering the display to just task types that contain a filter word in the TaskType field would be a big help.
For example, all of my country-specific tasks have a task type that starts with the two-letter country code. Being able to filter the tasks list for, say, only tasktypes that start with CA would be a useful improvement.
Mind you, I would also love for you to add a CountryCode field to tasks (with the default being "All countries") and allow me to filter on that, too.
@TPLA3794 I did create a few custom tasks. Because my practice is small (I'm semi-retired), I only created tasks that met my immediate needs rather than attempt to be fully general. But I'd be happy to share them with you, of course with the understanding that I take no responsibility for how you use them or for any errors that might be in them.
Drop me an email at richard@schafer-ip.com and I'll try to figure out a good way to share them.
@SadiqA2304 That certainly seems odd and I haven't seen that problem in my account.
@KristaJ3145 Don't be too shy about changing standard tasks to fit your needs. I've done it a lot without any problems.
I can think of a few ways to do this.
Create a user field that indicates annuities are paid by the client as a Yes/No field, such as TaxPaidByClient. Then update the triggers for the annuity tasks to include a criterion that the TaxPaidByClient does not contain Yes. You could do it with the criteria that the field contains No, but then you'd have to set that user field in every matter where you pay the annuities. Which is best may depend on the ratio of client pays vs. attorney pays.
Add a tag to the Contact entry for the client that indicates Client pays annuities. Then add a trigger criterion that says the tag does not contain that indication to the trigger for generating the annuity task.
Put a keyword in any matter where the annuities are to be paid by the client. Then add a trigger criterion that that says the keyword field for the matter doesn't contain that keyword.
The feature of automatically generating a billing item when the Task Status value changes should be enhanced by making the triggering status value a drop-down using the configured completion states instead of having to type in a value.
One of the great weaknesses of AppColl is the lack of tasks related to non-US prosecution. I'm trying to develop a fleet of tasks for Madrid applications for use with my clients. Is anyone willing to share how they're doing it?
@JessamyN2308 Here's a way I think might work. Create a user checkbox field named something like USNonpublicationRequest. Check the box in the US matter if true. When you create a non-US app where a non-pub request was filed, check that box i the foreign matter, too. Then create a "Request non-pub recission" task that is triggered by the filing date field in the non-US app gets any value while that checkbox is checked. Make sure that the task setup checks the "only create in any related US app" box. That should generate the task in the relevant US app.
Alternatively, you could skip the checkbox in the foreign app, and just auto-generate the task in the related US app any time you file a foreign app, but then you close the US task with not needed.
It's not ideal, but it might be better than nothing. To do more would require AppColl to implement a way for one task to cause the creation of a task in another matter, depending on a condition in the other matter.
While the Connections field lets me see the priority application(s) for the current application, including information on child applications would be really nice. Yes, I can go into Patent Center (for US applications) and use the Continuity tab to get that, but being able to click on a link to a child application in AppColl would be quite useful.
@GeorgeJ4336 At first glance, the right answer would seem to be don't change commas to semicolons except when parsing email address fields. There's no reason to change commas to semicolons elsewhere. But your template would fail even if they only did that and you had a BillTo.EmailNoCC value of "jack@xxx.com, jill@xxx.com"; that would produce an invalid email address:
Nicole Sxxxx Xsssss(USA), Inc. <jack@xxx.com; jill@xxx.com>
Gregg, yes it does. But I start from the Reports module, generate a report, then change it, I have to enter the report name in full, since the drop-down wasn't used.
From time to time I need to edit a report to change something. Now, I have retype the report name and select the overwrite existing report just to save a change in a report. Can you provide a way simply to save changes in an existing report without going through the "save as" process?
@GeorgeJ4336 My suggestion is that Matter.Examiner and other name fields should be treated similarly to a Contact so that the .First, .Middle, .Last, etc. subfields that we can specify for Contacts could be used for non-Contact name fields.
Can you share with us anything about your plans for future development? Is there a roadmap that you can share?
@TarC6989 You can also see the client name if you click on the field name "Client" in the Matter Details screen.
On further review, I'm a bit confused by both the original posting and your response. There is no Matter.ClientCode field nor a Matter.ClientFull field. There is a Contact.Client field and a Contact.ClientFull field, but at the moment those fields appear unused in Client contact entries and I can't see a way to provide them with any value. There is a Contact.ShortName field, which is what is filled in from the field labeled "Client Code" in a Client contact entry, and a Contact.Name field, which is what is filled in from the field labeled Company in a Client contact entry. There is also a Client.Company field, which appears to be a duplicate of the Contact.Name field.
However, in a Client/Solo Inventor type contact, oddly enough, the Contact.Client field is filled in with the "Client Code" value from the screen and is a duplicate of the Client.ShortName field. And, again only in a Client/Solo Inventor type contact, the Contact.ClientFull field is a duplicate of the Contact.Name field, i.e., the full name of the person, with the Contact.Company field being the Contact.Client field concatenated with the Contact.Name field in parentheses, e.g.,
1999 (John Doe)
This inconsistency between Client and Client/Solo Inventor type contacts is a bad idea, I think, although by now that would be somewhat disruptive to fix.
NB: There is a formatting problem with the Client Code field on the Client-type contact data entry screen. Instead of being aligned with the Client Code: label, the entry field and the small entity checkbox are vertically offset from the field label, unlike any other field on the screen.
The formatting error in the Client type contact doesn't appear in the Client/Solo Inventor type contact:
@gregg_appcoll As far as I can determine, there is no field named {Matter.ClientFull}. It's not listed in the help topic listing all form fields and there is no field by that name that appears in a dropdown for configuring columns to show in a report.
I think what you meant to say is {Matter.Client.Name}. For example, my form letters all start with:
{Matter.ClientContact.PersonalName}
{Matter.Client.Name}
{Matter.ClientContact.Address}
Re: [variable stuff depending on the form letter]
Our file: {Matter.AttorneyRef}
Dear {Matter.ClientContact.NicknameorFirst}:
My {Matter.Client} value (which I presume is what TarC6989 refers to as Client Code) is always a 3- or 4-digit number. My AttorneyRef values are always in the form of
[clientcode]-[matternumber][countrycode][optional extension]
e.g., 1295-0002US.
@JonahP1621 I've certainly worked with more than one docketing systems that allowed matters and docket entries to be assigned to multiple attorneys. That way, things would show up on each person's docket. Usually, the docketing system simply designated them as Attorney 1, Attorney 2, etc. and the firm could choose by policy the roles assigned to each of the Attorney n fields. At one big firm where I was a partner, at least one partner insisted that docket reports produced for him only show docket items for those few cases where he was the working attorney. The system we had there was so bad that I found to my horror that
one docketing clerk spent their entire day just producing daily docket reports for each attorney by running a giant docket for everyone, then manually extracting the docket for each attorney into a spreadsheet for just that person. I was able to cut that down to no more than an hour by writing some code to split the giant docket into individual files. It wasn't a great solution but was the best we could do with the limited capability of the system.
@TarC6989 While that might be a nice idea, given how little support is currently builtin to AppColl for non-U.S. prosecution, I'd rather they spend time developing that support.
@MelissaT3398 Like other firms I've been at, my current firm includes the country code in the matter number. E.g., the AU designation in a Madrid case would be 1234.0002AU. So including an extra copy of the country code in the search results would be counterproductive for us, since it would take up more of the limited space.
From time to time, I need to send an informative email to a group or all of my active clients. I would really like to generate that email by selecting the relevant client contacts, then have AppColl generate the email, either as separate emails with them as To:, or as a group email, with each of them in the Bcc: line.
I'm looking for suggestions on the best way to docket dates for a client to file an opposition or an EOT request against a third-party trademark application. AppColl has a fairly well-developed series of tasks for opposition due dates once an opposition has been instituted, but nothing before then. Surely someone must have done this already.
Do you use a regular trademark matter or an opposition matter? You have to ask AppColl to add the opposition matter type, and it's pretty limited in the available fields, so there's nothing like a publication date field that you could trigger an opposition deadline task against. Before I go through a lot of effort to build a structure of tasks for this, I thought I'd see if anyone else had useful advice.
@jonah-soundhound-com And based on my experience, I can guarantee that foreign associates will do that.
@SadiqA2304 I'm used to programming, so the idea of adding syntax for more control of the templates feels better to me than adding fields that have logic embedded into them. I agree that putting the first name into the nickname field if no nickname exists isn't a great solution, but it does work until they provide something better. You only have to embed the nickname field into your template to get the desired result. It's a little extra setup work to remember to fill in the nickname field when it's not really a nickname, but that's a one-time effort when you create the contact.
I'll always prefer a programmatic way to accomplish the result over fields that have field-specific logic embedded into them, because they allow a more generalized result. For example, none of the several priority fields produces exactly how I often
want priority information specified. As it is, the list of fields doesn't remind me how each version is formatted, so I have to do tests to figure out which one has the closest to what I need, then manually edit the result of the template every time it's used.
If we had a generalized formatting syntax, we wouldn't have to wait for AppColl to create yet another special-purpose field, but would immediately have the ability to get what we want.
@SadiqA2304 The format I proposed is very similar to the way you can format cells in Excel and the way date fields can already be formatted, But the real advantage would be that you wouldn't be limited to specific fields, but could format any field you want however you like it.
@SadiqA2304 I'd rather not add yet another field. First Name and Nickname aren't the only fields that could use something like this. For example Filing Date and Official Filing Date. What I'd really prefer is some kind of syntax that allows generally indicating "use field X if it's not null, but use field Y if field X is null." Perhaps something like:
{{Matter.ClientContact.Nickname},{Matter.ClientContact.FirstName}}
I'm not pushing that syntax. It was just the first thing that came to mind. Even more powerful would be a more generalized IF syntax.
What I end up doing now is filling in Nickname with the first name all the time, and just using Nickname all the time.
@SadiqA2304 Instead of a new field, I'd rather have AppColl allow formatting characteristics in non-date fields like it does with dates. Something like:
{Contact.USPTORegNum(#dd,ddd)}
That way I don't have to remember yet another field name.
There's already a link from the matter to billing items for it. Look for the green $ just to the left of the matter number at the top of the matter details screen, or in the group of icons in the Links column of a list of matters.
Does anyone have any suggestions for the best way to docket international design registrations under the Hague convention? If you've already done that and would be willing to share what tasks you created, I would appreciate the help and not having to customize everything from scratch.
@BerndN5890 How did the DOCX fill go wrong? I had a problem where the fields in the header weren't being filled and fields in the body were filled, but followed by the last letter of the field name and a ). That problem was supposedly fixed.