Monthly Update – January 2017

Welcome to another dissection of the miniTPMS update.

So far we talked about couple of stuff at the very beginning, like basic project entry into our TMS.

And then we moved on to client and vendor finances a little.

During January we continued working, but a little differently - which will become ​sort of a "standard" procedure for the next period: less design, more development. Unfortunately, it's non-visible development, but hey, you just have to trust me, things are happening.

A little more on Purchase Ordering for Vendors

First let me get back a little to the Purchase Orders system that I left out in my last post.

​The goal of our translation management system is to combine usability, simplicity, and speed with customisable and flexible models. Since we have no idea how other agencies work, and how ready they are to accept what we're cooking for them, this is not so easy to do. We're trying, bare with us.

So, in that light this is the general concept behind our Purchase Orders systems for Vendors, and Invoicing procedure for Clients:

​For example, this PO grouping is much better if your vendors like to get one big PO at the end of the month (or quarter, or year for that matter) instead of you filling their inbox with useless PO mails that will get lost, possibly deleted, thrown away like an old pair of ripped jeans.

But, since you are just piling up task after task on the screen with approved vendor jobs and not sending the PO out, it might get a little crowded over there.

Just in case you missed last months screenshot of Vendor tasks that​ are ready for Purchase Order, here it is again:

Now you can wait and do nothing for a month and click all at the end of the month and send it all at once (in ONE combined PO, how awesome is that). But, sometimes there is too much Vendor work, and you don't want to pay all of it, you only want to pay some. Or you can have other reasons... ​

And that is why you can create a "Draft PO" or, kind of move the actual PO to the "PO waiting room". Call it as you see fit, the point is: you can create a PO without sending it out. This removes vendor jobs from the "Approved for PO" screen, and puts it in the "PO Waiting Room" where - if you made a mistake or changed your mind - you can always go and change stuff to better or worse. 

If you have vendors who you are paying every six months, and there is 500 tasks on the list, this kind of "waiting room" becomes pretty handy. Here's a model screenshot: 

You can add new approved tasks to these POs (from the approved tasks screen), or you can delete tasks from the POs (in that case they go back to the approved tasks screen)​, which is all great if you have just remembered that one more task was not paid in time, and you want to fix that error now. So, it's a better control of your actual finances. And error management. Fixin' the mistakes. Etc.

The "Archiving" POs or just showing the sent POs below is still on debate. But obviously, we need to have a good place to show what was sent and what is the status of the sent POs (paid, unpaid, etc)​. Of course, this will be closely connected to Vendor invoicing which comes later. So many things to do...

Small tweaks: We'll most probably make the PO number (or the whole row) clickable, in which case the user will be able to see the actual PO in html, or PDF format.

Using the same System for Client Invoicing

The same system will be applied for Customers and their PO's, because of consistency reasons (actually, we are trying to create the whole minitpms very consistent and "familiar" once you get to know the very basics). Anyway, this is where it becomes interesting.

So we have a client that sends us, say, 55 components in one month and all are in one PO. This can easily create a little chaos on your financing side, I mean, if all these PO numbers and their data is filling in your screen like grandma fills your plate when you go over to lunch. So we are creating a way to put "away" the tasks you want, and to leave the rest on the list, if that is your cup of tea.

As I said, the concept is similar to the one with Vendors. Draft invoices are created, and can be changed at any time, tasks can be deleted from them, or they can be added, so that you can completely synchronize your actual financials with the numbers that you get from clients (after approval, or if they are sending you a PO later down the line).

Of course, for those who like sending the invoices immediately, there will be a possibility to send the invoice upon creation (to the appropriate e-mail address).​

Ignore the numbers discrepancy etc, as I often mention, this is a screen model not the actual "live" screen. We like working this way because:

The Tasks List in Many Disguises 

Finally let's get a sneak peek of the current tasks. It's a simple list of active (or here called "current") projects. Ongoing stuff. 

This is the first draft concept, pretty basic, pretty simple, but it will grow bigger and have a lot of customization possibilities:

​The last bullet points might need a little explanation. Let's say the "Default" data layout is: LSP company + EndClient + ComponentRoot + Component + Languages + Vendors + Dates.

If you don't like this, you can change to show Start date in column 1, or Due date in column 1, etc. You will be able to completely ​rearrange it in our translation management system, because that's what makes it super-useful for a user like you.

One thing I'm thinking about implementing is the "Recently finished" list which will be put below the list of currently ongoing projects. The point is to have it there to see what was finished in a short period of time (let's say, one day), and to have an easy way to get into the project and change something or approve the financials if you want, etc.

Extremely powerful if you have different people clicking the "task done" and approving the financial part.  

Let's see the finished projects with different grouping, and different data shown:

Of course, there also will be a separate list of finished projects, announced projects, etc. The possibilities are endless.

Okay, so basically that is for the visible part, let's move on to the non-visible for just one minute.

Backend is where the magic happens​

Unfortunately, the magic is something we don't see. We only know it exists. 

Backend development started now in January. It will take us some time to build it, and then move on to front-end, and finally, there is a light at the end of the next ​couple of months long tunnel, so our early adopters can start rubbing their hands because they will get a very early beta to test... 

Want to be an Early Adopter? That is awesome, because our prices go up every month (plus couple of days) until we reach the point of Global launch. But right now, you can still get in for dirt cheap which is the best long term strategy ever. 

Find our current prices here.