Ginesys version 12.8.0 onward, below mentioned components will have to be present in the Ginesys application server for functioning of Ginesys. These are components that are important for advancement of the .NET technology stack of Ginesys. They have no functional impact and should be installed by your IT administrator before attempting to update to Ginesys version 12.8.0.

1. Windows version 2012 R2 (x64) or above

2. Visual C++ 2015 Redistributable (x64)

3. IIS (Internet Information Services) 8.5 or above

4. .NET 5.0 (x64) hosting bundle to run .NET 5.0 based applications

   1. Download from this link - http://support.ginesys.in/downloads/current/dotnet-hosting-5.0-win.exe

   2. Alternative link from Microsoft Website: https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-aspnetcore-5.0.14-windows-hosting-bundle-installer

   3. Know more about .NET 5.0 features at https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-5

To know more, How to install software component prerequisites for Ginesys 12.8.0

Release Date

May 3, 2022

HO Version

12.8.0

POS Version

2.8.0

Web Database Compatibility Version

1.16

Features & Enhancements

24

Bug Fixes

00

Navigation

5729

Data sync status management has been migrated to Ginesys Web

Ginesys is moving its entire functionality to Web from Windows. Moving Data Sync Status Management to the Ginesys Web is part of the same endeavour. The Data sync related information was already available for viewing, now two more functionalities are available by selecting any Received Data and right clicking it and selecting the option from the available drop-down.

The two available options are -

1. Reprocess failed data

2. Request Resend of Data

Open

2552

ERP & OMS (Browntape) connected app integration

Ginesys has come up with a unique offering wherein, the same stock can be utilized for both, wholesale/distribution and online retail order fulfillment, with the orders getting reserved from the warehouse and fulfilled seamlessly. Brands often struggled with the fulfillment of the online orders due to lack of integration with WMS and/or custom integrations between two partners.

The working flow for the same is as follows: Order Received from Marketplace / Webstore → Order synced to OMS → Order pushed to ERP & Stock reserved → Pick list created → Picking done → Packing & Invoicing done → Shipped

Once the stock is reserved for online retail order, the stock won’t be available for any wholesale/distribution enabling full control in the system.

For more details, please get in touch with your account manager.

2942

E-Commerce Sale: Changes in menu name

Earlier “Fulfilled by“ was used in the menu names like for fulfilled by seller and fulfilled by marketplace. However, with newer business practices, the nomenclature of the menus were conflicting.

For example: For cases where you are sending goods to a marketplace warehouse upfront and marketplace is billing under your GSTIN (on your behalf) when order is received, it was being posted in “fulfilled by seller” which was conflicting.

• Purpose of “Fulfilled by Seller” menu: When the brand is selling goods and brand is liable to pay the output tax, then it should be posted in this menu. So we have renamed this menu to “Billing by Brand“.

• Purpose of “Fulfilled by Marketplace“ menu: When the brand is sending goods to marketplace warehouse, marketplace is billing and marketplace is liable to pay the output tax, then it should be posted in this menu. So we have renamed this menu to “Billing by Marketplace“.

The impact of this change has been added to both menus and import excels.

E-Commerce Sale: Manual scheme document number allowed

We always used to create numbers for the transactions imported or created via excel or UI. But we had this request that many of the non-integrated online sellers didn’t want to create a new number and wanted to use the number which was available/generated in their OMS for accounting and GST returns purposes.

• In UI, the user can select manual numbering and provide the number against which the document needs to be imported.

• In excel, the user can select manual numbering and map the document number column.

Note: For using the manual number, the user needs to first tag the manual numbering scheme to the menu.

Impacted Modules:

• UI / Excel Import: Provisions are done as mentioned above.

• New Public API / ERP <> OMS (Browntape): Always manual.

• Old API (used for existing e-com OMS integrations): Always manual.

2953

E-Commerce Sale: GST credit note numbering enabled for return transactions

Now you can issue GST credit note against B2B online sale returns. Previously, in GST returns, it was handled and added to B2C sales but now it will be posted as credit note.

If GST credit note numbering is selected, system will only allow return items to be populated, no sale items.

Impacted Modules:

• UI / Excel Import: Provisions are done as mentioned above.

• New Public API / ERP <> OMS (Browntape): Always manual numbering and will be considered automatically as a GST Credit Note.

• Old API (used for existing e-com OMS integrations): Always manual numbering and will be considered automatically as a GST Credit Note.

2946

E-Commerce Sale: Transporter accounting now enabled

This change is applicable for scenarios where the brand is shipping using their logistics (not using marketplace logistics) and there is a Cash on Delivery (COD) or Pay on Delivery (POD) transaction.

Current accounting in retail sale used to debit the “MOP Control A/C” or Channel (renamed, details mentioned below separately) even though the amount was to be received from the transporter due to COD/POD. Now while creating the transaction, if COD/POD amount is provided, transporter selection will be mandatory, and the transporter will be debited instead of channel.

There can be partial COD/POD cases as well. In such case, up to the COD/POD amount transporter will be debited, for rest of the sale amount channel will be debited.

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Not possible, works in existing way.

2947

E-Commerce Sale: Delivery details can now be captured

Delivery details can now be captured along-with the retail sale transactions like AWB number, shipping date, delivery date and transporter. These are non-mandatory fields and just for information capturing purposes only.

Impacted Modules:

• UI / Excel Import: Provisions are added while creating the transaction.

• New Public API / ERP <> OMS (Browntape): Logistics update is a separate API which can be consumed after posting invoice.

• Old API (used for existing e-com OMS integrations): Not possible.

2831

E-Commerce Sale: Customer capturing revamp

Customer’s billing and shipping details can be captured separately

Now with this release, billing and shipping details can be captured against each transaction separately. Previously we were only allowing billing details capturing.

Customer mobile number mandatory change

Previously, while doing any retail sale transaction, customer’s mobile number was mandatory but it used to happen that many of the marketplaces didn’t provide the same. This used to create operational challenges wherein dummy customers state wise used to be created for posting inter-state transactions.

We have changed the flow and now with this release, only billing detail’s GST state code is mandatory for inter-state transactions. If customer’s mobile number is provided, we shall create/update the retail customer, else we shall only store the billing and shipping details in the transaction itself.

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Not possible, works in existing way.

2875

E-Commerce Sale: Receiving good and damage returns in separate stock points from UI

We have introduced two more stock points (Return stock point & Damage stock point) at header/document level. In case user is passing return entry then return stock is mandatory and if return item also has damage items in it, damage stock point is also mandatory.

Provision to mark return item as damage is also available at item level.

For example:

If return has been made for an icode A100 (2 qty) where one piece is good and other is damaged then user need to create two line item for the same Icode where one will have damage flag as No and other line will have damage flag as Yes. In this case both Return and Damage stock point shall be compulsory at the document level.

Impacted Modules:

• UI / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Excel Import: Not possible, works in existing way.

• Old API (used for existing e-com OMS integrations): Not possible, works in existing way.

2952

E-Commerce Sale: Shipping / other charges handling as per GST norm (Mixed supply/Composite supply) is now possible from Excel Import / UI

There are multiple ways in which customer want to handle the Shipping/other charges (non-inventory item) in e-com transactions. So we have introduced three parameters at item level namely : Secondary Supply, Taxation Policy, Secondary supply parent Icode.

• Scenario 1 - Treating Shipping/other charges as a separate line item (neither composite supply nor mixed supply)

  • Example: Two items where one item has 5% GST and other has 12% GST, in this case GST rate applied to the HSN of the shipping/other charges (non-inventory item) will be applicable.

  • Previous flow: create a separate line item for such non-inventory item and GST rate will be applied based on HSN code tagged with this item.

  • New flow: The flow is exactly same as previous flow, the only change is user need to pass values in below parameters as,

    • Secondary Supply : Yes

    • Taxation Policy : “I” / As per the Item

    • Secondary supply parent Icode : -NA-

• Scenario 2 - Treating Shipping/other charges as a mixed supply (highest GST tax rate and HSN will be applicable)

  • Example: Two items where one item has 5% GST and other has 12% GST, in this case 12% GST will be applicable for shipping/other charges (non-inv item)

  • Previous flow: This was not currently possible.

  • New flow: User need to pass values in below parameters as,

    • Secondary Supply : Yes

    • Taxation Policy : “M” / As per max primary supply Item

    • Secondary supply parent Icode : -NA-

• Scenario 3 - Treating Shipping/other charges as a composite supply (GST tax rate and HSN of parent item will be applicable)

  • Example: Two items where one item has 5% GST and other has 12% GST, and both item has shipping/other charges (non-inv item). In this case 5% will be applicable for shipping/others of Item 1 and 12% GST will be applicable for shipping/other charges for line item 2.

  • Previous flow: This was not currently possible.

  • New flow: User need to pass values in below parameters as,

    • Secondary Supply : Yes

    • Taxation Policy : “P” / As per parent Supply Item

    • Secondary supply parent Icode : “Parent icode“

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Not possible, works in existing way.

2952

E-Commerce Sale: GST charge in case of Export can now be configured

If you are doing any export transaction, previously for e-com transactions, the system always used to calculate GST. However, there is a concept of LUT which is obtained from Government if the brand doesn’t want to charge GST in the export transactions. If LUT without GST is obtained, system should ideally shouldn’t calculate GST in such e-com export transactions.

Now, with this update, you can mark the LUT status in the GSTIN master. Accordingly while creating e-com transactions, GST calculation will be done.

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Already supported.

2666

E-Commerce Sale: Introduction of Channel Master

Till date, for doing any e-commerce transaction, the user had to create a Sub-Ledger (others) with AR/AP ledger tagged to it. The same used to be displayed under “MOP Control A/C” field. However, the same was not visible in the procurement - service invoice module.

Challenge: Consider a marketplace sale is posted for a mop control a/c. However, we shall receive a commission bill from the marketplace. But in the same sub-ledger that accounting was not possible and the users had to create inter-party journal to set off and derive the net receivable.

Now with this enhancement,

• While doing e-com sale transaction, the user will have to select channel instead of mop control a/c.

• Commission bill can be posted under the same channel SL which automatically gives the net receivable from the channel.

Note: Existing other type of sub-ledger (which has e-com transactions done against them) with AR/AP ledger tagged to it are automatically migrated to the channel class (master).

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Provisions are done as mentioned above.

E-Commerce Sale: Channel wise sales ledger now possible

Previously, e-com sale transaction was done in the “Consignment Sales” ledger tagged in OU which was creating accounting issues. There was no clear segregation on the sales done from POS and the sale done from marketplaces / web store. Now with this release, we have provided “Sales ledger” field in channel master.

If the “Sales ledger” field is provided, the system will post the sale into that “Sales ledger” only instead of OU. This gives a flexibility to the users to maintain even channel wise sales (like amazon, flipkart etc.).

Impacted Modules:

• UI / Excel Import / New Public API / ERP <> OMS (Browntape): Ledger will be populated as per the new flow.

• Old API (used for existing e-com OMS integrations): Ledger will be populated from OU (old flow).

2953

E-Commerce Sale: Configuration added to specify which number to pick for GST returns

Existing working: The number was used while creating the transaction, was picked up for GST return purpose.

• If created via UI or excel import, then Ginesys scheme document number was used.

• If created via API, then marketplace / OMS scheme document number was used.

Changed behaviour:

• Document created using ERP scheme document number - The same number will be used for GST returns.

• Document created using manual number / marketplace number / OMS number -

  • A flag in channel master “Allow ERP to generate auto GST doc number“ has been added.

  • If this flag is set to “Yes”, the system will auto create a number and put in GST doc number field which ultimately will be used for GST returns. However, payment reconciliation can be done based on transaction number itself.

  • There are two system defined scheme numbers for this purpose, i.e., for Tax Invoice and for Credit Note.

E-Commerce Sale: Recalculate tax while posting via API now configurable

Previously, whenever any data was posted in Ginesys via API, the system always used to recalculate the tax. Now we have added a flag in channel master called “Recalculate Tax”. If this flag is enabled, the system will automatically recalculate the tax, else, the system will post the tax values supplied in the API call.

Impacted Modules:

• New Public API / ERP <> OMS (Browntape): Provisions are done as mentioned above.

• Old API (used for existing e-com OMS integrations): Not possible, works in existing way, i.e., always recalculate.

E-Commerce Sale: Additional visible changes applicable only for ERP <> OMS (Browntape) connected app integration

Retail Order

Online e-commerce order is posted into ERP as a Retail Order. Types of retail orders can be New (first sale order), Return, Exchange (Forward order against return).

This is a view only menu as retail orders can be created only via ERP <> OMS (Browntape) connected app API. Reason: An entire workflow is mapped with our OMS platform like reservation, picklist, confirmation, etc. Such operations of retail order is not possible from frontend.

Channel Master → “Is marketplace” field

This field is applicable only when channel is being configured for ERP <> OMS (Browntape) connected app integration.
If this field is set to “No”, then MOP with ledger needs to be specified while creating the channel. The usage of MOP is while pushing own web store’s retail orders which in turn creates deposit journals.

3071

WMS: Introduction of “Packing Bin”

Challenges

Consider a normal order fulfillment process wherein, the stock was reserved, pick list was created and picking was done. Until the packing was done, the system used to show the picked stock in the bin itself. This process led to the following operational challenges:

• Mismatch between book stock and physical stock for the bin (until packing was done).

• “Bin count” module in the mobile app used to disallow counting due to this mismatch and asked the user to wait until it is packed.

• Once picked, if the order needs to be cancelled or kept on hold, the reduction of confirmed quantity used to show the stock back into the original bin whereas the stock is physically lying in the floor.

Solution done

Now when picking is done, the stock will move from the original bin to a “Packing Bin”.
Packing bin is a system virtual bin which shows the pendency to pack.

After picking if you are creating a packet/invoice, the stock will move out from the packing bin. Else, if you need to stop the dispatch, i.e., cancel the order, the stock will be moved to the floor stock-point defined for the organization site. Thereafter, normal Put Away can be done.

3200

WMS: Cancellation process change

Module:
Inventory → WMS → Transaction → Stock Reservation → Action → Cancel

Enhancement Summary:

Cancellation of dispatch can happen during any stage of the processing as per the business demand. Previously, the process flow for cancellation was very tedious but now we have simplified / automated the flow. Scenario wise explanation is mentioned below:

• Scenario 1 - Cancellation before pick list creation

  • Previous flow: Go to reservation list view, select the reservation, click on cancel and do the cancellation as required.

  • New flow:

    • It’s exactly same as previous flow.

    • Only difference is that the cancel reservation window UI has been changed.
      User will have to go to the tab “Available to cancel“ in the reservation cancellation window.
      
      

• Scenario 2 - Cancellation after pick list creation (but not picked/cancelled)

  • Previous flow: Cancel Pick List, then cancel reservation (scenario 1).

  • New flow:

    • It’s exactly same as previous flow.

    • Only difference is that the cancel reservation window UI has been changed. User will have to go to the tab “Available to cancel“ in the reservation cancellation window.
      Note: If the pick List is not cancelled / confirmed, the pick list is considered in a “WIP” stage. So the pick list details will be shown in the reservation cancellation window’s “Pick list in-progress“ tab. The user will first need to cancel the pick list and then proceed with reservation cancellation. We have not automated this due to the fact that pick list might be in the floor and can create operational bottle-necking.
      
      

• Scenario 3 - Cancellation after pick list creation and confirmed

  • Previous flow: Reduce pick list confirm quantity, cancel pick list, cancel reservation (scenario 1), do Take Away (to move to floor), do Put Away

  • New flow:

    • We have automated the entire previous flow and restricted the reduction of pick list confirm quantity (due to movement to packing bin).

    • Now the user just needs to visit the reservation screen, select the reservation and click on cancel.

    • The user will then go to the tab “Confirmed Pick List“, provide quantity to be cancelled and click on “free stock”.

    • The following will get recorded in the system automatically: Pick list confirm cancellation, pick list cancellation, reservation cancellation and movement of stock to floor stock point.

    • User can do Put Away to which ever bin is available.
      
      

• Scenario 4 - Cancellation after pick list creation, confirmed and packed

  • Previous flow: Cancel packet, reduce pick list confirm qty, cancel pick list, cancel reservation, do Take Away (to move to floor), do Put Away

  • New flow:

    • Cancel packet

    • Then follow the new flow of Scenario 3.

WMS: Pick List confirmation and Confirm cancellation user details now captured

Module:
Web Reports → Pick list confirmation history

Enhancement Summary:

Previously, there was no details on who confirmed the pick list, when was the bin-item confirmed etc. which was needed to identify the picker efficiency. So we are now capturing the same in detail. Similarly, pick list confirm cancel details are also being captured now in detail level.

3070

WMS: Bulk pick list user-assignment from list view

Module:
Inventory → WMS → Transaction → Pick List → Action → Bulk Assign

Enhancement Summary:

Now multiple pick list can be selected and assigned to a picker from the pick list view at one go.

WMS: App - Auto save of pick list confirm if all items are picked

Module:
WMS App → Confirm pick list

Enhancement Summary:

Suppose you need to pick 10 pcs of an item from a particular bin. If you have scanned all 10 pcs, there is an expectation to confirm it automatically, else you would need to manually click on save. We have automated this with a setting in app which will only work if marked as “Auto”.

WMS: App - Bin count will now allow physical item save

Module:
WMS App → Bin Count

Enhancement Summary:

Suppose, in books a particular bin is showing x item of 20 pcs. However, physically the bin is empty. Earlier ‘‘Bin Count’’ module did not allow saving the actual physical value that is “0“. It required the User to scan an item. Now, after the version update, users can update “ 0” value through the “ Bin Count ” module.

WMS: App - During Pick List confirmation items may be grouped order wise or item wise

Module:
WMS App → Confirm pick list

Enhancement Summary:

Let’s understand the case first: same bin, same item, 2 orders, same pick list.
Currently, when a user is bulk picking and not segregating destination wise, the user was shown 2 different rows in the bin - item confirmation screen which can now be grouped optionally order wise (2 rows) or item wise (1 row).
Note: By default the flow remains same, i.e., order wise. If required, user can change the view standing on the screen itself.

5556

POS Analytics Designer now provided from POS

Enhancement Summary:

With the release of this version, we have made some changes in the POS Analytics Report management. Please refer the following document for an outline of the objective, the changes that has been done from this version and changes which are coming in future in this regard: Click here.