Review fixes G0019, G0108: added hidden tests; revalidated

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aUaQeLnwbb1zTpN7kHeat

tasks_gen/eval/G0122/spec.md

@@ -1,69 +1,49 @@
 # 1. Goal
-A rail infrastructure manager charges a track access fee to train operating
-companies. A billing program calls one function module for each operating day.
-The function module calculates the fee of each train path and groups the result
-by train category.
+A brewery plans the bottling runs of its beer types. The planning program calls
+one function module. The function module reads the open bottling orders, groups
+them by beer type and stores the bottling plan.
 
 # 2. Open questions
 None.
 
 # 3. Context
-- Function group {{P}}FG_TRACK exists in package $TMP.
-- Function module {{P}}TRACK_SAMPLE exists in this group. It shows the interface
-  that the billing program uses. Do not change it.
-- The global class {{P}}TRACK_TYPES exists in package $TMP. It only holds the row
-  types of the input and of the result. Do not change it. Its public types are:
-  - TY_PATH: PATH_ID (type N, length 8), TRAIN_CAT (type C, length 2),
-    DISTANCE_KM (packed, length 13, 2 decimals), NIGHT_FLAG (type C, length 1).
-  - TT_PATH: standard table of TY_PATH.
-  - TY_FEE: TRAIN_CAT (type C, length 2), PATH_COUNT (type I), TOTAL_KM (packed,
-    length 13, 2 decimals), TOTAL_FEE (packed, length 13, 2 decimals).
-  - TT_FEE: standard table of TY_FEE.
-- The billing program builds a standard table with the components of TY_PATH and
-  reads a standard table with the components of TY_FEE. The component names are
-  the interface between the billing program and the function module.
+- Function group {{P}}FG_BOT exists in package $TMP.
+- The database table {{P}}BOTORD exists in package $TMP. Its fields are
+  client (key), order_id (key, NUMC 10), beer_type (CHAR 4) and
+  volume_hl (DEC 13,3).
+- The database table {{P}}BOTPLN exists in package $TMP. Its fields are
+  client (key), beer_type (key, CHAR 4), plan_pos (INT4), total_hl (DEC 13,3)
+  and order_count (INT4).
 
 # 4. Contract
-Create the function module {{P}}TRACK_FEE in function group {{P}}FG_TRACK with
-this interface:
-- Importing parameter IT_PATHS, type STANDARD TABLE.
-- Exporting parameter ET_FEES, type STANDARD TABLE.
-- Exceptions INVALID_DISTANCE and INVALID_CATEGORY.
-The two table parameters are generic standard tables. Their row components are
-fixed by TY_PATH and TY_FEE of {{P}}TRACK_TYPES.
+Create the function module {{P}}BOT_PLAN in function group {{P}}FG_BOT.
+The interface of the function module is:
+- Importing parameter iv_min_hl TYPE decfloat34.
+- Exporting parameter ev_total_hl TYPE decfloat34.
+- Exporting parameter ev_plan_count TYPE int4.
 
 # 5. Business rules
-1. A train path with DISTANCE_KM less than or equal to zero is not valid. Raise
-   the exception INVALID_DISTANCE.
-2. The rate of a train category is:
-   - IC: 1.20 per kilometre
-   - RG: 0.90 per kilometre
-   - FR: 0.60 per kilometre
-   - SP: 1.50 per kilometre
-3. A train category that is not in rule 2 is not valid. Raise the exception
-   INVALID_CATEGORY.
-4. The fee of one path is DISTANCE_KM multiplied by the rate of its train
-   category.
-5. If NIGHT_FLAG is 'X', multiply the fee of the path by 1.20.
-6. Round the fee of the path half up to two decimals.
-7. The minimum fee of one path is 5.00. If the fee of the path is less than
-   5.00, use 5.00.
-8. The result table has one row for each train category that occurs in the
-   input table.
-9. PATH_COUNT is the number of paths of the category.
-10. TOTAL_KM is the sum of DISTANCE_KM of the paths of the category.
-11. TOTAL_FEE is the sum of the fees of the paths of the category.
-12. Sort the result table in ascending order of TRAIN_CAT.
-13. If the input table is empty, the result table is empty. Do not raise an
-    exception.
+1. Read all rows of the table {{P}}BOTORD.
+2. Ignore every order whose volume_hl is less than or equal to 0.
+3. Group the other orders by beer_type. Compare beer types exactly.
+4. For each group, total_hl is the sum of the volume_hl values of the orders
+   of the group, and order_count is the number of orders of the group.
+5. Keep only the groups whose total_hl is greater than or equal to iv_min_hl.
+6. Delete all rows of the table {{P}}BOTPLN and write one row per kept group.
+7. The rows of {{P}}BOTPLN are numbered with plan_pos, starting at 1. The row
+   with the largest total_hl gets plan_pos 1. If two rows have the same
+   total_hl, the row with the smaller beer_type gets the smaller plan_pos.
+8. ev_total_hl is the sum of the total_hl values of the kept groups. If no
+   group is kept, ev_total_hl is 0.
+9. ev_plan_count is the number of kept groups.
+10. {{P}}BOTPLN contains no rows other than the rows that rules 2 to 7 define.
 
 # 6. Constraints
-- Release target: 8.16.
-- Coding standard: Clean ABAP. Keep methods below 40 statements. Pass large
-  parameters by reference.
-- Out of scope: do not change {{P}}TRACK_SAMPLE or {{P}}TRACK_TYPES.
+- Release target: SAP_BASIS 8.16.
+- Use Clean ABAP. Keep every procedure below 40 statements.
+- Out of scope: do not change the tables {{P}}BOTORD and {{P}}BOTPLN.
 
 # 7. Acceptance
-- The function module is active and has no syntax error.
+- The function module {{P}}BOT_PLAN is active and has no syntax error.
 - The hidden tests pass.
 - Write ABAP Unit tests for the function module in a global test class.