TWI895807B - Method for managing payment information and electronic device supporting thereof - Google Patents

Abstract

The present invention discloses a payment information management method for managing payment information of items ordered in an electronic device, comprising the following steps: obtaining business event information including at least order identification information in response to the occurrence of a business event; generating and storing first accounting event information based on the order information and the business event information, wherein the order information is confirmed based on the order identification information; providing payment information generated based on accounting cycle information and the first accounting event information to a supplier management server; and generating confirmed payment information based on the first information received from the supplier management server in response to the provision of the payment information.

Description

Method for managing payment information and electronic device supporting the method

The present invention relates to an electronic device and method for managing payment information. Specifically, the invention relates to a payment information management method for determining payments for ordered and delivered goods and performing payment processing for multiple delivery companies, and an electronic device supporting the method.

With the development of electronic technology, e-commerce has become a major player in the shopping world. Customers can purchase items online without having to visit a shopping mall, market, or store. Items purchased online are then delivered to the customer's requested location.

In e-commerce, providing detailed and accurate product information has a significant impact on service satisfaction. Therefore, the industry is discussing various solutions to provide more detailed and accurate information.

The payment information management system used to operate e-commerce services as described above can effectively manage payment between service providers and delivery companies, thereby providing more efficient services.

Furthermore, in order to effectively operate the e-commerce services described above, it may be necessary to account for payments for delivered items.

For this, please refer to previous literature such as KR101756594B1 or KR101500849B1.

[Identify the problem you want to solve]

According to the method of the present invention, the electronic device can dynamically generate the data required for accounting processing based on various basic data generated by ordering or inventory management, thereby effectively managing payment information.

According to the method of the present invention, electronic devices can dynamically generate data required for accounting processing based on various basic data generated by ordering or inventory management, thereby seeking to facilitate accounting processing and effectively utilize services.

According to the method of the present invention, when managing multiple delivery companies (suppliers), the electronic device can adapt to the various business processing methods of the suppliers to manage payment information.

The technical issues to be achieved by this invention are not limited to those mentioned above. Those skilled in the art to which this invention relates will clearly understand other technical issues not mentioned based on the following description. [Technical Means for Solving the Problem]

Various embodiments may provide a method for managing payment information and an electronic device supporting the method.

The various embodiments disclosed in this specification include methods for managing payment information for items ordered in an electronic device, which may include the following steps: obtaining business event information including at least order identification information in response to the occurrence of a business event; generating and storing first accounting event information based on the order information and the above-mentioned business event information, wherein the order information is confirmed based on the above-mentioned order identification information; providing the first accounting event information generated based on the accounting cycle information and the above-mentioned first accounting event information to a supplier management server; and generating confirmed payment information based on the first information received from the above-mentioned supplier management server in response to the provision of the above-mentioned payment information.

In an embodiment, the business event information may include event type information, quantity information, and order identification information corresponding to the business event.

In an embodiment, the event types may include inbound events and outbound events.

In an embodiment, the order information may include at least a portion of order item information, supplier information, price information, order quantity information, tax type information, tax rate information, and accounting period information.

In an embodiment, the first accounting event information may include at least a portion of information on the action type corresponding to the business event, quantity information, the order identification information, item information, and supplier information confirmed based on the order information.

In an embodiment, the above-mentioned providing step may further include the following steps: confirming the above-mentioned accounting cycle information based on the above-mentioned order information; confirming whether the accounting date corresponding to the above-mentioned order information has arrived based on the above-mentioned accounting cycle information; and when the above-mentioned accounting date has arrived, generating the above-mentioned payment information based on the above-mentioned stored first accounting event information.

In an embodiment, the providing step may further include the following steps: confirming the total inventory quantity information corresponding to the order identification information based on the first accounting event information; and generating payment information based on the total inventory quantity information and the order information.

In an embodiment, the step of generating the above-mentioned confirmed payment information may further include the following steps: generating payment target quantity information based on the above-mentioned first information and the above-mentioned total inventory quantity information; and generating the above-mentioned confirmed payment information based on the above-mentioned payment target quantity information and the above-mentioned order information.

In an embodiment, the step of generating the confirmed payment information may further include the following steps: generating second accounting event information based on the first information; and generating the confirmed payment information based on the payment occurrence information and the second accounting event information.

In an embodiment, the step of generating the second accounting event information may further include the following step: generating the second accounting event information based on the information on whether the payment information is approved or not, and the information on whether the payment information is approved or not is confirmed based on the first information.

In an embodiment, the first information may include tax invoice information, and the step of generating the second accounting event information further includes the following steps: confirming the supplier's supply quantity information based on the tax invoice information; and confirming whether the payment information is approved based on the result of comparing the supplier's supply quantity information with the payment information.

In an embodiment, the above-mentioned payment information management method may further include the following steps: providing the above-mentioned confirmed payment information to the accounting server.

In an embodiment, the above-mentioned payment information management method may further include the following steps: generating sales cost information of the items corresponding to the above-mentioned order information based on the above-mentioned payment information and the above-mentioned confirmed payment information; and providing the above-mentioned generated sales cost information to the accounting server.

The electronic device of various embodiments disclosed in this specification may include a memory; a transceiver; and a processor; the processor being configured to obtain business event information including at least order identification information in response to the occurrence of a business event; generate and store first accounting event information based on the order information and the business event information, wherein the order information is confirmed based on the order identification information; provide payment information generated based on accounting cycle information and the first accounting event information to a supplier management server; and generate confirmed payment information based on the first information received from the supplier management server in response to the provision of the payment information. [Effects of the Invention]

According to the method of the present invention, an electronic device can dynamically generate data required for accounting processing based on various basic data generated by ordering or inventory management, which has a technical effect in effectively managing payment information.

According to the method of the present invention, an electronic device can dynamically generate data required for accounting processing based on various basic data generated by ordering or inventory management, which has a technical effect in seeking convenience in accounting processing and effectively utilizing services.

According to the method of the present invention, an electronic device can propose a method for adaptively processing information received from suppliers based on each supplier's accounting cycle and data processing method. This has technical effects in effectively managing payment information based on the characteristics of multiple suppliers.

The effects that can be achieved by the present invention are not limited to the effects mentioned above. Those with common knowledge in the technical field to which the present invention belongs can clearly understand other effects not mentioned based on the following description.

The following embodiments are obtained by combining the components and features of various embodiments in specified configurations. Unless otherwise explicitly stated, each component or feature is considered optional. Each component or feature can be implemented in a form without being combined with other components or features. Furthermore, some components and features can be combined to form various embodiments. The order of the actions described in the various embodiments may be changed. Some components or features of one embodiment may be included in other embodiments, or may replace corresponding components or features of other embodiments.

In the description of the accompanying drawings, procedures or steps that may obscure the subject matter of various embodiments are not described, nor are procedures or steps that are understandable to a person having ordinary knowledge in the art are described.

Throughout this specification, when it is stated that a certain part "comprising or including" a certain component, it means that other components may be further included unless otherwise stated, and other components are not excluded. In addition, terms such as "...part", "...device", and "module" described in the specification refer to a unit that processes at least one function or action, which can be implemented by hardware, software, or a combination of hardware and software. In addition, in the text describing various embodiments (especially in the scope of the invention application below), unless otherwise indicated in the present invention or not explicitly contradicted in the text, "a (or an)", "one (one)", "the (the)" and similar related words can be used to include both the singular and the plural meaning.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The following detailed description in conjunction with the accompanying drawings is intended to illustrate exemplary embodiments of the present invention and is not intended to represent the only embodiment.

Furthermore, specific terms used in various embodiments are provided to facilitate understanding of the various embodiments, and the use of such specific terms may be changed into other forms without departing from the technical ideas of the various embodiments.

At this point, it should be understood that the combination of each block of the process flow chart and the flowchart can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the instructions executed by the processor of the computer or other programmable data processing device will produce a method for implementing the functions described in the flow chart blocks. In order to implement the functions in a specific manner, these computer program instructions can be stored in a computer-usable or computer-readable memory that is oriented to the computer or other programmable data processing device. The instructions stored in the computer-usable or computer-readable memory or recording medium can also produce an article of manufacture that includes the following instruction method, which implements the functions described in the flow chart blocks. Computer program instructions can be loaded onto a computer or other programmable data processing device, thereby executing a series of action steps on the computer or other programmable data processing device to generate a process executed by the computer. Therefore, the instructions executed by the computer or other programmable data processing device can also provide steps for executing the functions described in the flowchart blocks.

Furthermore, each block may represent a module, code segment, or portion of code that includes one or more executable instructions for performing a specific logical function. Furthermore, it should be noted that in some alternative embodiments, the functions mentioned in the blocks may not occur in the order in which they are described. For example, two blocks shown in succession may be executed simultaneously, or may occasionally be executed in the reverse order depending on the corresponding functions.

FIG1 is a diagram of a payment information management system 100 for illustrating a method for managing payment information using an electronic device according to various embodiments.

Referring to FIG. 1 , the payment information management system 100 of various embodiments can be implemented in various types of devices. For example, the payment information management system 100 can be implemented in an electronic device 101, an administrator device 102, an accounting server 103, and a supplier management server 104. In other words, the electronic device 101, the administrator device 102, the accounting server 103, and the supplier management server 104 can perform the operations of the various embodiments of the present invention based on the payment information management system 100 implemented in each device. Furthermore, the payment information management system 100 of various embodiments is not limited to that shown in FIG. 1 and can be implemented in a wider variety of electronic devices and servers.

In various embodiments, the electronic device 101 can be a device that communicates wirelessly and wired with one or more administrator devices 102, accounting servers 103, and/or vendor management servers 104 and includes a storage device with a large storage capacity. For example, the electronic device 101 can be a cloud device connected to one or more administrator devices 102, accounting servers 103, and/or vendor management servers 104.

The administrator device 102 of various embodiments can be a desktop computer, tablet computer, PDA (personal digital assistant), mobile terminal, or other device that can be used by a personal user. In addition, other electronic devices that perform similar functions can also be used as the administrator device 102.

In various embodiments, the accounting server 103 can be a device that communicates wirelessly and wired with the electronic device 101, one or more administrator devices 102, and/or the vendor management server 104, and includes a storage device with a large unit of storage capacity. For example, the accounting server 103 can be a cloud device connected to one or more administrator devices 102, the electronic device 101, and/or the vendor management server 104.

In various embodiments, the vendor management server 104 can be a device that communicates wirelessly and wired with the electronic device 101, one or more administrator devices 102, and/or the accounting server 103, and includes a storage device with a large unit of storage capacity. For example, the vendor management server 104 can be a cloud device connected to one or more administrator devices 102, the electronic device 101, and/or the accounting server 103.

The payment information management system 100 of various embodiments may include various modules for performing operations. The modules included in the payment information management system 100 may be computer code and one or more instructions that enable a physical device (e.g., electronic device 101) that implements the payment information management system 100 (or included in the physical device) to perform specified operations. In other words, the physical device that implements the payment information management system 100 may store multiple modules in the form of computer code in memory. When the multiple modules stored in the memory are executed, the multiple modules cause the physical device to perform the specified operations corresponding to the multiple modules.

FIG2 is a diagram showing the configuration of an electronic device and a user device according to various embodiments.

2 , the electronic device 101 , the management device 102 , the accounting server 103 , and the vendor management server 104 may include an input/output unit 210 , a communication unit 220 , a storage 230 , and a processor 240 .

The input/output unit 210 can be any interface or port for receiving user input or outputting information to the user. The input/output unit 210 can include an input module and an output module. The input module receives user input. User input can be implemented in various forms, including keystroke input, touch input, and voice input. Examples of input modules capable of receiving such user input include: a traditional numeric keypad or keyboard, a mouse, a touch sensor that senses user touch, a microphone that receives voice signals, a camera that recognizes gestures through image recognition, a proximity sensor that includes at least one of an illumination sensor or an infrared sensor to detect user proximity, a motion sensor that recognizes user motion using an accelerometer or a gyroscope, and various input components that sense or receive various forms of user input. The input module of embodiments of the present invention may include at least one of the devices listed above. Here, the touch sensor can be implemented as a piezoelectric or electrostatic touch sensor that senses touch via a touch panel or touch film attached to the display panel, or an optical touch sensor that senses touch optically. Alternatively, the input module can be implemented as an input interface (such as a USB (Universal Serial Bus) port or a PS/2 (Personal System 2) port) that connects to an external input device that receives user input, rather than as a device that itself senses user input. Furthermore, the output module can output various types of information. The output module may include at least one of a display for outputting images, a speaker for outputting sounds, a tactile device for generating vibrations, and various other output mechanisms. Furthermore, the output module may also be implemented in the form of a port-type output interface connected to a single output mechanism.

For example, an output module in the form of a display can display text, static images, or video. Displays may include at least one of: liquid crystal displays (LCDs), light emitting diode (LED) displays, organic light emitting diode (OLED) displays, flat panel displays (FPDs), transparent displays, curved displays, flexible displays, 3D displays, holographic displays, projectors, and other devices capable of outputting images. Such displays may also be touch displays integrated with the touch sensor of the input module.

The communication unit 220 enables communication with other devices. Therefore, the electronic device 101, the administrator device 102, the accounting server 103, and the vendor management server 104 can exchange information with other devices via the communication unit. For example, the electronic device 101, the administrator device 102, the accounting server 103, and the vendor management server 104 can use the communication unit to communicate with each other or with other devices.

Here, communication, i.e., the transmission and reception of data, can be achieved either wired or wirelessly. For this purpose, the communication unit may be configured as: a wired communication module connected to the Internet via a LAN (Local Area Network), a mobile communication module connected to a mobile communication network via a mobile communication base station to transmit and receive data, a short-range communication module utilizing WLAN (Wireless Local Area Network) communication methods such as Wi-Fi or WPAN (Wireless Personal Area Network) communication methods such as Bluetooth and Zigbee, a satellite communication module utilizing GNSS (Global Navigation Satellite System) such as GPS (Global Positioning System), or a combination thereof.

Memory 230 can store various types of information. Memory can store data temporarily or semi-permanently. For example, the memory of electronic device 101 can store the operating system (OS) used to drive electronic device 101, data used to host a website, or data used to generate Braille programs or applications (such as web applications). Furthermore, as described above, the memory can store modules in the form of computer code.

Examples of the memory 230 include a hard disk drive (HDD), a solid state drive (SSD), a flash memory, a read-only memory (ROM), and a random access memory (RAM). Such memory may be provided as a built-in or removable type.

The processor 240 controls the overall operation of the electronic device 101, the administrator device 102, the accounting server 103, and the supplier management server 104. To this end, the processor 240 can perform calculations and processing of various information and control the operation of the components of the electronic device 101. For example, the processor 240 can execute a program or application to manage payment information. The processor 240 can be implemented by a computer or similar device based on hardware, software, or a combination thereof. In terms of hardware, the processor 240 can be implemented in the form of an electronic circuit that processes electrical signals and performs control functions. In terms of software, it can be implemented in the form of a program that drives the hardware processor 240. On the other hand, unless otherwise specified in the following description, the actions of the electronic device 101, the administrator device 102, the accounting server 103, and the supplier management server 104 can be interpreted as being performed under the control of the processor 240. Specifically, when executing the modules implemented in the aforementioned payment information management system 100, the modules can be interpreted as controlling the processor 240 by causing the electronic device 101, the administrator device 102, the accounting server 103, and the supplier management server 104 to perform the following actions.

In summary, various embodiments can be implemented by various mechanisms. For example, various embodiments can be implemented by hardware, firmware, software, or a combination thereof.

In the case of hardware implementation, the methods of various embodiments may be implemented by one or more ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, etc.

When implemented via firmware or software, the methods of various embodiments may be implemented as modules, procedures, or functions that implement the functions or actions described below. For example, the software code may be stored in memory and driven by a processor. The memory may be located internally or externally to the processor and may communicate with the processor via various known mechanisms.

Based on the above technical concepts, various embodiments are described in more detail below. The various embodiments described below can be applied to the content described above. For example, actions, functions, and terms not defined in the various embodiments described below can be implemented and described based on the content described above.

In the following description, various embodiments are described based on the premise that the electronic device 101 and the administrator device 102 perform the action of managing payment information. According to various embodiments, the electronic device 101 and the administrator device 102 can send and receive information related to the action of managing payment information with the user device 103.

FIG3 is a flowchart of various embodiments of an electronic device managing payment information.

According to various embodiments, in action S301, the electronic device 101 may obtain business event information.

In an embodiment, business events may include various types of events related to payment. For example, they may include order events, order information generation events, order information change events, inventory entry events, inventory shipment events, and at least a portion of inventory shipment events. Business events may also include inventory change events. Electronic device 101 may obtain business event information in response to the occurrence of a business event. Business event information may correspond to each event type, corresponding to at least one of inventory entry event information, inventory shipment event information, order event information, and order change event information. According to one embodiment, business event information may include event type information, quantity information, and order identification information.

In this embodiment, an inventory change event may include a business event that may include an inventory change event for payment of goods. The inventory used for payment may include both ordered goods and shipped goods. For example, an inventory change event may include an order event, a stock-in event, and a stock-out event.

In an embodiment, an entry event can be understood as an event in which a delivered item enters the warehouse. For example, when an entry event occurs for an item, the operator device 102 can obtain entry event information and provide it to the electronic device 101. The electronic device 101 can obtain the entry event information from the operator device 102 in response to the entry event. According to one embodiment, the entry event information provided by the operator device 102 to the electronic device 101 may include basic information of the business event. For example, the entry event information may include order identification information, event type information, and quantity information. The operator device 102 may provide the electronic device 101 with at least a portion of the order information of the item entered into the warehouse. According to one embodiment, the operator device 102 can scan the order form corresponding to the item to be entered into the warehouse through the sensor included in the input module. The order form may include order identification information corresponding to the order. According to one embodiment, the electronic device 101 can generate warehouse entry event information based on the basic information of the business event. For example, the electronic device 101 can receive event type information, quantity information and order identification information from the operator device 102 in response to the warehouse entry event, and generate warehouse entry event information based on the order information, and the order information is confirmed based on the order identification information. The warehouse entry event information may include at least a portion of the event type information, quantity information, item information, order identification information and supplier information.

In an embodiment, an outbound event can be understood as an event in which a delivered item is outbound from inventory. For example, an outbound event may occur in the following situations: an item in the warehouse is defective, does not have commercial properties, or is returned by a service user after being outbound. For example, when an outbound event occurs for an item, the operator device 102 may obtain outbound event information and provide it to the electronic device 101. The electronic device 101 may obtain the outbound event information from the operator device 102 in response to the outbound event. According to one embodiment, the outbound event information provided by the operator device 102 to the electronic device 101 may include basic information of the business event. For example, the outbound event information may include order identification information, event type information, and quantity information. The operator device 102 may provide the electronic device 101 with at least a portion of the order information of the items to be shipped. According to one embodiment, the operator device 102 may scan an order form corresponding to the items to be shipped by a sensor included in the input module. The order form may include order identification information corresponding to the order. According to one embodiment, the electronic device 101 may generate shipping event information based on basic information of a business event. For example, the electronic device 101 may receive event type information, quantity information, and order identification information from the operator device 102 in response to a shipping event, and generate shipping event information based on the order information, where the order information is confirmed based on the order identification information. The outbound event information may include at least a portion of event type information, quantity information, item information, order identification information, time period information, and supplier information.

In an embodiment, an order event can be understood as an event of ordering an item to be delivered from a supplier. The electronic device 101 can obtain order event information in response to the occurrence of an order event. The order event information may include order identification information and order information. For example, when an order event occurs, the operator device 102 can generate order information and order event information and provide them to the electronic device 101 and/or the supplier management server 104. In an embodiment, the order information may include at least a portion of order identification information, supplier information, item information, unit price information, order quantity information, tax type information, tax rate information, and billing cycle information. Order identification information can be assigned in response to the occurrence of an order event. According to one embodiment, the electronic device 101 can confirm the billing cycle information based on the supplier information. The electronic device 101 can pre-store the supplier management information, which can include supplier information, item information, and billing cycle information.

In an embodiment, an order change event may occur when the order information of an already placed order is changed. Electronic device 101 may obtain order change event information in response to the occurrence of the order change event. The order change event information may include order identification information and the changed order information. For example, when an order change event occurs, operator device 102 may generate the changed order information and order change event information and provide them to electronic device 101 and/or supplier management server 104. According to one embodiment, at least a portion of the order information other than the order identification information may be changed in response to the order change event.

According to various embodiments, in action S302, electronic device 101 may generate first accounting event information. The accounting event may include an event related to data that electronic device 101 needs to process when making a payment. According to one embodiment, the accounting event may occur in response to at least a portion of a business event.

In an embodiment, the first accounting event information may include information used to generate payment information. The first accounting event information may include at least a portion of information on the action type corresponding to the business event type, quantity information, order identification information, item information, and supplier information. The electronic device 101 may generate the first accounting event information based on the business event information and the order information. In this case, the electronic device 101 may confirm the order information with the supplier management server 104 based on the order identification information corresponding to the business event information, or confirm the order information by loading an order database containing individual order information. According to one embodiment, the electronic device 101 can confirm the order information corresponding to the business event information based on the order identification information included in the business event information, and generate the first accounting event information based on the order information. The action type may include type information of the operation action used to combine the quantity information included in each of the multiple first accounting event information. For example, the action types corresponding to the warehousing event and the outbound event can be defined respectively. According to one embodiment, each action type can correspond to more than one business event. For example, the action type corresponding to the warehousing event and the action type corresponding to the order change event can be defined as "RECEIVE_TEMP". According to an embodiment, the electronic device 101 can generate and store the first accounting event. The electronic device 101 may include a separate database for the first accounting event information to store the generated first accounting event information.

According to various embodiments, in action S303, electronic device 101 may provide payment information. Payment information may include inventory receipt event information and/or inventory payment information. Incoming inventory event information occurs in response to an order, while inventory payment information occurs in response to an outgoing inventory event. For example, payment information may be related to accounts payable (AP) on financial statements. Specifically, it may correspond to information regarding accrued AP. In one embodiment, payment information may include quantity information and the corresponding amount information. The payment information may include the actual quantity of the incoming goods event and the outgoing goods event, that is, the quantity information confirmed based on the first accounting event information corresponding to the incoming goods event information and the first accounting event information corresponding to the outgoing goods event information. The electronic device 101 may calculate each first accounting event information based on the action type of each first accounting event information to generate the payment information. For example, the electronic device 101 may calculate the quantity information by adding the quantity included in the first accounting event information of the incoming goods event and deleting the quantity included in the first accounting event information of the outgoing goods event. The electronic device 101 may receive a message queue and generate the payment information based on the action type, and the message queue includes the first accounting event information loaded into the first accounting event database. According to one embodiment, the electronic device 101 may generate payment information based on unit price information and quantity information, which are confirmed based on order information. The electronic device 101 may also confirm total inventory quantity information based on the first accounting event information. For example, the electronic device 101 may confirm the total inventory quantity, excluding the quantity shipped from the total inventory quantity, which is received based on the action type and quantity information of one or more first accounting event information. The electronic device 101 may generate payment information based on the total inventory quantity information and order information.

Electronic device 101 can generate payment information based on billing cycle information and first accounting event information. According to one embodiment, electronic device 101 can generate payment information based on order information and first accounting event information, where the order information is confirmed based on order identification information. The billing cycle information can be information about the payment billing cycle for orders agreed upon with each supplier for the services provided by electronic device 101. The billing cycle information can include information about the period during which the supplier receives payment, the billing date for billing, and the deadline by which the supplier should receive payment after delivery. According to one embodiment, when the same supplier delivers the same item, different orders can have the same payment settlement period. According to one embodiment, when the same supplier delivers different orders for different items, different orders can have different payment settlement periods. According to one embodiment, different suppliers can have different payment settlement periods. According to one embodiment, the electronic device 101 can confirm the payment settlement period corresponding to the supplier information based on the supplier information, and the supplier information is confirmed based on the order information. The electronic device 101 can generate payment information based on the information of the settlement date, and the information of the settlement date is confirmed based on the payment settlement period. The electronic device 101 can confirm whether the settlement date corresponding to the order information has arrived based on the settlement cycle information. If the settlement date has arrived, the electronic device 101 can generate payment information based on the stored first accounting event information.

In an embodiment, the electronic device 101 may provide the generated payment information to the accounting server 103 and/or the supplier management server 104 .

According to various embodiments, in action S304, the electronic device 101 may receive the first information. The first information may include information received by the electronic device 101 from the supplier management server 104 in response to the provision of the payment information. The first information may include information on whether the supplier approves the payment. The electronic device 101 may generate the second accounting event information based on the information on whether the payment information is approved or not. According to one embodiment, the first information may include approval information for approving the payment information or change request information for requesting a change in the payment information. The electronic device 101 may generate the second accounting event information including information on the action type based on the approval or disapproval information included in the first information. According to one embodiment, the second accounting event information may include the same action type regardless of approval or disapproval. For example, when the first information includes a change request information regarding the occurrence of payment information, the electronic device 101 may change the occurrence of payment information. In this case, the electronic device 101 may modify the total inventory quantity information corresponding to the occurrence of payment information based on the change quantity information included in the change request information. The electronic device 101 may generate second accounting event information, which includes the changed quantity information and information on the action type of the quantity change. For another example, when the occurrence of payment information is approved, there may be a situation where the occurrence of payment information does not need to be changed. Even if the action type is the same as when it is not approved (in the case of a change request), the information on the changed quantity may have a value of "0". Alternatively, the electronic device 101 may generate the second accounting event information only when a request is made to change the payment information. In an embodiment, the first information may include supplier supply quantity information. For example, the first information may include information about the quantity claimed by the supplier. The electronic device 101 may confirm the approval based on the comparison between the supplier's claimed supply quantity, i.e., the supplier's supplied quantity information, and the quantity information included in the payment information. The electronic device 101 may generate the second accounting event information to modify the payment information based on the supplier's supplied quantity information and the payment information.

In one embodiment, the first information may include tax invoice information. According to one embodiment, the first information may include tax invoice information provided by a supplier. The tax invoice information may include supplier-side tax information for goods delivered by the supplier. According to one embodiment, the electronic device 101 may confirm supplier supply quantity information based on the tax invoice information. The electronic device 101 may use the ordered item information, supplier information, price information, tax type information, tax rate information, and accounting period information confirmed based on the order information to confirm the supplier supply quantity information corresponding to the tax invoice information.

According to one embodiment, the tax invoice information may include image data from an electronic file and/or a handwritten file. The electronic device 101 may obtain tax information based on the tax invoice information. According to one embodiment, the electronic device 101 may perform optical character recognition (OCR) to obtain the tax information included in the tax invoice information. The electronic device 101 may verify supplier quantity information based on the tax information.

According to various embodiments, in action S305, the electronic device 101 may generate confirmed payment information based on the first information. The confirmed payment information may include at least a portion of information on the amount of confirmed payment to be paid to the supplier for the service provided by the electronic device 101 and information on the number of payment recipients corresponding to the confirmed payment. The confirmed payment information may be information about accounts payable (AP) on the financial statements, specifically, information corresponding to actual accrued accounts payable (actual AP). The electronic device 101 may generate confirmed payment information based on the approval information included in the first information. For example, when the supplier approves the occurrence payment information, the electronic device 101 may generate confirmed payment information that is identical to the occurrence payment information. In the event that the supplier does not approve the payment information and requests a change, the electronic device 101 may change the payment information based on the supplier supply quantity information included in the first information, thereby generating confirmed payment information.

According to one embodiment, the electronic device 101 may generate payment target quantity information based on the first information and the payment generation information. The payment target quantity information may include quantity information of delivered items as the payment target. The electronic device 101 may generate payment target quantity information based on the first information and the total inventory quantity information. According to one embodiment, the electronic device 101 may generate payment target quantity information based on the second accounting event information and the payment generation information. The electronic device 101 may generate confirmed payment information based on the payment target quantity information and the order information. The electronic device 101 may provide the confirmed payment information to the accounting server 103.

FIG4 shows functional modules included in electronic devices according to various embodiments.

The electronic device 101 of various embodiments of this specification may include an order module 410, an inventory management module 420, an event data module 430, an AP module 440, and a database 450 as functional modules.

According to various embodiments, the ordering module 410 and the inventory management module 420 may each provide basic business event information to the event data module 430. According to one embodiment, the event data module 430 may receive a message queue based on the order identification information included in the basic business event information and generate business event information based on the basic business event information. The message queue includes the basic business event information generated by the ordering module 410 and/or the inventory management module 420.

For example, when the order module 410 generates order event information in response to an order event, the order module 410 may transmit basic information of the business event including order identification information and order information to the event data module 430. The event data module 430 may generate order event information including order identification information, event type information and order information.

Inventory management module 420 can generate basic information for incoming inventory events. For example, inventory management module 420 can provide basic information for incoming inventory events, including order identification information, event type information, and quantity information, to event data module 430. Event data module 430 generates incoming inventory event information by mapping at least a portion of the order information confirmed based on the order identification information, such as by mapping supplier information.

Inventory management module 420 can generate basic information for outbound events. For example, inventory management module 420 can provide basic outbound event information, including order identification information, event type information, and quantity information, to event data module 430. Event data module 430 generates outbound event information by mapping at least a portion of the order information confirmed based on the order identification information, such as by mapping supplier information.

According to various embodiments, the event data module 430 may provide the generated business event information to the AP (account payable) module 440. The AP module 440 may generate accounting event information. According to one embodiment, the AP module 440 may generate first accounting event information based on the business event information. According to one embodiment, the AP module 440 may generate second accounting event information based on the first information. The AP module 440 may receive business event information based on accounting cycle information, which is confirmed based on order information. For example, the AP module 440 may distinguish and receive business event information based on order identification information corresponding to the accounting cycle. The AP module 440 may store the generated accounting event information in the database 450.

FIG5 is a flowchart showing the operation of the electronic device in various embodiments for managing payment information based on the first information.

According to various embodiments, in action S501, the electronic device 101 may receive the first information. The first information may include information received by the electronic device 101 from the supplier management server 104 in response to the provision of the payment information. The first information may include information on whether the supplier approves the payment. In an embodiment, the first information may include supplier supply quantity information. For example, the first information may include information on the quantity that the supplier claims to supply, i.e., supplier supply quantity information. The electronic device 101 may confirm the approval information based on the comparison result between the supplier supply quantity information and the quantity information included in the payment information. The electronic device 101 may generate second accounting event information to modify the payment information based on the supplier supply quantity information and the payment information.

In one embodiment, the first information may include tax invoice information. According to one embodiment, the first information may include tax invoice information provided by a supplier. The tax invoice information may include supplier-side tax information for goods delivered by the supplier. According to one embodiment, the electronic device 101 may confirm supplier supply quantity information based on the tax invoice information. The electronic device 101 may use the ordered item information, supplier information, price information, tax type information, tax rate information, and accounting period information confirmed based on the order information to confirm the supplier supply quantity information corresponding to the tax invoice information.

According to one embodiment, the tax invoice information may include image data from an electronic file and/or a handwritten file. The electronic device 101 may obtain tax information based on the tax invoice information. According to one embodiment, the electronic device 101 may perform optical character recognition (OCR) to obtain the tax information included in the tax invoice information. The electronic device 101 may verify supplier quantity information based on the tax information.

According to various embodiments, in action S502, the electronic device 101 may generate the second accounting event information based on the first information. According to one embodiment, the electronic device 101 may generate the second accounting event information based on the information on whether the payment information is approved or not. According to one embodiment, the first information may include approval information for approving the payment information or change request information for requesting to change the payment information. The electronic device 101 may generate the second accounting event information including the action type information based on the approval or disapproval information included in the first information. According to one embodiment, the second accounting event information may include the same action type regardless of approval or disapproval. For example, when the first information includes change request information for the payment information, the electronic device 101 may change the payment information. In this case, the electronic device 101 can modify the total inventory quantity information corresponding to the payment information based on the change quantity information included in the change request information. The electronic device 101 can generate the second accounting event information, which includes the changed quantity information and the information on the action type of the quantity change. For example, when the payment information is approved, there may be a situation where the payment information does not need to be changed. Even if the action type is the same as when it is not approved (in the case of a change request), the information on the changed quantity may have a value of "0". Alternatively, the electronic device 101 can only generate the second accounting event information when a change is requested to change the payment information.

According to various embodiments, in action S305, electronic device 101 may generate confirmed payment information based on the payment occurrence information and the second accounting event information. The confirmed payment information may include at least a portion of information regarding the confirmed payment amount payable to the supplier for the services provided by electronic device 101 and information regarding the number of payment recipients corresponding to the confirmed payment. Electronic device 101 may generate confirmed payment information based on the approval/disapproval information included in the first information. For example, if the supplier approves the payment occurrence information, electronic device 101 may generate confirmed payment information identical to the payment occurrence information. In the event that the supplier does not approve the payment information and requests a change, the electronic device 101 may change the payment information based on the supplier supply quantity information included in the first information, thereby generating confirmed payment information.

According to one embodiment, the electronic device 101 may generate payment target quantity information based on the first information and the payment generation information. The payment target quantity information may include quantity information of delivered items as the payment target. The electronic device 101 may generate payment target quantity information based on the first information and the total inventory quantity information. According to one embodiment, the electronic device 101 may generate payment target quantity information based on the second accounting event information and the payment generation information. The electronic device 101 may generate confirmed payment information based on the payment target quantity information and the order information. The electronic device 101 may provide the confirmed payment information to the accounting server 103. According to one embodiment, the electronic device 101 may provide payment confirmation information to the accounting server 103 and receive approval information from the accounting server 103 regarding the payment confirmation information. Based on the approval information, the electronic device 101 may provide the payment confirmation information to the supplier management server 104. The supplier management server 104 may pay the supplier upon delivery of the ordered items based on the payment confirmation information.

FIG6 shows a method for managing payment information based on accounting cycle information according to various embodiments.

According to various embodiments, the electronic device 101 may generate first accounting event information, payment occurrence information, second accounting event information, and/or payment confirmation information based on the accounting cycle information.

The service provided by electronic device 101 is to request the delivery of goods from suppliers, i.e., to place an order. The supplier can deliver the goods corresponding to the order based on the billing cycle information. In response to this, a business event can occur, and electronic device 101 can obtain business event information corresponding to the occurrence of the business event.

Referring to Figure 6, the following scenario can be illustrated: based on fixed billing cycle information, orders are periodically placed with suppliers, deliveries are accepted, and payment is settled. The supplier, based on the fixed billing cycle information, continues to accept orders and is paid after delivery. In the example of Figure 6, this can be understood as a scenario where a delivery deadline is set within the Mth cycle, and an order with a billing date (e.g., the Mth order) is received within the (M+1)th cycle. In other words, corresponding to the Mth order with a delivery deadline set within the Mth cycle, confirmed payment information is generated on a payment date set within the (M+1)th cycle.

In one embodiment, the electronic device 101 may generate first accounting event information during the Mth cycle. According to one embodiment, the first accounting event information may be generated based on business event information. Business event information may be generated and/or obtained in response to the occurrence of a business event. Since business events such as warehousing and shipping may occur during the Mth cycle, the electronic device 101 may generate the first accounting event information at time 620 corresponding to the business event occurring during the Mth cycle.

In an embodiment, electronic device 101 may generate payment information on a designated accounting date 630 within the Mth cycle. For example, electronic device 101 may load first accounting event information into a database. Upon the arrival of accounting date 630 corresponding to the loaded first accounting event information and supplier information, electronic device 101 may receive the first accounting event information confirmed based on the order identification information of the Mth order corresponding to the supplier information, and generate payment information. Accounting date 630 may be confirmed based on the Mth order information, which is confirmed based on the order information, supplier information, and/or supplier information of the Mth order. Electronic device 101 can provide payment information generated upon the arrival of accounting date 630 to the accounting server and/or supplier management server. Based on supplier information and accounting cycle information, electronic device 101 can receive the first accounting event information for the Mth order. For example, when accounting date 630 arrives, as confirmed based on the supplier's accounting cycle information, electronic device 101 can retrieve the order corresponding to the current accounting date 630 from the database for one or more order information corresponding to the corresponding supplier, i.e., the first accounting event information corresponding to the Mth order, and generate payment information.

In this embodiment, the electronic device 101 may generate the second accounting event information during the (M+1)th cycle. The electronic device 101 may generate the second accounting event information in response to receipt of the first information. For example, the first information may be received from the supplier management server 104 at a predetermined time point during the (M+1)th cycle, corresponding to the occurrence of payment information. The electronic device 101 may generate the second accounting event information at time 640 corresponding to receipt of the first information.

In an embodiment, the electronic device 101 may generate the confirmed payment information in the (M+1)th cycle. The electronic device 101 may generate the confirmed payment information in response to the generation of the second accounting event information.

In one embodiment, electronic device 101 may generate additional accounting event information. This additional accounting event information may include accounting event information generated in response to business events that do not properly adhere to the specified accounting cycle information corresponding to orders. For example, business event information corresponding to the Mth order is obtained during the Mth cycle, but due to various reasons, a business event corresponding to the Mth order may occur after the Mth cycle. For example, assume that after the payment corresponding to the Mth order is settled based on the confirmed payment information, a business event occurs in which items corresponding to the Mth order are either received or shipped from the warehouse. Electronic device 101 obtains business event information in response to the occurrence of a business event and generates a first accounting event based on the business event information. However, if a business event occurs after payment confirmation information is generated based on the accounting cycle information, additional accounting event information is generated accordingly. The additional accounting event information may include accounting event information for incorporating business events that were not processed during the accounting cycle for an order corresponding to the previous cycle (e.g., the Mth order corresponding to the Mth cycle) into the accounting cycle for an order corresponding to the next cycle (e.g., the (M+1)th order corresponding to the (M+1)th cycle) for processing. If the business event corresponding to the Mth order occurs after the payment confirmation information is generated at time 650 and before the start of the (M+2)th cycle, the electronic device 101 may generate second additional accounting event information corresponding to the Mth order. The second additional accounting event information corresponding to the Mth order may be used in the accounting process for the (M+1)th order. In this case, the electronic device 101 may use the second additional accounting event information in the accounting process corresponding to the (M+1)th order only if the Mth order and the (M+1)th order include the same supplier information, unit price information, and item information. Similarly, the first additional accounting event information may be a business event occurring at or before the Mth cycle, for example, at a specified time 610 after the generation of the confirmed payment information included in the (M-1)th cycle. This may also be accounting event information corresponding to a business event corresponding to an order before the Mth order (for example, the (M-1)th order or the (M-2)th order). Based on a comparison result between the time 610 at which the first additional accounting event information was obtained, the order information corresponding to the first additional accounting event information, and the order information for the Mth order, the electronic device 101 may generate payment information based on the first accounting event information and the first additional accounting event information. According to one embodiment, the additional accounting event information may include information on the action type and quantity corresponding to whether it is an outbound event or an inbound event.

FIG7 shows accounting event information generated by electronic devices according to various embodiments.

Referring to Figure 7, Figure 7 can be understood as displaying accounting event information in a table. Referring to Figure 7, accounting event information can be confirmed based on various embodiments for managing payment information for different suppliers with the same accounting cycle. Each cycle (Mth cycle or (M+1)th cycle) included in the "Processing Period" row of Figure 7 can be displayed, with each column corresponding to the accounting event information generated during the corresponding cycle. Each order included in the "Object" row can display either the Mth order corresponding to the Mth cycle or the (M+1)th order corresponding to the (M+1)th cycle.

Referring to FIG7 , each accounting event information can be mapped to a corresponding action type. The action type can include type information used to combine the calculation action of the quantity information included in each accounting event information. Each accounting event information can include a corresponding action type and corresponding quantity information.

In this embodiment, action types can be mapped to accounting event information by corresponding to the event type of business event information. For example, the action type "RECEIVE_TEMP" can be the action type corresponding to a receipt event, while the action type "RELEASE_CONFIRMED" can be the action type corresponding to a shipment event. In the case of a shipment event, the corresponding quantity information can be modified based on the first information received from the supplier, so the action type can be marked with temporary information such as "TEMP". In the case of a shipment event, the corresponding quantity information cannot be modified by the supplier, so the action type can be marked with confirmed information such as "CONFIRMED". That is, the first accounting event information may include information of the action type "RECEIVE_TEMP" or "RELEASE_CONFIRMED" and the corresponding quantity information.

In this embodiment, even if payment has been completed, if a business event occurs afterward, the action type "RECEIVE_TEMP_ADJUST_REVERSE" can be mapped to the accounting event information. That is, when additional accounting event information is generated, information with the action type "RECEIVE_TEMP_ADJUST_REVERSE" can be included. For example, if the business event corresponding to the Mth order occurs after payment (or after payment confirmation information is generated), additional accounting event information corresponding to the Mth order can be generated in the (M+2)th cycle, and the additional accounting event information includes the action type "RECEIVE_TEMP_ADJUST_REVERSE." For example, referring to the fourth supplier, electronic device 101 may, based on the accounting cycle information, identify the accounting event information corresponding to the Mth order as additional accounting event information. This accounting event information corresponds to the "RECEIVE_TEMP" action type generated in the (M+1)th cycle. In response to this additional accounting event information, electronic device 101 may generate another additional accounting event information for the correction value, including the action type "RECEIVE_TEMP_ADJUST_REVERSE."

In an embodiment, electronic device 101 may generate payment information based on one or more first accounting event information. According to one embodiment, the payment information may include total inventory quantity information and action type information. The action type corresponding to the payment information may be defined as "RECEIVE_CONFIRMED." In this case, the action type "RECEIVE_TEMP_REVERSE" may be defined as the quantity information corresponding to the action type "RECEIVE_CONFIRMED," and is auxiliary accounting event information defined to remove the "TEMP" quantity from the calculation. The electronic device 101 may generate payment information based on the first accounting event information corresponding to the inventory receipt event and the first accounting event information corresponding to the inventory shipment event. The payment information includes information of the action type "RECEIVE_CONFIRMED".

In an embodiment, electronic device 101 may generate second accounting event information based on receipt of the first information. The second accounting event information may include information of the action type "RECEIVE_CONFIRMED_ADJUST." The action type "RECEIVE_CONFIRMED_ADJUST" may be an action type that maps a difference value calculated based on supplier supply quantity information and total inventory quantity information corresponding to the payment information. The supplier supply quantity information is confirmed based on the first information. Alternatively, electronic device 101 may obtain information of the difference value based on the first information and generate second accounting event information mapped to the action type "RECEIVE_CONFIRMED_ADJUST." The electronic device 101 can generate confirmed payment information (701) based on the second accounting event information and the payment information. The confirmed payment information can include information on the payment target quantity as the object of payment. The payment target quantity can be determined based on the total inventory quantity and the supplier supply quantity. The electronic device 101 can calculate the total inventory quantity and the supplier supply quantity based on the action type of the payment information and the action type of the second accounting event information, thereby confirming the payment target quantity. The electronic device 101 can provide the confirmed payment information to the supplier management server 104, and the supplier management server 104 completes the payment of the confirmed payment to the supplier based on the confirmed payment information. That is, the confirmed payment can be determined based on the payment target quantity and unit price information. The payment target quantity is confirmed based on the confirmed payment information, and the unit price information is confirmed based on the order information.

FIG8 is a flowchart of the steps for generating sales cost information for electronic devices according to various embodiments.

According to various embodiments, in action S801, the electronic device 101 may generate sales cost information based on the incurred payment information and the confirmed payment information. The sales cost information may include information on the unit amount of the corresponding items purchased from the supplier corresponding to the items sold. According to one embodiment, the unit amount information may correspond to the value obtained by dividing the confirmed payment by the total inventory quantity, and the confirmed payment is confirmed based on the payment target quantity information and the order information. That is, the confirmed payment information is determined based on the payment target quantity information, and the confirmed amount corresponding to the confirmed payment information is paid to the supplier, but the actual inventory quantity corresponding to the incurred payment information, that is, the total inventory quantity, may be different from the payment target quantity information. Therefore, cost of goods sold (COGS) information can be generated based on the relationship between actual inventory quantities and actual confirmed payment amounts. Electronic device 101 can generate unit amount information based on incurred and confirmed payment information, and generate total additional asset quantity information based on unit amount information and total inventory quantity information. For example, COGS information can be generated for each item or for a specified period.

Cost of sales information can be determined by dividing the sum of the base asset's total quantity, the additional asset's total quantity, and the converted asset's total quantity by the sum of the base asset's quantity, the additional asset's quantity, and the converted asset's quantity. A converted asset is an item that is received or sold in response to the receipt or sale of another item (i.e., a converted good). The total asset quantity can be determined by multiplying the item's quantity by its unit price.

The quantity of the base asset can correspond to the total quantity of items remaining after sales during the past period in which COGS information was generated. The total quantity of the base asset can correspond to the total unit price corresponding to the past COGS information multiplied by the total quantity of items remaining (the quantity of the base asset).

The quantity of additional assets can correspond to the total quantity of items received during the current COGS information generation cycle (total received quantity). The total quantity of additional assets can correspond to the unit price of the item purchased from the supplier multiplied by the total received quantity. At this point, electronic device 101 can confirm the quantity of additional assets used to generate COGS information and the total quantity of additional assets based on the incurred payment information and the total payment information.

Cost of sales information can be determined based on the value obtained by dividing the sum of the total quantity of the base asset, the total quantity of the additional asset, and the total quantity of the converted asset by the sum of the quantity of the base asset, the quantity of the additional asset, and the quantity of the converted asset. The electronic device 101 can determine the total unit price used to calculate the cost of sales information based on the value obtained by dividing the sum of the total quantity of the base asset, the total quantity of the additional asset, and the total quantity of the converted asset by the sum of the quantity of the base asset, the quantity of the additional asset, and the quantity of the converted asset. The electronic device 101 can generate the cost of sales information based on the product of the total unit price and the shipment quantity information. The electronic device 101 can provide the generated cost of sales information to the accounting server (S802).

The embodiments of the present invention disclosed in this specification and accompanying drawings are provided merely as specific examples to facilitate explanation of the technical content of the present invention and to aid understanding of the present invention. They are not intended to limit the scope of the present invention. In other words, those skilled in the art will undoubtedly be able to implement other variations based on the technical principles of the present invention. Furthermore, the above-mentioned embodiments may be combined as needed. For example, some embodiments may be combined to implement all embodiments of the present invention as a system.

Furthermore, the system and methods of the present invention can be implemented in the form of program commands that can be executed by various computer mechanisms and recorded in a computer-readable medium.

As described above, in certain aspects, various embodiments of the present invention may be implemented in the form of computer-readable code in a computer-readable recording medium. A computer-readable recording medium is any data storage device that can store data that is accessible by a computer system. Examples of computer-readable recording media may include read-only memory (ROM), random access memory (RAM), compact disk-read-only memory (CD-ROM), magnetic tape, floppy disk, optical data storage devices, and carrier waves (such as those used for data transmission over the Internet). The computer-readable recording medium can also be distributed by computer systems connected to a network, thereby storing and executing computer-readable codes in a distributed manner. In addition, the functional programs, codes, and code segments used to implement various embodiments of the present invention can be easily interpreted by programmers skilled in the art of applying the present invention.

Furthermore, it is understood that the devices and methods of various embodiments of the present invention can be implemented in the form of hardware, software, or a combination of hardware and software. Such software, for example, is not subject to whether it can be deleted or recorded again, and can be stored in a volatile or non-volatile storage device such as a ROM, or a RAM, a memory chip, a device or an integrated circuit memory, or a storage medium such as a compact disk (CD), a DVD (Digital Versatile Disc), a magnetic disk, or a magnetic tape that can be optically or magnetically recorded and read by a machine (e.g., a computer). It is understood that the methods of various embodiments of the present invention can be implemented by a computer including a control unit and a memory, or a vehicle including the memory or computer as described above. Such a memory is an example of a program including commands for implementing the embodiments of the present invention or a storage medium that can be read by a machine suitable for storing the program.

Therefore, the present invention includes a program as code for implementing the apparatus or method described in the scope of the invention application of this specification and a storage medium readable by a machine (such as a computer) storing such a program. Furthermore, such a program can be electronically transferred via any medium that transmits communication signals, such as via a wired or wireless connection, and the present invention appropriately includes their equivalents.

The above description refers to the embodiments of the present invention. However, the embodiments of the present invention disclosed in this specification and the accompanying drawings are merely specific examples to facilitate explanation of the technical content of the present invention and to facilitate understanding of the present invention. They are not intended to limit the scope of the present invention. Furthermore, it should be understood that the embodiments of the present invention described above are merely illustrative, and those skilled in the art will be able to implement various variations and equivalent embodiments based on these embodiments. Therefore, the true scope of technical protection for the present invention should be defined in accordance with the scope of the invention application below.

100: Payment Information Management System 101: Electronic Device 102: Administrator Device 103: Accounting Server 104: Supplier Management Server 210: Input/Output Unit 220: Communication Unit 230: Storage Unit 240: Processor 410: Order Module 420: Inventory Management Module 430: Event Data Module 440: Access Control Module 450: Database 610: Time 620: Time 630: Accounting Date 640: Time 650: Time 701: Confirm Payment Information S301: Action S302: Action S303: Action S304: Action S305: Action S501: Action S502: Action S503: Action S801: Action S802: Action

Figure 1 is a diagram illustrating a payment information management system that can implement various embodiments of a method for managing payment information using an electronic device. Figure 2 is a diagram illustrating the configuration of an electronic device, an administrator device, an accounting server, and a supplier management server according to various embodiments. Figure 3 is a flowchart illustrating the operation of the electronic device managing payment information according to various embodiments. Figure 4 is a diagram illustrating the functional modules included in the electronic device according to various embodiments. Figure 5 is a flowchart illustrating the operation of the electronic device managing payment information based on first information according to various embodiments. Figure 6 illustrates various embodiments of a method for managing payment information based on accounting cycle information. Figure 7 illustrates accounting event information generated by the electronic device according to various embodiments. Figure 8 is a flowchart of the steps involved in generating cost of sales information for electronic devices according to various embodiments.

S301:Action

S302: Action

S303: Action

S304: Action

S305: Action

Claims (13)

A payment information management method for managing payment information for items ordered in an electronic device comprises the following steps: Acquiring business event information including at least order identification information in response to the occurrence of a business event; Generating and storing first accounting event information based on the order information and the business event information, wherein the order information is confirmed based on the order identification information; Providing payment information generated based on accounting cycle information and the first accounting event information to a supplier management server; In response to the provision of the payment information, generating confirmed payment information based on the first information received from the supplier management server, which includes information indicating whether the payment information is approved; Based on the incurred payment information and the confirmed payment information, generate cost of sales information for the items corresponding to the order information for each period; and provide the cost of sales information to the accounting server; wherein, the cost of sales information is determined based on the following calculation: the sum of the total amount of the first asset, the total amount of the second asset, and the total amount of the third asset, and the sum of the quantity of the first asset, the quantity of the second asset, and the quantity of the third asset; The quantity of the first asset corresponds to the total quantity of goods remaining after sales in the cycle preceding the previous cycle, and the total amount of the first asset is determined based on the calculation between the unit price determined in the previous cycle and the quantity of the first asset; The quantity of the second asset corresponds to the total quantity of goods received during the cycle, and the total amount of the second asset is determined based on the calculation between the price information confirmed by the payment information and the confirmed payment information and the quantity of the second asset; wherein the quantity of the third asset corresponds to the total quantity of the exchanged items, and the total amount of the third asset is determined based on an operation between the price information of the exchanged items and the quantity of the third asset; wherein, the exchanged items correspond to items received in response to the sale of another item; wherein, the first accounting event information includes information on the action type corresponding to the business event, quantity information, order identification information, item information, and supplier information confirmed based on the order information; wherein, the payment information is generated by receiving a message queue containing the first accounting event information and considering the action type; wherein, the action type corresponds to the type information marked for each operation of the first accounting event information; The above-mentioned type information is determined by considering whether the above-mentioned first accounting event information has been modified based on the above-mentioned first information. In the payment information management method of claim 1, the business event information includes event type information, quantity information, and order identification information corresponding to the business event. For example, in the payment information management method of claim 2, the event types include incoming events and outgoing events. In the payment information management method of claim 1, the order information includes at least a portion of order item information, supplier information, price information, order quantity information, tax type information, tax rate information, and accounting period information. The payment information management method of claim 1, wherein the providing step further includes the following steps: Confirming the accounting cycle information based on the order information; Confirming whether the accounting date corresponding to the order information has arrived based on the accounting cycle information; and If the accounting date has arrived, generating the payment information based on the stored first accounting event information. The payment information management method of claim 1, wherein the providing step further includes the following steps: Determining the total inventory quantity information corresponding to the order identification information based on the first accounting event information; and Generating payment information based on the total inventory quantity information and the order information. In the payment information management method of claim 6, the step of generating the confirmed payment information further includes the following steps: Generating payment recipient quantity information based on the first information and the total inventory quantity information; and Generating the confirmed payment information based on the payment recipient quantity information and the order information. In the payment information management method of claim 1, the step of generating the confirmed payment information further includes the following steps: Generating second accounting event information based on the first information; and Generating the confirmed payment information based on the payment occurrence information and the second accounting event information. In the payment information management method of claim 8, the step of generating the second accounting event information further includes the following step: Generating the second accounting event information based on the information regarding approval or disapproval of the payment information, wherein the information regarding approval or disapproval of the payment information is confirmed based on the first information. In the payment information management method of claim 8, wherein the first information includes tax invoice information, the step of generating the second accounting event information further includes the following steps: Confirming the supplier's supply quantity information based on the tax invoice information; and Confirming whether the payment information is approved based on a comparison of the supplier's supply quantity information with the payment information. The payment information management method of claim 1 further comprises the following steps: Providing the confirmed payment information to an accounting server. An electronic device comprising: a memory; a transceiver; and a processor; the processor being configured to: obtain business event information including at least order identification information in response to the occurrence of a business event; generate and store first accounting event information based on the order information and the business event information, the order information being confirmed based on the order identification information; provide payment information generated based on accounting cycle information and the first accounting event information to a supplier management server; in response to the provision of the payment information, generate confirmed payment information based on the first information received from the supplier management server, which includes information indicating whether the payment information is approved; Based on the incurred payment information and the confirmed payment information, generate cost of sales information for the items corresponding to the order information for each period; and provide the cost of sales information to the accounting server; wherein, the cost of sales information is determined based on the following calculation: the sum of the total amount of the first asset, the total amount of the second asset, and the total amount of the third asset, and the sum of the quantity of the first asset, the quantity of the second asset, and the quantity of the third asset; The quantity of the first asset corresponds to the total quantity of goods remaining after sales in the cycle preceding the previous cycle, and the total amount of the first asset is determined based on the calculation between the unit price determined in the previous cycle and the quantity of the first asset; The quantity of the second asset corresponds to the total quantity of goods received during the cycle, and the total amount of the second asset is determined based on the calculation between the price information confirmed by the payment information and the confirmed payment information and the quantity of the second asset; wherein the quantity of the third asset corresponds to the total quantity of the exchanged items, and the total amount of the third asset is determined based on an operation between the price information of the exchanged items and the quantity of the third asset; wherein, the exchanged items correspond to items received in response to the sale of another item; wherein, the first accounting event information includes information on the action type corresponding to the business event, quantity information, order identification information, item information, and supplier information confirmed based on the order information; wherein, the payment information is generated by receiving a message queue containing the first accounting event information and considering the action type; wherein, the action type corresponds to the type information marked for each operation of the first accounting event information; The above type of information is determined by considering whether the first accounting event information has been modified based on the first information. A non-transitory computer-readable recording medium records a program for executing the method of claim 1 on a computer.