Maintenance on Google Group registrants

In the last article and the one before the last, I introduced you Business Process Definitions which automatized addition or deletion of members of "Google Group" to be carried out.

If Google Group is being used as "In-house information sharing tool" in your company, these functions such as automatic addition and automatic deletion could be very useful as "mechanism to guarantee timely update".

Height of reliability requirement

However, even if you introduced such a mechanism, "maintaining correct members" is not easy.

In some cases, for example, you could have added a member to a "wrong group" (system administration screen) in corresponding to a rush-request. Or, there may be cases where a user him/herself commits "unsubscribe processing" (User setting screen). Those cases are state of "Information will reach people who should not reach" or "Information does not reach the person to reach".

"What? Was there such a notification?"

An employee worked without receiving information via mailing list for months feeling something was strange. That kind of Tragedy (which is a very terrible thing) will always occur someday.

[ML Member Confirmation]

Management of mailing list

In the previous article, I introduced you a Business Process Definition of a Workflow in which (email address of) "newsletter subscribers" are added to "Google Group" automatically. (Task of corresponding to information material request.)

That was a mechanism by which one email address to be added to "one mailing list" automatically.

However, when you look around mailing lists inside your company, (even though it is on a downward trend due to the spread of so-called "chat tool") you will find various in-house mailing lists are used on a daily basis in many tasks, such as "Directive of the business policy", "Sharing information that should be limited within a department" and "Receiving system alerts".

Therefore, regarding management of mailing lists, it might be more cases where you want to add an email address to all of the "multiple mailing lists" at once.

Bulk registration to multiple Google Groups

The following Business Process Definition is "flow for new account request".

If there is a "new account request" from within the company, the IT system department will make necessary system settings such as "issue new account" and "modify LDAP setting".

What noteworthy is that the Step for addition and deletion in "multiple mailing lists" is automated. (automatization of Step)

That is, when an Issue reaches the Step of [Add Group Member] or [Delete Group Member], the Workflow system will send a request for addition / deletion (OAuth2). This means that, concerning a task of "addition / deletion in mailing list", the person in IT system department in charge is required only to confirm if selection is correct: "Google Group to be added to" (Checkbox) and "Google Group to be deleted from" (Checkbox). So the personnel in charge no longer needs to access "G Suite" dashboard and edit the Group setting one by one. (Admin SDK Directory API v1)

[Account issuance - List registration]

Information sharing by email

Mailing lists are useful.

It is used in many organizations on a daily basis, such as for "information sharing" within the organization or for "information announcement" to customers. However, there are not a few cases where "maintenance work" of the list is neglected.
  • Delivering to people who should not receive the email (Information leakage?)
  • Not delivered to people who should receive the email (Typical tragedy on newcomers?)
Such a kind of situation will be occurring all over the world.

Automatic addition of Subscriber

The following Business Process definition is "Information material request correspondence flow".

This Workflow will be initiated by request via Web by a customer. And, when the requested Issue reaches at the automatic Step "Add to Subscriber", the "customer's email address" will be automatically added to the mailing list (Google Group).

Such "automatization" of processing not only eliminates the trouble of the G Suite administrator accessing the management screen to manually copy the data, but also contributes to preventing troubles due to setting mistakes and time loss. Moreover, it realizes "Address addition history record" which was difficult by manual setting.

[Information Material Request Correspondence]

Productivity Improvement by Automation of Steps

In the last article and one before the last, I introduced you a mechanism to control "PayPal billing system" from Workflow system.

In these mechanisms (Workflow Application), an automatic Step (Addon Service Task) is arranged in the middle of the flow diagram. That is, each time when a billing Issue arrives these Steps, the Workflow system transmits "Requests" such as
  • Generate "PayPal Invoice" (PayPal Create)
  • Transmit a "PayPal Invoice" (PayPal Send)
  • What is the settlement status? (PayPal Check)
In other words, "accounting works" such as "generation of electronic invoice", "transmission of electronic invoice", "confirmation of status of electronic invoice" have been made unmanned. (REST / OAuth2 communication with PayPal Invoicing API)

Today, not only the "payment system" (*1) as in this example, but also the operation of various information systems are automated, and the productivity is improved. For example, preservation of quotation to "Storage system" (*2), or management of product master data in "Spreadsheet / Data management system" (*3), are typical examples.

*1: PayPal, Stripe, etc. *2: Dropbox, Box, Google Drive, etc. *3 Google SpreadSheet, Kintone, etc.

<Setting screen: PayPal Create>

<Setting screen: PayPal Send>

<Setting screen: PayPal Check> 

The fact that the process owner only needs to set properties of the Addon automatic Step (programming knowledge is no longer needed) is also one of the reasons for popularization.

Until which stage of situation change you should make unmanned?

However, there are not only "advantages" that unmanning brings.

In the previous article, for example, it was a business flow that it continues confirming (keep on looping) until the status of electronic invoice turns to "PAID".

It sure is, there is no human cost on "confirmation work" alone since human does not intervene.

However, if an event such as "order cancellation" or "remittance with another settlement method" has occurred, it may be necessary to stop the Task of "shipping processing" in some cases. Or depending on circumstances, it may become necessary to modify the processing of "recording sales". Yet, as for the situation change which "influence degree × occurrence probability" is large, as a business process definition, I would like to make it "within the range of assumption" as much as possible, not leaving it as "unexpected".

In the following business process definition, "CANCELED status" (cancellation) which is relatively frequently occurring has been taken into consideration. That is, it is added devising that alert email to be sent when payment is refused.

[PayPal Invoice Issuance-Cancellation notification]

Automatize billing

In the previous article, we created a workflow in which "PayPal Invoice" is automatically sent, by placing two automatic Steps "PayPal Create" and "PayPal Send".

That is, "billing data" which has been checked and approved in the human Step is automatically POSTed to PayPal side and then "PayPal invoice" is generated. And at the specified time (send command is delivered), it will be sent by email. After all, since it can be defined with only "Addon Service Task" ("Script Task" is not used), it is attractive to be able to build an "automatic billing system" according to your business even if you had no programming knowledge.

However, it was "out of scope" for "work of checking whether 'PayPal invoice' was settled".

Automatize throughout deposit confirmation

In the following Business Process, an automatic Step called "PayPal Check" (Addon Service Task) has been added furthermore. In other words, this Workflow system is set to continuously check the settlement status for "PayPal invoice" that has been sent, periodically and automatically.

Specifically, an Issue which is staying at "(3. Unpaid retention)" will arrive at "PayPal Check", each time when
  • the accounting staff proceeds the Issue, or
  • retention time of 12 hours passes.
So, the settlement status is inquired via secure communication (OAuth 2 communication / PayPal Invoicing API). If the status is "settled (PAID)", it will store "Settled time" and "Settled amount", and the entire process end, without returning to "(3. Unpaid retention)".

[PayPal Invoice Issuance-PayPal Check]

Invoice directly connected to settlement

"PayPal Invoice" is an electronic invoice in the format of "Email".

From the viewpoint of the person who received the mail, it is very simple since you can click on the "View and Pay Invoice" button and immediately complete the settlement processing (card payment / PayPal account settlement). Of course, even when "in-house transfer to accounting personnel" is required, it is very easy to do, just a transfer operation on email client.

Also, viewing from person who issued the invoice, it is very easy since its procedures are only
  1. Login to PayPal and enter billing data
  2. (receive Settlement completion notification)
comparing to conventional "Business Process of invoicing in paper" took
  1. Create Excel data of invoice
  2. Printout the invoice
  3. Mail the invoice
  4. Confirm remittance in specified bank account

Moreover, we do not receive credit card information, so there is no "information leakage risk".

In recent years, it has also gained much attention on the aspects of "productivity improvement" and "teleworking environment improvement". (PayPal Invoice)

[Example of received email]

API connection to Workflow

"PayPal invoice" does not require introduction of particular system.

However, this ease of "you can send an invoice by logging in to PayPal" also brings new challenges such as "ambiguous approval by supervisor" and "difficult to make mistake checks by multiple people". Especially if a company emphasizes "Business Process", there is a possibility of being discussed as a problem on governance.

In the following Business Process definition example, we have realized the policy that

"to utilize PayPal invoice without logging in to PayPal"

by implementing API control from the Workflow system. That is, the data which have been approved and checked in the workflow system is automatically linked to PayPal side through the API, and the "command to send the invoice email" is also delivered from the Workflow system via the API. And all work records of "When and who did what" are all recorded on the Workflow system side.

* If it is a Cloud-based workflow "Questetra BPM Suite", it can be realized for free. (By importing the Business Process definition, you can build it in a few hours.)

[PayPal Invoice Issuance]

Passive Step of "Receiving acceptance report"

Illustration production, Website production, Interior construction... "Acceptance inspection" is accompaniment to these outsourced businesses.

Issues based on contract is, not simply 1)"to deliver" the deliverable, but through 2) the step of "Receiving an acceptance report" from the client, and finally you can 3)"Claim the commission fee".

(Although there are cases in special business relationship where "Acceptance inspection step' is omitted and "immediate billing on delivery" is allowed...)

Pathetically sincere efforts and ingenuity have been performed all over the world, such as
  • attaching a sample of "Acceptance report" for clients, or
  • titling the slip as "Acceptance report request (cum-Deliverly note)" instead of "Delivery note".

Not yet decided what the Step is for to do?

However, "Receiving of Acceptance report" in the reality, there are not only cases that
  • A) They give "Acceptance report" on the delivery day.

There occurs various cases such as
  • B) they will send "Acceptance report" to the inspection deadline limit, or
  • C) the client presupposes the application of the "provision on deemed inspection passed" without submitting the acceptance report.

Moreover, there could be
  • D) cases where it is judged that "the deliverable do not meet the specifications" and forced to extend the acceptance period, or
  • E) cases where it is judged that "the deliverable do not meet the specifications" and forced to re-deliver.

So what kind of Business Process diagram should you draw for such cases? In particular, for cases of C) which is "doing nothing until the deadline, then ends", it is difficult how to express it.

[Acceptance inspection corresponding flow]

Measuring working time on certain process

For example, when you want to measure the "time required for translation" in the translation process, you can consider a method that having "reporting (inputting)" actual working time" together with the"translation result".

However, in that method, it requires to have the workers to measure the actual work time in the means such as;
Such an act of "self-measuring and reporting working hours" must be a major effort.

* However, there are still advantages that it is possible to respond flexibly, such as temporarily stopping the measurement, when time to be excluded such as "coffee break" or "corresponding to interrupt work " occurs halfway.

The accuracy of the reported value

Also, "Inaccurate actual work time" may be reported as a result.

For example, the "work time" would be entered a little differently from the fact, if it is a system in which some incentive affects to make the "translation time" looks shorter (or longer) in terms of personnel evaluation and ability assessment.

Alternatively, if there are workers who are proud of their outcome of the work itself and have no interest in such as "translation time", we have to assume that 'perfunctory data' will be entered.

[Translation flow]

Productivity declining due to mistakes

For those who make approvals, processing of "Sending back" is annoying.

Instead of reading the contents of an application and giving approval on it without saying anything (It will take 3 minutes), he or she must write a "reason for sending back" which costs 10 more minutes. (You don't dare to reject without a word, do you?) And if that was for "Point out simple mistake or typo", and if that occurred five, ten times a day, it may make you depressed.

And of course, the time to get home will be delayed by 1 hour and 2 hours.

Mistake occurrence rate lowered by system improvement

Mistake in "Date", "Amount", or "Customer name".

The applicants don't dare to make mistake on purpose. Basically, we would like to consider how to lower occurrence rate by "improving the Business Process Definition".

  • Improve "notes" and "input check" on input screen
  • Add "reviewing step" by colleagues to Workflow

[Base flow of Request type process-Script]

Logs of each Issue

When considering the optimization of the Business Process, in two categories of "master type data" and "transaction type data", analyze the latter.

More specifically, I will analyze "transaction type data" as an occurrence record such as "details of estimate No. 123" and "details of invoice No. 123", instead of "master type data" such as "merchandise master" or "customer master".

Logs useful for analysis

"FooBar Issue Details" flowing in the Workflow system is data that is accumulated every time an Issue is started, and it is all "transaction type data".

However, not all transaction information is stored in the "Data Items" defined within the Business Process. For example, "information held by the system side" (log of each case) such as "time reached at the 2nd Step" and "the number of times it has revolved around the loop structure" are not stored in an exportable form.

In the following workflow, it is configured "the number of times sent back" (number of times it has circled around the loop structure), that is "information held on the system side", to be automatically imported into "Data Item" which is on the Business Process side.

[Base flow of Request type process]

Start small

"How can I get used to the system?"

Considering only the investment effect, it is effective to systemize "existing inefficient work". If there is a work being done on "paper base", you should consider systematization of that work. If systemization is applied to "core business" such as order receiving, shipping and billing, "effect" will be more than "investment" relatively easily.

However, there are also risks that you can not get "effects" at all, if in a situation which is 1) administrator: insufficient system setting skill, 2) general worker: insufficient computer literacy. It is like forcing computer graphic to an oil painting artist.

"I may worsen business efficiency introducing a system." If you have such anxiety, it may be better to start a trial run first with "a small operation" (a work to be done every day if possible).

Habit of continuing to improve

When promoting paperless and teleworking, introduction of "workflow system" will be considered.

It is a very annoying question that to which operation to apply for the first, but for example, the following small workflow called "work time report" could be a powerful candidate. It is definitely good because "inevitably to use every day".

Naturally you will understand what you need and what you can omit, by actually trying "entering data", and "approving on it". And various ideas will be born through the usage.
  • Administrator: Will be Increased the skill of designing workflow
  • General worker: Understand the basic usage of handling Steps

[Hours Worked Report]

Too many input errors?

In the workflow system, "input errors" in human steps can not be avoided.

For example, if it is a workflow step that requires input of two date values "Bill issuance date" and "Payment due date", mistakes tend to occur such as;
  • Enter the date of one year ago as leaving the date after duplicating data
  • Enter Bill issuance date and Payment due date inversely
(You'd better to calculate the actual occurrence rate, occasionally.)

Of course, it may be careless of the person in charge who made mistake. Alternatively, if you were highly concentrated, you could enter without making mistakes during that moment. However, I have to say it is rather difficult to keep on doing 100 cases or 1000 without mistakes. If you have numerous input items, it may be difficult even for 5 or 10 cases without mistakes.

Configure initial values

If it is possible to set "Initial value" as a function of the system, you should actively use it.

In the Cloud-based workflow, "Questetra BPM Suite", you can set "Three days after today" and "last day of the next month" as the initial value of Date data items. Although it is ineffective in the case of "data duplication", it is a very effective method when flowing new Issue data to the business process.

<Setting screen>

[Date Input Form Test]

Too many input errors?

In the workflow system, "input errors" in human steps can not be avoided.

For example, if it is a workflow step that requires input of two numerical values "unit price" and "quantity", mistakes tend to occur such as;
  • 1200 is input which is a numerical value one digit less of 12000.
  • Enter the quantity in the place where the unit price to be entered.
(You'd better to calculate the actual occurrence rate, occasionally.)

Of course, it may be careless of the person in charge who made mistake. Alternatively, if you were highly concentrated, you could enter without making mistakes during that moment. However, I have to say it is rather difficult to keep on doing 100 cases or 1000 without mistakes. If you have numerous input items, it may be difficult even for 5 or 10 cases without mistakes.

Configure maximum and minimum values

If it is possible to set "limitation to the input value" as a function of the system, you should actively use it.

In the Cloud-based workflow, "Questetra BPM Suite", you can set "maximum value" and "minimum value" for Numeric data items. If you have limited the input value of "unit price" to "10,000 JPY - 100,000 JPY", the occurrence rate of incorrect input "1200 JPY" can be reduced to zero by that input restriction.

[Setting screen]

[Alert on a mistake]

[Numeric Input Form Test]

Season for reviewing Processes


In Japan, it is a month when a new fiscal year starts.

Not only the accounting of the nation, accounting of local governments, new grades at school, etc. start, but also the ceremony for new entrants are conducted simultaneously in April. (About 20% of Japanese companies start their fiscal year in April)

It can be said that in Japan, April is 'the month when motivation for improving business processes increases' or 'perfect month for improving business process'.

Also in Questetra, Inc., which operates this blog, the amount of updating on Business Processes (number of version upgrades of Workflow Apps) will increase in April.

Dare to extend the time required

The business process introducing this time is a slightly strange improvement example that is "extending the time required at all Steps".

As a usual business improvement, it is normal to consider about improvement on "flows" or "data input screens" upon "dissatisfaction" and "challenges" that you are feeling during your daily work.
  • Automation of Steps
  • Addition of double-checking Step
  • Addition of guidance sentences
  • Implementation of handy button

And, in many cases, we will seek "a direction for a measure to shorten the total duration of work as much as possible".

However, in April, which is a break of the fiscal year, you might become wanting to deal with "inefficiencies you felt throughout the total counting work". In this business process (Workflow-App), it has been revised to stay in the middle of the way. (Addition of Human Process: "x. Retaining Rework")
Business process before improvement: Episode 511: Automatically Generate Transfer Slip File (Excel-CSV)

[Invoice Issuance-Retention]

Measurement of error rate

The invoice issuance process is one of the tasks in which mistakes are not allowed.

"Accounts receivable / sales" is recorded based on accurate billing data, and "savings accounts / accounts receivable" should be recorded upon collection afterword.

However, "redoing" occurs on the actual work site. For example, even in the same human process in Questetra, "Redo" occurred with a 2.8% chance as a result of last year.
  • Correction on "customer address and name"
  • Correction on "quantity and amount"
  • Correction on "issue date and due date"

Of course, the causes are various, including "unavoidable redoing".
  • Information was changed between order acceptance and billing (change of person in charge of customer)
  • The sales representative made a mistake in transcribing the contents of the order form
  • In the first place 'order data' was wrong

However, in any case, if the invoice (billing data) is "redoing the entire process again" when the customer receives it, in addition to the effort of redoing the bill approval processing, the data of the accounting system must also be manually corrected.

I must say such a "Redoing process from scratch" is "big loss".

Reworking and Sending back

In this business process improvement, the retaining Step of "x. Retain Sending back" of the Accounting manager is added, and progress toward the downstream process (data cooperation with the accounting system) is restrained.

That is, it will retain in the state that can be sent back to the most upstream, for a while (e.g. until the end of the month). (Reduce the risk of occurrence of "big loss" rather than increasing overall speed.)

Certainly, data such as 'sales' would like to be incorporated into the accounting system as soon as possible. I agree that it is a wonderful direction as a business management to further "accelerate monthly settlement of accounts" aiming for "daily settlement of accounts."

However, as in this example, "Business process that can absorb some extent of data modification by slowly flowing business Issues" can be another direction of business process improvement.

[Invoice Issuance-Retention:"1. Bill info entry" screen]

[Data Items list]

[Free Download]
<Similar Models>
<<Related Articles>>

[Japanese Entry (和文記事)]

Is information collection a "business"?

There seems to be various opinions. If you watching television programs in the conference room, it might be a "business".

And if you are working for a department store, you may care about news concerning "Department stores". Or if you work for an Internet company, you might be curious about keywords such as 'AI', 'IoT', and 'big-data'.

If "special program" related to those keywords is scheduled as a television broadcast, you can't miss it. Particularly if it is planned by public broadcasting station, the impact on society could be very big.

<NHK API control screen>

NHK API that opened to anyone

NHK, a public broadcasting station in Japan, has published "Program Guide API". In June 2016, they started provision of Ver.2 , and it is now possible to acquire program information of "7 days ahead".

Response excerpt

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "NHKニュース おはよう日本",
"subtitle" : "▼国内外の最新ニュース ▼スポーツ情報 ▼地域の課題や話題のリポート ▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります ▼番組HP",
"act" : "【キャスター】森田洋平,【気象キャスター】酒井千佳",

This API is a very simple OPEN API.

As long as you register yourself, anyone can access it immediately, and regarding usage rules, it is very clear that "up to 300 accesses a day".
There is no authorization flow such as OAuth1 / OAuth2, it is not even secure communication (HTTPS)!

On the other hand, it can be said that it is APIs strict to standard specifications.

That is, if you are using various APIs on a daily basis, you would suppose that the characters that can be used on the website (UTF - 8) are communicated as they are. However, it is "Truly NHK". They firmly comply to the rule which "Send and receive with only alphanumeric characters (ASCII characters)" (Unicode escape) (JSON RFC7159) , so each and every Japanese character is converted to \nXXXX. (Even though It is hard to use in verifying communication log etc.)

[Keyword Search on TV Listing]

Automatic operation of bank account

"Banking APIs" is booming in Japan.

Questetra Inc., which is hosting this Workflow Sample blog, can also check real-time deposit information by "the benefits of API cooperation between" MF Cloud "(Accounting Cloud) and" Mizuho Business Web "(Bank Online Service)" , And the record to the accounting system is to be processed about on the same day (daily settlement). (Information on accounts receivable and so on that can be created only by workflow is still by "CSV import" ... but I believe MF Cloud itself would provide an API in near future ...)

* Incidentally, cooperation by "scraping method" (method of passing bank password to the Accounting-cloud) has been forbidden to use.

The policy of "Bank API" that enables data connection of this deposit / withdrawal information is expected to be legislated as "revision of the Banking Act" in 2017, and the FinTech industry also accepts it favorably. Therefore, it is expected that the bank system and various online services will be closely connected in the future.

Start with data retrieving API

However, at present, only some businesses can access "Bank API".

For the future as well, it is expected that a certain review will be in place to become an accessible business operator. Moreover, it could be a "licensing system", depending on the discussion in the current Diet session.

Also, regarding the access permission of the bank side, there is a possibility that it will be limited to "Data retrieving API" for the time being.

That is, I suppose that it is started as a service limited to data reference communication without movement of assets such as "acquisition of deposit / withdrawal information" or "acquisition of balance information", as a trial operation period of "API service". (Even though cases of 'Data updating API comes out already since April 2017...)

By the way, "Issues unique to Japan" is also hidden.

That is, there are historical circumstances that most account names have been handled in "Half-width kana" which is uncommon for modern computers. It results that systems accessing to APIs will be required "Data conversion" for their own (Automatic Journal entry rule, etc.)

[Remittance Process]

Isolation of Accounting Steps

It is very convenient if prepared "PayPal Billing Flow" as "Independent Subroutine Process".

Since it can be called from various business flows in the Workflow system, the process owner can focus on the design and maintenance of the main business flow.

Even from the perspective of the Accounting department on the downstream side, they will be able to perform efficient business since they can handle multiple business flows without distinction. (However, involvement to upstream will tend to decrease.) In addition, there is a need that "want to manage and maintain centrally" in the accounting system (*) in which the changes in the past one or two years were extremely vigorous.

* ※ "Cloud Accounting", "Bank API", "Accounting BPO", etc.

Processing of PayPal Invoice

The following business process definition (Workflow / App) is "PayPal billing process" which automatically collaborates with PayPal.

Various requests are made from the Workflow system side via "PayPal REST API", specifically "PayPal Invoicing API". That is, it is a mechanism that
  • let PayPal generate 'PayPal Invoice'
  • let PayPal send "PayPal Invoice"
  • check payment status of "PayPal Invoice" against PayPal.
(The opportunity to login directly to PayPal will be reduced.)


Automation of billing

It will be very convenient if you can control "PayPal" as a billing system from the workflow system "Questetra".

For example, if you create a mechanism that automatically issues a "PayPal invoice according to delivery details" immediately after "product delivery flow" is completed, it is possible to prevent the occurrence of "billing mistake" or "billing omission". If the current situation is a billing operation that mails a "paper invoice", it is also possible to reduce all stamp fee, printing fee and office work labor costs to zero.

In the previous article, I introduced you mechanisms that automatically instructs PayPal "to generate invoices in PayPal" and "to send the invoice generated in PayPal further to customers".

Further automation

If you could automate
  • letting PayPal generate a "PayPal Invoice", and
  • letting PayPal send a "PayPal Invoice" via email,

I would like to further automate
  • confirming payment to PayPal. (Improve efficiency of debt collection business)

In this article, we will consider assembling the automatic Steps cleverly and making the "payment check flow" unmanned.

* Here, programming knowledge is required since we are going to use "Script Task" which is a type of automatic Step

[Entry reception system-PayPal billing-Payment confirmation]

PayPal as a Billing System

"PayPal Invoice" is very useful.

Just by logging-in to PayPal and entering "destination email address" and "details of sold item", anyone can easily send the invoice. It can be said that it is one of a few settlement methods that can flexibly deal with "a little consignment work" or "special discounts". It almost makes me think that procedures of shopping at EC site is rather more difficult. Moreover, there is no need to tell "credit card number" from the buyer to the seller.

However, if dozens of issuance must be, it will inevitably be troublesome. (Its "flexibility" serves harmful.)

If the billing contents were exactly the same, there was a function to process collectively, but if the contents are subtly different from each other, you have to set the billing information one by one. However, repetition of manual work falls into error, by all means.

Automate invoice creation and transmission

In the previous article (*), I introduced you "a mechanism to automatically generate a request that "Generate a PayPal invoice" and transmit it to the PayPal system.
* Episode 525: How to Send OAuth2 Request from Automatic Step

In this article, I would like to study further about "a mechanism to automatically send a request that "generate and send PayPal invoice to the buyer". (Programming knowledge is required)

[Entry reception system]

Japanese calendar text

There are many cases in Japan that use "Japanese calendar" instead of "Western (Gregorian) calendar".

This year is "2017" as well as "Heisei 29".

In other words, there are many cases where Date type data such as "2017-03-13" should be displayed as "March 13, Heisei 29" in prints and email texts. In the article (*) about one year ago, I introduced you the Japanese calendar conversion using the [Script Task], the automatic step. (Automatic conversion of Issue data flowing in the Cloud-based Workflow "Questetra BPM Suite")

Episode 467: Certificate Issue Date on Auto-generated PDF in Japanese Era Name (2016-01-25)

Script step and Service step

However, as of version 11.1 or later (2016-09-05) of the Cloud-based Workflow "Questetra BPM Suite", it is possible to add arbitrary [Service step] by "Service definition file" (add-on XML).

That is, if you use [Service step] which performs Japanese calendar conversion, you do not need to use [Script step] (which requires programming knowledge).

[Certificate Issuance-Japanese Calendar]