Google Docs Gets an API For Task Automation (techcrunch.com)

An anonymous reader quotes a report from TechCrunch: Google today announced the general availability of a new API for Google Docs that will allow developers to automate many of the tasks that users typically do manually in the company's online office suite. The API has been in developer preview since last April's Google Cloud Next 2018 and is now available to all developers. As Google notes, the REST API was designed to help developers build workflow automation services for their users, build content management services and create documents in bulk. Using the API, developers can also set up processes that manipulate documents after the fact to update them, and the API also features the ability to insert, delete, move, merge and format text, insert inline images and work with lists, among other things.

The canonical use case here is invoicing, where you need to regularly create similar documents with ever-changing order numbers and line items based on information from third-party systems (or maybe even just a Google Sheet). Google also notes that the API's import/export abilities allow you to use Docs for internal content management systems.

Comments

... until two weeks later, when they casually ment

[Anonymous Coward]

... until two weeks later, when they casually mention in a blog post somewhere that they have removed it.

Re: ... until two weeks later, when they casually

[Anonymous Coward]

It is impossible to keep up with google and their changes unless you are constantly logged in which I am not

VBA macros for Google Docs!

[Anonymous Coward]

Google Docs gets malware macros. Welcome to the big leagues! What could possible go wrong?

Re:VBA macros for Google Docs!

[Narcocide]

Well, someone could write an anti-virus program in JavaScript, which would then subsequently exhaust the entirety of the world's computing resources. Poof, no more bitcoin. Sound bad enough?

Re:VBA macros for Google Docs!

[HarrySquatter]

Will the anti-virus run in a Javascript VM as well?

Re: ... until two weeks later, when they casually

[Anonymous Coward]

Just shove a big, black, spiked dildo up your ass. That's what being a Google cuck...err... user is like.

Congratulations, Google

[Voyager529]

This sounds like a "Macro" with more steps. Welcome to the 1980's.

Re: Congratulations, Google

[Anonymous Coward]

With a macro, everything still stays within the Google Docs environment. An API will let external applications initiate actions, push/pull data, etc.

Invoices need to be electronic.

[SETY]

Rant..
Invoices are generated by a computer and then get typed into the receivers computer by a human. Super inefficient and prone to error. Invoices need to be electronic and this needed to happen years ago. Iâ(TM)m not talking about special cases for big business. This is a small business problem and needs to happen in atime ftware such as quickbooks without vendor lock-in.

Re:Invoices need to be electronic.

[Mr.No]

Rant.. Invoices are generated by a computer and then get typed into the receivers computer by a human. Super inefficient and prone to error. Invoices need to be electronic and this needed to happen years ago. Iâ(TM)m not talking about special cases for big business. This is a small business problem and needs to happen in atime ftware such as quickbooks without vendor lock-in.

Exactly. More than 30 years after the usage of computers in most businesses it is shocking to see 100 pages invoices being sent as PDF files and then some other company either typing them into their accounting system or attempt to OCR, push into Excel and then process. Why can't the business analysts, IT people and accounting department sit around a table? The generation of the initial PDF should surely come from an accounting system isn't it?

Re: Invoices need to be electronic.

[Anonymous Coward]

QR codes seems like solution if a physical document is required.

Re:Invoices need to be electronic.

[fluffernutter]

Normally you have to work with real paper when real signatures are required. There is no digital alternative to a real signature.

Re:Invoices need to be electronic.

[Anonymous Coward]

Funny, it's been years since Amazon delivery guys asks me to sign on a digital screen without paper. Also, was involved myself in adding digital signatures to a workflow in iOS apps. Digital signatures can work, but people have to make the effort. Plus if you go digital why use a fakeable signature graphic when you could as well use PKI. Maybe in the next 100 years or so

Re:Invoices need to be electronic.

[Anonymous Coward]

Welcome to modern world !
https://www.docaposte.com/en/solutions/electronic-signature

Re:Invoices need to be electronic.

[fluffernutter]

Yes and how much does this solution cost? Before you answer, it had better be as cheap as the ink from the pen in my hand or you're wasting your breath.

Re:Invoices need to be electronic.

[fluffernutter]

Are there free digital solutions? Because if I have to pay a cent extra I'll use real paper thanks.

Re: Invoices need to be electronic.

[sce7mjm]

It would require to systems staff of both companies to have a ten minute chat to work out suitable format that can be emailed or uploaded to the other and then parsed into the accounting system.

I doubt this happens very much because the amount of people who have understanding or control of the systems to the extent required is limited, especially since the push to the cloud with access via api and or third parties only and simplified user interfaces which no longer required a systems team. Ie outsourcing made the process complex, inflexible and cheaper.

Whoops.

Re:Invoices need to be electronic.

[dinfinity]

They can be:
http://ubl.xml.org/wiki/ubl-fa...

Re: Invoices need to be electronic.

[Anonymous Coward]

I'm pretty sure it had more to do with the face that this 10 minute conversation would need to happen with every single customer thus giving you a multitude of standards to deal with. I mean sure you could force all of your customers to adhere to your standard but what about their customers?

I mean nice try, but just like the multitude of methods of communication between individual human beings, there exists a multitude of methods of communication between businesses and good luck getting everyone to the same standard.

This is the problem with the over specialization that is taught today, people only think of their own use case and how to solve that and forget to consider how that solution would affect the rest of the use cases. This is extremely beneficial to large conglomerates like google who can come out with a standard that satisfies the majority of use cases and then use their influence from other areas to force this on to whole industries

There has been a push for an XML variant names UBL (for universal business language) but the problem with adoption is the lack of control. That is what the fight is about now a days, power and control, and if you dont control the standard then you are at the mercy of the group that does.

For example: say you start implementing all of your business documents in google docs and you start to implement this flashy Macro API, you are now at the whim of google and they have a track record of discontinuing things after a couple of years to force people to adopt the next new thing (which will most likely be some old thing but with an all white background and google colored icons for a UI) Sure it will be easier to get all of the suppliers and customers to switch to google docs but then you have just handed google a large amount of power over your industry, one it can use to extract money from you at the rate just less than it would cost you to go to some other standard.

Re: Invoices need to be electronic.

[sce7mjm]

I agree with you. It's a question of scale though.

If I have ten invoices a month from 1 supplier and 10000 invoices a month from another then I would definitely seek to improve the flow from the larger supplier, whether it is by some published standard or rolled between us and the larger supplier.

I would not try to solve both tasks with the same solution.

If my invoice load is 1 invoice each from 10000 suppliers the problem is different and I would be encouraging them to use either our system or again some published standard but be aware that they may refuse.

My point was if the companies can't do this at all if they no longer have the skills to modify the systems.

Mail merge 2.0

[Anonymous Coward]

Congratulations for reinventing something?

Decades late

[Anonymous Coward]

There are libraries for pretty much every programming/scripting language for automating document creation with a lot more power than this seems to have.

The problem with these types of things is that you end up getting the wrong types of people using them. That's why you see people rolling their own software using macros in Excel when it is way outside of the scope of what Excel should be used for.

wow, welcome to 2010 google.

[Anonymous Coward]

I look at this in comparison to what other cloud platforms offer and provide and think OMFG how did google get ANY enterprise customers. I know they lost a lot when reality set in after being conned into moving to them but such basic functionality that is missing is inexcusable and even what they bringing with this still leaves them many years behind their competitors.

Re:wow, welcome to 2010 google.

[Anonymous Coward]

2010?? You are about 20 years too late.

Welcome to the 90's.

Re:wow, welcome to 2010 google.

[fluffernutter]

I agree, the google mail console was not better than the yahoo mail or the hotmail console. They all suck, yet somehow they persist largely in the state they were at their inception.

Sounds potentially useful, how long until they EoL

[AbRASiON]

Well, it is Google, only a matter of time

They could save themselves the hassle and just Jill it off now to be honest.

Not really impressed

[eminencja]

After looking at some code samples in the documentation - I'd rather go back in time to the 90's and work with MSOffice and VBA.

Re:Not really impressed

[Anonymous Coward]

Could you elaborate?

Google deploys sed

[packrat0x]

... but changes all the options

weak AI

[fluffernutter]

Wow, other office suites do this with regular programming but Google does it with "AI"! That's progress!

In other news...

[Anonymous Coward]

The Google Tasks web interface is being shutdown.
https://9to5google.com/2019/02/05/google-tasks-web-dead/

Sparking more inventions

[GlobalEcho]

Every few years, I end up talking to some poor schlub who has reinvented relational databases. Badly.

It's not their fault, some of the folks are pretty smart. They just don't know. Anyway, Google just enabled another menagerie of eldritch cross-referencing nightmares.

Re:... until two weeks later, when they casually m

[Hognoxious]

They're already working on an API for removing it automatically.

Re:... until two weeks later, when they casually m

[slack_justyb]

They'll have a framework for that API to automatically remove uses of the replaced API, the framework however will require the use of a new programming language of which they've got a handy SDK for converting Go, C++, and Java into the new programming language which then "compiles" into a 126MB JavaScript blob.

Re:... until two weeks later, when they casually m

[Hognoxious]

They already did all that, but they accidentally ran it on itself.

You want proof? Well it's not there any more, is it?