# Epicor Function Library Design Template > Source: https://netray.co/tools/epicor-function-library-design-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A design document for an Epicor function: signature, inputs, outputs, logic notes, security, test cases and sign off. ## Category epicor ## Erp Epicor Kinetic ## Audience - Epicor developer - Technical lead - ERP architect ## Tool **Kind:** template **Output:** document **Fields:** #### Company **Key:** company **Type:** text **Default:** Acme Precision Ltd #### Function library ID **Key:** library **Type:** text **Default:** AcmeShipping #### Function ID **Key:** function **Type:** text **Default:** CalcPromiseDate #### Author **Key:** author **Type:** text **Default:** A. Developer #### Date **Key:** date **Type:** date **Default:** 2026-10-20 #### Business purpose **Key:** purpose **Type:** textarea **Default:** Return a promise date for a sales order line based on part lead time, warehouse calendar and customer ship via. #### Input parameters **Key:** inputs **Type:** textarea **Default:** partNum (string), orderQty (decimal), shipViaCode (string), requestDate (date) #### Output parameters **Key:** outputs **Type:** textarea **Default:** promiseDate (date), message (string) #### Callers **Key:** callers **Type:** select **Options:** - Method directive - Data directive - UI customization - BPM widget - Another function - REST call **Default:** Method directive #### Tables read or written **Key:** tables **Type:** textarea **Default:** Read: Part, PartPlant, Calendar. Write: none. #### Logic summary **Key:** logic **Type:** textarea **Default:** 1. Look up plant lead time. 2. Add transit days from ship via. 3. Skip non working days using the plant calendar. 4. Return the date and a message if the request date cannot be met. #### Error handling rule **Key:** errors **Type:** select **Options:** - Throw BLException - Return message only - Log and continue **Default:** Return message only **Blocks:** #### Function Design: {{library}}.{{function}} **Body:** Company: {{company}} Author: {{author}} Date: {{date}} Primary caller: {{callers}} #### 1. Purpose **Body:** {{purpose}} #### 2. Signature **Body:** Inputs: {{inputs}} Outputs: {{outputs}} #### 3. Data access **Body:** {{tables}} Use the Epicor business object or an Ice.Tables reference through the library context rather than raw connections. Keep reads narrow and avoid loops that call the database once per row. #### 4. Logic **Body:** {{logic}} #### 5. Error handling **Body:** Rule: {{errors}} Document every message text and who sees it (end user, log, or calling code). #### 6. Security and delivery **Table:** **Columns:** - Item - Decision **Rows:** **0:** Library security **1:** Which security groups may run the function **0:** Allow custom code **1:** Is the function written in widgets or in code **0:** Environment promotion **1:** Export and import between Test and Live **0:** Version note **1:** Describe the change in the library description #### 7. Test cases **Table:** **Columns:** - Case - Inputs - Expected result - Actual - Pass **Rows:** **0:** Normal **0:** Boundary **0:** Missing data **0:** Weekend or holiday #### 8. Approvals **Signatures:** - Developer - Functional lead - Technical reviewer **Notes:** Epicor Kinetic functions live in function libraries and can be called from directives, customizations and REST. Names such as method directives and widgets differ slightly by release, so adapt the headings to your version. ## Content **Intro:** A function that nobody documented turns into a black box within a year. This template gives each Epicor function a one page design record so the next developer knows what it does, who calls it, and how to test it. **Sections:** #### How to use the template **Body:** Fill in one document per function, not per library. Start with the business purpose in plain words, then list inputs and outputs with data types. The logic summary should be steps a reviewer can check, not code. Choose the main caller, because a function used in a method directive has different performance and error concerns than one called from a dashboard. Export to Word or PDF and attach it to the change request or store it with the library description. **Bullets:** - One document per function - Purpose written for a business reader - Typed inputs and outputs - Numbered logic steps #### Why design before building **Body:** Functions are shared. A BPM, a report and a customization may all call the same one, so a change to its signature breaks callers silently. Writing the signature and the error rule first forces the conversation about who depends on it. Keeping reads narrow also matters: a function called inside a method directive runs during a user transaction, and an extra query per line adds up across large orders. #### Reading the sections **Body:** The data access section lists tables read and written. If a function writes, call that out clearly, since write functions in directives can cause loops or unintended updates. The error handling rule says whether the function throws, returns a message or logs. Test cases should include a boundary case and a missing data case, as those are where date and quantity logic usually fails. #### Common mistakes **Body:** Teams often skip documenting output parameters, reuse a generic name like Calc1, or put business constants inside code instead of a UD table or configuration. Another frequent problem is promoting a function to Live without recording what changed. Treat the library description and this document as the version history. **Bullets:** - Avoid vague names such as Calc1 or DoStuff - Keep constants in configuration, not inside code - Record the change in the library description - Test as a normal user, not only as manager **Cta:** If you want help reviewing a function library or building a private assistant that explains your customizations from the source, Netray can discuss a read-only approach on your own infrastructure. **Faq:** #### What is an Epicor function library? **Answer:** In Epicor Kinetic a function library is a container of reusable functions created in the Function Maintenance area. Functions can be built with widgets or code, then called from method directives, data directives, customizations and REST. #### Should a function write to the database? **Answer:** It can, but be cautious. Prefer read only functions and let the calling business object or directive do the update. When a function must write, document it and guard against loops where the write triggers the same directive again. #### How do I promote a function between environments? **Answer:** Functions are normally exported from the Test environment as a package and imported into Live, subject to your change control. Record the export date and the version note in the library description so the history is traceable. #### How many test cases are enough? **Answer:** At least one normal case, one boundary case and one missing or invalid data case per function. Add a case for each branch of conditional logic, because untested branches are where problems reach production. ## Search terms epicor function library design, epicor kinetic functions template, epicor function design document, epicor functions best practices, epicor custom function documentation, epicor kinetic function library, epicor technical design template --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json