Bill generation method and related device

Abstract

This application discloses a bill generation method and related equipment, relating to the field of data processing technology. The method includes: responding to a bill generation instruction, obtaining bill generation requirements; selecting business data from a database based on the bill generation requirements; determining a target bill template, the target bill template containing multiple target bill modules; determining atomic components corresponding to each target bill module in a preset component library to obtain multiple target atomic components; and rendering based on the target atomic components and the business data to generate a bill. This application selects business data in response to a bill generation requirement and determines a target bill template containing multiple modules, then determines the atomic components corresponding to each module and renders the bill based on the atomic components and business data. This allows bill modules to be dynamically combined as needed, and atomic components to support cross-module reuse, thereby reducing development costs and improving the flexibility and efficiency of bill generation.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to bill generation methods and related equipment. Background Technology

[0002] In related technologies, hospitals typically use HIS systems to manage medicines and consumables. However, existing systems lack effective support for crucial aspects of hospital financial reporting, such as inventory receipt settlement and reconciliation settlement. Significant differences exist between hospital information systems in terms of data formats, field definitions, and business processes. This necessitates the repeated development of the same billing function in different hospitals or application scenarios, resulting in high R&D costs and low maintenance efficiency. Currently, there is no universal billing generation solution that can adapt to multiple applications and scenarios, hindering cross-warehouse, multi-scenario, and multi-terminal reuse and restricting the rapid construction and flexible iteration of hospital settlement management systems. Summary of the Invention

[0003] The main purpose of this application is to provide a bill generation method and related equipment, which aims to solve the technical problems of poor reusability of the bill module and difficulty in adapting to different data formats in existing bill generation solutions.

[0004] To achieve the above objectives, this application proposes a bill generation method, which includes: Responding to the bill generation command, obtain the bill generation requirements; Based on the bill generation requirements, business data is selected from the database, and a target bill template is determined, which contains multiple target bill modules; Determine the atomic component corresponding to each target bill module in the preset component library to obtain multiple target atomic components; Based on the target atomic component and the business data, rendering is performed to generate an invoice.

[0005] In one embodiment, the step of rendering based on the target atomic component and the business data to generate an invoice further includes: Perform a data transformation operation on the business data to unify the format of the business data and obtain initial business data; Perform field filtering on the initial business data to obtain the target business data; Based on the target atomic component and the target business data, rendering is performed to generate an invoice.

[0006] In one embodiment, the step of performing field filtering on the initial business data to obtain the target business data further includes: Based on the bill generation requirements, determine the explicitness or implicitness of each field in the initial business data; Based on the explicitness and implicitness, implicit fields are removed from the initial business data to perform field filtering on the initial business data, thereby obtaining the target business data.

[0007] In one embodiment, before the step of selecting business data from the database based on the bill generation requirement, the method further includes: An accuracy verification operation is performed on the data to be written, including invoice verification, red-ink verification, overdue verification, and voiding verification. If the verification passes, the data to be written is written to the database; if the verification fails, the writing of the data to be written to the database is prevented, and a data error message is generated.

[0008] In one embodiment, prior to the step of determining the target bill template, the method further includes: Identify multiple candidate functional units in the bill generation scenario; Based on each candidate functional unit, construct its corresponding candidate bill module; For each candidate bill module, a corresponding atomic component is constructed, and the atomic component defines a unified data input format; A preset candidate bill module library is built based on multiple candidate bill modules, and a preset component library is built based on multiple atomic components.

[0009] In one embodiment, the step of determining the target bill template further includes: Obtain the scenario information from the bill generation requirement, including the application information and the current business scenario type; Based on the scenario information, multiple target bill modules that match the scenario information are selected from the preset candidate bill module library; Obtain the configuration information from the bill generation requirement, and determine the display order configuration for each target bill module based on the configuration information; Based on the display order configuration and multiple target bill modules, a target bill template is obtained.

[0010] In one embodiment, the step of selecting multiple target bill modules that match the scenario information from the preset candidate bill module library based on the scenario information further includes: Based on the application information, determine the entry point type, and based on the current business scenario type, determine the required set of sub-functions; Based on the entry type and the sub-function set, search the preset candidate bill module library for a first candidate bill module set corresponding to the entry type, and filter out a second candidate bill module set that matches the sub-function set from the first candidate bill module set; The candidate bill modules in the second candidate bill module set are set as multiple target bill modules that match the scenario information.

[0011] Furthermore, to achieve the above objectives, this application also proposes a bill generation apparatus, the bill generation apparatus comprising: The acquisition module is used to acquire the bill generation requirement in response to the bill generation instruction; The selection module is used to select business data from the database based on the bill generation requirements and determine the target bill template, which contains multiple target bill modules. The determining module is used to determine the atomic component corresponding to each target bill module in the preset component library, thereby obtaining multiple target atomic components; A generation module is used to render data based on the target atomic component and the business data to generate an invoice.

[0012] In addition, to achieve the above objectives, this application also proposes a bill generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the bill generation method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the steps of the bill generation method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the bill generation method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application discloses a bill generation method and related equipment, relating to the field of data processing technology. Compared to related technologies where information systems in different hospitals differ significantly in data format, field definitions, and business processes, leading to repeated development of the same billing function in different hospitals or application scenarios, resulting in high R&D costs and low maintenance efficiency, this application first obtains bill generation requirements in response to a bill generation instruction. Then, based on the bill generation requirements, business data is selected from a database, and a target bill template is determined. The target bill template contains multiple target bill modules. Further, atomic components corresponding to each target bill module in a preset component library are determined, resulting in multiple target atomic components. Finally, based on the target atomic components and the business data, rendering is performed to generate a bill.

[0016] Understandably, this application selects business data and determines a target bill template containing multiple modules by responding to bill generation requirements. Then, it determines the atomic components corresponding to each module and generates bills based on the atomic components and business data. This allows bill modules to be dynamically combined as needed, and atomic components to support cross-module reuse, thereby reducing development costs and improving the flexibility and efficiency of bill generation. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the invoice generation method of this application in Implementation Example 1; Figure 2 This is a flowchart illustrating Embodiment 2 of the bill generation method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the bill generation method of this application; Figure 4 This is a schematic diagram of the module structure of the bill generation device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the bill generation method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution in this application's embodiments is: In this embodiment, for ease of description, the bill generation device will be used as the execution subject in the following description.

[0024] Based on this, the embodiments of this application provide a bill generation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the bill generation method of this application.

[0025] In this embodiment, the bill generation method includes steps S10 to S40: Step S10: In response to the bill generation instruction, obtain the bill generation requirement; It should be noted that the bill generation instruction refers to the operation signal triggered by the user through the front-end interface to start the bill generation process, such as clicking the "Generate Statement" button, selecting an inbound order record and clicking "View Bill", etc.

[0026] A bill generation requirement refers to a set of information describing the business conditions that must be met for this bill generation, including but not limited to application information, current business scenario type, user permission information, and field configuration information. The application information indicates the front-end application system that calls the bill generation function, and the current business scenario type indicates the specific business step corresponding to this bill generation.

[0027] In this embodiment, after receiving the bill generation instruction triggered by the front end, the system parses the context parameters carried in the instruction, including user identifier, current page routing information, operation object identifier, etc., and extracts all the requirement information required for this bill generation from these parameters, and organizes them into a structured bill generation requirement object for subsequent steps to call.

[0028] Understandably, this step is responsible for collecting all the configuration information required for this bill generation, providing a basis for subsequent business data selection and target bill template determination.

[0029] Step S20: Based on the bill generation requirements, select business data from the database and determine the target bill template, which includes multiple target bill modules; It should be noted that the database refers to a persistent storage system used to store various business data in hospital settlement and reconciliation scenarios, including inbound order data, invoice data, and reconciliation statement data.

[0030] Business data refers to the original data records directly related to the generation of this invoice, such as basic information of the inbound order, product details, and related invoice information.

[0031] The target bill template refers to a page layout scheme that is dynamically combined according to the bill generation requirements. It is used to indicate which functional modules need to be displayed on the final generated bill page and the order in which the functional modules are arranged.

[0032] The target bill module refers to the individual functional units that make up the target bill template, such as the basic information module, product details module, and associated invoice module. Each target bill module corresponds to a display area on the bill page.

[0033] In this embodiment, the system first extracts the corresponding business data records from the database based on the query conditions in the bill generation requirement. Simultaneously, based on the scenario information and configuration information in the bill generation requirement, the system selects multiple candidate bill modules matching the current scenario from a pre-set candidate bill module library, and then arranges these candidate bill modules according to the display order specified in the configuration information to form the target bill template.

[0034] Understandably, this step involves both reading business data and dynamically determining the billing page structure, laying the data and structural foundation for subsequent matching and rendering of atomic components.

[0035] Specifically, before the step of selecting business data from the database based on the bill generation requirement, steps S21-S22 are also included: Step S21: Perform an accuracy verification operation on the data to be written. The accuracy verification includes invoice verification, red-ink verification, overdue verification, and voiding verification. It should be noted that the data to be written refers to the business data that will soon be stored in the database, such as warehouse entry data imported from external systems or invoice data collected through interfaces.

[0036] Accuracy verification refers to the process of verifying the authenticity and compliance of data, including invoice verification, invoice cancellation verification, overdue verification, and voiding verification. Specifically, invoice verification verifies the authenticity of information such as invoice number and invoice code; invoice cancellation verification determines whether an invoice has been cancelled; overdue verification determines whether an invoice has exceeded the prescribed processing period; and voiding verification determines whether an invoice has been voided.

[0037] In this embodiment, before storing the data to be written into the database, the system sequentially performs various accuracy checks on the data. The order of these checks can be flexibly configured according to actual needs. Each check is completed by calling the corresponding check service or interface, and the check result is recorded.

[0038] Understandably, this step involves quality control before data is entered into the database to ensure that the business data entering the database is authentic and valid, thus guaranteeing the accuracy of the data upon which subsequent invoice generation depends from the source.

[0039] Step S22: If the verification passes, the data to be written is written to the database; if the verification fails, the data to be written to the database is prevented from being written, and a data error message is generated.

[0040] It should be noted that data anomaly alerts are messages used to inform users of the reasons for verification failures, specifically indicating which verification failed and the corresponding error details, so that users can correct the data.

[0041] In this embodiment, the system determines the overall result of the accuracy checks in step S21. If all checks pass, the data to be written is normally stored in the corresponding data table of the database; if any check fails, the data is prevented from being written to the database, and a corresponding data error message is generated based on the specific reason for the check failure and returned to the front end for display to the user.

[0042] Understandably, this step determines whether data is allowed to enter the database based on the verification results, ensuring the data quality in the database, and guiding users to correct problematic data through error messages.

[0043] Step S30: Determine the atomic component corresponding to each target bill module in the preset component library to obtain multiple target atomic components; It should be noted that the pre-built component library refers to a collection of pre-built atomic components. This component library is exported according to a general module definition specification and supports the import and invocation of multiple technology stacks. Each atomic component in the component library corresponds to a candidate bill module and has a unified data input and data output format defined.

[0044] An atomic component is the smallest reusable front-end rendering unit corresponding to a single billing module. It encapsulates the rendering and interaction logic of a specific functional module and exposes standardized data interfaces to the outside. An atomic component receives business data in a unified format for rendering and, when internal data changes, exposes the changed data externally through the data output format.

[0045] A target atomic component refers to an atomic component instance that is matched from the preset component library and corresponds to the target billing module. One target billing module corresponds to one target atomic component.

[0046] In this embodiment, the system traverses each target bill module in the target bill template, searches and matches it in a preset component library according to the module identifier or module type of each target bill module, finds the atomic components corresponding to each target bill module, and summarizes all the matched atomic components into multiple target atomic components.

[0047] Understandably, this step transforms the abstract billing module definition into an executable front-end rendering unit, enabling the component-based assembly of the billing page through the mapping relationship between modules and components.

[0048] Step S40: Based on the target atomic component and the business data, perform rendering to generate an invoice.

[0049] It should be noted that rendering refers to the process of combining atomic components with business data to generate a visual page in a browser or front-end application.

[0050] In this embodiment, the system sequentially mounts each target atomic component to the page container according to the arrangement order of the target bill modules in the target bill template. Before mounting each atomic component, the system converts the data portion of the business data corresponding to that atomic component according to the data input format defined by that atomic component, and then passes the converted data into the atomic component. The atomic component then completes the final view rendering and interaction logic binding internally, thereby generating a complete bill page for users to view and operate.

[0051] Understandably, this step integrates components and data for output, completing the transformation from data to a page and achieving a visual presentation of the target bill.

[0052] This application discloses a bill generation method and related equipment, relating to the field of data processing technology. Compared to related technologies where information systems in different hospitals differ significantly in data format, field definitions, and business processes, leading to repeated development of the same billing function in different hospitals or application scenarios, resulting in high R&D costs and low maintenance efficiency, this application first obtains bill generation requirements in response to a bill generation instruction. Then, based on the bill generation requirements, business data is selected from a database, and a target bill template is determined. The target bill template contains multiple target bill modules. Further, atomic components corresponding to each target bill module in a preset component library are determined, resulting in multiple target atomic components. Finally, based on the target atomic components and the business data, rendering is performed to generate a bill.

[0053] Understandably, this application selects business data and determines a target bill template containing multiple modules by responding to bill generation requirements. Then, it determines the atomic components corresponding to each module and generates bills based on the atomic components and business data. This allows bill modules to be dynamically combined as needed, and atomic components to support cross-module reuse, thereby reducing development costs and improving the flexibility and efficiency of bill generation.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The step of rendering based on the target atomic component and the business data to generate an invoice further includes steps A10 to A30: Step A10: Perform a data conversion operation on the business data to unify the format of the business data and obtain initial business data; It should be noted that data transformation refers to the process of converting raw business data from different sources and with different data structures into a unified standard format. Because existing data from different hospitals or systems differ in field naming, data structure, and data type, the data transformation operation is responsible for mapping this heterogeneous data into a standard format that atomic components can uniformly recognize.

[0055] Initial business data refers to business data with a unified format obtained after data transformation. This data has eliminated the format inconsistencies caused by differences in source, but it has not yet undergone field-level filtering and sorting.

[0056] In this embodiment, the system determines the corresponding field configuration information based on the application information and current business scenario type in the bill generation request. This field configuration information includes the mapping relationship between field key names defined in the standard format and the original data fields. The system iterates through each field in the original business data and, according to the mapping relationship, fills the values ​​of the original fields into the positions of the corresponding key names in the standard format, forming a data object with a unified key-value pair structure. For fields missing in the original data, the system processes them according to the default values ​​or null values ​​in the field configuration information to ensure that the converted data structure is complete and consistent. Finally, the converted data object is output as the initial business data.

[0057] Understandably, this step masks the format differences between different data sources, transforming heterogeneous data into a standard data format that atomic components can uniformly consume, thereby ensuring that subsequent field filtering and component rendering can be performed based on a unified specification.

[0058] Step A20: Perform field filtering on the initial business data to obtain the target business data; It's important to note that field filtering refers to the process of selecting the fields that actually need to be displayed from the full set of fields in the initial business data based on the configuration information in the bill generation requirements, and removing unnecessary fields. Field filtering ensures that the bill page only displays the fields that the user needs to focus on in the current scenario, avoiding information overload.

[0059] The target business data refers to the business data obtained after field filtering. Compared to the initial business data, this data has been streamlined in terms of volume, retaining only the fields that need to be displayed in the current scenario and their corresponding values.

[0060] In this embodiment, the system obtains the configuration information from the bill generation requirement and extracts the field display / hidden configuration for the current scenario from the configuration information. The system determines whether each field in the initial business data needs to be displayed based on the display / hidden configuration, and then iterates through all fields in the initial business data, removes fields marked as hidden, and retains only fields marked as explicit and their corresponding values, thereby generating the target business data.

[0061] Understandably, this step enables flexible configuration of the bill display content, allowing the same bill to display different sets of fields in different scenarios, thus meeting the differentiated needs of businesses while avoiding the duplication of developing different bill pages.

[0062] Specifically, the step of performing field filtering on the initial business data to obtain the target business data further includes steps A21 to A22: Step A21: Based on the bill generation requirements, determine the explicitness or implicitness of each field in the initial business data; It's important to note that "explicit" or "implicit" refers to the attribute indicating whether a field is displayed on the billing page. "Explicit" means the field should be shown on the billing page, while "implicit" means it shouldn't. This attribute is managed through backend configuration and can be dynamically adjusted based on different scenarios.

[0063] In this embodiment, the system extracts field configuration information from the bill generation requirements. This field configuration information contains a list of display / concealment configurations for all fields that can be displayed in the current scenario. The system iterates through each field in the initial business data, using the field's key name as the matching criterion, and searches for the corresponding display / concealment status in the display / concealment configuration list. If a match is found, the display / concealment status specified in the configuration item is adopted; if no match is found, the system's preset default display / concealment status is applied. After the above iteration, the system determines the display / concealment status of each field in the initial business data in the current scenario.

[0064] Understandably, this step is a preparatory step for field filtering operations, providing explicit and implicit judgment criteria for subsequent filtering and enabling field filtering to be dynamically adjusted according to the actual scenario.

[0065] Step A22: Based on the explicitness and implicitness, remove implicit fields from the initial business data to perform field filtering on the initial business data and obtain the target business data.

[0066] It should be noted that implicit fields refer to fields marked as implicit in step A21. These fields do not need to be displayed in the current scenario and should be removed in the filtering operation.

[0067] In this embodiment, the system iterates through all fields in the initial business data and judges each field according to the explicitness or implicitness determined in step A21. If a field is marked as explicit, the field and its corresponding value are retained; if a field is marked as implicit, the field and its corresponding value are deleted from the data object. After the iteration is completed, all implicit fields in the initial business data are removed, and the remaining fields and their values ​​constitute the target business data.

[0068] Understandably, this step completes the actual execution of field filtering, outputs simplified target business data, and ensures that subsequent atomic component rendering only receives the fields that need to be displayed, reducing data redundancy and improving rendering efficiency.

[0069] Step A30: Based on the target atomic component and the target business data, perform rendering to generate an invoice.

[0070] In this embodiment, the system sequentially mounts each target atomic component to the page container according to the arrangement order of the target bill modules in the target bill template. Before mounting each atomic component, the system passes the data portion corresponding to that atomic component from the target business data to that atomic component. The atomic component receives the data according to its internally predefined data input format and completes the view drawing and interaction binding of that functional module according to its own rendering logic. After each target atomic component has been rendered, they are combined to form a complete bill page.

[0071] Understandably, this step integrates the filtered business data with the various atomic components to complete the transformation from data to page, thereby achieving a visual presentation of the target bill.

[0072] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Before the step of determining the target bill template, steps B10 to B40 are also included: Step B10: Identify multiple candidate functional units in the bill generation scenario; It's important to note that candidate functional units refer to the abstract definitions of the various independent functional blocks that make up the bill page in a bill generation scenario. Each candidate functional unit corresponds to a display area on the bill page, such as an area for displaying basic document information, an area for displaying a product detail list, or an area for displaying a list of related invoices. Candidate functional units represent a functional division of the bill page from a business perspective.

[0073] In this embodiment, the system analyzes all business processes in the hospital settlement and reconciliation scenario, identifying the types of information and user operations that need to be presented on the billing page at each stage. The system defines each information type or operation type as an independent functional unit and compiles all identified functional units to form a complete list of candidate functional units.

[0074] Understandably, this step involves a comprehensive review of the billing page's functional structure from a business perspective, providing a basis for functional division in the subsequent construction of the candidate billing module and atomic components.

[0075] Step B20: Construct the corresponding candidate billing module for each candidate functional unit; It should be noted that a candidate bill module refers to a modular unit with complete business semantics, built upon candidate functional units. Each candidate bill module is a concrete implementation of a corresponding candidate functional unit, containing the data field definitions and business logic rules required by that functional unit. Candidate bill modules form the foundation for building atomic components.

[0076] In this embodiment, for each candidate functional unit identified in step B10, the system defines its required set of data fields, field types, field validation rules, and data dependencies between modules, forming a structured candidate billing module definition. Each candidate billing module remains logically independent and supports on-demand combination.

[0077] Understandably, this step concretizes abstract functional units into implementable module definitions, providing clear business boundaries and data structure specifications for the encapsulation of atomic components.

[0078] Step B30: For each candidate bill module, construct its corresponding atomic component, wherein the atomic component defines a unified data input format; It's important to note that a unified data input format refers to the standard data interface specification exposed by atomic components. All atomic components adhere to the same data input format definition, including naming conventions for field keys, data type conventions for field values, and identifiers for required and optional fields. This unified format enables different atomic components to receive business data in a consistent manner.

[0079] In this embodiment, for each candidate bill module constructed in step B20, the system uses front-end framework technology to encapsulate the corresponding atomic components. During the encapsulation process, the system defines a unified data input format for each atomic component. This format specifies the data structure that the atomic component can receive, including attribute names, attribute types, default values, etc. The atomic component internally parses the incoming data according to this data input format and renders it as visual page elements. All atomic components follow the same data input format specification, ensuring consistency in the data input method.

[0080] Understandably, this step completes the transformation from business modules to front-end components. By defining a unified data input format, it ensures that different atomic components can receive data in a standardized way, laying the foundation for the flexible combination and reuse of components in the future.

[0081] Step B40: Based on multiple candidate bill modules, construct a preset candidate bill module library; based on multiple atomic components, construct a preset component library.

[0082] It should be noted that the preset candidate bill module library refers to a collection used to store all candidate bill modules. Each candidate bill module in this library has a unique module identifier, which supports searching and calling by identifier.

[0083] The pre-defined component library is a collection used to store all atomic components. This component library is packaged and exported according to a common module definition specification, supporting the import and invocation of various front-end technology stacks. Each atomic component in the component library corresponds to a candidate bill module in the pre-defined candidate bill module library.

[0084] In this embodiment, the system uniformly catalogs and stores all candidate bill modules constructed in step B20, establishes a module index system, and forms a preset candidate bill module library. Simultaneously, the system constructs and packages all atomic components encapsulated in step B30 according to a unified packaging specification, generating a component library file that can be referenced externally, forming a preset component library. A one-to-one mapping relationship is established between modules in the preset candidate bill module library and components in the preset component library through module identifiers.

[0085] Understandably, centralized management and standardized encapsulation of preset resources enable candidate bill modules and atomic components to be quickly found and invoked during subsequent bill generation, thus achieving resource reuse.

[0086] Specifically, the step of determining the target bill template further includes steps B50 to B80: Step B50: Obtain the scenario information from the bill generation requirement, the scenario information including the application information and the current business scenario type; It should be noted that scenario information refers to the set of information used to describe the business environment in which this bill is generated, and it is the core basis for filtering target bill modules.

[0087] The application information refers to the identification information of the front-end application system that is used to indicate the invocation of the bill generation function, such as different front-end applications such as hospital system and supplier system.

[0088] The current business scenario type refers to the type of specific business process corresponding to the generation of this invoice, such as the scenario of viewing warehouse entry details, the scenario of viewing bank statement details, and the scenario of viewing invoice details.

[0089] In this embodiment, the system extracts the scenario information field from the bill generation requirements obtained in step S10, reads the values ​​of the application information and the current business scenario type respectively, and uses them as input parameters for the subsequent target bill filtering module.

[0090] Understandably, this step extracts scenario-related filtering conditions from the bill generation requirements, providing a basis for accurate matching of the target bill module.

[0091] Step B60: Based on the scenario information, select multiple target bill modules that match the scenario information from the preset candidate bill module library; It should be noted that the target bill module refers to the candidate bill module selected from the preset candidate bill module library that matches the information of the current scenario. These modules will constitute the main content of the target bill template.

[0092] In this embodiment, the system uses the scenario information obtained in step B50 as the query condition and performs a matching operation in the preset candidate billing module library. Based on the application information and the current business scenario type, the system searches for candidate billing modules that simultaneously meet both conditions, and outputs all successfully matched candidate billing modules as the target billing module.

[0093] Understandably, this step completes the initial screening of the target bill modules, reducing the full set of modules in the preset candidate bill module library to a subset of modules relevant to the current scenario, thus providing module materials for subsequent template assembly.

[0094] Specifically, the step of selecting multiple target bill modules that match the scenario information from the preset candidate bill module library based on the scenario information further includes steps B61 to B63: Step B61: Based on the application information, determine the entry type, and based on the current business scenario type, determine the required set of sub-functions; It should be noted that the entry point type refers to the category of the caller determined based on the application information. Different front-end application systems correspond to different entry point types; for example, hospital applications correspond to hospital entry points, and supplier applications correspond to supplier entry points. Different entry point types correspond to different API call strategies and data permission strategies.

[0095] A sub-function set refers to a combination of functional units that need to be activated in the current business scenario, determined by the current business scenario type. A business scenario may correspond to multiple sub-functions, which together constitute the complete functional requirements of the scenario.

[0096] In this embodiment, the system searches for the corresponding entry type in a preset application-entry mapping table based on the application information. Simultaneously, the system searches for all sub-functions required for the current business scenario in a preset scenario-function mapping table based on the current business scenario type, and then aggregates these sub-functions into a sub-function set.

[0097] Understandably, this step further refines the scenario information into executable technical parameters, transforms the application information into entry types for interface and permission adaptation, and breaks down the current business scenario type into a set of sub-functions for precise module matching.

[0098] Step B62: Based on the entry type and the sub-function set, search the preset candidate bill module library for a first candidate bill module set corresponding to the entry type, and filter out a second candidate bill module set that matches the sub-function set from the first candidate bill module set; It should be noted that the first candidate billing module set refers to the set of all candidate billing modules in the preset candidate billing module library that match the entry type. Different entry types correspond to different module visibility ranges; for example, a hospital-side entry may have more accessible modules than a supplier-side entry.

[0099] The second candidate billing module set refers to the set of candidate billing modules that are further filtered from the first candidate billing module set and match the sub-function set. This set is the source of the final determined target billing modules.

[0100] In this embodiment, the system first uses the entry type as a filtering condition to extract all candidate billing modules that match the entry type from a preset candidate billing module library, forming a first candidate billing module set. Subsequently, the system uses each sub-function in the sub-function set as a matching condition to compare each candidate billing module in the first candidate billing module set one by one, retaining candidate billing modules that match any sub-function and removing candidate billing modules that do not match, forming a second candidate billing module set.

[0101] Understandably, this step achieves precise positioning of the target billing module through two-level filtering of entry type and sub-function set, ensuring that the filtered modules not only comply with the access permissions of the application to which they belong, but also meet the functional requirements of the current scenario.

[0102] Step B63: Set the candidate bill modules in the second candidate bill module set as multiple target bill modules that match the scenario information.

[0103] In this embodiment, the system directly uses all candidate bill modules in the second candidate bill module set obtained in step B62 as target bill modules for matching with the scene information. At this point, these modules simultaneously satisfy the dual matching conditions of entry type and sub-function set.

[0104] Understandably, this step completes the final determination of the target billing module and outputs the filtering results for subsequent template assembly.

[0105] Step B70: Obtain the configuration information in the bill generation requirement, and determine the display order configuration of each target bill module based on the configuration information; It should be noted that the configuration information refers to the set of adjustable parameters carried in the bill generation requirements, which are used to control the display effect of the bill page, including the display order parameters and the display status parameters of each module.

[0106] Display order configuration refers to parameters used to specify the order in which each target billing module is arranged on the final billing page. Values ​​for display order configuration can be in the form of numerical sequence numbers, priority levels, or ordered lists.

[0107] In this embodiment, the system extracts configuration information from the bill generation requirements and reads the display order parameters corresponding to each target bill module from the configuration information. The system iterates through all target bill modules, binds the corresponding display order parameters to each module, and forms a mapping relationship between modules and order.

[0108] Understandably, this step determines the order of each target billing module, ensuring that the vertical arrangement of the modules on the final generated billing page conforms to the business reading habits of the current scenario.

[0109] Step B80: Based on the display order configuration and multiple target billing modules, a target billing template is obtained.

[0110] In this embodiment, the system sorts all target bill modules according to the display order determined in step B70, in ascending order, and outputs the sorted list of modules as the target bill template. At this point, the target bill template not only contains multiple target bill modules but also determines the arrangement order of each module on the page.

[0111] Understandably, this step combines the selected target bill modules with the display order configuration to output a target bill template with a complete structure and clear order, providing structural guidance for the matching and rendering of subsequent atomic components.

[0112] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the bill generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0113] This application also provides a bill generation device, please refer to... Figure 4 The bill generation device includes: The acquisition module 10 is used to acquire the bill generation requirement in response to the bill generation instruction; Selection module 20 is used to select business data from the database based on the bill generation requirements and determine the target bill template, which includes multiple target bill modules; Determining module 30, the determining module is used to determine the atomic component corresponding to each target bill module in the preset component library, to obtain multiple target atomic components; Generation module 40 is used to perform rendering based on the target atomic component and the business data to generate an invoice.

[0114] The bill generation apparatus provided in this application, employing the bill generation method described in the above embodiments, can solve the technical problem of bill generation. Compared with related technologies, the beneficial effects of the bill generation apparatus provided in this application are the same as those of the bill generation method provided in the above embodiments, and other technical features in the bill generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0115] This application provides a bill generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the bill generation method in Embodiment 1 above.

[0116] The following is for reference. Figure 5The diagram illustrates a structural schematic suitable for implementing the bill generation device of the embodiments of this application. The bill generation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The bill generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0117] like Figure 5 As shown, the bill generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the bill generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the billing device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show billing devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0118] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0119] The bill generation device provided in this application, employing the bill generation method described in the above embodiments, can solve the technical problem of bill generation. Compared with related technologies, the beneficial effects of the bill generation device provided in this application are the same as those of the bill generation method provided in the above embodiments, and other technical features of the bill generation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0120] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0122] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the bill generation method in the above embodiments.

[0123] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0124] The aforementioned computer-readable storage medium may be included in the billing device or may exist independently and not assembled into the billing device.

[0125] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the billing device, cause the billing device to: Responding to the bill generation command, obtain the bill generation requirements; Based on the bill generation requirements, business data is selected from the database, and a target bill template is determined, which contains multiple target bill modules; Determine the atomic component corresponding to each target bill module in the preset component library to obtain multiple target atomic components; Based on the target atomic component and the business data, rendering is performed to generate an invoice.

[0126] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0129] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described bill generation method, thereby solving the technical problem of bill generation. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the bill generation method provided in the above embodiments, and will not be repeated here.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the bill generation method described above.

[0131] The computer program product provided in this application can solve the technical problem of bill generation. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the bill generation method provided in the above embodiments, and will not be repeated here.

[0132] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A bill generation method, characterized in that, The bill generation method includes: Responding to the bill generation command, obtain the bill generation requirements; Based on the bill generation requirements, business data is selected from the database, and a target bill template is determined, which contains multiple target bill modules; Determine the atomic component corresponding to each target bill module in the preset component library to obtain multiple target atomic components; Based on the target atomic component and the business data, rendering is performed to generate an invoice.

2. The bill generation method as described in claim 1, characterized in that, The step of rendering based on the target atomic component and the business data to generate an invoice further includes: Perform a data transformation operation on the business data to unify the format of the business data and obtain initial business data; Perform field filtering on the initial business data to obtain the target business data; Based on the target atomic component and the target business data, rendering is performed to generate an invoice.

3. The bill generation method as described in claim 2, characterized in that, The step of performing field filtering on the initial business data to obtain the target business data further includes: Based on the bill generation requirements, determine the explicitness or implicitness of each field in the initial business data; Based on the explicitness and implicitness, implicit fields are removed from the initial business data to perform field filtering on the initial business data, thereby obtaining the target business data.

4. The bill generation method as described in claim 1, characterized in that, Before the step of selecting business data from the database based on the bill generation requirement, the method further includes: An accuracy verification operation is performed on the data to be written, including invoice verification, red-ink verification, overdue verification, and voiding verification. If the verification passes, the data to be written is written to the database; if the verification fails, the writing of the data to be written to the database is prevented, and a data error message is generated.

5. The bill generation method as described in claim 1, characterized in that, Before the step of determining the target bill template, the following are also included: Identify multiple candidate functional units in the bill generation scenario; Based on each candidate functional unit, construct its corresponding candidate bill module; For each candidate bill module, a corresponding atomic component is constructed, and the atomic component defines a unified data input format; A preset candidate bill module library is built based on multiple candidate bill modules, and a preset component library is built based on multiple atomic components.

6. The bill generation method as described in claim 5, characterized in that, The step of determining the target bill template further includes: Obtain the scenario information from the bill generation requirement, including the application information and the current business scenario type; Based on the scenario information, multiple target bill modules that match the scenario information are selected from the preset candidate bill module library; Obtain the configuration information from the bill generation requirement, and determine the display order configuration for each target bill module based on the configuration information; Based on the display order configuration and multiple target bill modules, a target bill template is obtained.

7. The bill generation method as described in claim 6, characterized in that, The step of selecting multiple target bill modules that match the scenario information from the preset candidate bill module library based on the scenario information further includes: Based on the application information, determine the entry point type, and based on the current business scenario type, determine the required set of sub-functions; Based on the entry type and the sub-function set, search the preset candidate bill module library for a first candidate bill module set corresponding to the entry type, and filter out a second candidate bill module set that matches the sub-function set from the first candidate bill module set; The candidate bill modules in the second candidate bill module set are set as multiple target bill modules that match the scenario information.

8. A bill generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the bill generation method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the bill generation method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the bill generation method as described in any one of claims 1 to 7.

Images