与Nipendo该架构和平台是从其之上的应用程序中抽象出来的(关于该方法和日本公司历史的额外背景，请参见:Nipendo：在电子发票带领的平台转型的进一步证明）.这有点类似于Intenda已与它的权力下放平台/体系结构启用的，但是是完全不同的比已经做了别人的供应商网络/平台空间，一般来说（除Tradeshift）.
此外，公司在部署或持续使用Nipendo(仅使用业务分析师资源，而不是IT资源)时可以配置的细粒度细节级别，超出了其他供应商网络产品在应用程序端无需进行重大定制的支持。例如，无论后端系统(或P2P系统)如何，组织都可以定义高度特定的容差和路由。
这些可能是基于特定元素发票，类别和地理的给定类型的不只是通过的信息流被触发，但是其他元件（例如，事件之间的时间序列）。Nipendo也可以提醒用户，例如，如果供应商没有对请求进行响应，或者如果活动的其他元件（例如，发布时间表）没有在特定层在供应链中，因为他们应该根据所定义的方案发生。而全部关闭这种情况发生在公司之间，而不是ERP，业务应用程序，甚至是网络上的“应用程序”的网络空间。
您可能会说，这很奇怪，但这将如何影响启用特定应用程序(如P2P功能，包括电子发票)的能力呢?在定位他们的电子发票方法时，Nipendo建议启用这种类型的连接性的传统方法集中在数据库级别的事务映射上。例如，传统的事务映射可能采用将EDI或XML模式从一种格式转换为另一种格式的形式。即使在涉及多对多网络的情况下，供应商或买家与网络之间的“连接”也是一对一的，这意味着模式和系统输出可能被映射为支持多对多连接，但底层系统和业务流程却不是这样。
Nipendo的电子发票的方法通过使更多的不仅仅是基本的翻译，路由和交易验证利用基础平台在网络中发生的“云”。Nipendoenables basic connectivity approaches as well as more advanced transactional, business process validations and changes (e.g., amendments) to occur on the platform level because it is able to abstract all inbound documents and metadata into a persistent, translated and standardized structure It can then push information either into Nipendo’s application, other network “apps,” or a buyer or supplier’s own system.
这种类型的网络驱动的连接性可以在整个源到结算过程的生命周期发生，从上前方出价/确认，然后通过订单处理/履行级联，运输/接收，收讫，发票，和归档处理- 在一层，或许多是必需的。虽然基于平台的方法来连接的潜在用途是无止境的，Nipendo启用了以下的一般连接使用情况至今：询价，采购订单（PO），先进船舶的通知（ASN），送货单，仓单，发票草稿，形式发票，电子发票（信用卡/借记卡），支付通知书，GL信息和供应商主数据。
在接下来的几周，我们将继续在Spend Matters Plus/PRO上对任天堂进行回顾，以比较的方式进一步了解这家供应商的电子发票功能以及他们的网络驱动连接方法。
讨论这一点：