COR•REC Service enables plug-in developers to tap into installed plugins through the services offered. This allows developers to envision COR•REC in ways that best support their goals. COR•REC Accounting and COR•REC Inventory have many services available that can be leveraged, helping to make your plug-in more useful and the platform more powerful. COR•REC Service is the glue that will bind others' abilities to yours. Adding your services to your plugin will only make it more valuable. Requesting additional services for CORGROUP plugins is encouraged.
The COR•REC Platform application administrator has total control over which plug-in is allowed to collaborate with another. Through the service system a plug-in requests access to a service it is then up to the administrator to grant access. Once access is granted the service plugin may apply additional conditions to the plugins it allows to request permission. This is not a user-initiated process. A plugin must request a service programmatically through a COR•REC extension.
Both COR•REC Accounting and COR•REC Inventory offer services. The examples described here are both omnidirectional and unidirectional. The examples are not technical but examples presented as scenarios.
Technical is available hereAccount Receivable Invoice opens the invoicing process to collaboration by requesting access to a specific service "Inventory Product". The administrator has granted Account Receivable access to the service.
The user creates a new or opens a retained invoice. This Invoice may contain any number of ad-hoc line items and Inventory products. Keep in mind, that invoicing knows how the service will respond to various actions and requests. The service would have provided the necessary documentation.
Inventory has a collaborative service that allows the actions used in this scenario.
The invoice requests the action COMPOSITE. Inventory Service notes the consumer and then supplies a composite that contains three tabs. Each tab enables the selection of a particular type of Inventory Product. When an invoice requests an inventory product, the service listener fetches the inventory product delivering it to the invoice as a key-values map. The invoice then uses this information to create an invoice item and adds it to the invoice.
When the invoice is posted the INVOICED action is sent to the service. The service responds by making the necessary adjustments to the product's quantity. It then sends a DISPOSE action to the service so that the service can perform any required cleanup.
In this scenario, the invoice system is supplied with what is needed for it to process the movement of a product. The process of creating a product whether it be complex or simple is managed by Inventory.
As-an-aside a plugin developer accessing Accounts Receivable Schedule Service, Account Receivable Account Service and Inventory Product Service could easily create an alternative Invoicing system should one be required to support their software leveraging all aspects of our robust COR•REC Accounting.
In this scenario, the Inventory Product requests all authorized services of a known type. Inventory has no idea what this service does. It just knows that access has been requested and granted to Inventory Product.
Hypothetically a service has been offered called Quality Control. From the Inventory Product record view Quality Control is selected. Inventory collaborates with the service by sending a key value map representing the product. Quality Control takes over from there. From within the Quality Control plugin, the product profile is developed and managed. Inventory needs to know nothing of this process.
In this scenario, a quality control view is opened. The view contains what is required to manage the quality control testing process and stores the results. The service connects the product to the quality control record for future reference.
This service type allows plugin developers to enhance Inventory with specialized functions required by their install base.
There are many different ways in which businesses generate payables. For example, Inventory purchase orders. In this scenario, we will receive items on a purchase order and generate a payable request. The payable created is not executed until authorized from within Account Payable.
Inventory asks for access to Account Payable and the administrator has granted access. The Purchase Order Batch view is open and a Purchase Order is selected. At least one Batch Ticket is created. This is the source record that identifies the uniqueness of the inventory item being received. This may be a partial or complete fulfillment of the ordered amount. The purchase order is right-click selected offering several actions. Two of these actions are relevant here, Create a Payable Voucher and Add a Payable Alert.
Selecting Create Payable Voucher opens a dialog listing all Batches received that have not yet been assigned to a Payable Voucher. Select accept and a Payable Voucher is created. Account Payable now has a record that Inventory has been received and will follow its normal procedure. This action does not post a payable. Posting is exclusively an Account Payable managed action. Selecting Add Payable Alert adds an Accounting Alert indicating that a specific Purchase Order has been received and its status is partial or complete. This selection does not create a voucher it only alerts Account Payable that a specific Purchase Order has been processed.
Account Payable accounts run the gamut. In this scenario, we will isolate those payable accounts that represent shipping companies and those that are authorized suppliers of material. The Inventory Administrator view allows for just this isolation. Inventory asks for access to Account Payable and the administrator has granted access.
The Inventory Administrator view is opened and the shipper panel is propagated with all Payable Accounts. The administrator selects the accounts to designate them as shippers. The same is done in a separate panel for suppliers. In the Purchase Order view only authorized suppliers are available for selection and only authorized shippers are available for delivery. Here Account Payable is unaware of Inventory so there is no predetermined connection only a service. Inventory has not been granted the ability to modify Account Payable accounts at the accounting level but only in the scope of inventory. In fact, there is no service available from accounting that would allow for the modification of payable accounts from an outside plugin.
This is a supplemental service. In this scenario, the Inventory Product requests all authorized services of a known type. The Inventory system does not have any knowledge of the functions provided by these services; it only knows that it has requested access to the Inventory Product and has been granted that access.
For instance, let’s consider a service called Quality Control. When the Quality Control option is selected from the Inventory Product record view, Inventory collaborates with the service by sending a key-value map that represents the product. Quality Control then takes over from that point.
Within the Quality Control plugin, the product profile is developed and managed, and Inventory needs to remain unaware of this process. In this scenario, a quality control view is opened, which contains all the necessary elements to manage the quality control testing process and store the results. The service connects the product to the quality control record for future reference.
This type of service allows plugin developers to enhance Inventory with specialized functions required by their install base.
Reference Links:
COR•REC Service allows you to take advantage of additional plugin module services. Enhance both your work and that of others, adding value for the end user. Focus on your strengths while collaborating with others, seamlessly utilizing their expertise!