Lets join efforts
This page is a starting point for collaboration and coordination of community efforts.
iDempiere is widely used - and is being widely developed. Smart guys and persistent teams from different parts of the world are creating new code every day building on the foundation of iDempiere enterprise platform.
They make plans for their efforts. You make plans for yours. Let’s make our plans and efforts visible to each other. Let’s share. Let’s combine our efforts. Let’s avoid duplication of effort.
So, if you plan to start working on some feature or you are already working on it we kindly invite you to:
- Make a proud announcement in our public forum
- Use Joined_Efforts tag there for better searching if you use classic version of Groups. (New version of Groups has a labels functionality still in the works)
- Fill the table below. The Feature status can be any of these values: idea, alpha, beta, in development, stable, POC (proof of concept). The better you explain the goal of the feature, the more likely you are to draw attention from others, so be as specific as possible.
P.S. We assume that doing so you declare your resulting code to be open to the community. Also, we consider this page to be not suitable for sponsor search. For sponsor search you may use Market place page
| Feature you plan to build (purpose, technology, frameworks) | Feature status (idea, alpha, beta, in development) | Your name | Link to your announcement and discussion in our forum |
|---|---|---|---|
| Rest API. There are many REST API plugins available for iDempiere. I think the community should work on stabilizing one and using that one as a standard. | Beta | Diego Ruiz | GitHub repository / Forum |
| Blockchain integration. This Hyperledger Fabric (blockchain for business) integration can give new features for enhanced interoperability privacy, security, traceability and reliability you business. | Alfa | Peter Shepetko | Forum |
| Support for Withholding Tax for partial payments in LCO_Withholdings. For Withholding taxes to be deducted and posted at payment (flag Is Calc On Payment=Y), withholding tax should be calculated proportionally based on partial payment amount or payment schedule. For example:
Vendor invoice = 100 USD WHT = 10%. For a partial payment or a payment schedule 30%+70%, WHT tax for the first payment should be 3 USD, for the second payment 7 USD. |
Alpha | Michael Powacht/CTO Zuellig Industrial | JIRA IDEMPIERE-4720 |
| Invoice Price Variations for Average PO costing method
Currently, the system is designed to post invoice price variations (IPV) occurring between PO and Vendor invoice back into inventory and updates the costing records, which is OK as long as there is sufficient stock coverage and no quantities have been sold to the customer between Material Receipt and the invoice containing price variations. Problems arise if there is insufficient stock coverage and the entire IPV is posted back to inventory. This will distort our Inventory value because the entire IPV will be distributed to the remaining stock quantity. This is an incorrect accounting treatment. What the system should do is to determine how many quantities are still on stock on only allocate the proportional IPV back to inventory while the rest of the IPV shall get posted to a price variation account in the P/L. As an example, the following link explains how this works in an SAP environment: https://help.sap.com/saphelp_46c/helpdata/en/a8/b994d9452b11d189430000e829fbbd/frameset.htm
Matched Invoice NIR = +50 (Not Invoiced Receipts) IC = -60 (Inventory Clearing) INV = (1*[12-10]) = +2 (Inventory Asset) IPV = (4*[12-10]) = +8 (Invoice Price Variance) The resulting Average PO cost would be: Scenario Init: 5 with $50 total value => $10/piece MAP (Moving Average Price or Average PO) After Ship: 1 with $10 total value => $10/piece MAP After Inv: 1 with $12 total value => $12/piece MAP (where $12 is derived from $10 from After Ship + $2 from Matched Invoice inventory adjustment) |
Alpha | Michael Powacht/CTO Zuellig Industrial | JIRA IDEMPIERE-3040 |
| Estimated Landed Cost in local currency (or any other currency)
Currently a landed cost estimate in a purchase order can only be made in the PO's pricelist currency. E.g. if I order a product from my supplier in Europe, it's a EUR pricelist and a landed cost estimate in PO=>sub-tab Estimated Landed Cost only provides an amount field but no currency field which can be changed. However, it is very common that for imported products/POs in foreign currency, the landed costs incur in local currency (not in the POs order currency), including import duty, clearing expenses, import taxes, freight etc. In order to estimate PO landed costs in local currency (or better, in any currency to be more flexible), a currency field should be made available in PO=>sub-tab Estimated Landed Cost where the currency can be changed to whatever the estimated landed costs are going to incur in (operating in Thailand, I'd be selecting currency THB). If this currency also happens to be the currency in any of the accounting schemas the organization is a member of (primary or secondary schema), then the specified estimated amount should be posted "as-is" (w/o further conversions) to GL "Landed Cost Clearing" in that respective schema. |
Alpha | Michael Powacht/CTO Zuellig Industrial | JIRA IDEMPIERE-3427 |
If you are interested in and want to join efforts in any of the above-mentioned projects please don't hesitate to contact the others in their respective announcement forum thread or write them in the support channel in Mattermost telling them what you're interested in, your feedback (can be ideas, design, similar work that you've done).
Really, community-powered enterprise!
