Why PDF is not supported anymore in the new POS?

ERPNext
1

I’m playing with the new Point of Sales, and it’s wonderful, but I found a very weird thing!

This new POS introduced a new print format type named JS, this print format is not renderized with wkhtmltopdf, it’s renderized directly on the browser!

Why is that?

Anyway I need to ask, why the number of incompatibilities are increasing too much?

This POS don’t support PDF, is only a small issue, but across the entire system, every new release crash the developer integrations, one example are the apps listed in frappe website, some of they don’t work anymore.

If the purpose of ERPNext team, is gain new developers across the ecosystem, I think is very difficulty defend the system, if the API’s change on each new release!

That’s sounds like a regress to 2011, when I started in this community, when wnframework was not designed to support apps, and the unique possible development method was to make forks and lose days of works solving merge-conflicts, now it’s already in the system and many documentation, videos and tutorials are introduced to explain to who is beginning in the community how they can develop better and stable apps.

I know that ERPNext is a mature product, but is a product with no dead-line too! That’s great, but these small things, are forcing me too just still taking a look into these new amazing features, because in my point of view, ERPNext is losing the maturity of API’s for developers.

Pls ERPNext don’t be Py3.6 with your type annotations and asyncio, be the beauty and simple Py2.x.

4 Likes
2

Maybe its designed to be offline![quote=“max_morais_dmm, post:1, topic:21651”]
That’s sounds like a regress to 2011, when I started in this community, when wnframework was not designed to support apps, and the unique possible development method was to make forks and lose days of works solving merge-conflicts, now it’s already in the system and many documentation, videos and tutorials are introduced to explain to who is beginning in the community how they can develop better and stable apps.
[/quote]

@max_morais_dmm Thanks for bringing this up. I think what we realize is that it is better if ERPNext is one monolithic app with lots of features that users can switch off if not needed.

Start contributing all your extensions to the core with test cases, that will ensure things will not fail anymore!

3

@rmehta I dont know if you remember but 2 years ago, I started discuss into this community to build the integration of ERPNext with salad, to unify the tests, from a user point of view!

Using selenium to test the software, instead of just Make unittests!

Just to you remember ERPNext setup with Salad · GitHub

I openned a discuss here, asking for contribution only to get help define a standard dialect, to write tests into frappe framework.

But no interess emerged from anyone in the community!

When I started this integration, I was with a lot of free time, to work into that, but now the things changed!

The code, that I shared, still being the same code, that I use, to write my own tests, because I still using Frappe V6, because It´s the most stable version that you have made, IMO!

4

I agree, and I got that it´s designed to work into offline, but, has no compatibilty!

When you try create a Print Format template, using JS notation eg {% var customer = doc.customer %}

Jinja gives an error, it should be {% set customer = doc.customer %} !

If you use the same notation that is supported by Jinja, it don’t work, because the templates in the browser don’t use a unified API!

This is only the top of the iceberg! You cant make an incompatible Print Format, for POS, because validations into Jinja, and you can’t make a compatible because , it don’t use jinja!

Sorry, it’s sounds like “Brazilian logic”, where you need Trucks, to transport vagons of Trains to reach the sea, to exportation!

5

Max, I think the community has also grown in the last 2 years! I has this same discussion with @dominik a few days ago and it is what I recommend everyone.

Start with small contributions to the core, if you are building something big, start with something. Selenium testing is still a major TODO in the framework. Maybe writing one simple test would be a starting point.

You have been one of the earliest members of this community (and still one of the most helpful!), would love to see more of your code finding its way back in the core. That will help you get free of it and also let the community maintain it. Just that it can’t come in all at once, we have to do it in small steps.

6

It’s what I’m doing, proof of that is:

  • Error snapshot (that was born as app)
  • Title Links, that is an app (and are being used for some developers including @JoEz, that helped me to increase the madurity of the project!)
  • Print Node Integration, that is used daily by @jpp
    And some others small pieces of code, that I’m detaching from my development environment and sharing!

About tests, one thing that I learned with frappe, is that tests should not be dependand of the framework.
If you see salad, it work, without any trick, and is able to check if the setup of ERPNext is work correctly or not!

Think that the actual scheme of tests is unable, because it misses to tests in the same point of interaction of the user, the browser.

About my apps, I have other apps, to share, like the SOAP Connector, the rule-builder from Coreflow, but I´ll share as apps, until it have maturity to join the framework, that is the case of title-links, I’m not sharing code to take out of a problem, I’m sharing my codes, to help people that are suffering which same things, that I suffer while I code.

In my point of view, @rmehta, if I´ll share a integration that need to be tested, to be improved, I share this as an app, because the user can test, try, and remove that, and go ahead!.

7

I agree user testing is very important, but if you keep in app, you won’t find as many users

That is why we have develop branch. Also all features need to be designed in a way that they are not “mandatory” unless the user wants to use them.

We should also tag a feature as “beta” until it is fully ready to be used.

But, I would strongly recommend addition to the core as the primary strategy. We will raise the standard of code / PR but we need to build as a community.