error with abc rendering. updated to gettin_started_with_ti

Author: usrbinr

554.R

@@ -9,7 +9,6 @@ x <-  contoso::sales |> fpaR::mtd(order_date,margin,calendar_type = "445")
 
 
 
-
 ## find beginng date indicator
 
 

R/abc.R

@@ -42,7 +42,7 @@ abc <- function(.data,category_values,.value){
 
 
   x <-   segment_abc(
-    datum                      = datum(.data,date_vec = NA,calendar_type = NA)
+    datum                      = datum(.data,date_vec = NA,calendar_type = NA_character_)
     ,value                    = value(value_vec = value_vec,new_column_name_vec = "abc")
     ,category                 = category(category_values=category_values)
     ,fn = fn(

R/classes.R

@@ -101,7 +101,7 @@ datum <- S7::new_class(
         ,default = "standard"
         ,validator =function(value){
 
-          valid_names <- c("standard","544","445","454")
+          valid_names <- c("standard","544","445","454",NA_character_)
 
           if(!any(value %in% valid_names)) return(cli::format_error("Please return {.or {.val {valid_names}}}"))
 

_pkgdown.yml

@@ -15,7 +15,8 @@
     - title: "Utilities"
       desc: "General helper and execution utilities."
       contents:
-        - augment_calendar
+        - augment_standard_calendar
+        - augment_non_standard_calendar
         - calculate
 
     - title: "Cohort & Classification"

vignettes/articles/abc.qmd

@@ -6,6 +6,9 @@ subtitle: "How to use classification strategies to focus your analysis"
 
 ```{r}
 #| echo: false
+
+library(fpaR)
+
 quarto::write_yaml_metadata_block(
    date=format(Sys.Date())
    )

vignettes/articles/calendar_types.qmd

@@ -1,5 +1,5 @@
 ---
-title: "Standard vs. 5-5-4 Calendar"
+title: "Standard vs. 5-4-4 Calendar"
 subtitle: "What do we mean by standard and non-standard calendar?"
 author: "Alejandro Hagan"
 format: html

vignettes/articles/getting_started_with_ti.qmd

@@ -13,32 +13,31 @@ format: html
 library(dplyr)
 library(fpaR)
 
-
 hook <- fansi::set_knit_hooks(knitr::knit_hooks, which = c("output", "warning", "error", "message"))
 
 options(crayon.enabled = TRUE)
 
+
 ```
 
 
 ## How to use fpaR?
 
-### Time Intelligence
-
-When you execute a time intelligence function, it will return a "ti" class object with a custom print method that explains what the function is doing and a summary of transformation steps and the calendar attributes.
-
 Simply pass your data in either tibble or a lazy DBI object to the time intelligence function and input the required arguments.
 
 > Regardless if you pass a tibble or lazy DBI object, all time intelligence functions will return a lazy DBI object for performance reasons
 
-We will use `mtd()` function to calculate the month-to-date sum of contoso's company' revenue (`contoso::sales`).
+We will use `mtd()` function to calculate the month-to-date sum of contoso's company' margin (`contoso::sales`).
 
 Most time intelligence functions follow the same structure:
 
--  specify the date column to index the time intelligence functions
--  specify the value column to aggregate
--  if there is a period rollback / rollforward then clarify the number of periods
--  clarify if we are using a "standard" calendar or non-standard variation (currently supports 5-5-4)
+-  Specify the date column to index the time intelligence functions (eg. `order_date` or `deliver_date`)
+-  Specify the value column to aggregate
+-  If there is a period rollback / rollforward then clarify the number of periods to roll
+-  Clarify if we are using a "standard" calendar or non-standard variation (currently supports 5-4-4, 4-4-5 and 4-5-4 calendars) see [standard vs. non standard calendar article](https://usrbinr.github.io/fpaR/articles/calendar_types.html)
+
+> For most of your uses cases, you are likely to reference "standard" calendar which is your standard gregorian calendar:
+> - 365 days in a year except for leap years where you have 366, 7 days make up a week, January has 30 days, etc
 
 When you execute `mtd()`, your console return a `ti` object and will print a  summary of the function's actions, details the calendar's attributes, describes the main transformation steps and lists out possible next actions.
 
@@ -49,7 +48,7 @@ When you execute `mtd()`, your console return a `ti` object and will print a  su
 #| eval: true
 
 contoso::sales |> 
-   fpaR::mtd(.date=order_date,.value = revenue,calendar_type = "standard") 
+   fpaR::mtd(.date=order_date,.value = margin,calendar_type = "standard")
 
 ```
 
@@ -59,27 +58,23 @@ To return the results to a lazy tibble of results, pass the ti object through to
 
 ```{r}
 #| label: calculate-example
+#| eval: false
 #| echo: true
 #| warning: false
 #| error: false
 #| message: false
-#| eval: false
 
 contoso::sales |>                                                          
    fpaR::mtd(.date=order_date,.value = margin,calendar_type = "standard") |>  
    fpaR::calculate()                                                          
 ```
 
 
-If you using a tibble, under the hood, `fpaR` is converting your data to
-a [duckdb](https://github.com/duckdb/duckdb-r) database.
-
-If your data is in a database, the package will leverage
-[dbplyr](https://dbplyr.tidyverse.org/) to execute all the calculations.
+If you using a tibble, under the hood, `fpaR` is converting your data to a [duckdb](https://github.com/duckdb/duckdb-r) database
 
-Either case use `dplyr::collect()` to return your results to a local
-tibble.
+If your data is in a database, the package will leverage [dbplyr](https://dbplyr.tidyverse.org/) to execute all the calculations
 
+Either case use `dplyr::collect()` to return your results to a local tibble
 
 ```{r}
 #| label: collect-example
@@ -90,7 +85,8 @@ tibble.
 contoso::sales |>                                                                
    fpaR::mtd(.date=order_date,.value = margin,calendar_type = "standard") |>  
    fpaR::calculate() |>                                                       
-   dplyr::collect() |>                                               
+   dplyr::collect() |>  
+   dplyr::arrange(date) |> 
    head(10)
 ```
 
@@ -112,22 +108,20 @@ contoso::sales |>
 
 ```
 
-The functions will work with your database even if you don't have write permission by creatively leveraging CTEs to create interim tables.
+In the print, we 
 
-## Why do we need this package when we have lubridate?
+### Why do we need this package when we have lubridate?
 
-[Lubridate](https://lubridate.tidyverse.org/) is an excellent package and is heavily used by the package. The issue isn't lubridate but rather
-issues you may not be aware of in your package.
+[Lubridate](https://lubridate.tidyverse.org/) is an excellent package and is heavily used by the package. The issue isn't lubridate but rather challenges and issues in your dataset that aren't readily visible.
 
-Time-based comparisons, such as Year-over-Year (YoY), Quarter-over-Quarter (QoQ), and Month-to-Date (MTD), are common for tracking business performance. However, they come with challenges:
 
 -   Many datasets **do not have continuous dates**, especially if data is recorded only on business days or for active transactions
 
--   Period imbalances between periods (Eg. the different number of days between February vs. January) can create misleading analysis or trends
 
--   Your analysis may need to reference a non-standard calendar such as  a 5-5-4, 4-4-5, or 13 month calendar
+-   Period imbalances between periods (Eg. the different number of days between February vs. January) can create misleading analysis or trends requiring non-standard calendars (eg. 4-4-5)
+
+-   Calculating time intelligence for groups can lead to larger than memory issues even with smaller datasets
 
--   Your data may be in excel sheets, csv or databases and you need to inter-operable framework to switch between all your data types
 
 ### Issue 1: Continuous Dates
 
@@ -171,15 +165,17 @@ tibble::tibble(
 
 ## Issue 2: Period imbalances
 
-When comparing two performance periods with a standard calendar, you often will compare a period with unequal number of days or periods. For example if you want to compare January sales to February you can get misleading conclusions due to the unequal number of weekends and days in those periods.
+When comparing two performance periods with a standard calendar, you often will compare a period with unequal number of days or periods.
+
+For example if you want to compare January sales to February you can get misleading conclusions due to the unequal number of weekends and days in those periods.
 
 > In practice you have two choices:
 >
  -  compare periods with similar days (eg. the 28th of February compares should only compare up to the 28th of January) and you omit three days of January sales all together 
 >
 -  compare have an imbalanced comparison (eg. the 28th of February compares to the 31st of January so that no days are lost).
 
-this package does the second option which is ensure we don't loose any of January's sales but to help flag for imbalance, fpaR will add a column to let you know how many periods (eg. days) are in your comparison period to increase transparency to this dynamic.
+This package does the second option to  ensure we don't loose any of January's sales but to help flag for imbalance, fpaR will add a column to let you know how many periods (eg. days) are in your comparison period to increase transparency to this dynamic.
 
 To create this example, we will use the `pmtd()` function to calculate the prior month to date cumulative margin in the current month.
 
@@ -218,22 +214,15 @@ contoso::sales |>
    tinytable::tt(width=1)
 ```
 
-## what is going on under the hood
+### Issues 3: larger than memory
 
-In financial planning and analysis, it is common to compare **year-to-date (YTD)** metrics against the **previous year's YTD** to understand performance trends.  
+If your data isn't already in a database then fpaR will leverage duckdb to convert your data to enable larger than memory calculation. 
 
-The function `yoytd_fn()` provides this functionality. While it is an **internal, non-exported function**, it is called by [yoytd()] and executed through [calculate()].  
+This is necessary for time intelligence functions because when you have grouped data, you need to complete calendar for each group combination. For even modest datasets, this can quickly multiple and grow you data to be larger than memory. 
 
-This vignette explains what the function does, how it works, and how to work with its output.
+If your data is already in database, then fpaR will use [dbplyr](https://dbplyr.tidyverse.org/) and will convert the functions to SQL to write the queries.
 
-# Function Purpose
+In either scenario, you can use `dplyr::collect()` to execute your SQL query and return a tibble to your local computer. 
 
-`yoytd_fn()` performs the following:
 
-1. Computes **current year-to-date (YTD)** values.
-2. Computes **previous year-to-date (PYTD)** values, optionally applying a lag.
-3. Joins YTD and PYTD tables together on `date`, `year`, and grouping variables.
-4. Fills missing dates downward for consistency.
-5. Summarizes the data by summing the YTD and PYTD values by group.
 
-The output is a **DBI object** that can be converted into a **tibble** using `dplyr::collect()` for further analysis.