Multivendor Accounting Commision Invoice, Commision Reports,

Multi-Vendor Feedback
21

I use Multi Vendor CS-Cart, I had no problems with product placement, imports, etc., but when it comes to end of month payments to vendors, I have to do almost everything manually. As Gurdji mentioned, it should be able to produce Vendor commission invoices with orders and commisions. Fortunately there are not many sales yet. If there is an increase, it is not possible to do it this way.

1 Like
22

@CS-Cart_team it is one years since this request was posted…Do you have any news?

23

Hi @gurdji!

Unfortunately there is no news at the moment except that the accounting is being refactored. Slowly, gradually, weighing all the pros and cons and gathering all the valuable feedback you all provide via the forums and Help Desk.

All I can add at the moment is that the new accounting will definitely not be included in the next minor release (4.17.1).

24

why is 4.17.1 so numbered if it is a minor release and where is the next major release?

When paying for support subscription you kind of want them to drop within that paid subscription in case upgrade throws some curve balls!

25

The type of upgrade (major, minor, patch) depends on which number changes between versions. Changes in the first number mean that the new version is a major upgrade. The second is a minor and the last is a patch.

Next major release is currently named as CS-Cart Multi-Vendor Enterprise, and already is available for purchase :slight_smile:

We try our best to make all upgrades stunning, but sometimes some stunning features need more time than one minor release to be fully completed, so we’ve got what we’ve got :slight_smile:

26

I don t see any price or option to purchase CS-Cart Multi-Vendor Enterprise

27

I thought I’d chime in and add a few more things to the discussion.

The terms “major”, “minor”, and “patch” come from Semantic Versioning; we adopted them a long time ago. Semantic Versioning describes a “major” release as something that breaks backward compatibility. So, it’s mostly a technical thing; perhaps we’ll need to revisit how CS-Cart versions are named and numbered at some point.

When we started building CS-Cart Enterpise from scratch using the Laravel framework, it was only fitting to call it “CS-Cart 5” (sometimes at the forums as well). We did it because we knew for a fact that it wouldn’t have backward compatibility. However, CS-Cart and CS-Cart Enterprise are essentially separate products, each with an own team of developers.

Yes, that’s because CS-Cart Multi-Vendor and Multi-Vendor Enterprise are very different products. For now, the only option to purchase Multi-Vendor Enterprise is to contact us through our website.

The best analogy I can give is “a house that you can move into” (CS-Cart Multi-Vendor) vs. “a foundation for a skyscraper” (CS-Cart Multi-Vendor Enterprise). More on that difference in the blog article.

1 Like
28

Returning to the topic of “Accounting” page: we are in fact working on it. Going through all the feedback we’ve accumulated, picking things that absolutely have to be there, figuring out how it all will work together. Hopefully, I’ll be able to show some mockups soon enough.

The “Accounting” page is taking so long because we need to account for a lot of functionality. :sweat_smile: How it works in various scenarios (direct payments, multiparty payments, etc.), with various features of Multi-Vendor, etc.

1 Like
29

Will you take into consideration invoicing system?
To generate proforma, storno invoices, to cancel invoice, serial/number for invoices?
I can provide a document that I created with some functionalities that could be implemented if you are open to this.

30

I can’t make any promises yet, “Accounting” is a big project with quite a few potential tasks. But I’d be happy to take a look at the document you created, and maybe get some inspiration as to how to approach certain tasks. Feel free to PM it to me via the forum, or I can give you an email where to send it.

31

I got caught up in other tasks, but I remember the promise. Here’s my very early work-in-progress take on the “Transactions” page, from the marketplace owner’s point of view (the colors of some numbers will depend on it). At this point, I’m trying to determine what information is required and sufficient on the transaction page. Any feedback is welcome.

accounting-all-transactions
accounting-all-transactions1373×988 53.8 KB

32

Detail is good, balance column recommended (see below).

I like colours, black for placed/owed, red for decrease, green for increase/complete. If this is scheme then for “Plan payment” the amount to marketplace should be black when owned and green when paid and red when deducted, i.e. in current example vendor amount should be red, but when initially owed (mnthly/annual plan “run”, as opposed to payment) both vendor and marketplace fee be black, as is a liability not a payment. Additionally order paid the amount to vendor should be green in example (black when placed is correct).

All currency amounts should have decimals.

“To …” not required/misleading, as sometimes from or owed.

Perhaps a second header row could have (under vendor) icon of truck for shipping and word tax, with these amounts in columns as opposed to sub detail. These amounts italic text (non-bold), with total to vendor bolded. That said phone processing fee not catered for in mock-up and an additional column for that may crowd screen and multiple tax amounts would require drill-down (whereas current mock-up would allow you to show each tax type).

Second header row would also allow “Processor” above fees (indicating payment gateway).

Second header row would also allow “Trans” & “Bal” columns under marketplace. Trans = this transaction & Bal
= marketplace running total liability to all vendors if payments come to marketplace first
= total fees owed on plan related transactions
= total pending to MP if order placed
= total owed to vendor/MP on order paid (depending on MP model)
= total owed to vendor when a withdrawal (orange is good for these)

Placing time of transaction on second row would allow more realestate for aforementioned additional columns.

2 Likes
33

I would also add plan column is nice, but in my view lower priority than suggested columns and as only relevant to paid orders and plan transaction could be a sub row in MP column on those transactions.

1 Like
34

First of all, thank you for taking the time to check out the mock-ups! Many things about them will change (for example, there probably won’t be a separate “Fees” column, although I’ll retain the info somewhere).

If I got this request right, every transaction needs to have the “Balance” column, with vendor’s balance after this transaction. That’s something I can get behind.

I still haven’t done all the math and proper coloring here :sweat_smile: The general idea of the new “Transactions” page is that:

  • The numbers in “Transactions” should always be the same. It doesn’t matter if it’s a marketplace administrator or vendor who’s watching the page.
  • The colors do change depending on who is seeing the page. They help distinguish what’s earned and what’s owed by the one who’s watching the page.

The mock-up above doesn’t have a transaction for the “Direct Customer-to-Vendor Payments” just yet. Once I delve deeper, it might make me reconsider and recolor some things. :slight_smile:

Good catch, they definitely will!

We can cater for it, but only if we consider the “Payment surcharge” from the settings of any payment method a part of the fee.

For example, Stripe Connect (a multiparty payment that splits money between the marketplace and the sellers) does provide the fees it takes. Whereas with “Phone ordering”, there’s no way for CS-Cart to know how you process the payment.

Its main (and only) point is to help explain why a certain sum went to vendor/marketplace as a result of this transaction. Perhaps we won’t need a separate column for that :thinking:

2 Likes
35

P.S. I’m also planning to add a separate tab called “Balance”, to with the list of vendors and what they owe to the marketplace, and vice versa.

3 Likes
36

Before getting to “Balance”, here’s what “Transactions” may look like, from the marketplace owner’s angle.

  • I’m using green for what the marketplace supposedly earned (but not necessarily received yet).
  • Grey are the transactions that didn’t appear on the page before (withdrawals) or the ones that don’t make a difference just yet (unpaid orders).

accounting-transactions
accounting-transactions1100×1100 38.7 KB

2 Likes
37

Been looking into accounting a bit more lately, and determined the 3 tabs that I think might help. Would appreciate your thoughts on them.

  • My post above is for the “Transactions” tab — the balance history for all vendors.

  • This post has two more tabs:

1 Like
38

Hallo Ikoshkin,

Thanks for this mockup; it’s quite ideal. However, I believe there are some crucial elements missing:

  1. Filter & Export Options: There should be comprehensive details for filtering and exporting sales and transactions, covering only sales, only transactions, payment methods, taxes, etc. The export should be possible in both PDF and Excel formats.
  2. Payment Method View: It’s essential to have a column or view that showcases the payment method used for a sale or transaction. This could be card, cash, or any other payment mode available at the respective store.
  3. Currency Decimal Representation: Keep in mind that different regions have distinct currency decimal representations. For instance, the EU uses a comma, while the USA uses a period.
  4. Access Control: It’s crucial to limit access to detailed transaction and sales reports. Only individuals with the requisite permissions should have the ability to view this confidential business information.
  5. Sales Reporting: Sellers often need to document their sales data for tax and compliance reasons. Offering them a streamlined way to filter and export the necessary details will simplify their tasks.
  6. Immutable Statements: The sales and transaction statements should be set in stone, meaning they shouldn’t be alterable.
  7. Returns & Refunds: The report should explicitly highlight any items that were returned, and maybe along with the reasons for those returns.
  8. Voided Transactions: The report should also indicate any transactions that were initiated but subsequently canceled.
  9. Data Export: It’s vital to ensure that data can be exported in machine-readable and standard formats, like PDF, XML, or CSV. This ensures that tax authorities can assess the data when required.
  10. Tax Reporting: The system should be capable of producing reports that align with tax filing requirements.
3 Likes
39

Thank you for detailed feedback! I can’t promise that we’ll manage to implement everything the coming months, but we’ll consider all of it. :slight_smile:

Some of these things you mentioned are already planned (or even exist) in some capacity. For example:

  • The main purpose of the “Transactions” page is to show how a vendor’s balance changed, and why. That’s the part that we intend to make immutable. Any change to the order (such as its cancellation, a refund, etc.) will appear as a new transaction on the “Transactions” page.

  • The current “Accounting” page—even without the changes above—already respects the decimal separator you set for the currency. That should remain the case the new “Transactions” page.

  • For payment methods, I’ve currently listed only payment types (“Paid to marketplace”, “Paid to vendor”, “Multiparty”), because they help explain why the balance changed a certain way.

    • Could you elaborate why you’d like the names of the payment methods? I have my ideas why it could help, but I’d rather hear your thoughts.

  • The “Transactions” doesn’t show too much info about the order. But it does provide a link to each order. It is a form of access control. That way, only those who can view the orders will be able to follow the link and see the details.

My main concern for the “Transactions” page is to find the sweet spot: how much info the page shows, and what info it is. Some of the things you mentioned seem like they may be better suited for “Sales reports” or only for the exported CSV sheets.

40

Dear Ikoshkin,

I genuinely appreciate your feedback and the time taken to share it.

For businesses operating within the EU, particularly those focused on local shops, the documentation of payment methods associated with their sales is of paramount importance for both accounting and tax compliance. Given the diverse business models and types, there are a myriad of payment methods such as cash on delivery, online payments, and card transactions. Ensuring the availability of this data is crucial for comprehensive reporting.

From you response footer, my understanding is that your current focus is primarily on optimizing the transaction page. However, my concerns extend beyond just that; they encompass the transaction page, invoicing details, compliance with taxation and accounting processes, and comprehensive sales reports.

Constructive feedback is the cornerstone of improvement. In this light, I’d like to point out that the software, as it stands, does not adequately cater to the nuanced needs of business sales, transaction compliance, reporting, and information within the EU context. My concerns aren’t rooted in external system integrations but rather in the depth and breadth of data essential for vendors and marketplaces to make informed decisions and generate financial reports. As I have recently soft-launched my project, the looming risk of non-compliance penalties holds me in a state of caution, further underscoring the importance of this ongoing dialogue in this community.

I must acknowledge the positive vibe you convey about ongoing improvements within the software. However, a clearer timeline on these enhancements would be greatly appreciated.

To provide some context regarding the tax and account management system, in countries like Germany, online marketplace operators can be held liable for VAT discrepancies if merchants fail to pay correctly. While EU countries have their individual laws, aligning with Germany’s stipulations could potentially cover the compliance needs of nearly 95% of EU nations, given the overarching similarities.

Here are some pivotal features to consider:

  1. Audit Trail: A comprehensive trail capturing all transactions, inclusive of invoices, payments, and tax computations, is essential. This facilitates issue resolution and ensures a robust record for tax reporting. An accounting page with a filtering option for invoices (for both Admin & Vendor) that encompasses all charges is a must.

  2. Digital Tax Compliance: Beyond traditional tax norms, the software must align with digital tax regulations, like those introduced in Germany, requiring real-time transaction data sharing with tax authorities.

  3. Tax and business Reporting: Both vendors and the marketplace need capabilities to generate detailed tax, transactions and sales reports, encompassing aspects like VAT returns and yearly financial statements. The software should support both automatic and manual report generation based on various transaction timelines (Daily, weekly, monthly, yearly and custom).

  4. Invoicing and Billing: A feature-rich module to generate invoices and bills, detailing transaction date, amount, VAT, commissions, etc., for both buyers and sellers, is indispensable.

I hope this feedback proves beneficial, and I am eager to see how the software evolves to meet these essential requirements. Your dedication to progress is commendable, and I look forward to our continued collaboration.

Warm regards,

3 Likes