Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create standing instructions for payments and receivables #24

Open
htmfilho opened this issue Jan 21, 2019 · 2 comments
Open

Create standing instructions for payments and receivables #24

htmfilho opened this issue Jan 21, 2019 · 2 comments

Comments

@htmfilho
Copy link
Owner

htmfilho commented Jan 21, 2019

Standing instructions are rules to automatically generate transactions according to recurring payments and receivables. This ways, most of the work of recording transactions is actually automatically done by the application, reducing the effort of the user.

Depends on #23

Frequency

  • Annually: Once a year in a specific date of the year.
  • Semi-Annually: Twice a year.
  • Three-Annually: Three times a year.
  • Quarterly: Four times a year.
  • Bi-Monthly: Every two months.
  • Monthly: Every month.
  • Semi-Monthly (12 * 2): Event falls on the same two days of each month. For instance, make payments on the 1st and 15th of each month, or on the 15th and 30th of the month; therefore, there will be a total of 24 payments during the year (twice per month times 12 months).
  • Bi-Weekly (52 / 2): Event happen every two weeks. For instance, choose a set day, such as Thursday or Friday, and issue payment every other week on that day. With a bi-weekly payment schedule, 26 payments are issued during a standard year (52 weeks divided by two). In this case, two months out of the year produce three paychecks.
  • Weekly: Every week.

Calculate the Next Payment Date

Given:

  • start date
  • stop date
  • frequency
  • list of holidays
  • optional previous payment date

we can calculate the next payment date. When the previous payment date is not informed then the next payment day is the same as the start date. The next payment date is between the start date or the previous payment date and the stop date. If the calculated next payment date falls in the weekend or in a holiday then it is recalculated to the next working day.

The following table shows how the frequency is used in the calculation of the next payment date.

Frequency Block Day Example
Annually 1 to 12 (month) 1 to 31 (day) 04 / 15 (Every year on April 15th)
Semi-Annually 1 to 6 (month) 1 to 31 (day) 3 / 20 (March 20th and September 20th)
Three-Annually 1 to 4 (month) 1 to 31 (day) 2 / 12 (February 12th, June 12th, and October 12th)
Quarterly 1 to 3 (month) 1 to 31 (day) 1 / 31 (January 31th, April 30th, July 31th, and October 31th)
Bi-Monthly 1 to 2 (month) 1 to 31 (day) 2 / 30 (February 28th, April 30th, June 30th, August 30th, October 30th, and December 30th)
Monthly 1 (month) 1 to 31 (day) 1 / 5 (January 5th, and so on)
Semi-Monthly 1 to 15 (day) 16 to 31 (day) 1 / 16 (January 1st, January 16th, February 1st, February 16th, etc)
Bi-Weekly 1 to 2 (week) 1 to 7 (day of the week) 2 / 3 (January 1st, January 15th, January 29th, etc)
Weekly 1 (week) 1 to 7 (day of the week) 1 / 5 (Every Thursday)

We already mentioned the case when the next payment date falls in a weekend or in a holiday. An extra special case is when the day of the month is not valid for some of the months, like February 30th or June 31th.

@keniasousa
Copy link
Collaborator

keniasousa commented Jan 25, 2019 via email

@htmfilho
Copy link
Owner Author

To simplify things, we could define a default amount and let the user change it when necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Minimal Viable Product
  
Awaiting triage
Development

No branches or pull requests

2 participants